From leifj@mnt.se Wed Jan 2 03:52:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3465B21F9071 for ; Wed, 2 Jan 2013 03:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMYqv1Csezyc for ; Wed, 2 Jan 2013 03:52:51 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CA21F90AF for ; Wed, 2 Jan 2013 03:52:50 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id eg20so5936898lab.30 for ; Wed, 02 Jan 2013 03:52:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=8rp1V1kSi1v6oQ2SY0T9RiY+Bc5CAsqxzKRYoTUmwC8=; b=OrETsZaZI7gngt4Lv5ay+3GQ4MXNEUZJmkZKKVKP6Xl3cqpfj/rSF8FKnm9DfwuSjo 2LI/0gokQ0IRRHdzFbRrELNbPcGC7Ekkyf8cpvdcWj8jbm6qY3GtsOW15mkG3FfXmyOG 7nQ7BW+Qny6GICsXoWJEUV3KB3EDYXMQNkPcOKyDVsuZGkxVwwJ4Lcawm9onHbqh4iqj Og/s5VYBPLePCHHx5SIwxZrIxAwHR0M2lnde4r0cqQ2DS69TIYgRIfG99wuMp8iuqpcD +ds2VCLQzLMAQv3kQrlO+HKdmkCVGlA1jtK+mXq4vCJwOWaihc6rccdEdbneMr3k3qIX pExA== X-Received: by 10.112.11.34 with SMTP id n2mr18498775lbb.100.1357127569896; Wed, 02 Jan 2013 03:52:49 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:e866:6c05:2c66:5bdc? ([2001:6b0:7:0:e866:6c05:2c66:5bdc]) by mx.google.com with ESMTPS id k7sm16005594lbf.4.2013.01.02.03.52.48 (version=SSLv3 cipher=OTHER); Wed, 02 Jan 2013 03:52:49 -0800 (PST) Message-ID: <50E41F8F.4060903@mnt.se> Date: Wed, 02 Jan 2013 12:52:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlJ4NpRZepYsr/hYaPi0vEQaTYOFBLgOgr28H6o7aCIihXDXkBnRZFcW54lvzBnrDhfhzmS Subject: [OAUTH-WG] review http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 11:52:52 -0000 Some comments in the order I discovered them... - the term holder-of-_the_-key (my ascii-emphasis) is used when the normal terminology is just "holder-of-key", not sure what is added by the definite form... - s/incredients/ingredients/g - say "a mechanism for secure and scalable key management" in 1 (1) instead of using the word "dynamic" which is pretty vague. - the wording in 3.1 makes it a bit hard to tell when you're talking about HotK or stock OAUTH. - "profile" seems like too generic term to spend what is essentially a choice of key format. - in the example authz request you should clearly state that the 'id' parameter is use to carry the key identifier (just to improve readability). Perhaps change 'hotk' to 'hotk_id'. - why do key identifiers, profile names etc need their own ABNF (end of 3.1.1)? - when computing the signature, don't you want to hash over the entire request string so that you include the HTTP version? At least in theory the semantics of the method is tied to the version... - what does "put into the body of the HTTP request." mean? Are you using any particular mime-type for instance? - have you investigated the deployability of 3.2.2? I would expect that using signatures (JWS) would be a lot easer to code for in practice. Its a strange world. Cheers Leif From ve7jtb@ve7jtb.com Wed Jan 2 12:42:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42A921F88F1 for ; Wed, 2 Jan 2013 12:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-2.261, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un4e9Xkg5uf3 for ; Wed, 2 Jan 2013 12:42:14 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5721F88EA for ; Wed, 2 Jan 2013 12:42:13 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id a19so11863961qad.20 for ; Wed, 02 Jan 2013 12:42:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=1vAnrvW5G3OBbl/uwEyDZYRSwqSzR395WQF5hFhe6EE=; b=PNCPgKhqUj+DbzvOdGJAvy0iqteuvMoF1aqRfpS1t4lV3OZppRwBcUFAjv+AmR6Rzi Cn4ykOQjxage1iizF0dPntb3m4UCVfUl302+Uq19PA6ZWp0YK9SqUEX6f+ws4SvdtNXD KsaUXE9N3P0B5fmv+ehPHFw/9avnwUHcDEJzwj3vrRxtEfjfn05bTEcwGCzWa1SAUSDR pZW4o0PGf9ZVVtdJ5EMSzszdLs+O4CTi6AxoerOJZwOD8dKwfNDLNEar308k+ToCrpeT 6W0p5TwQJsEPZoZytUXqy6fPxIRGOUYCg3gQmrv3+DsindJX5foPnutMqsRQWAg/ILXR vFrw== X-Received: by 10.49.127.101 with SMTP id nf5mr29948020qeb.20.1357159332368; Wed, 02 Jan 2013 12:42:12 -0800 (PST) Received: from [192.168.1.211] (190-20-59-54.baf.movistar.cl. [190.20.59.54]) by mx.google.com with ESMTPS id l6sm12071526qal.21.2013.01.02.12.42.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 12:42:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B1BB714-12E8-46B9-9B5D-E6F81C7F17D0" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <27E7BEAA-5922-48D4-98B1-C063F2C782F9@adobe.com> Date: Wed, 2 Jan 2013 17:42:01 -0300 Message-Id: References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com> <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com> <-2232710541978003268@unknownmsgid> <27E7BEAA-5922-48D4-98B1-C063F2C782F9@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm6hyWigyW35khYD3a4cGpTSEmT4xpcGQW0+O7W0SIOFcwVvbKnAZ1Y9j1B8rzI3mxYiKW1 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 20:42:17 -0000 --Apple-Mail=_6B1BB714-12E8-46B9-9B5D-E6F81C7F17D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In JWE the bulk encryption algorithms must be AEAD or composites = guaranteeing integrity (AES-CBC + HMAC or AES-GCM. etc) The key wrap/agreement algotithems like RSA-PKCS1-1.5 , AES-KW and = ECDH-ES are a separate issue. The Algorithms for JWE were updated and the reference in JWT to = "AES-128-CBC, and AES-256-CBC" below should now be "A128CBC+HS256, and = A256CBC+HS512" The previous reference was correct, however you needed to look in JWE to = see that the HMAC was required. Now it is part of the composite = algorithm. I am copying Mike Jones the JWT editor so that he can update the JWT = spec with the new algs. The change was relatively recent, thanks for = catching that. John B. On 2012-12-30, at 1:00 PM, Antonio Sanso wrote: > Thanks Nat, >=20 > so I assume [0] is out of date since nether RSA-PKCS1 and AES-* are = not AEAD algorithms as long as I know. >=20 > Quoting: >=20 > "If an implementation provides encryption capabilities, of the JWE > encryption algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES- > 128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be = implemented > by conforming implementations. It is RECOMMENDED that > implementations also support ECDH-ES with 256 bit keys, = AES-128-GCM, > and AES-256-GCM. Support for other algorithms and key sizes is > OPTIONAL." >=20 > Regards >=20 > Antonio >=20 > [0] = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-8 > On Dec 29, 2012, at 7:01 PM, Nat Sakimura wrote: >=20 >>=20 >>=20 >> =3Dnat via iPhone >>=20 >> Dec 29, 2012 19:35=E3=80=81Antonio Sanso = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>=20 >>> Hi Nat, >>>=20 >>> apologies if this sounds trivial but I am trying to understand the = JW* stuff and this mail thread is helping me to clarify some of my = doubts. >>>=20 >>>=20 >>> On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote: >>>=20 >>>> Thanks.=20 >>>>=20 >>>> Just a few things:=20 >>>>=20 >>>> 1. Sign+Encrypt >>>=20 >>> kind of nitpicking here, but would not be better to invert those = terms in order to sound Encrypt+Sign (as long as I know the order = matters here and the only safe way is encrypt than MAC). >>=20 >> No. You should use AEAD algorithms for the integrity protection.=20 >>=20 >> Signing something that you cannot decrypt and verify is pretty = meaningless in the contractual settings.=20 >>=20 >>>=20 >>>>=20 >>>> Sign+Encrypt is useful when you want the signed JWT as a proof of = consent to sign.=20 >>>> It can also exist after being decrypted.=20 >>>> If you just want integrity protection, use JWE.=20 >>>=20 >>> For integrity should not be enough the signature so JWS? >>=20 >> All JWE algorithms are AEAD so JWS signing over JWE is redundant.=20 >>=20 >>>=20 >>> Thanks a lot and regards >>>=20 >>> Antonio >>>=20 >>>>=20 >>>> 2. Alphabetization of the terminology >>>>=20 >>>> That's one way of organizing it.=20 >>>> Another way of organizing it is to lay them out in a semantic = order,=20 >>>> where the preceding definition cannot use the terms defined later.=20= >>>> It is a good way to make sure the consistency, and I probably like = this way better.=20 >>>>=20 >>>> Of the definition themselves, I agree it still lacks bunch of terms = that needs to be defined,=20 >>>> and needs tightening up.=20 >>>>=20 >>>> Best,=20 >>>>=20 >>>> Nat >>>>=20 >>>>=20 >>>> On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones = wrote: >>>> Thanks a bunch for the useful review, Jeff! Responses are inline = in green. >>>>=20 >>>> =20 >>>>=20 >>>> -- = Mike >>>>=20 >>>> =20 >>>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of =3DJeffH >>>> Sent: Tuesday, November 27, 2012 2:23 PM >>>> To: IETF oauth WG >>>> Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 >>>>=20 >>>> =20 >>>>=20 >>>> Hi, at ietf-85 atlanta I agreed to do a review of = draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. = Also, +1 to Hannes' comments. >>>>=20 >>>> =20 >>>>=20 >>>> Overall the spec seems to get its idea across, but is pretty rough. = Part of this is due to the language being convoluted, plus some concepts = are only tacitly described (with clues scattered throughout the spec), = and thus it is difficult to understand without multiple passes of this = spec as well as [JWE] and [JWS]. >>>>=20 >>>> =20 >>>>=20 >>>> For example, a JWT appears to be simply either a JWS or a JWE = containing a JWT Claims Set, but this is not stated until right before = section 3.1 (and it isn't stated that clearly). >>>>=20 >>>> =20 >>>>=20 >>>> OK, I=E2=80=99ll say that earlier and more clearly. >>>>=20 >>>> =20 >>>>=20 >>>> Immediately below are some overall comments, and then below that = some detailed comments on various portions of the spec. I'm not = addressing everything I noticed due to time constraints (apologies). >>>>=20 >>>> =20 >>>>=20 >>>> HTH >>>>=20 >>>> =20 >>>>=20 >>>> =3DJeffH >>>>=20 >>>> ------ >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> JWT terminology: >>>>=20 >>>> =20 >>>>=20 >>>> Some issues seem to me to be caused by defining the JWT to be the = base64url encoded JSON object itself and not having terminology to = clearly refer to its unencoded form. >>>>=20 >>>> =20 >>>>=20 >>>> For example, these two JSON objects together apparently comprise a = (unencoded) JWT.. >>>>=20 >>>> =20 >>>>=20 >>>> {"typ":"JWT", >>>>=20 >>>> "alg":"HS256"} >>>>=20 >>>> =20 >>>>=20 >>>> This is the JWT Header. The base64url encoded version is the = Encoded JWT Header. >>>>=20 >>>> =20 >>>>=20 >>>> {"iss":"joe", >>>>=20 >>>> "exp":1300819380, >>>>=20 >>>> "http://example.com/is_root":true} >>>>=20 >>>> =20 >>>>=20 >>>> This is the JWT Claims Set. >>>>=20 >>>> =20 >>>>=20 >>>> ..but there's no defined way to refer to them given the spec's = terminlogy. >>>>=20 >>>> =20 >>>>=20 >>>> The terms above are already defined in the spec. >>>>=20 >>>> =20 >>>>=20 >>>> Consider terming the above a JWT and its encoded-string form an = Encoded JWT, and define them separately. And then there'll be similar = definitions for JWT Header and JWT Claims Set, e.g., >>>>=20 >>>> =20 >>>>=20 >>>> I disagree with redefining the term =E2=80=9CJWT=E2=80=9D to not = also include the signature. The term =E2=80=9CJWT=E2=80=9D should = continue to refer to the whole thing. >>>>=20 >>>> =20 >>>>=20 >>>> Encoded JWT A JWT that has been encoded according to the >>>>=20 >>>> process defined in Section X. >>>>=20 >>>> =20 >>>>=20 >>>> Encoded JWT Header The encoded-string form of a JWT Header >>>>=20 >>>> =20 >>>>=20 >>>> Encoded JWT Claims Set The encoded-string form of a JWT = Claims Set >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll note that when the JWT is encrypted, a base64url = encoded representation of the JWT Claims Set is never used. (The = encrypted form of them is base64url encoded instead.) >>>>=20 >>>> =20 >>>>=20 >>>> encoded-string form The result of applying Base64url encoding = to an >>>>=20 >>>> input JSON text . >>>>=20 >>>> =20 >>>>=20 >>>> Sometimes he input to the base64url encoding is not JSON =E2=80=93 = for instance signature values or encrypted payloads. >>>>=20 >>>> =20 >>>>=20 >>>> JSON Web Token (JWT) A JWT comprises a JWT Header and a JWT = Claims Set. ... >>>>=20 >>>> =20 >>>>=20 >>>> JWT Header A JSON object that is a component of a JWT. It = denotes the >>>>=20 >>>> cryptographic operations applied to the JWT. ... >>>>=20 >>>> =20 >>>>=20 >>>> JWT Claims Set A JSON object containing a set of claims. ... >>>>=20 >>>> =20 >>>>=20 >>>> This also gets rid of the use of the "A string representing a JSON = object..." >>>>=20 >>>> which I find confusing and potentially misleading (because it is = actually "a Base64url encoding of a JSON object"). >>>>=20 >>>> =20 >>>>=20 >>>> Aah =E2=80=93 I now see that this is the real misunderstanding. = The =E2=80=9Cstring representing a JSON object=E2=80=9D is not the = base64url encoded form =E2=80=93 it=E2=80=99s the string representation = that=E2=80=99s parseable into a JSON object. For instance, it could be = a string such as {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=9D} =E2=80=93= not the base64url encoded version of that string. The reason for the = syntactic construction =E2=80=9Cstring representing a JSON object=E2=80=9D= is that its string representation is distinct from the abstract JSON = object itself. If I insert whitespace after the colon in the string = {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=9D} it would parse to an = equivalent JSON object but it would be a different string = representation. It=E2=80=99s the string representation that is actually = operated on by the JWT/JWS/JWE operations. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll try to make this clearer in the spec. >>>>=20 >>>> =20 >>>>=20 >>>> UTF-8: >>>>=20 >>>> =20 >>>>=20 >>>> UTF-8 is mentioned in lots of places. It could probably be stated = once up near >>>>=20 >>>> the beginning of the spec that all the JSON text is UTF-8 encoded, = and all the >>>>=20 >>>> JSON strings are UTF-8 encoded. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll see if I can figure out how to do this without = introducing ambiguity. >>>>=20 >>>> =20 >>>>=20 >>>> Semantics, profiles and relationship to SAML: >>>>=20 >>>> =20 >>>>=20 >>>> The spec does not define any overall JWT semantics (i.e., what any = given JWT >>>>=20 >>>> /means/). Semantics are only defined in context of each individual = Reserved >>>>=20 >>>> Claim Name. >>>>=20 >>>> =20 >>>>=20 >>>> Thus any application of JWTs will need to profile the JWT spec: = specifying the >>>>=20 >>>> claim set(s) contents, and the overall semantics of the resultant = JWT(s). This >>>>=20 >>>> is not explicitly explained in the JWT spec. >>>>=20 >>>> =20 >>>>=20 >>>> Can you suggest some language you=E2=80=99d like to see added about = this? >>>>=20 >>>> =20 >>>>=20 >>>> In terms of SAML, Appendix B should refer to SAML assertions rather = than saml >>>>=20 >>>> tokens. Also, I'm not sure SAML assertions inherently have more = expressivity >>>>=20 >>>> than JWTs. They do have more pre-defined structure and semantics. >>>>=20 >>>> =20 >>>>=20 >>>> OK >>>>=20 >>>> =20 >>>>=20 >>>> Syntactically, it seems one can encode pretty much anything in = whatever amount >>>>=20 >>>> in a JWT (one can do the same with SAML assertions), and thus = theoretically JWTs >>>>=20 >>>> could be used to accomplish the same things as SAML assertions. >>>>=20 >>>> =20 >>>>=20 >>>> Semantically, SAML assertions are explicitly statements made by a = system entity >>>>=20 >>>> about a subject. But by default, a JWT is empty, and has no = semantics (this >>>>=20 >>>> isn't stated explicitly). All semantics defined in the JWT spec are = particular >>>>=20 >>>> to individual reserved claims, but all reserved claims are = optional. Thus an >>>>=20 >>>> application of JWTs to use cases also apropos for SAML assertions = will require >>>>=20 >>>> arguably more profiling than that needed to apply SAML assertions. >>>>=20 >>>> =20 >>>>=20 >>>> All true. However once you add an issuer and a principal, then = you=E2=80=99re back to the JWT being statements made by an entity about = a subject. Again, if there is language you believe should be added in = that regard, please let me know. (BTW, one such usage profile is in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03. Another is = in http://openid.net/specs/openid-connect-messages-1_0.html#id_token.) >>>>=20 >>>> =20 >>>>=20 >>>> The token size & complexity comparison seems nominally fine. >>>>=20 >>>> =20 >>>>=20 >>>> Some detailed-but-rough comments and musings on portions of the = spec as I was >>>>=20 >>>> reading through it... >>>>=20 >>>> =20 >>>>=20 >>>> > 2. Terminology >>>>=20 >>>> =20 >>>>=20 >>>> terminology is not alphabetised! >>>>=20 >>>> =20 >>>>=20 >>>> No, it=E2=80=99s in a top-down descriptive order. Is there a = requirement in IETF specs that the terminology be alphabetized? >>>>=20 >>>> =20 >>>>=20 >>>> "claim", "claims", "token" should be defined in terminology >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll add a definition for =E2=80=9Cclaim=E2=80=9D. = =E2=80=9Ctoken=E2=80=9D should actually probably become =E2=80=9Csecurity = token=E2=80=9D, with a definition of the term. >>>>=20 >>>> =20 >>>>=20 >>>> suggestion: >>>>=20 >>>> =20 >>>>=20 >>>> Claim: an assertion of something as a fact. Here, claims are >>>>=20 >>>> name and value pairs, consisting of a Claim Name and a >>>>=20 >>>> Claim Value. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > JSON Web Token (JWT) >>>>=20 >>>> =20 >>>>=20 >>>> is jwt always a "string" or is it string (only) when it's been = serialized >>>>=20 >>>> into one? >>>>=20 >>>> =20 >>>>=20 >>>> It=E2=80=99s always the string representation of the serialized = parts. >>>>=20 >>>> =20 >>>>=20 >>>> > A string representing a set of claims as a = JSON >>>>=20 >>>> > object that is digitally signed or MACed and/or encrypted. >>>>=20 >>>> =20 >>>>=20 >>>> is it more that it's a set of claims encoded as a JSON object >>>>=20 >>>> that is string-serialized? >>>>=20 >>>> =20 >>>>=20 >>>> No, per my earlier comments >>>>=20 >>>> =20 >>>>=20 >>>> is it /not/ a JWT by definition if it is not ((signed or = unmac'd) and/or >>>>=20 >>>> encrypted) ? No, because there are Plaintext JWTs, but they = aren't in >>>>=20 >>>> terminology (probably should be). >>>>=20 >>>> =20 >>>>=20 >>>> Good catch >>>>=20 >>>> =20 >>>>=20 >>>> "parts" in JWT definition is unclear >>>>=20 >>>> are "parts" json objects or arrays unto themselves ? >>>>=20 >>>> =20 >>>>=20 >>>> The parts are all base64url encoded values. I=E2=80=99ll review = this terminology usage to see if it can be clarified. >>>>=20 >>>> =20 >>>>=20 >>>> the definition assumes knowledge that's presented later. perhaps = needs fwd >>>>=20 >>>> reference(s), or perhaps better is to not present as much = technical detail >>>>=20 >>>> in the definitions. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll review >>>>=20 >>>> =20 >>>>=20 >>>> > JWT Claims Set >>>>=20 >>>> =20 >>>>=20 >>>> similar comments as to JSON Web Token (JWT) >>>>=20 >>>> =20 >>>>=20 >>>> the definition says how it is encoded and encrypted, but not how = claims are >>>>=20 >>>> mapped into a JSON object >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> should probably be simply: >>>>=20 >>>> =20 >>>>=20 >>>> JWT Claims Set: A set of claims expressed as a JSON object, = where each >>>>=20 >>>> claim is an object member (i.e., a name/value pair). A claim = may have >>>>=20 >>>> a JWT Claims Set as a value. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll look into moving the definition in this direction. = What you=E2=80=99re missing in the above, though, is the distinction = between the string representing the JSON object and the abstract JSON = object. We want the former. >>>>=20 >>>> =20 >>>>=20 >>>> > Claim Name The name of a member of the JSON object = representing a >>>>=20 >>>> > JWT Claims Set. >>>>=20 >>>> =20 >>>>=20 >>>> should probably be simply: >>>>=20 >>>> =20 >>>>=20 >>>> Claim Name The name portion of a claim, expressed as a JSON = object member >>>>=20 >>>> name. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > Claim Value The value of a member of the JSON object = representing a >>>>=20 >>>> > JWT Claims Set. >>>>=20 >>>> =20 >>>>=20 >>>> should probably be simply: >>>>=20 >>>> =20 >>>>=20 >>>> Claim Value The value portion of a claim, expressed as a JSON = object member >>>>=20 >>>> value. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ll look into moving the definitions in this direction.=20 >>>>=20 >>>> =20 >>>>=20 >>>> > 3. JSON Web Token (JWT) Overview >>>>=20 >>>> =20 >>>>=20 >>>> > The bytes of the UTF-8 representation of the JWT Claims Set = are >>>>=20 >>>> > digitally signed or MACed in the manner described in JSON Web >>>>=20 >>>> > Signature (JWS) [JWS] and/or encrypted in the manner described = in >>>>=20 >>>> > JSON Web Encryption (JWE) [JWE]. >>>>=20 >>>> =20 >>>>=20 >>>> s/ and/or encrypted / or encrypted and signed / >>>>=20 >>>> =20 >>>>=20 >>>> I think you mean =E2=80=9Cencrypted and integrity protected=E2=80=9D = rather than =E2=80=9Cencrypted and signed=E2=80=9D, right? >>>>=20 >>>> =20 >>>>=20 >>>> > The contents of the JWT Header describe the cryptographic = operations >>>>=20 >>>> > applied to the JWT Claims Set. If the JWT Header is a JWS = Header, the >>>>=20 >>>> > claims are digitally signed or MACed. If the JWT Header is a = JWE >>>>=20 >>>> > Header, the claims are encrypted. >>>>=20 >>>> =20 >>>>=20 >>>> What if a JWT is signed AND encrypted? Hm, from my looking at JWS = and JWE >>>>=20 >>>> specs, it seems that in that case one uses JWE because that = encompasses both >>>>=20 >>>> encrypt & sign. >>>>=20 >>>> =20 >>>>=20 >>>> No, actually JWE just provides an integrity check =E2=80=93 not a = signature. If you want a signature, you need to use JWS. They can (and = often are) used in a nested fashion. >>>>=20 >>>> =20 >>>>=20 >>>> > A JWT is represented as a JWS or JWE. The number of parts is >>>>=20 >>>> > dependent upon the representation of the resulting JWS or JWE. >>>>=20 >>>> =20 >>>>=20 >>>> Does the above mean to say.. >>>>=20 >>>> =20 >>>>=20 >>>> A JWT consists of a JWS or JWE object, which in turn conveys = the JWT >>>>=20 >>>> Claims Set. In the case of a JWS, the JWT Claims Set is the JWS >>>>=20 >>>> Payload. In the case of a JWE, the JWT Claims Set is the input >>>>=20 >>>> Plaintext. >>>>=20 >>>> =20 >>>>=20 >>>> Yes. Although this is missing the fact that nested = signing/encryption may be employed. >>>>=20 >>>> =20 >>>>=20 >>>> > 4. JWT Claims >>>>=20 >>>> > >>>>=20 >>>> > >>>>=20 >>>> > The JWT Claims Set represents a JSON object whose members are = the >>>>=20 >>>> > claims conveyed by the JWT. The Claim Names within this = object MUST >>>>=20 >>>> > be unique; JWTs with duplicate Claim Names MUST be rejected. >>>>=20 >>>> =20 >>>>=20 >>>> does the above mean to say claim names must be unique amongst the = set of claim >>>>=20 >>>> names within any given JWT Claims Set ? If so, that's only implied = by the above >>>>=20 >>>> but should be stated explicitly; as it is, the above is ambiguous. >>>>=20 >>>> =20 >>>>=20 >>>> OK >>>>=20 >>>> =20 >>>>=20 >>>> > 4.2. Public Claim Names >>>>=20 >>>> > >>>>=20 >>>> > >>>>=20 >>>> > Claim names can be defined at will by those using JWTs. = However, in >>>>=20 >>>> =20 >>>>=20 >>>> s/Claim names/Public claim names/ >>>>=20 >>>> =20 >>>>=20 >>>> > order to prevent collisions, any new claim name SHOULD either = be >>>>=20 >>>> > registered in the IANA JSON Web Token Claims registry Section = 9.1 or >>>>=20 >>>> > be a URI that contains a Collision Resistant Namespace. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> why should a claim name be a URI if I wish to make use of Collision = Resistant >>>>=20 >>>> Namespaces? For example, if I simply use say UUIDs as claim = names.. >>>>=20 >>>> =20 >>>>=20 >>>> {"iss":"joe", >>>>=20 >>>> "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"} >>>>=20 >>>> =20 >>>>=20 >>>> ..it will be universally unique provided I minted it appropriately = (no URI >>>>=20 >>>> syntax is needed). >>>>=20 >>>> =20 >>>>=20 >>>> Fair enough. I=E2=80=99ll try to generalize the language. >>>>=20 >>>> =20 >>>>=20 >>>> > 4.3. Private Claim Names >>>>=20 >>>> > >>>>=20 >>>> > >>>>=20 >>>> > A producer and consumer of a JWT may agree to any claim name = that is >>>>=20 >>>> > not a Reserved Name Section 4.1 or a Public Name Section 4.2. = Unlike >>>>=20 >>>> > Public Names, these private names are subject to collision and = should >>>>=20 >>>> > be used with caution. >>>>=20 >>>> =20 >>>>=20 >>>> it seems private claim names are only subject to collision if the = implementers >>>>=20 >>>> don't make appropriate use of Collision Resistant Namespaces, i.e. = they "can be" >>>>=20 >>>> subject to collision. >>>>=20 >>>> =20 >>>>=20 >>>> True >>>>=20 >>>> =20 >>>>=20 >>>> the above two sections use "public" and "private" as distinguishing = factors, but >>>>=20 >>>> it seems to me the distinguishing factor (given how the above is = written) is >>>>=20 >>>> more whether Collision Resistant Namespaces are employed or not. >>>>=20 >>>> =20 >>>>=20 >>>> Yes, although using a collision resistant namespace effectively = makes them public, as we=E2=80=99re using the term >>>>=20 >>>> =20 >>>>=20 >>>> An implied aspect of public claim names seems to be that it is = assumed that they >>>>=20 >>>> are publicly listed/documented/leaked, thus the "public" moniker, = and hence >>>>=20 >>>> ought to be universally unique as a matter of course. >>>>=20 >>>> =20 >>>>=20 >>>> and "private" ones seem to be assumed to be obfuscated to all but = the agreeing >>>>=20 >>>> parties? Or they are "private" in only the sense that they are = created in the >>>>=20 >>>> context of a private arrangement? >>>>=20 >>>> =20 >>>>=20 >>>> Private in that they are created in the context of a private = arrangement. I=E2=80=99ll try to clarify this point. Facebook could = define how they=E2=80=99re going to use the =E2=80=9Cid=E2=80=9D claim = very publicly, and yet it would still be a private claim if not = registered with IANA. >>>>=20 >>>> =20 >>>>=20 >>>> > >>>>=20 >>>> > 7. Rules for Creating and Validating a JWT >>>>=20 >>>> > >>>>=20 >>>> > >>>>=20 >>>> > To create a JWT, one MUST perform these steps. The order of = the >>>>=20 >>>> > steps is not significant in cases where there are no = dependencies >>>>=20 >>>> > between the inputs and outputs of the steps. >>>>=20 >>>> > >>>>=20 >>>> > 1. Create a JWT Claims Set containing the desired claims. = Note that >>>>=20 >>>> > white space is explicitly allowed in the representation = and no >>>>=20 >>>> > canonicalization is performed before encoding. >>>>=20 >>>> =20 >>>>=20 >>>> I presume the rationale for allowing white space is that JSON = objects are >>>>=20 >>>> unordered (and can contain arbitrary whitespace), thus simple = buffer-to-buffer >>>>=20 >>>> comparisons between serialized objects cannot be reliably = performed. If so this >>>>=20 >>>> should be explicitly stated. >>>>=20 >>>> =20 >>>>=20 >>>> Actually, it=E2=80=99s to avoid canonicalization. I=E2=80=99ll = reread the spec to see if we=E2=80=99ve stated that clearly or not. >>>>=20 >>>> =20 >>>>=20 >>>> It seems that member/value-by-member/value comparisons must always = be done, by >>>>=20 >>>> parsing the JSON objects and extracting all members and values, = this should be >>>>=20 >>>> stated explicitly in the spec. >>>>=20 >>>> =20 >>>>=20 >>>> I found meager jwt comparison instructions at the very end of = Section 7. it >>>>=20 >>>> should probably be its own subsection. It should probably = explicitly say that >>>>=20 >>>> JWTs need to be parsed into their constituent components, and the = latter must be >>>>=20 >>>> individually examined/compared. >>>>=20 >>>> =20 >>>>=20 >>>> We tried to cover this in the end of section 7, starting with the = sentence =E2=80=9CProcessing a JWT inevitably requires comparing known = strings to values in the token=E2=80=9D, which says how these = comparisons must be performed. I agree that this should become its own = subsection. I don=E2=80=99t understand your remark about constituent = components. Can you clarify? >>>>=20 >>>> =20 >>>>=20 >>>> > Comparisons between JSON strings and other Unicode strings = MUST be >>>>=20 >>>> > performed as specified below: >>>>=20 >>>> =20 >>>>=20 >>>> this comparison algorithm seems to be attempting to allow for = comparison of >>>>=20 >>>> UTF-8 encoded JSON strings with other unicode strings in any of the = unicode >>>>=20 >>>> encoding formats, but only implies that; it should be stated. >>>>=20 >>>> =20 >>>>=20 >>>> Good >>>>=20 >>>> =20 >>>>=20 >>>> > >>>>=20 >>>> > 1. Remove any JSON applied escaping to produce an array of = Unicode >>>>=20 >>>> > code points. >>>>=20 >>>> =20 >>>>=20 >>>> I don't think (1) is correct. A JSON string is by default encoded = in UTF-8. A >>>>=20 >>>> UTF-8 encoded string is not "an array of Unicode code points" (its = a sequence of >>>>=20 >>>> code units, which must be decoded into code points), i think a step = is missing >>>>=20 >>>> here.. >>>>=20 >>>> =20 >>>>=20 >>>> 1. Remove any JSON escaping from the input JSON string. >>>>=20 >>>> =20 >>>>=20 >>>> 1.a convert the string into a sequence of unicode code points. >>>>=20 >>>> =20 >>>>=20 >>>> How about =E2=80=9CRemove any JSON escaping from the input JSON = string and convert the string into a sequence of Unicode code points=E2=80= =9D? >>>>=20 >>>> =20 >>>>=20 >>>> ..and then compare code point-by-code point. This overall algorithm = /seems/ ok, >>>>=20 >>>> but I'm not sure, it seems there's rationale that's not expressed, = eg for >>>>=20 >>>> excluding use of Unicode Normalization [USA15]. Also the alg is = incomplete in >>>>=20 >>>> that it doesn't stipulate converting the "other unicode string" = into a sequence >>>>=20 >>>> of code points. >>>>=20 >>>> =20 >>>>=20 >>>> Fair enough >>>>=20 >>>> =20 >>>>=20 >>>> > 10. Security Considerations >>>>=20 >>>> > >>>>=20 >>>> > >>>>=20 >>>> > All of the security issues faced by any cryptographic = application >>>>=20 >>>> > must be faced by a JWT/JWS/JWE/JWK agent. Among these issues = are >>>>=20 >>>> > protecting the user's private key, preventing various attacks, = and >>>>=20 >>>> > helping the user avoid mistakes such as inadvertently = encrypting a >>>>=20 >>>> > message for the wrong recipient. The entire list of security >>>>=20 >>>> > considerations is beyond the scope of this document, but some >>>>=20 >>>> > significant concerns are listed here. >>>>=20 >>>> > >>>>=20 >>>> > All the security considerations in the JWS specification also = apply >>>>=20 >>>> > to JWT, as do the JWE security considerations when encryption = is >>>>=20 >>>> > employed. In particular, the JWS JSON Security Considerations = and >>>>=20 >>>> > Unicode Comparison Security Considerations apply equally to = the JWT >>>>=20 >>>> > Claims Set in the same manner that they do to the JWS Header. >>>>=20 >>>> > >>>>=20 >>>> =20 >>>>=20 >>>> dunno if you can get away with sec cons wholly in other docs, and = I'm not sure >>>>=20 >>>> it's appropriate given that JWTs are a profile of JWE or JWS. >>>>=20 >>>> =20 >>>>=20 >>>> That was the approach that Sean had suggested. If there other = things you think we should specifically add, however, please let me = know. >>>>=20 >>>> =20 >>>>=20 >>>> above needs editorial polish -- there aren't any "significant = concerns" >>>>=20 >>>> actually listed here. >>>>=20 >>>> =20 >>>>=20 >>>> True enough >>>>=20 >>>> =20 >>>>=20 >>>> --- >>>>=20 >>>> end >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> OAuth mailing list >>>>=20 >>>> OAuth@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6B1BB714-12E8-46B9-9B5D-E6F81C7F17D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = JWE the bulk encryption algorithms must be AEAD or composites = guaranteeing integrity (AES-CBC + HMAC or AES-GCM. = etc)

The key wrap/agreement algotithems like = RSA-PKCS1-1.5 , AES-KW and ECDH-ES are a separate = issue.

The Algorithms for JWE were updated and = the reference in JWT to "AES-128-CBC, and AES-256-CBC" below should = now be "A128CBC+HS256,  and = A256CBC+HS512"

The previous reference was = correct, however you needed to look in JWE to see that the HMAC was = required.  Now it is part of the composite = algorithm.

I am copying Mike Jones the JWT = editor so that he can update the JWT spec with the new algs.  The = change was relatively recent, thanks for catching = that.

John = B.


On 2012-12-30, at 1:00 = PM, Antonio Sanso <asanso@adobe.com> = wrote:

Thanks = Nat,

so I assume [0] is out of date since = nether RSA-PKCS1 and AES-* are not AEAD algorithms as long as I = know.

Quoting:

"If an implementation provides encryption capabilities, of the = JWE
   encryption algorithms, only =
RSA-PKCS1-1.5 with 2048 bit keys, AES-
   128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be implemented
   by conforming implementations.  It is RECOMMENDED that
   implementations also support ECDH-ES with 256 bit keys, AES-128-GCM,
   and AES-256-GCM.  Support for other algorithms and key sizes is
   =
OPTIONAL."

Regards

Anton= io

[0] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#secti= on-8
On Dec 29, 2012, at 7:01 PM, Nat Sakimura = wrote:



=3Dnat via = iPhone

Dec 29, 2012 19:35=E3=80=81Antonio Sanso <asanso@adobe.com> = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

Hi Nat,

apologies = if this sounds trivial but I am trying to understand the JW* stuff and = this mail thread is helping me to clarify some of my = doubts.


On Dec 20, 2012, at 7:12 AM, Nat Sakimura = wrote:

Thanks. 

Just a few = things: 

1. Sign+Encrypt

kind of nitpicking here, but would not = be better to invert those terms in order to sound Encrypt+Sign (as long = as I know the order matters here and the only safe way is encrypt than =  MAC).

No. You should use AEAD = algorithms for the integrity = protection. 

Signing something that you cannot = decrypt and verify is pretty meaningless  in the contractual = settings. 



Sign+Encrypt is useful when you want = the signed JWT as a proof of consent to sign. 
It can = also exist after being decrypted. 
If you just want integrity protection, use = JWE. 

For integrity should = not be enough the signature so JWS?

All = JWE algorithms are AEAD so JWS signing over JWE is = redundant. 


Thanks a lot = and regards

Antonio


2. Alphabetization of the = terminology

That's one way of organizing = it. 
Another way of organizing it is to lay them out in a = semantic order, 
where the preceding definition cannot use the terms defined = later. 
It is a good way to make sure the consistency, = and I probably like this way better. 

Of = the definition themselves, I agree it still lacks bunch of terms that = needs to be defined, 
and needs tightening = up. 

Best, 

Na= t


On Thu, Dec = 20, 2012 at 9:14 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks a bunch for the useful review, Jeff!  Responses are = inline in = green.

 

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

 

-----Original = Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =3DJeffH
Sent: Tuesday, November 27, 2012 2:23 PM
To: IETF oauth WG
Subject: [OAUTH-WG] review: = draft-ietf-oauth-json-web-token-05

 

Hi, = at ietf-85 atlanta I agreed to do a review of = draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. = Also, +1 to Hannes' = comments.

 

Overall the = spec seems to get its idea across, but is pretty rough. Part of this is = due to the language being convoluted, plus some concepts are only = tacitly described (with clues scattered throughout the spec), and thus = it is difficult to understand without multiple passes of this spec as well as [JWE] and = [JWS].

 

For example, a JWT = appears to be simply either a JWS or a JWE containing a JWT Claims Set, = but this is not stated until right before section 3.1 (and it isn't = stated that clearly).

 

OK, I=E2=80=99ll say that earlier = and more clearly.

 

Immediately = below are some overall comments, and then below that some detailed = comments on various portions of the spec.  I'm not addressing = everything I noticed due to time constraints = (apologies).

 

HTH<= /u>

 

=3DJeffH

------

 

 

J= WT terminology:

 

Some = issues seem to me to be caused by defining the JWT to be the base64url = encoded JSON  object itself and not having terminology to clearly = refer to its unencoded = form.

 

For example, these = two JSON objects together apparently comprise a (unencoded) = JWT..

 

   &nb= sp;  = {"typ":"JWT",

       = "alg":"HS256"}

 

This is the JWT Header.  The = base64url encoded version is the Encoded JWT = Header.

 

     = ; {"iss":"joe",

       = "exp":1300819380,

      = "http://example.com/is_root= ":true}

 

This is the JWT Claims = Set.

 

..but there's no defined = way to refer to them given the spec's = terminlogy.

 

The terms above are already = defined in the spec.

 

Consider terming the above = a JWT and its encoded-string form an Encoded JWT, and define them = separately. And then there'll be similar definitions for JWT Header and = JWT Claims Set, e.g.,

 

I disagree with redefining the = term =E2=80=9CJWT=E2=80=9D to not also include the signature.  The = term =E2=80=9CJWT=E2=80=9D should continue to refer to the whole = thing.

 

    Encoded = JWT   A JWT that has been encoded according to = the

       process = defined in Section = X.

 

    = Encoded JWT Header   The encoded-string form of a JWT = Header

 

    = Encoded JWT Claims Set   The encoded-string form of a JWT = Claims Set

 

I=E2=80=99ll note that when the = JWT is encrypted, a base64url encoded representation of the JWT Claims = Set is never used.  (The encrypted form of them is base64url = encoded instead.)

 

    = encoded-string form   The result of applying Base64url = encoding to an

       = input JSON text .

 

Sometimes he input to the = base64url encoding is not JSON =E2=80=93 for instance signature values = or encrypted payloads.

 

    JSON Web = Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set. = ...

 

    = JWT Header  A JSON object that is a component of a JWT. It denotes = the

       cryptographic operations applied to = the JWT.  = ...

 

    = JWT Claims Set  A JSON object containing a set of claims.  = ...

 

This also gets rid of = the use of the "A string representing a JSON object..."

which I find confusing and potentially misleading = (because it is actually "a Base64url encoding of a JSON = object").

 

Aah =E2=80=93 I now see that this = is the real misunderstanding.  The =E2=80=9Cstring representing a = JSON object=E2=80=9D is not the base64url encoded form =E2=80=93 it=E2=80=99= s the string representation that=E2=80=99s parseable into a JSON = object.  For instance, it could be a string such as {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS= 256=E2=80=9D} =E2=80=93 not the base64url encoded version of that = string.  The reason for the syntactic construction =E2=80=9Cstring = representing a JSON object=E2=80=9D is that its string representation is = distinct from the abstract JSON object itself.  If I insert whitespace after the colon in the string = {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=9D} it would parse to an = equivalent JSON object but it would be a different string = representation.  It=E2=80=99s the string representation that is = actually operated on by the JWT/JWS/JWE = operations.

 

I=E2=80=99ll try to make this clearer in the = spec.

 

UTF-8:

 

UTF-8 is mentioned in lots of places. It = could probably be stated once up near

the beginning of the spec that all the JSON text is = UTF-8 encoded, and all the

JSON strings are UTF-8 = encoded.

 

I=E2=80=99ll see if I can figure = out how to do this without introducing = ambiguity.

 

Semantics, profiles and = relationship to SAML:

 

The = spec does not define any overall JWT semantics (i.e., what any given JWT

/means/). Semantics are only defined in context of = each individual Reserved

Claim = Name.

 

Thus any = application of JWTs will need to profile the JWT spec: specifying the

claim set(s) contents, and the overall semantics of = the resultant JWT(s).  This

is not explicitly explained in the JWT = spec.

 

Can you suggest some language = you=E2=80=99d like to see added about this?

 

In terms of SAML, Appendix = B should refer to SAML assertions rather than saml

tokens. Also, I'm not sure SAML assertions = inherently have more expressivity

than JWTs. They do have more pre-defined structure = and semantics.

 

OK

 

Syntactically, it seems one = can encode pretty much anything in whatever amount

in a JWT (one can do the same with SAML = assertions), and thus theoretically JWTs

could be used to accomplish the same things as SAML = assertions.

 

Semantically, = SAML assertions are explicitly statements made by a system entity

about a subject. But by default, a JWT is empty, = and has no semantics (this

isn't stated explicitly). All semantics defined in = the JWT spec are particular

to individual reserved claims, but all reserved = claims are optional. Thus an

application of JWTs to use cases also apropos for = SAML assertions will require

arguably more profiling than that needed to apply = SAML assertions.

 

All true.  However once you = add an issuer and a principal, then you=E2=80=99re back to the JWT being = statements made by an entity about a subject.  Again, if there is = language you believe should be added in that regard, please let me know.  (BTW, one such usage profile is in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  = Another is in = http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)=

 

The token size & = complexity comparison seems nominally = fine.

 

Some = detailed-but-rough comments and musings on portions of the spec as I was

reading through = it...

 

> 2. = Terminology

 

terminology = is not alphabetised!

 

No, it=E2=80=99s in a top-down = descriptive order.  Is there a requirement in IETF specs that the = terminology be alphabetized?

 

"claim", "claims", "token" should be defined in = terminology

 

I=E2=80=99ll add a definition for = =E2=80=9Cclaim=E2=80=9D.  =E2=80=9Ctoken=E2=80=9D should actually = probably become =E2=80=9Csecurity token=E2=80=9D, with a definition of = the term.

 

suggestion:

=

 

      = Claim:  an assertion of something as a fact. Here, claims = are

         = name and value pairs, consisting of a Claim Name and = a

         = Claim = Value.

 

 =

>    JSON Web Token = (JWT)

 

   is jwt = always a "string" or is it string (only) when it's been serialized

into = one?

 

It=E2=80=99s always the string = representation of the serialized parts.

 

>    &= nbsp;           &nb= sp;   A string representing a set of claims as a = JSON

>       object = that is digitally signed or MACed and/or = encrypted.

 

   = is it more that it's a set of claims encoded as a JSON = object

   that is = string-serialized?

 

No, per my earlier comments =

 

   is it /not/ a = JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are = Plaintext JWTs, but they aren't in

terminology (probably should = be).

 

Good = catch

 

   "parts" in JWT = definition is unclear

     are = "parts" json objects or arrays unto themselves = ?

 

The parts are all base64url = encoded values.  I=E2=80=99ll review this terminology usage to see = if it can be clarified.

 

   the = definition assumes knowledge that's presented later. perhaps needs = fwd

   reference(s), or perhaps better is = to not present as much technical detail

   = in the definitions.

 

I=E2=80=99ll = review

 

>    JWT = Claims Set

 

   = similar comments as to JSON Web Token = (JWT)

 

   the = definition says how it is encoded and encrypted, but not how claims are

mapped into a JSON = object

 

 =

should probably be = simply:

 

    = JWT Claims Set: A set of claims expressed as a JSON object, where = each

       claim is = an object member (i.e., a name/value pair). A claim may = have

       a JWT = Claims Set as a value.

 

I=E2=80=99ll look into moving the = definition in this direction.  What you=E2=80=99re missing in the = above, though, is the distinction between the string representing the = JSON object and the abstract JSON object.  We want the former.

 

>    Claim = Name  The name of a member of the JSON object representing = a

>       JWT = Claims Set.

 

should probably be = simply:

 

    = Claim Name  The name portion of a claim, expressed as a JSON object = member

       = name.

=  

 

>  &nbs= p; Claim Value  The value of a member of the JSON object = representing = a

>       JWT = Claims Set.

 

should = probably be = simply:

 

    = Claim Value  The value portion of a claim, expressed as a JSON = object member

       = value.

 

I=E2=80=99ll look into moving the = definitions in this direction. 

 

> 3. JSON Web Token (JWT) = Overview

 

>  &n= bsp; The bytes of the UTF-8 representation of the JWT Claims Set = are

>    digitally signed or MACed = in the manner described in JSON = Web

>    Signature (JWS) [JWS] = and/or encrypted in the manner described = in

>    JSON Web Encryption (JWE) = [JWE].

 

s/ and/or = encrypted / or encrypted and signed = /

 

I think you mean =E2=80=9Cencrypted= and integrity protected=E2=80=9D rather than =E2=80=9Cencrypted and = signed=E2=80=9D, right?

 

>    The = contents of the JWT Header describe the cryptographic = operations

>    applied to the JWT = Claims Set. If the JWT Header is a JWS Header, = the

>    claims are digitally = signed or MACed.  If the JWT Header is a = JWE

>    Header, the claims are = encrypted.

 

What if a JWT = is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE = because that encompasses both

encrypt & = sign.

 

No, actually JWE just provides an = integrity check =E2=80=93 not a signature.  If you want a = signature, you need to use JWS.  They can (and often are) used in a = nested fashion.

 

>    A = JWT is represented as a JWS or JWE.  The number of parts = is

>    dependent upon the = representation of the resulting JWS or JWE.

 

Does the above mean to = say..

 

    = A JWT consists of a JWS or JWE object, which in turn conveys the = JWT

    Claims Set. In the case of a = JWS, the JWT Claims Set is the = JWS

    Payload. In the case of a = JWE, the JWT Claims Set is the = input

    = Plaintext.

 

Yes.  Although this is = missing the fact that nested signing/encryption may be = employed.

 

> 4. JWT = Claims

>

>

=

>    The JWT Claims Set represents a JSON object = whose members are the

>    claims = conveyed by the JWT.  The Claim Names within this object = MUST

>    be unique; JWTs with = duplicate Claim Names MUST be = rejected.

 

does the above = mean to say claim names must be unique amongst the set of claim

names within any given JWT Claims Set ?  If = so, that's only implied by the above

but should be stated explicitly; as it is, the = above is ambiguous.

 

OK

 

> 4.2. Public Claim = Names

>

>

<= p>>    Claim names can be defined at will by those = using JWTs.  However, = in

 

s/Claim names/Public = claim = names/

 

>  &nbs= p; order to prevent collisions, any new claim name SHOULD either = be

>    registered in the IANA = JSON Web Token Claims registry Section 9.1 = or

>    be a URI that contains a = Collision Resistant = Namespace.

 

 =

why should a claim name be a URI if I wish to make use of = Collision Resistant

Namespaces?  For example, if I simply use say = UUIDs as claim = names..

 

   &= nbsp;  = {"iss":"joe",

       = "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}

&= nbsp;

..it will be universally unique provided I minted it = appropriately (no URI

syntax is = needed).

 

Fair enough.  I=E2=80=99ll = try to generalize the language.

 

> 4.3. = Private Claim = Names

>

>

<= p>>    A producer and consumer of a JWT may agree to = any claim name that is

>    not a = Reserved Name Section 4.1 or a Public Name Section 4.2.  = Unlike

>    Public Names, these = private names are subject to collision and = should

>    be used with = caution.

 

it seems private = claim names are only subject to collision if the implementers

don't make appropriate use of Collision Resistant = Namespaces, i.e. they "can be"

subject to = collision.

 

True

 

the above two sections use = "public" and "private" as distinguishing factors, but

it seems to me the distinguishing factor (given how = the above is written) is

more whether Collision Resistant Namespaces are = employed or not.

 

Yes, although using a collision = resistant namespace effectively makes them public, as we=E2=80=99re = using the term

 

An implied aspect of public = claim names seems to be that it is assumed that they

are publicly listed/documented/leaked, thus the = "public" moniker, and hence

ought to be universally unique as a matter of = course.

 

and "private" = ones seem to be assumed to be obfuscated to all but the agreeing

parties?  Or they are "private" in only the = sense that they are created in the

context of a private = arrangement?

 

Private in that they are created = in the context of a private arrangement.  I=E2=80=99ll try to = clarify this point.  Facebook could define how they=E2=80=99re = going to use the =E2=80=9Cid=E2=80=9D claim very publicly, and yet it = would still be a private claim if not registered with = IANA.

 

>

> = 7. Rules for Creating and Validating a = JWT

>

>

= >    To create a JWT, one MUST perform these = steps.  The order of the

>    = steps is not significant in cases where there are no = dependencies

>    between the = inputs and outputs of the = steps.

>

>   = 1.  Create a JWT Claims Set containing the desired claims.  = Note = that

>        = white space is explicitly allowed in the representation and = no

>        canonicalization is = performed before = encoding.

 

I presume the = rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), = thus simple buffer-to-buffer

comparisons between serialized objects cannot be = reliably performed.  If so this

should be explicitly = stated.

 

Actually, it=E2=80=99s to avoid = canonicalization.  I=E2=80=99ll reread the spec to see if we=E2=80=99= ve stated that clearly or not.

 

It = seems that member/value-by-member/value comparisons must always be done, = by

parsing the JSON objects and extracting all members = and values, this should be

stated explicitly in the = spec.

 

I found meager jwt = comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should = probably explicitly say that

JWTs need to be parsed into their constituent = components, and the latter must be

individually = examined/compared.

 

We tried to cover this in the end = of section 7, starting with the sentence =E2=80=9CProcessing a JWT = inevitably requires comparing known strings to values in the token=E2=80=9D= , which says how these comparisons must be performed.  I agree that this should become its own subsection.  I don=E2=80=99t= understand your remark about constituent components.  Can you = clarify?

 

>    = Comparisons between JSON strings and other Unicode strings MUST = be

>    performed as specified = below:

 

this comparison = algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode = strings in any of the unicode

encoding formats, but only implies that; it should = be stated.

 

Good

 

>

>=     1.  Remove any JSON applied escaping to produce = an array of = Unicode

>       = code points.

 

I don't = think (1) is correct.  A JSON string is by default encoded in = UTF-8. A

UTF-8 encoded string is not "an array of Unicode = code points" (its a sequence of

code units, which must be decoded into code = points), i think a step is missing =

here..

 

    1.  Remove any JSON escaping from the input = JSON = string.

 

    = 1.a  convert the string into a sequence of unicode code = points.

 

How about =E2=80=9CRemove any = JSON escaping from the input JSON string and convert the string into a = sequence of Unicode code points=E2=80=9D?

 

..and = then compare code point-by-code point. This overall algorithm /seems/ = ok,

but I'm not sure, it seems there's rationale that's = not expressed, eg for

excluding use of Unicode Normalization [USA15]. = Also the alg is incomplete in

that it doesn't stipulate converting the "other = unicode string" into a sequence

of code = points.

 

Fair = enough

 

> 10. Security = Considerations

>

>=

>    All of the security issues faced by = any cryptographic application

>    = must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues = are

>    protecting the user's = private key, preventing various attacks, = and

>    helping the user avoid = mistakes such as inadvertently encrypting = a

>    message for the wrong = recipient.  The entire list of = security

>    considerations is = beyond the scope of this document, but = some

>    significant concerns are = listed = here.

>

>    = All the security considerations in the JWS specification also = apply

>    to JWT, as do the JWE = security considerations when encryption = is

>    employed.  In = particular, the JWS JSON Security Considerations = and

>    Unicode Comparison = Security Considerations apply equally to the = JWT

>    Claims Set in the same = manner that they do to the JWS = Header.

>

 <= /p>

dunno if you can get away with sec cons wholly in other docs, and = I'm not sure

it's appropriate given that JWTs are a profile of = JWE or JWS.

 

That was the approach that Sean = had suggested.  If there other things you think we should = specifically add, however, please let me = know.

 

above needs editorial = polish -- there aren't any  "significant concerns"

actually listed = here.

 

True = enough

 

---

end<= /u>

 

 

___= ____________________________________________

OAuth = mailing list

OAuth@ietf.org<= u>

https://www.ietf.org/mailm= an/listinfo/oauth


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




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

=

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

= --Apple-Mail=_6B1BB714-12E8-46B9-9B5D-E6F81C7F17D0-- From adrian@c4media.com Wed Jan 2 13:25:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726F821F8584 for ; Wed, 2 Jan 2013 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz4Y6XHHv8w8 for ; Wed, 2 Jan 2013 13:25:58 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1521F854B for ; Wed, 2 Jan 2013 13:25:58 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so12921875obb.40 for ; Wed, 02 Jan 2013 13:25:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=fbEhvooo7ZiYl/BP3TjqVKDkUa26k078hp1TW3Z5y88=; b=dDPk55xFkvc2nqcloWN/7xOAuHw6cUFqQNjR+4at+mG7qa8r9dv4vTHJR3LDj+GsyD UJ18DXQ0gAuHSpEd1GU9J8y+bx8ITHSxAAOTPAhmZuDH47agfMPkqVJHHxUWKjrZANMn S+hcmw6Iqug3B7sI1jMfEAXQLhQOJAvCA9udpDXFTAf2b4/bXrZHg4+th/AG0OpnBN5b dJfpW4v0v2kZdJdRrk3zSID8x1njjYFMr+mggOVPbxQCKsNTHA32YYQ82MMShp1Y+VsD kkKfU9GwhjVHU3aLkhz6/ZBcS18RRH/Q7H96yLiD7eGiC23H9lrNo6qki/XtGwcmW25b 2TXg== MIME-Version: 1.0 Received: by 10.60.169.207 with SMTP id ag15mr25853471oec.120.1357161958028; Wed, 02 Jan 2013 13:25:58 -0800 (PST) Received: by 10.60.40.232 with HTTP; Wed, 2 Jan 2013 13:25:57 -0800 (PST) Date: Wed, 2 Jan 2013 23:25:57 +0200 Message-ID: From: Adrian Servenschi To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec550afdc69373904d254e465 X-Gm-Message-State: ALoCoQlD7/XMDnw8JNprYZZ4w5veiODZwcIW3VJ6glVHY1S0HzG5uqjDjJw5+OKxi+lulhIlx2NT X-Mailman-Approved-At: Thu, 03 Jan 2013 08:57:29 -0800 Subject: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:27:03 -0000 --bcaec550afdc69373904d254e465 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I am working on implementing login/registration with common identity providers into our application. I am using Scribe for java library which implements the *OAuth* protocol. I've encountered what I consider a small security issue that I don't know how to solve. If I sign in into our application via let's say Google and then I sign out, the Google session cookie remains active in the browser. I can open Gmail afterwards in my browser and my inbox is displayed without the need of authentication. Imagine that a user signs in to our application in an internet cafe, then signs out and leaves the facility. A different client comes at the same desk, opens Gmail and he/she sees the inbox of the first person. This can be a security hazard which I don't know how to solve. I see only 3 options: 1) I can leave it like this --> hazardous 2) If I use Google API to sign out the user from the Google when performing Sign out from our application then the user will be signed out from every Google application he has opened in his browser. In addition I heard that the documentation for performing Sign Out via various identity providers APIs is not quite clear. But this still needs to be investigated. 3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider, seems to be the best option. I will highly appreciate if you can advise me regarding this issue. Thank you very much in advance! Adrian Servenschi. P.S. This is what I found on Facebook Platform Policies page http://developers.facebook.com/policy/ Your website must offer an explicit "Log Out" option that also logs the user out of Facebook. So indeed a form of 3) option will be the best choice? Looking forward to your advices and suggestions. --bcaec550afdc69373904d254e465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,

I am working on implementing login/registration= with common identity providers into our application.
I am using = Scribe for java library which implements the OAuth protocol.

I've encountered what I consider a small security i= ssue that I don't know how to solve.
If I sign in into our ap= plication via let's say Google and then I sign out, the Google session = cookie remains active in the browser.
I can open Gmail afterwards in my browser and my inbox is displayed wi= thout the need of authentication.

Imagine that a u= ser signs in to our application in an internet cafe, then signs out and lea= ves the facility.
A different client comes at the same desk, opens Gmail and he/she sees= the inbox of the first person.
This can be a security hazard whi= ch I don't know how to solve.=A0
I see only 3 options:

1) I can leave it like this --> hazardous
= 2) If I use Google API to sign out the user from the Google when performing= Sign out from our application then the user will be signed out from every = Google application he has opened in his browser.
In addition I heard that the documentation for performing Sign Out via= various identity providers APIs is not quite clear. But this still needs t= o be investigated.

3) The third option : displayin= g some informative text when the user sings out from the application inform= ing him that he/she signed out from our application only, and not from Goog= le/other identity provider,
seems to be the best option.

I will highly ap= preciate if you can advise me regarding this issue.
Thank you ver= y much in advance!

Adrian Servenschi. =A0 =A0

P.S. This is what I found on Facebook Platform Policies= page http://developers.= facebook.com/policy/=A0
Your website must= offer an explicit "Log Out" option that also logs the user out o= f Facebook.

So indeed a form of 3) option will be the best choice?
Lo= oking forward to your advices and suggestions. --bcaec550afdc69373904d254e465-- From jricher@mitre.org Thu Jan 3 09:05:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1621F8CF8 for ; Thu, 3 Jan 2013 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZen2oS7q7XN for ; Thu, 3 Jan 2013 09:05:58 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2B221F8CF4 for ; Thu, 3 Jan 2013 09:05:53 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7ABF41F229D; Thu, 3 Jan 2013 12:05:50 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6C02C1F229C; Thu, 3 Jan 2013 12:05:50 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 3 Jan 2013 12:05:50 -0500 Message-ID: <50E5B9EB.3060106@mitre.org> Date: Thu, 3 Jan 2013 12:03:39 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Servenschi References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080003040701040307090605" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:05:59 -0000 --------------080003040701040307090605 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, This isn't really an OAuth question, especially since OAuth is not an authentication protocol on its own. It is used by several authentication protocols, such as OpenID Connect, Google, and Facebook -- which is where your questions really lie. Thus, OAuth itself can't help you with the sign out issue here and any answers are going to be more server specific. I would encourage you to re-post this question onto Stack Overflow with the appropriate tags, such as "oauth", "facebook", "google", etc. -- Justin On 01/02/2013 04:25 PM, Adrian Servenschi wrote: > Hi guys, > > I am working on implementing login/registration with common identity > providers into our application. > I am using Scribe for java library which implements the *OAuth* protocol. > > I've encountered what I consider a small security issue that I don't > know how to solve. > If I sign in into our application via let's say Google and then I sign > out, the Google session cookie remains active in the browser. > I can open Gmail afterwards in my browser and my inbox is displayed > without the need of authentication. > > Imagine that a user signs in to our application in an internet cafe, > then signs out and leaves the facility. > A different client comes at the same desk, opens Gmail and he/she sees > the inbox of the first person. > This can be a security hazard which I don't know how to solve. > I see only 3 options: > > 1) I can leave it like this --> hazardous > 2) If I use Google API to sign out the user from the Google when > performing Sign out from our application then the user will be signed > out from every Google application he has opened in his browser. > In addition I heard that the documentation for performing Sign Out via > various identity providers APIs is not quite clear. But this still > needs to be investigated. > > 3) The third option : displaying some informative text when the user > sings out from the application informing him that he/she signed out > from our application only, and not from Google/other identity provider, > seems to be the best option. > > I will highly appreciate if you can advise me regarding this issue. > Thank you very much in advance! > > Adrian Servenschi. > > P.S. This is what I found on Facebook Platform Policies page > http://developers.facebook.com/policy/ > > Your website must offer an explicit "Log Out" option that also logs > the user out of Facebook. > > So indeed a form of 3) option will be the best choice? > Looking forward to your advices and suggestions. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080003040701040307090605 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Adrian,

This isn't really an OAuth question, especially since OAuth is not an authentication protocol on its own. It is used by several authentication protocols, such as OpenID Connect, Google, and Facebook -- which is where your questions really lie. Thus, OAuth itself can't help you with the sign out issue here and any answers are going to be more server specific.

I would encourage you to re-post this question onto Stack Overflow with the appropriate tags, such as "oauth", "facebook", "google", etc.

 -- Justin

On 01/02/2013 04:25 PM, Adrian Servenschi wrote:
Hi guys,

I am working on implementing login/registration with common identity providers into our application.
I am using Scribe for java library which implements the OAuth protocol.

I've encountered what I consider a small security issue that I don't know how to solve.
If I sign in into our application via let's say Google and then I sign out, the Google session cookie remains active in the browser.
I can open Gmail afterwards in my browser and my inbox is displayed without the need of authentication.

Imagine that a user signs in to our application in an internet cafe, then signs out and leaves the facility.
A different client comes at the same desk, opens Gmail and he/she sees the inbox of the first person.
This can be a security hazard which I don't know how to solve. 
I see only 3 options:

1) I can leave it like this --> hazardous
2) If I use Google API to sign out the user from the Google when performing Sign out from our application then the user will be signed out from every Google application he has opened in his browser.
In addition I heard that the documentation for performing Sign Out via various identity providers APIs is not quite clear. But this still needs to be investigated.

3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider,
seems to be the best option.

I will highly appreciate if you can advise me regarding this issue.
Thank you very much in advance!

Adrian Servenschi.    

P.S. This is what I found on Facebook Platform Policies page http://developers.facebook.com/policy/ 
Your website must offer an explicit "Log Out" option that also logs the user out of Facebook.

So indeed a form of 3) option will be the best choice?
Looking forward to your advices and suggestions. 

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

--------------080003040701040307090605-- From wmills_92105@yahoo.com Thu Jan 3 09:54:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FA421F8C08 for ; Thu, 3 Jan 2013 09:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WjrMHpkm2Bl for ; Thu, 3 Jan 2013 09:54:20 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with ESMTP id E174721F86AA for ; Thu, 3 Jan 2013 09:54:19 -0800 (PST) Received: from [98.139.214.32] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jan 2013 17:54:18 -0000 Received: from [98.139.212.249] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jan 2013 17:54:18 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 03 Jan 2013 17:54:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 884567.70199.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 55406 invoked by uid 60001); 3 Jan 2013 17:54:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357235658; bh=m1aqzxkMzbdyMfTCr+jYRvgP+IqqqAp8nRJruD3SUCM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RU+9WEOb6hiVZbTKb51qtGdhvtmH0k3eoFdcKxGe70D7EGIefKeT+b1XY17YsHRZwbaEWSMR60pp6oM7XwOusrA9WiVoyZ+KvfsKdXwP04fpQ4cXL8+gqFYpw84S5H29knL9Z8NaC5UkX3POTvo1aifc3z9Zudo2S9IsNM72Bss= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=woBTrL53gF4VSzhC+2at3coKsjixayaG7kTyIkow1Tml9sHsu6d+luqin2CqEju6s8uRMLKr8oZGfie6980Fn/ixWQM8k6FyxOuWwMNYlyNZSRJKT9LoIe8ZjDDiyNQJYg7TkWvxr0hlU5jf3jc/SzX7r9XX7fGJmT+wH7XA6tE=; X-YMail-OSG: OhyRR6kVM1mMTwhLYDpkN3XGPG5IPV4DZsG12v36KBztMhJ Y5zcZsFzXH09DM2667X9z6m.k9TFtPqU.dETrx4_9jvel7GQMbfWGf7Gkn94 zxlznNhpwd6Vhv2QSro4I4ahRzNfF6LiH_dQ3NqowYR6gamXPPPOhEZPrI_h s7W4KtoPLPHKnz4Grbz4cAQfIcJFMMF6V0UUczDrNt72d09Mhc9.Ei7xULjg Phchdczp91nbScy6kRDFr4bsDiX85yeDcYZ6JlM5j7c67V.ZjiChzCkEC2L4 AA38AGE.S8412eNoP3ctnu7l1ip1bnJhkiGwuq76tO6i5l0XBNG3op5tuOof MR1WtttNpnrMbfcbyOdcdF1N4FhNAKQTj2MQRXUWOPrVMhQl9bM_BygsszOi zWFtzcWsHpEwywnDPTvQl1HHwBCo9_YFprF3Dmi7QLlcQQf0V8xCF0lg3PbP 4vwVuD8dC6OFtN_cDnEJG0yL8oPUF0eGrGB0.f1D6T61S0FE65igievfPsrc .P54snIXv9_rXaIe4_FXJTRHgn27AT6h1Zh.Ww2RH5FSaGGb9YfUGPQ.I5eh rkcwLoldQLboxdlDZ_9O2PgKa36EwdysFirzUjkZOzxW8JlvPrBMJ4fb1aHB FEXeNbblIlTgF9bLqHHuqm8rgwek7wA-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 03 Jan 2013 09:54:17 PST X-Rocket-MIMEInfo: 001.001, RG9uJ3QgdXNlIE9BdXRoLCB1c2UgT3BlbklELiDCoE9BdXRoIGlzbid0IGRlc2lnbmVkIGZvciBhdXRoZW50aWNhdGlvbiBhbmQgT3BlbklEIGlzLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBBZHJpYW4gU2VydmVuc2NoaSA8YWRyaWFuQGM0bWVkaWEuY29tPgpUbzogb2F1dGhAaWV0Zi5vcmcgClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyLCAyMDEzIDE6MjUgUE0KU3ViamVjdDogW09BVVRILVdHXSBuZWVkIGFkdmljZSBvbiBzaWduIG91dCBhZnRlciBwZXJmb3JtaW5nIHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: Message-ID: <1357235657.53898.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 3 Jan 2013 09:54:17 -0800 (PST) From: William Mills To: Adrian Servenschi , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1234052338-1357235657=:53898" Subject: Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:54:21 -0000 --1458549034-1234052338-1357235657=:53898 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Don't use OAuth, use OpenID. =A0OAuth isn't designed for authentication and= OpenID is.=0A=0A=0A________________________________=0A From: Adrian Serven= schi =0ATo: oauth@ietf.org =0ASent: Wednesday, January = 2, 2013 1:25 PM=0ASubject: [OAUTH-WG] need advice on sign out after perform= ing sign in via OAuth 10x=0A =0A=0AHi guys,=0A=0AI am working on implementi= ng login/registration with common identity providers into our application.= =0AI am using Scribe for java library which implements the OAuth protocol.= =0A=0AI've encountered what I consider a small security issue that I don't = know how to solve.=0AIf I sign in into our application via let's say Google= and then I sign out, the Google session cookie remains active in the brows= er.=0AI can open Gmail afterwards in my browser and my inbox is displayed w= ithout the need of authentication.=0A=0AImagine that a user signs in to our= application in an internet cafe, then signs out and leaves the facility.= =0AA different client comes at the same desk, opens Gmail and he/she sees t= he inbox of the first person.=0AThis can be a security hazard which I don't= know how to solve.=A0=0AI see only 3 options:=0A=0A1) I can leave it like = this --> hazardous=0A2) If I use Google API to sign out the user from the G= oogle when performing Sign out from our application then the user will be s= igned out from every Google application he has opened in his browser.=0AIn = addition I heard that the documentation for performing Sign Out via various= identity providers APIs is not quite clear. But this still needs to be inv= estigated.=0A=0A3) The third option : displaying some informative text when= the user sings out from the application informing him that he/she signed o= ut from our application only, and not from Google/other identity provider,= =0Aseems to be the best option.=0A=0AI will highly appreciate if you can ad= vise me regarding this issue.=0AThank you very much in advance!=0A=0AAdrian= Servenschi. =A0 =A0=0A=0AP.S. This is what I found on Facebook Platform Po= licies page http://developers.facebook.com/policy/=0AYour website must offe= r an explicit "Log Out" option that also logs the user out of Facebook.=0AS= o indeed a form of 3) option will be the best choice?=0ALooking forward to = your advices and suggestions. =0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth --1458549034-1234052338-1357235657=:53898 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Don't use OAuth, use OpenID.  OAuth isn't designed for authenticatio= n and OpenID is.

From: Adrian Servensc= hi <adrian@c4media.com>
To:= oauth@ietf.org
Sent:= Wednesday, January 2, 2013 1:25 PM
Subject: [OAUTH-WG] need advice on sign out after = performing sign in via OAuth 10x

=0A
Hi guys,

I am working on implementing login/re= gistration with common identity providers into our application.
I= am using Scribe for java library which implements the OAuth protoco= l.
=0A

I've encountered what I consider a small sec= urity issue that I don't know how to solve.
If I sign in into our= application via let's say Google and then I sign out, the Google session c= ookie remains active in the browser.
=0A
I can open Gmail afterwar= ds in my browser and my inbox is displayed without the need of authenticati= on.

Imagine that a user signs in to our applicatio= n in an internet cafe, then signs out and leaves the facility.
=0AA different client comes at the same desk, opens Gmail and he/she sees the= inbox of the first person.
This can be a security hazard which I= don't know how to solve. 
I see only 3 options:
=0A
1) I can leave it like this --> hazardous
2) = If I use Google API to sign out the user from the Google when performing Si= gn out from our application then the user will be signed out from every Goo= gle application he has opened in his browser.
=0A
In addition I he= ard that the documentation for performing Sign Out via various identity pro= viders APIs is not quite clear. But this still needs to be investigated.

3) The third option : displaying some informative te= xt when the user sings out from the application informing him that he/she s= igned out from our application only, and not from Google/other identity pro= vider,
=0A
seems to be the best option.

I= will highly appreciate if you can advise me regarding this issue.
Thank you very much in advance!

Adrian Servensch= i.    
=0A

P.S. This is what I found on F= acebook Platform Policies page http://developers.facebook.com/policy/
=
Your website must offer an explicit "Log O= ut" option that also logs the user out of Facebook.
=0A
So indeed a form of 3) option will be the best choice?
Looking fo= rward to your advices and suggestions.=0A

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


--1458549034-1234052338-1357235657=:53898-- From ve7jtb@ve7jtb.com Thu Jan 3 10:02:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5A21F8521 for ; Thu, 3 Jan 2013 10:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C6t03m5AG21 for ; Thu, 3 Jan 2013 10:02:00 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 65CAB21F8518 for ; Thu, 3 Jan 2013 10:01:54 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so14094227obc.13 for ; Thu, 03 Jan 2013 10:01:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=kdxAR6qsWGteqAzPGeFK2RXjLof4D9JYAzoUCYU3x1Q=; b=YNQjPUJpxSYDKp8DtMwXo2AsPInLp0TzN6LOpwlWJQZm6OZTawO/iIiz8iuO20RBg+ IXsDEBVR1UVn9g+weNhzcGvJaDYNwVOuz8zuFw5pYR7E43YjNWbKnrsc93gx0lUN6z0P tQFR3EEy6c55N2cD5sV++sssoWgzj6yhAmIwXyYRwsZWySmLUfV2lTvYqbYgdM/ESEbe n+fEBka/dgZ+GsI3RGYh/iutJsZScYcznJv1/BOeZfWrGfQqJPpHUlce9ZliqKDNmI3f 8wEMHiFjgw92em0XIGE7QL++9wpj/CliwEj3axc2zaKCsApK41Lx5hiT3KMRipKoEqRt l6Dw== X-Received: by 10.60.171.133 with SMTP id au5mr28138681oec.90.1357236113831; Thu, 03 Jan 2013 10:01:53 -0800 (PST) Received: from [192.168.1.211] (190-20-6-196.baf.movistar.cl. [190.20.6.196]) by mx.google.com with ESMTPS id el2sm31851837obc.9.2013.01.03.10.01.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2013 10:01:52 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED3963B9-CFCC-46F9-8358-87B8AE3EC00E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 3 Jan 2013 15:01:43 -0300 Message-Id: References: To: Adrian Servenschi X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmph/vdbvsQQ6NIn6lNok4DRuMUv7TgGQimivSjcpqmR2fpkGsf0POGHaNpXJYy2S50Bnxo Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:02:01 -0000 --Apple-Mail=_ED3963B9-CFCC-46F9-8358-87B8AE3EC00E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It sounds like your issue is logging the user out of the IdP. There = are several non interoperable ways of doing that in SAML. That is out of scope for OAuth itself. In the open internet the issue tends to be that IdP don't want to be = accepting logout messages from RP that terminate the users session = without confirmation of the user. =20 In openID Connect we are doing some things with session management where = a RP can redirect a user to the IdP to terminate sessions, however that = is optional for the IdP to implement. For the moment you will have to deal with each IdP separately if you = want to try and kill idP sessions when the user logged out of your RP. John B. On 2013-01-02, at 6:25 PM, Adrian Servenschi wrote: > Hi guys, >=20 > I am working on implementing login/registration with common identity = providers into our application. > I am using Scribe for java library which implements the OAuth = protocol. >=20 > I've encountered what I consider a small security issue that I don't = know how to solve. > If I sign in into our application via let's say Google and then I sign = out, the Google session cookie remains active in the browser. > I can open Gmail afterwards in my browser and my inbox is displayed = without the need of authentication. >=20 > Imagine that a user signs in to our application in an internet cafe, = then signs out and leaves the facility. > A different client comes at the same desk, opens Gmail and he/she sees = the inbox of the first person. > This can be a security hazard which I don't know how to solve.=20 > I see only 3 options: >=20 > 1) I can leave it like this --> hazardous > 2) If I use Google API to sign out the user from the Google when = performing Sign out from our application then the user will be signed = out from every Google application he has opened in his browser. > In addition I heard that the documentation for performing Sign Out via = various identity providers APIs is not quite clear. But this still needs = to be investigated. >=20 > 3) The third option : displaying some informative text when the user = sings out from the application informing him that he/she signed out from = our application only, and not from Google/other identity provider, > seems to be the best option. >=20 > I will highly appreciate if you can advise me regarding this issue. > Thank you very much in advance! >=20 > Adrian Servenschi. =20 >=20 > P.S. This is what I found on Facebook Platform Policies page = http://developers.facebook.com/policy/=20 > Your website must offer an explicit "Log Out" option that also logs = the user out of Facebook. >=20 > So indeed a form of 3) option will be the best choice? > Looking forward to your advices and suggestions. = _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ED3963B9-CFCC-46F9-8358-87B8AE3EC00E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It = sounds like your issue is logging the user out of the IdP.   There = are several non interoperable ways of doing that in = SAML.

That is out of scope for OAuth = itself.

In the open internet the issue tends to = be that IdP  don't want to be accepting logout messages from RP = that terminate the users session without confirmation of the user. =  

In openID Connect we are doing some = things with session management where a RP can redirect a user to the IdP = to terminate sessions, however that is optional for the IdP to = implement.

For the moment you will have to deal = with each IdP separately if you want to try and kill idP sessions when = the user logged out of your RP.

John = B.

On 2013-01-02, at 6:25 PM, Adrian Servenschi = <adrian@c4media.com> = wrote:

Hi guys,

I am working on implementing = login/registration with common identity providers into our = application.
I am using Scribe for java library which = implements the OAuth protocol.

I've encountered what I consider a small security = issue that I don't know how to solve.
If I sign in into our = application via let's say Google and then I sign out, the Google session = cookie remains active in the browser.
I can open Gmail afterwards in my browser and my inbox is displayed = without the need of authentication.

Imagine = that a user signs in to our application in an internet cafe, then signs = out and leaves the facility.
A different client comes at the same desk, opens Gmail and he/she = sees the inbox of the first person.
This can be a security = hazard which I don't know how to solve. 
I see only 3 = options:

1) I can leave it like this --> = hazardous
2) If I use Google API to sign out the user from the = Google when performing Sign out from our application then the user will = be signed out from every Google application he has opened in his = browser.
In addition I heard that the documentation for performing Sign Out = via various identity providers APIs is not quite clear. But this still = needs to be investigated.

3) The third option : = displaying some informative text when the user sings out from the = application informing him that he/she signed out from our application = only, and not from Google/other identity provider,
seems to be the best option.

I will highly = appreciate if you can advise me regarding this issue.
Thank = you very much in advance!

Adrian Servenschi. =    

P.S. This is what I found on Facebook Platform = Policies page http://developers.facebook= .com/policy/ 
Your website must offer an explicit = "Log Out" option that also logs the user out of Facebook.

So indeed a form of 3) option will be the best = choice?
Looking forward to your advices and suggestions. _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_ED3963B9-CFCC-46F9-8358-87B8AE3EC00E-- From gffletch@aol.com Thu Jan 3 12:42:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E61C21F8D8D for ; Thu, 3 Jan 2013 12:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHdSFmls9XCF for ; Thu, 3 Jan 2013 12:42:53 -0800 (PST) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by ietfa.amsl.com (Postfix) with ESMTP id E889C21F8D03 for ; Thu, 3 Jan 2013 12:42:52 -0800 (PST) Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-mb01.mx.aol.com (Outbound Mail Relay) with ESMTP id 5C5651C00018C; Thu, 3 Jan 2013 15:42:52 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D3204E000384; Thu, 3 Jan 2013 15:42:51 -0500 (EST) Message-ID: <50E5ED4B.5070000@aol.com> Date: Thu, 03 Jan 2013 15:42:51 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Servenschi References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070106020901020708070609" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357245772; bh=9D8GnpmjQY1oau+67gF49Vz7Jup5Hp+zoDm4Q8YMpZ4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=DuYHx5/o8erG5x4edhB2VMk4hA1t8bAZe6cLgxLtBQ8VUePgTz3dKbpFzgz3O5+Co IZ76BI2AdiV9l/PTtVOERskWl3thRYGJuTuj/h07FBNJYDO7j436b/Mjpli07i8z/Z 7GUtHGWQjOU8V0ROQ1EDTLW7pbgyTUa0zrhGE9Do= X-AOL-SCOLL-SCORE: 0:2:466427328:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290450e5ed4b192c X-AOL-IP: 10.181.186.254 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:42:54 -0000 This is a multi-part message in MIME format. --------------070106020901020708070609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There is no standardization of the logout flow in OAuth or OpenID (there is in OpenID Connect as John mentioned) so your option 3... 3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider, seems to be the best option. is the best option right now. The problem is that as the application you don't know if the user signed in with Google just to access your app, or if they already had gmail open. In the first case it would be nice to sign the user out of Google since they authenticated solely for the purpose of accessing your app. In the second case you DON'T want to sign them out as that will kill their gmail session which is probably not what the user (or your app) wants. So, informing the user that they are still logged in at Google is a good choice. You might want to give the user the option to forgo the warning in the future once they understand what is happening. Thanks, George On 1/2/13 4:25 PM, Adrian Servenschi wrote: > Hi guys, > > I am working on implementing login/registration with common identity > providers into our application. > I am using Scribe for java library which implements the *OAuth* protocol. > > I've encountered what I consider a small security issue that I don't > know how to solve. > If I sign in into our application via let's say Google and then I sign > out, the Google session cookie remains active in the browser. > I can open Gmail afterwards in my browser and my inbox is displayed > without the need of authentication. > > Imagine that a user signs in to our application in an internet cafe, > then signs out and leaves the facility. > A different client comes at the same desk, opens Gmail and he/she sees > the inbox of the first person. > This can be a security hazard which I don't know how to solve. > I see only 3 options: > > 1) I can leave it like this --> hazardous > 2) If I use Google API to sign out the user from the Google when > performing Sign out from our application then the user will be signed > out from every Google application he has opened in his browser. > In addition I heard that the documentation for performing Sign Out via > various identity providers APIs is not quite clear. But this still > needs to be investigated. > > 3) The third option : displaying some informative text when the user > sings out from the application informing him that he/she signed out > from our application only, and not from Google/other identity provider, > seems to be the best option. > > I will highly appreciate if you can advise me regarding this issue. > Thank you very much in advance! > > Adrian Servenschi. > > P.S. This is what I found on Facebook Platform Policies page > http://developers.facebook.com/policy/ > > Your website must offer an explicit "Log Out" option that also logs > the user out of Facebook. > > So indeed a form of 3) option will be the best choice? > Looking forward to your advices and suggestions. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070106020901020708070609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There is no standardization of the logout flow in OAuth or OpenID (there is in OpenID Connect as John mentioned) so your option 3...
3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider,
seems to be the best option.
is the best option right now.

The problem is that as the application you don't know if the user signed in with Google just to access your app, or if they already had gmail open. In the first case it would be nice to sign the user out of Google since they authenticated solely for the purpose of accessing your app. In the second case you DON'T want to sign them out as that will kill their gmail session which is probably not what the user (or your app) wants.

So, informing the user that they are still logged in at Google is a good choice. You might want to give the user the option to forgo the warning in the future once they understand what is happening.

Thanks,
George

On 1/2/13 4:25 PM, Adrian Servenschi wrote:
Hi guys,

I am working on implementing login/registration with common identity providers into our application.
I am using Scribe for java library which implements the OAuth protocol.

I've encountered what I consider a small security issue that I don't know how to solve.
If I sign in into our application via let's say Google and then I sign out, the Google session cookie remains active in the browser.
I can open Gmail afterwards in my browser and my inbox is displayed without the need of authentication.

Imagine that a user signs in to our application in an internet cafe, then signs out and leaves the facility.
A different client comes at the same desk, opens Gmail and he/she sees the inbox of the first person.
This can be a security hazard which I don't know how to solve. 
I see only 3 options:

1) I can leave it like this --> hazardous
2) If I use Google API to sign out the user from the Google when performing Sign out from our application then the user will be signed out from every Google application he has opened in his browser.
In addition I heard that the documentation for performing Sign Out via various identity providers APIs is not quite clear. But this still needs to be investigated.

3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider,
seems to be the best option.

I will highly appreciate if you can advise me regarding this issue.
Thank you very much in advance!

Adrian Servenschi.    

P.S. This is what I found on Facebook Platform Policies page http://developers.facebook.com/policy/ 
Your website must offer an explicit "Log Out" option that also logs the user out of Facebook.

So indeed a form of 3) option will be the best choice?
Looking forward to your advices and suggestions. 

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

--------------070106020901020708070609-- From jricher@mitre.org Thu Jan 3 14:48:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EA821F8A71 for ; Thu, 3 Jan 2013 14:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iPdPP6hKfvN for ; Thu, 3 Jan 2013 14:48:01 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0B21F8B13 for ; Thu, 3 Jan 2013 14:47:51 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7400853111BC for ; Thu, 3 Jan 2013 17:47:21 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A1CC53111BA for ; Thu, 3 Jan 2013 17:47:21 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 3 Jan 2013 17:47:20 -0500 Message-ID: <50E609F6.3080904@mitre.org> Date: Thu, 3 Jan 2013 17:45:10 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Subject: [OAUTH-WG] Use Cases for Signed Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:48:01 -0000 I'd like to present two use cases for signed tokens, for input into the ongoing MAC/HoK/higher-security discussion. Both of these are actual cases that I've done in the past, and we've used either OAuth 1 or JW* to solve them. I think that with the right tooling, a MAC-token-like thing could be used here. I'll note to the crypto nerds in the group (ahem, John) that I'm going to be using terms like "signing" and "MAC" in a somewhat loose sense, so please don't get hung up on that because I think you actually know what I mean. So: 1) Message-level signing. In this, you protect the content of the HTTP message by signing it with the secret part of the token, effectively what was done in OpenID 2, OAuth1, and the MAC draft. You pick some subset of the HTTP components, add them to your signing base in a predictable and repeatable fashion, and sign it with your secret. You then send the signature along with all of the bare HTTP elements across the wire, and the far side does the same signature generation magic and you're good to go. The driving use case to this is security in depth. Yes, you probably still do want everything to go over TLS, but that only protects things in transit between endpoints. It won't protect anything as it gets chewed through an application platform or handed around a server farm. It's also considered "best practice" in many cases. In my experience in the health care space, you almost always want to have multiple layers protecting you. An alternative approach here is to use a JW* container like a JWS or JWE to hold all of your parameters (as claims) and sign/encrypt over that. But if you do that, you're not really using HTTP anymore, except as a dumb transport. This is the approach of SOAP, and I doubt that many will come to its defense. (At least, those that don't want to sell you something to process SOAP messages.) We've done this ourselves with a prototype, and losing all of the processing capability that comes with HTTP is a huge programmatic hit. 2) Signed URL as an authorized artifact. In this, you have party A generate a URL with parameters in it, protected by a signature. That URL points to party B, who can validate the signature. Party A then hands that fully baked URL to a third party, C, who can't do anything to the parameters in the URL without messing up the signature. From party B's perspective, so long as that signature is valid, all the parameters in the URL can be trusted and the request can proceed. With a timestamp and nonce parameter (built in to OAuth1), you've even got really nice replay and timeout protection. TLS doesn't do you any good here, because there's a party in the middle who has the full right to hold and view the artifact (URL), but does not have the right to modify it. We've solved this in the past using OAuth1's signature mechanism without tokens (aka, 2-legged OAuth1). We can't currently do this with OAuth2. If we had a generalizable HTTP components signing mechanism (which MAC *almost* is, and could become), then we could. Again, you could simply cram everything into a JW* container and send *that* as the sole parameter to a URL and get almost the same result. But then you've got to unpack that JW* container to get all of your parameters, and you're back in SOAP land. And again I posit: nerds hate SOAP. Hopefully both of these will help inform the discussion and shed some light onto why I think that: * MAC tokens (or equivalent) are still a good idea for the WG to pursue * Channel-binding and TLS don't solve all security problems * Abusing JOSE leads to breaking good HTTP designs -- Justin From Michael.Jones@microsoft.com Fri Jan 4 14:36:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4C21F8B06 for ; Fri, 4 Jan 2013 14:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsgvmVkhY0VS for ; Fri, 4 Jan 2013 14:36:03 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id E454A21F8AE5 for ; Fri, 4 Jan 2013 14:36:02 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB007.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.0.586.12; Fri, 4 Jan 2013 22:35:53 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Fri, 4 Jan 2013 22:35:53 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 4 Jan 2013 22:35:15 +0000 From: Mike Jones To: William Mills , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] December 27, 2012 OAuth Release Thread-Index: Ac3lYOVg59Z0pf6IRui17x5NiyOcmwACDrsAAVhycSA= Date: Fri, 4 Jan 2013 22:35:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669FE2ADTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(377454001)(15202345001)(50986001)(5343635001)(5343655001)(56776001)(33656001)(49866001)(55846006)(56816002)(4396001)(46102001)(74502001)(74662001)(44976002)(16297215001)(54316002)(77982001)(51856001)(53806001)(16406001)(16236675001)(15395725002)(31966008)(47446002)(47736001)(76482001)(512954001)(59766001)(5343645001)(47976001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB007; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0716E70AB6 Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 22:36:04 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669FE2ADTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There's no generic OAuth way to do this. There is a way to do it in OpenID= Connect - see request_object_signing_alg, userinfo_signed_response_alg, an= d id_token_signed_response_alg in http://openid.net/specs/openid-connect-re= gistration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, i= d_token_signing_alg_values_supported, and request_object_signing_alg_values= _supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#= anchor9. -- Mike From: William Mills [mailto:wmills_92105@yahoo.com] Sent: Friday, December 28, 2012 6:07 PM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release Mike, I've read through the JWT spec and I'm curious about something. How do I s= pecify a signature requirement as the server? I didn't see it but I probab= ly just missed it. I'm thinking that with very little work a JWT can do ev= erything that MAC does with greater flexibility, *BUT* the server needs to = be able to require a signed usage. Something I never liked about OAuth 1.0= is that the server must support all valid signature types, even PLAINTEXT,= so I want to be able to avoid that. It would require the client to be able to include client generated stuff in= the JWT. Thanks, -bill --_000_4E1F6AAD24975D4BA5B1680429673943669FE2ADTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There’s no generic = OAuth way to do this.  There is a way to do it in OpenID Connect ̵= 1; see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_alg in http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3= and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9<= /a>.

 <= /p>

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

 <= /p>

From: William = Mills [mailto:wmills_92105@yahoo.com]
Sent: Friday, December 28, 2012 6:07 PM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release

 

Mike,

 

I've read through the JWT spec and I'm curious about something.=  How do I specify a signature requirement as the server?  I didn= 't see it but I probably just missed it.  I'm thinking that with very little work a JWT can do everything that MAC does with greater f= lexibility, *BUT* the server needs to be able to require a signed usage. &n= bsp;Something I never liked about OAuth 1.0 is that the server must support= all valid signature types, even PLAINTEXT, so I want to be able to avoid that.

 

It would require the client to be able to include client genera= ted stuff in the JWT.

 

Thanks,

 

-bill

--_000_4E1F6AAD24975D4BA5B1680429673943669FE2ADTK5EX14MBXC283r_-- From wmills_92105@yahoo.com Fri Jan 4 14:48:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B0D21F883F for ; Fri, 4 Jan 2013 14:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRW-D2r44UiG for ; Fri, 4 Jan 2013 14:48:23 -0800 (PST) Received: from nm27-vm0.bullet.mail.bf1.yahoo.com (nm27-vm0.bullet.mail.bf1.yahoo.com [98.139.213.139]) by ietfa.amsl.com (Postfix) with ESMTP id 05DBC21F8815 for ; Fri, 4 Jan 2013 14:48:22 -0800 (PST) Received: from [98.139.212.148] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 22:48:22 -0000 Received: from [98.139.212.214] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 22:48:21 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 22:48:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 987596.88883.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 38945 invoked by uid 60001); 4 Jan 2013 22:48:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357339701; bh=DJUZhqBqw1/1lz2Fc2gQeHwHtYgbesvTKBLIR0zv3r8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xEqT0Hdomdh9wA4yZZSrl+8lv9RUJUZC1RUZsUgOVnjfl/RLSL7RRMylzKyo6MTMnrksctjPHM9PJ6azyDkDldAHbFiRoGmD7TGxMD+h0HUBV65sdUndeSssDqBkPiiPMmMQq6BxI0Fui6jizi7Z7+0YO0qwGQFcKzDlD6yJPxg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=amSZhMWh0/B27w2nkcvjWAMAvynmM2TpfrrXjy/AH6qKrp0TjJVsbWy6SXzZ/ij7ekV0kaI8nsRy/P8CcFkoAwv8k9epKPVjeluaV09dqFHV81q17XnvxspD3JtBNTpJ8QA7GWSpHhbg7WSdPVFoWYG3IoYAEU/447x0R/huZhw=; X-YMail-OSG: 2PrGFrkVM1mlvf6NkxQNMqFdL2n.SXw_mHzUfydMRIOyK7y 1z0GBCIUSO2xpLqjAuAUG2OZwfOpSY7_Tu82OvEjf4W5oBViRcdPx5vX8ixn lz6ZNXBeg2K.SxgFgFhQnuDot.K.ANOLEmyYR_3Mycm0vFxg._6X.YwPDw3B hhOkx73qnEbu.N8LneWO1NJVGgpFjaOiaDlD6DegqSd37UW38WVPBrGTKb2g vRUaydYM.dLhKl1xIpqmF9Or_ScbAYXVb.t.kG8TILpvLpZy3nF4aOJM2zm9 w2MN4Nd.qev2pkM1l5V0h099heQFdemTZHG_cpQP05NyS0Biq28hbmTjN.D5 StLs2yYDkwyRXaOpIFG7U01UpHcXVnYjr461iTeqKZ0OI91kyVuqsBfxMXZK 3geKjF4fzmxtlCIND6mnlThDH2Cfg4SdWxvNjFyfTUZM8zy4VAZUjrIDF3Fp T0r42pa8CkmrLinBxBumAaZfH0lGXavSO7a15dHhV4h81XlwMdDjjlAZps07 tP_CO6cCKR7fs0OaUF5eEsZOhL1y_lm.s4XKQWJFzpX6TsTIUhnlmqyWzOtV 0KrO9pcRkMLJpwJuwXAjVxJFc2EbXLa7aE1tW9mYSYjYfqrjCcL9DpixQnMk 4tVj.bBFH_zGZegjnTs9vxIL1UBYUox3tO0mx Received: from [209.131.62.113] by web31816.mail.mud.yahoo.com via HTTP; Fri, 04 Jan 2013 14:48:20 PST X-Rocket-MIMEInfo: 001.001, SXQncyB0aGUgY29yZSBwcm9ibGVtIEkgc2VlIE1BQyBzb2x2aW5nLiDCoEknZCBiZSBoYXBweSBlbm91Z2ggdG8gZGVmaW5lIGEgSldUIHZhcmlhbnQgdGhhdCBkb2VzIHRoaXMgaWYgdGhhdCdzIGVhc2llciB0aGFuIE1BQy4gwqBXaGF0IGRvIHlvdSB0aGluaz8KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT47ICJvYXV0aEBpZXRmLm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1357339700.37914.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Fri, 4 Jan 2013 14:48:20 -0800 (PST) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1086497344-1357339700=:37914" Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 22:48:24 -0000 ---1238014912-1086497344-1357339700=:37914 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It's the core problem I see MAC solving. =C2=A0I'd be happy enough to defin= e a JWT variant that does this if that's easier than MAC. =C2=A0What do you= think?=0A=0A=0A________________________________=0A From: Mike Jones =0ATo: William Mills ; "oaut= h@ietf.org" =0ASent: Friday, January 4, 2013 2:35 PM=0ASub= ject: RE: [OAUTH-WG] December 27, 2012 OAuth Release=0A =0A=0A =0AThere=E2= =80=99s no generic OAuth way to do this.=C2=A0 There is a way to do it in O= penID Connect =E2=80=93 see request_object_signing_alg, userinfo_signed_res= ponse_alg, and id_token_signed_response_algin=0Ahttp://openid.net/specs/ope= nid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_valu= es_supported, id_token_signing_alg_values_supported, and request_object_sig= ning_alg_values_supportedin=0Ahttp://openid.net/specs/openid-connect-discov= ery-1_0-11.html#anchor9.=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0AFrom:William Mills [mailto:wmills_92105@= yahoo.com] =0ASent: Friday, December 28, 2012 6:07 PM=0ATo: Mike Jones; oau= th@ietf.org=0ASubject: Re: [OAUTH-WG] December 27, 2012 OAuth Release=0A=C2= =A0=0AMike,=0A=C2=A0=0AI've read through the JWT spec and I'm curious about= something. =C2=A0How do I specify a signature requirement as the server? = =C2=A0I didn't see it but I probably just missed it. =C2=A0I'm thinking tha= t with very little work a JWT can do everything that MAC does with greater = flexibility, *BUT* the server needs to be able to require a signed usage. = =C2=A0Something I never liked about OAuth 1.0 is that the server must suppo= rt all valid signature types, even PLAINTEXT, so I want to be able to avoid= that.=0A=C2=A0=0AIt would require the client to be able to include client = generated stuff in the JWT.=0A=C2=A0=0AThanks,=0A=C2=A0=0A-bill ---1238014912-1086497344-1357339700=:37914 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It's the core problem I see MAC solving.  I'd be happy enough to def= ine a JWT variant that does this if that's easier than MAC.  What do y= ou think?

<= b>From: Mike Jones <Michael= .Jones@microsoft.com>
To: William Mills <wmills_92105@yahoo.com>; "oauth@ietf.org" <o= auth@ietf.org>
Sent: Friday, January 4, 2013 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release<= br>

=0A
=0A=0A =0A =0A=0A=0A=0A
=0A
There=E2=80=99s = no generic OAuth way to do this.  There is a way to do it in OpenID Co= nnect =E2=80=93 see=0Areque= st_object_signing_alg,=0Auserinfo_signed_respon= se_alg, and=0Aid_token_signed_response_alg in=0Ahttp://openid.net/s= pecs/openid-connect-registration-1_0-13.html#anchor3 and =0Auserinfo_signing_alg_values_supported,=0Aid_token_signing_alg_values_supported, and=0Arequest_obj= ect_signing_alg_values_supported in=0Ahttp://openid.net/specs/openid-connect-discovery-1_0-11.h= tml#anchor9.
=0A
 
=0A
            &n= bsp;            = ;            &n= bsp;            = ;          -- Mike =0A
 
=0A
=0A
=0A
From: William Mills [mailto:wmills_92105@yah= oo.com]=0A
=0ASent: Friday, December 28, 2012 6:07 PM
=0ATo= : Mike Jones; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Decem= ber 27, 2012 OAuth Release
=0A
=0A
=0A
 
=0A
=0A
=0A
Mike,
=0A
=0A
=0A
 =
=0A
=0A
=0A
I've read through the JWT spec and I'm curious about som= ething.  How do I specify a signature requirement as the server?  = ;I didn't see it but I probably just missed it.  I'm thinking that=0A = with very little work a JWT can do everything that MAC does with greater fl= exibility, *BUT* the server needs to be able to require a signed usage. &nb= sp;Something I never liked about OAuth 1.0 is that the server must support = all valid signature types, even PLAINTEXT,=0A so I want to be able to avoid= that.
=0A
=0A
=0A
 
=0A
=0A
=0AIt would r= equire the client to be able to include client generated stuff in the JWT.<= /span>
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks, =0A
=0A
=0A
 
=0A
=0A
=0A
-bill
=0A=0A
=0A
=0A
=0A=0A


---1238014912-1086497344-1357339700=:37914-- From wmills_92105@yahoo.com Fri Jan 4 15:44:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10721F8A6C for ; Fri, 4 Jan 2013 15:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q8yexzoXlhB for ; Fri, 4 Jan 2013 15:44:08 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id 5C97021F8A69 for ; Fri, 4 Jan 2013 15:44:08 -0800 (PST) Received: from [98.139.215.140] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:44:07 -0000 Received: from [98.139.215.249] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:44:07 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:44:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 684303.57963.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 63106 invoked by uid 60001); 4 Jan 2013 23:44:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357343046; bh=W9Yhs4p3E7RXm44PeUw6s6D4Yxf/XTE1oRXl12XcNS4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=6v+Hmg/nyvEpGNfLX8muDCJjjDSvBMzY3x9hgnT2lHl9q7EUBlAJ+SSfKAU4q5nIG5wzwovQbErz46NFnBe/bW3BxgWZhpibiHzoEhXvEAc1RUhNFq53KBbxopOZKG8d2XCZRPHbOkdprxHJHrDNWzO97JNIouNkNBydReOFvD4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=XK8tWm6K+dYlC1Ft+vIldEsnwLpGb7HsDFQ32xecXJWeZtrGmpk8FBoMWFJmqvQpr7X5AhWEjAwx6p5iSaIpLQUwJjLaPKNSKQARn+8XmRfpNlpz/OLOcRX28noyijDdVdsE/O9mWTkGo66/PlmwxdUz6SsdBgz+WCgHsHCEXf8=; X-YMail-OSG: DUpcXjoVM1nmPXX1XLC0.IXQLMjS_cYdp6DN8As30cwLK9B aJ4LjM3dHrucrEAYYKZhMxBm1d0LEKs4PTqBVlVwPU5TxuvuYVa4LTgvoLOK pmDT_zjzI67q1gG4t0Cgiv_.2.HMlOCeH6_LkeFkLd_.E862S9y3Y7QflfTL YQ2LUb0UdXNiYrJgr8s5q9Huzb.5ghnEwM3yaY7QX5Wp2C1F8Y3EL7_0hSWI T5lGBiLDdTqPk_jnpDsgpnLMQYiyGUshCSA6SD9MP1SYmCOUH7TybWhnCjOl PwzCHozdZAVYRHVXsXiaY8yziG4RtsXLLUDbaKwJvzHXyCITeS3ue0mrxM2u hNXdIhTCrQpTW19fUm_1NLhFqzgDxcDzR_ZHf88HxYX2_.eneSZAX7QJsfVH JWrwv7VrnDgk3nGijIB.Nu6Agzpwk.5mM7tQJ64XzkLkWcxN7Sy5z9yc2Q1b p4OfaWFDVkO_IBWcmB1Z4hJF7FVb3Wsr3hkJa6l4BHykeY_5Qzwc34B9UT3f A57RsODE64Glizsruk0MkhfqsmNb0RmGncL2gdGBPSCLVgHUFAN7BWnO5DGQ OQQjv6.zOuLRaAQ4vfjPMKt68cjgrV5vDSTmbLUvm6WRcS16hnZJelAAx9rw h4Q-- Received: from [209.131.62.145] by web31807.mail.mud.yahoo.com via HTTP; Fri, 04 Jan 2013 15:44:06 PST X-Rocket-MIMEInfo: 001.001, RllJCgpodHRwOi8vcHJvc2VjY28uZ2ZvcmdlLmlucmlhLmZyL0NWRS9GYWNlYm9va19KU18yMDEyLmh0bWwKCgoiQXMgYSBwYXJ0IG9mIG91ciBzdHVkeSBvZiB2YXJpb3VzIHNlY3VyaXR5IGNyaXRpY2FsIEphdmFzY3JpcHQgU0RLcyB3ZSAKZGlkIGFuIGFuYWx5c2lzIG9mIHRoZSBGYWNlYm9vayBDb25uZWN0IEpTIFNESy4gU2luY2UgdGhleSB1c2UgSFRNTDUgCmJhc2VkIFBvc3RNZXNzYWdlIEFQSSB3ZSB3ZXJlIHNwZWNpZmljYWxseSBpbnRlcmVzdGVkIGluIHRoZSB3YXkgdGhlIApvcmlnaW5zIHdlcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 Message-ID: <1357343046.53864.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 4 Jan 2013 15:44:06 -0800 (PST) From: William Mills To: O Auth WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-24180489-1357343046=:53864" Subject: [OAUTH-WG] OAuth 2 fun... for some values of fun. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 23:44:09 -0000 ---125733401-24180489-1357343046=:53864 Content-Type: text/plain; charset=us-ascii FYI http://prosecco.gforge.inria.fr/CVE/Facebook_JS_2012.html "As a part of our study of various security critical Javascript SDKs we did an analysis of the Facebook Connect JS SDK. Since they use HTML5 based PostMessage API we were specifically interested in the way the origins were validated. We managed to bypass the origin validation by exploiting 3 different bugs in their SDK." ---125733401-24180489-1357343046=:53864 Content-Type: text/html; charset=us-ascii
FYI

http://prosecco.gforge.inria.fr/CVE/Facebook_JS_2012.html

"As a part of our study of various security critical Javascript SDKs we did an analysis of the Facebook Connect JS SDK. Since they use HTML5 based PostMessage API we were specifically interested in the way the origins were validated. We managed to bypass the origin validation by exploiting 3 different bugs in their SDK."

---125733401-24180489-1357343046=:53864-- From ve7jtb@ve7jtb.com Fri Jan 4 15:44:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9925F21F8B19 for ; Fri, 4 Jan 2013 15:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew9vqJjJv28u for ; Fri, 4 Jan 2013 15:44:36 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66B21F8B08 for ; Fri, 4 Jan 2013 15:44:36 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id ez10so17140698vbb.11 for ; Fri, 04 Jan 2013 15:44:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=FSZFt4YmxOgRQcJTfhbsex+IZmAiNXDvytLNrbqGvT8=; b=pwnB30IP3e3iiu1SypEPKtb7wDKvtrjz9bqQz1Po7FrOn7brBGxEEI+PxnN0My5Kia MWj8ptg3EjcxkL16qtiMXwXfS6VIc7PuZWulKXfYV6L6PBYKWBeL/y4Q1WLL8sk16C6C ed8NCEnZKICWtiqk2PS5abdBVWq5AL9I2YF1lPkNspFt9zBt4NZHdGNSaRT4v3JvxQN0 3iOQy3y+ybMo4otvaMtb0yTY6ZUp8nx3/TTca2L7Eq1GnN8AlUrS+uF9oL1IOub+1ZRL Ghsn0+qf7W0ymh+/OToW65Uku53qdwZen0ICBON1y96LjQyEyjR3MM+KAM5foZcnck7A UIEg== X-Received: by 10.52.36.100 with SMTP id p4mr70943448vdj.16.1357343075918; Fri, 04 Jan 2013 15:44:35 -0800 (PST) Received: from [192.168.1.211] (190-20-25-66.baf.movistar.cl. [190.20.25.66]) by mx.google.com with ESMTPS id bj15sm47640566vdc.7.2013.01.04.15.44.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 15:44:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_433E7DCC-D018-458C-8078-4CF948E28CED" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <1357339700.37914.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Fri, 4 Jan 2013 20:44:26 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> <1357339700.37914.YahooMailNeo@web31816.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkzLjDEregdDU+5V9QKX/8edM2BIKqyd2yyzg4rNZOts1ElPJWKqqJl+i8Ffu2oIaS5MeH5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 23:44:37 -0000 --Apple-Mail=_433E7DCC-D018-458C-8078-4CF948E28CED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If everything you want to sign can go in the JWT there is nothing to = stop that. Otherwise you are back to coming up with a way of doing a = detached signature and putting a hash in the JWT like connect is doing = by putting a hash of the token in the id_token for the "token id_token} = flow. The hard part is figuring out what needs to be signed. =20 As for client generated JWT we already have the JWT assertion profile. = Connect is using that as an option to authenticate to the token = endpoint.=20 Would doing a similar thing but to the RS really work for you? John B. On 2013-01-04, at 7:48 PM, William Mills wrote: > It's the core problem I see MAC solving. I'd be happy enough to = define a JWT variant that does this if that's easier than MAC. What do = you think? >=20 > From: Mike Jones > To: William Mills ; "oauth@ietf.org" = =20 > Sent: Friday, January 4, 2013 2:35 PM > Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release >=20 > There=92s no generic OAuth way to do this. There is a way to do it in = OpenID Connect =96 see request_object_signing_alg, = userinfo_signed_response_alg, and id_token_signed_response_alg in = http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 = and userinfo_signing_alg_values_supported, = id_token_signing_alg_values_supported, and = request_object_signing_alg_values_supported in = http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9. > =20 > -- Mike > =20 > From: William Mills [mailto:wmills_92105@yahoo.com]=20 > Sent: Friday, December 28, 2012 6:07 PM > To: Mike Jones; oauth@ietf.org > Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release > =20 > Mike, > =20 > I've read through the JWT spec and I'm curious about something. How = do I specify a signature requirement as the server? I didn't see it but = I probably just missed it. I'm thinking that with very little work a = JWT can do everything that MAC does with greater flexibility, *BUT* the = server needs to be able to require a signed usage. Something I never = liked about OAuth 1.0 is that the server must support all valid = signature types, even PLAINTEXT, so I want to be able to avoid that. > =20 > It would require the client to be able to include client generated = stuff in the JWT. > =20 > Thanks, > =20 > -bill >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_433E7DCC-D018-458C-8078-4CF948E28CED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 If = everything you want to sign can go in the JWT there is nothing to stop = that.   Otherwise you are back to coming up with a way of doing a = detached signature and putting a hash in the JWT like connect is doing = by putting a hash of the token in the id_token for the "token id_token} = flow.

The hard part is figuring out what needs to be = signed.   

As for client generated = JWT we already have the JWT assertion profile.  Connect is using = that as an option to authenticate to the token = endpoint. 

Would doing a similar thing but = to the RS really work for you?

= --Apple-Mail=_433E7DCC-D018-458C-8078-4CF948E28CED-- From Michael.Jones@microsoft.com Fri Jan 4 15:55:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2221F8A8E for ; Fri, 4 Jan 2013 15:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMIwM0lTj2TM for ; Fri, 4 Jan 2013 15:55:57 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 529EE21F8428 for ; Fri, 4 Jan 2013 15:55:57 -0800 (PST) Received: from BL2FFO11FD006.protection.gbl (10.173.161.200) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.586.12; Fri, 4 Jan 2013 23:55:54 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Fri, 4 Jan 2013 23:55:54 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 4 Jan 2013 23:55:20 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: Ac3q1vQVjnUSZGp4QGSRPD4cbWM9SQ== Date: Fri, 4 Jan 2013 23:55:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669FE5FETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(31966008)(50986001)(47976001)(49866001)(5343635001)(33656001)(51856001)(16236675001)(56816002)(16297215001)(76482001)(5343645001)(53806001)(55846006)(5343655001)(54316002)(512954001)(47736001)(74502001)(59766001)(77982001)(74662001)(54356001)(15202345001)(15395725002)(16406001)(56776001)(4396001)(46102001)(44976002)(47446002)(59253001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB039; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0716E70AB6 Subject: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 23:55:58 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943669FE5FETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed from http://openid.net/specs/openid-connect-registration-1_0-13.html. = Specifically, while the OpenID Connect operation replaces all field values,= the OAuth operation allows only selective fields to be replaced, designati= ng fields to remain unchanged by specifying their value as the empty string= (""). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle "make simple things simple= and make more complicated things possible". Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943669FE5FETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something d= ifferent than the operation upon which it was based from http://openid.net/specs/openid-connect-registration-1_0-13.html. = Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifyin= g their value as the empty string (“”).

 

I'm personally not happy with the change to the sema= ntics of client field inclusion.  Updating some but not all fields is = a substantially more complicated operation than replacing all fields. = Is there some use case that motivates this?  I don't think it's a substantial burden on the registering party to rememb= er all the field values from the initial registration and then selectively = use them for update operations, when needed.  Then the work goes to th= e (I suspect rare) parties that need partial update - not to every server.  It complicates the simple case= , rather than pushing the complexity to the rare case, violating the design= principle “make simple things simple and make more complicated thing= s possible”.

 

Is anyone opposed to updating the OAuth Registration= semantics to match the Connect registration semantics?  Is so, why?

 

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

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943669FE5FETK5EX14MBXC283r_-- From wmills_92105@yahoo.com Fri Jan 4 15:57:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA521F8A8E for ; Fri, 4 Jan 2013 15:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QvRE769+kka for ; Fri, 4 Jan 2013 15:57:13 -0800 (PST) Received: from nm29-vm0.bullet.mail.bf1.yahoo.com (nm29-vm0.bullet.mail.bf1.yahoo.com [98.139.213.166]) by ietfa.amsl.com (Postfix) with ESMTP id E176B21F846E for ; Fri, 4 Jan 2013 15:57:12 -0800 (PST) Received: from [98.139.215.140] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:57:12 -0000 Received: from [98.139.212.192] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:57:12 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 04 Jan 2013 23:57:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 319047.49887.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 83213 invoked by uid 60001); 4 Jan 2013 23:57:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357343831; bh=9heNwMlDuvC02tTnnZcksGBs0QcSYB4snHsKYoLushc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KIrhfkxPRyiX+Wx1aN1zKkshxU/xns+i+swVtImqp995frYkPMsjjLkYwO+buEQBpWJVTSdd08HQhplrrXN5naEc76z33FmpqodFVEWC6d62NNXTwYEOsoHUmzhgsgcxmDqLlxHRcsLEqpHYxJvK+nsgewsCPJRMsPpn47tjkH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l7+EFAr2X6NuoHM4vfyz+lRzB8xsTuwKciYqypgTIxzn4qsVxcyDklClriodAZBh4L1Jzw4xgJgRuX8MGLfQe5FXsyL/TMR5vLJO4EsnIUx7wFngTIhOD+3AM4bvBduICwJvLqdFBhM9TChXmHAaW7MwomK1CDDdqkanwaUMXKE=; X-YMail-OSG: oE9F4OEVM1nhFG_0qf.hB5.PKJ4N0CGignK6AmqW5tnNdgP _Q6CH8NsgkjS5YcmgNyWydXImHuZp1LFekXuKzfyNdHoRVMZGvd4o367nlwz aGRww1T3xBAj3XhRNUEgVRJzVCtBukm59ZiSZwGFgodGqqtM20S_LfYQrQO3 idTXXkM2pXo636zWUt0XzEX.YH9J92lD1sdS1rHBIQhf9D.HARYPGs4QXcnG B5pKJ4uginUyD3EB1TJWTrUTaJf0tnRKNFCJbKhQU1Q0qxbG.4x_2CdCFO3P 5U0831zL6gzHOE1akDtv3lqNy36qwewi4kB0KHxMEWONBidwCTXRnD8StY8m ibgbGlB7trYSu775RAJWwypPAHTbbEjGnglV6nEB6udAiMVRnBYdSmf6lRFF piRpsMyBlcSpo0w67Q.Wt3lU7mQoKyRnFixFC6zKaUvKi02gZVQFnUNyKj5T _IXO1PiJAo5v_ViBF1ngnfqobnnKYufGNujKmX5..Dlq0ebCkCQXUTQeEqUJ MxYThHZZrsyAU0yL40KuxaXu16P5GU30MziGnV.7h_HYG_IZXQjr3F7e5GW4 0AM.b262RuJC8YbfpiZ0IQ4VGq7WqHAe2q7vLQ7ZltM8dW0E_7hSy7yo99iB yg4VbrDWdZhU3VG.azkNDa6i61CxsWrO.S9BR88AwX5GtHXlFycE2oo4sgbF wtaEfIm1P5aCsKg-- Received: from [209.131.62.113] by web31810.mail.mud.yahoo.com via HTTP; Fri, 04 Jan 2013 15:57:11 PST X-Rocket-MIMEInfo: 001.001, WWVhaCwgSSB0aGluayBpdCB3b3VsZCB3b3JrLiBBZGRpbmcgY2xpZW50IGFzc2VydGVkIEpXVCBwYXlsb2FkIHdvdWxkIGFsc28gbmljZWx5IGdldCBvdXQgb2YgdGhlIHdob2xlIHF1ZXN0aW9uIG9mIHdoZXJlIHRoZSBub25jZSwgdGltZXN0YW1wLCBhbmQgc3VjaCBnbyBhbmQgd2hldGhlciB0aGV5IGNhbiBiZSBwYXJ0IG9mIHRoZSBxdWVyeSBzdHJpbmcsIHdoaWNoIHdhcyBhbHdheXMgYW5ub3lpbmcgd2l0aCBNQUMgYW5kIE9BdXRoIDEuCgpXZSBzdGlsbCBoYXZlIHRoZSBwcm9ibGVtIHRoYXQgc29tZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> <1357339700.37914.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1357343831.30497.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Fri, 4 Jan 2013 15:57:11 -0800 (PST) From: William Mills To: John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-435661301-1357343831=:30497" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 23:57:14 -0000 --1935884094-435661301-1357343831=:30497 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, I think it would work. Adding client asserted JWT payload would also = nicely get out of the whole question of where the nonce, timestamp, and suc= h go and whether they can be part of the query string, which was always ann= oying with MAC and OAuth 1.=0A=0AWe still have the problem that some client= s don't know what order the query or post arguments will be generated in, b= ut that wasn't resolved yet anyway.=0A=0AHow do we solve for the server req= uiring a specific set of supported hashes and feeding that back to the clie= nt?=0A=0A-bill=0A=0A=0A________________________________=0A From: John Bradl= ey =0ATo: William Mills =0ACc: = Mike Jones ; "oauth@ietf.org" = =0ASent: Friday, January 4, 2013 3:44 PM=0ASubject: Re: [OAUTH-WG] Decembe= r 27, 2012 OAuth Release=0A =0A=0AIf everything you want to sign can go in = the JWT there is nothing to stop that. =C2=A0 Otherwise you are back to com= ing up with a way of doing a detached signature and putting a hash in the J= WT like connect is doing by putting a hash of the token in the id_token for= the "token id_token} flow.=0A=0AThe hard part is figuring out what needs t= o be signed. =C2=A0=C2=A0=0A=0AAs for client generated JWT we already have = the JWT assertion profile. =C2=A0Connect is using that as an option to auth= enticate to the token endpoint.=C2=A0=0A=0AWould doing a similar thing but = to the RS really work for you?=0A=0AJohn B.=0A=0AOn 2013-01-04, at 7:48 PM,= William Mills wrote:=0A=0AIt's the core problem I= see MAC solving. =C2=A0I'd be happy enough to define a JWT variant that do= es this if that's easier than MAC. =C2=A0What do you think?=0A>=0A>=0A>=0A>= ________________________________=0A> From: Mike Jones =0A>To: William Mills ; "oauth@ietf.org" =0A>Sent: Friday, January 4, 2013 2:35 PM=0A>Subject: RE: [O= AUTH-WG] December 27, 2012 OAuth Release=0A> =0A>=0A> =0A>There=E2=80=99s n= o generic OAuth way to do this.=C2=A0 There is a way to do it in OpenID Con= nect =E2=80=93 see request_object_signing_alg, userinfo_signed_response_alg= , and id_token_signed_response_algin=0Ahttp://openid.net/specs/openid-conne= ct-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_suppor= ted, id_token_signing_alg_values_supported, and request_object_signing_alg_= values_supportedin=0Ahttp://openid.net/specs/openid-connect-discovery-1_0-1= 1.html#anchor9.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike=0A>=C2=A0=0A>From:William Mills [mailto:wmills_92105@yaho= o.com] =0A>Sent: Friday, December 28, 2012 6:07 PM=0A>To: Mike Jones; oauth= @ietf.org=0A>Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release=0A>=C2= =A0=0A>Mike,=0A>=C2=A0=0A>I've read through the JWT spec and I'm curious ab= out something. =C2=A0How do I specify a signature requirement as the server= ? =C2=A0I didn't see it but I probably just missed it. =C2=A0I'm thinking t= hat with very little work a JWT can do everything that MAC does with greate= r flexibility, *BUT* the server needs to be able to require a signed usage.= =C2=A0Something I never liked about OAuth 1.0 is that the server must supp= ort all valid signature types, even PLAINTEXT, so I want to be able to avoi= d that.=0A>=C2=A0=0A>It would require the client to be able to include clie= nt generated stuff in the JWT.=0A>=C2=A0=0A>Thanks,=0A>=C2=A0=0A>-bill=0A>= =0A>_______________________________________________=0A>OAuth mailing list= =0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A> --1935884094-435661301-1357343831=:30497 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yeah, I think it would work. Adding client asserted JWT payload would als= o nicely get out of the whole question of where the nonce, timestamp, and s= uch go and whether they can be part of the query string, which was always a= nnoying with MAC and OAuth 1.

<= /span>
We still have the problem that some= clients don't know what order the query or post arguments will be generate= d in, but that wasn't resolved yet anyway.
How do we solve for the serv= er requiring a specific set of supported hashes and feeding that back to th= e client?

-bill<= /div>

From: John Bradley <ve7jtb@ve7jtb.com&= gt;
To: William Mills = <wmills_92105@yahoo.com>
Cc= : Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.or= g" <oauth@ietf.org>
Sent:<= /span> Friday, January 4, 2013 3:44 PM
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Releas= e

=0A
If everything yo= u want to sign can go in the JWT there is nothing to stop that.   Othe= rwise you are back to coming up with a way of doing a detached signature an= d putting a hash in the JWT like connect is doing by putting a hash of the = token in the id_token for the "token id_token} flow.

The= hard part is figuring out what needs to be signed.   
=
As for client generated JWT we already have the JWT assertio= n profile.  Connect is using that as an option to authenticate to the = token endpoint. 

Would doing a similar thing = but to the RS really work for you?

John B.
On 2013-01-04, at 7:48 PM, William Mills <wmills_92105@yahoo.com> wrote:

<= span>It's the core problem I see MAC solving.  I'd be happy enough to = define a JWT variant that does this if that's easier than MAC.  What d= o you think?

= From: Mike Jones <Michael.Jones@microsoft.c= om>
To: William = Mills <wmills_92105@yahoo.com>; "= oauth@ietf.org" <oauth@ietf.org>
Sent:= Friday, January 4, 2013 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Rel= ease

=0A
=0A=0A =0A =0A=0A=0A
= =0A
=0A
There=E2=80=99s n= o generic OAuth way to do this.  There is a way to do it in OpenID Con= nect =E2=80=93 see=0Arequest_object_sig= ning_alg,=0A<= span lang=3D"EN" style=3D"">userinfo_signed_response_alg, and=0Aid_token_signed_response_alg in=0Ahttp://openid.net/specs/openid-connect-registration-1_0= -13.html#anchor3 and =0Auserinfo_signing_alg_values= _supported,=0Aid_token_signing_alg_values_supported, and=0Areques= t_object_signing_alg_values_supported in=0Ahttp://openid.net/specs/openid-connect-discovery-1_0= -11.html#anchor9.
=0A
 
=0A
           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          -- Mike<= /div> =0A
 
=0A
=0A
=0A
From: William Mills [mailto:wmills_92105= @yahoo.com= ]=0A
=0ASent: Friday, December 28, 2012 6:07 PM
=0ATo:<= /b> Mike Jones; oauth@ietf.org
=0ASub= ject: Re: [OAUTH-WG] December 27, 2012 OAuth Release
=0A=0A
=0A
 
=0A=0A
=0A
Mike,
=0A
=0A
=0A
 <= /span>
=0A
=0A
=0A
I've read through the JWT spec and I'm curious about something= .  How do I specify a signature requirement as the server?  I did= n't see it but I probably just missed it.  I'm thinking that=0A with v= ery little work a JWT can do everything that MAC does with greater flexibil= ity, *BUT* the server needs to be able to require a signed usage.  Som= ething I never liked about OAuth 1.0 is that the server must support all va= lid signature types, even PLAINTEXT,=0A so I want to be able to avoid that.=
=0A
=0A
=0A
 
=0A
=0A
=0A
It would require the client to be able t= o include client generated stuff in the JWT.
=0A
=0A
= =0A
  =0A
=0A
=0A
Thanks,
=0A
=0A
=0A
 
=0A
=0A
=0A
-bill
=0A=0A
=0A
=0A
=0A=0A


_______________________________________________
OAuth mailing list
<= a rel=3D"nofollow" ymailto=3D"mailto:OAuth@ietf.org" target=3D"_blank" href= =3D"mailto:OAuth@ietf.org">OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth



--1935884094-435661301-1357343831=:30497-- From ve7jtb@ve7jtb.com Fri Jan 4 16:10:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC021F8797 for ; Fri, 4 Jan 2013 16:10:10 -0800 (PST) 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=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXaY1l40GazF for ; Fri, 4 Jan 2013 16:10:09 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1E21F86BA for ; Fri, 4 Jan 2013 16:10:09 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so17184395vcb.15 for ; Fri, 04 Jan 2013 16:10:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=bznY+FTqSxyq8JsLaq08J5b9xK/V+wEpanjrdbH/cHU=; b=LaXYnTpyw4vF5GK7ITQ3B2mg8QqMAiu62TBuTUqNlfRU2+2/46f86r9Hm7oY+1/XZM mNN2yAKm4tQb65HoPlobW3EOh2IYuJhOnB1tlRPgfVr7EWnBdV1/ZnuvIIbGqLdlqZbX xqncbnNh00pVLdE3C/YTM4cTuhgxiz6z4UXqM5uDcZcEh6bb6mySTFvQsWxR2zu641lu 5/rcC+8tz5yeVNpnRV7VokZED8nfZWvr3oLRtgWIeCkfog5hExuKPqBNNpzFdwaVH+0q dNJEcbixN3nP4p5O/cKrMtWd9VoYmXOR0E2014k3H1kZ5fZSNjODRk/w0bWDDui37fOm 0SAg== X-Received: by 10.58.198.135 with SMTP id jc7mr78987293vec.51.1357344608736; Fri, 04 Jan 2013 16:10:08 -0800 (PST) Received: from [192.168.1.211] (190-20-25-66.baf.movistar.cl. [190.20.25.66]) by mx.google.com with ESMTPS id y7sm47693319vdt.14.2013.01.04.16.10.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:10:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_95E905EA-4532-45AD-9C6C-074E7DF382A8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <1357343831.30497.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Fri, 4 Jan 2013 21:09:58 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com> <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B1680429673943669FE2AD@TK5EX14MBXC283.redmond.corp.microsoft.com> <1357339700.37914.YahooMailNeo@web31816.mail.mud.yahoo.com> <1357343831.30497.YahooMailNeo@web31810.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnwb/lHgo1CNMsTG2+7rwnoJQgEgoyPxyvtxAl0usD3RSHuf+B2rhVAe9HNCujo2f2Kuk3R Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:10:10 -0000 --Apple-Mail=_95E905EA-4532-45AD-9C6C-074E7DF382A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In the Connect case part of discovery is a JSON document in .well-known = that describes the servers capabilities.=20 Something similar might work. There is nothing JWT specific about the = connect document though we do specify the JWA set of algorithms and JWK = for publishing keys. John On 2013-01-04, at 8:57 PM, William Mills wrote: > Yeah, I think it would work. Adding client asserted JWT payload would = also nicely get out of the whole question of where the nonce, timestamp, = and such go and whether they can be part of the query string, which was = always annoying with MAC and OAuth 1. >=20 > We still have the problem that some clients don't know what order the = query or post arguments will be generated in, but that wasn't resolved = yet anyway. >=20 > How do we solve for the server requiring a specific set of supported = hashes and feeding that back to the client? >=20 > -bill >=20 > From: John Bradley > To: William Mills =20 > Cc: Mike Jones ; "oauth@ietf.org" = =20 > Sent: Friday, January 4, 2013 3:44 PM > Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release >=20 > If everything you want to sign can go in the JWT there is nothing to = stop that. Otherwise you are back to coming up with a way of doing a = detached signature and putting a hash in the JWT like connect is doing = by putting a hash of the token in the id_token for the "token id_token} = flow. >=20 > The hard part is figuring out what needs to be signed. =20 >=20 > As for client generated JWT we already have the JWT assertion profile. = Connect is using that as an option to authenticate to the token = endpoint.=20 >=20 > Would doing a similar thing but to the RS really work for you? >=20 > John B. > On 2013-01-04, at 7:48 PM, William Mills = wrote: >=20 >> It's the core problem I see MAC solving. I'd be happy enough to = define a JWT variant that does this if that's easier than MAC. What do = you think? >>=20 >> From: Mike Jones >> To: William Mills ; "oauth@ietf.org" = =20 >> Sent: Friday, January 4, 2013 2:35 PM >> Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release >>=20 >> There=92s no generic OAuth way to do this. There is a way to do it = in OpenID Connect =96 see request_object_signing_alg, = userinfo_signed_response_alg, and id_token_signed_response_alg in = http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 = and userinfo_signing_alg_values_supported, = id_token_signing_alg_values_supported, and = request_object_signing_alg_values_supported in = http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9. >> =20 >> -- Mike >> =20 >> From: William Mills [mailto:wmills_92105@yahoo.com]=20 >> Sent: Friday, December 28, 2012 6:07 PM >> To: Mike Jones; oauth@ietf.org >> Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release >> =20 >> Mike, >> =20 >> I've read through the JWT spec and I'm curious about something. How = do I specify a signature requirement as the server? I didn't see it but = I probably just missed it. I'm thinking that with very little work a = JWT can do everything that MAC does with greater flexibility, *BUT* the = server needs to be able to require a signed usage. Something I never = liked about OAuth 1.0 is that the server must support all valid = signature types, even PLAINTEXT, so I want to be able to avoid that. >> =20 >> It would require the client to be able to include client generated = stuff in the JWT. >> =20 >> Thanks, >> =20 >> -bill >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 --Apple-Mail=_95E905EA-4532-45AD-9C6C-074E7DF382A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 In = the Connect case part of discovery is a JSON document in .well-known = that describes the servers capabilities. 
Something similar = might work.  There is nothing JWT specific about the connect = document though we do specify the JWA set of algorithms and JWK for = publishing keys.

John
On = 2013-01-04, at 8:57 PM, William Mills <wmills_92105@yahoo.com> = wrote:

Yeah, I think it would work. Adding client = asserted JWT payload would also nicely get out of the whole question of = where the nonce, timestamp, and such go and whether they can be part of = the query string, which was always annoying with MAC and OAuth = 1.

We still have the problem that some clients don't know = what order the query or post arguments will be generated in, but that = wasn't resolved yet anyway.
How do we solve for the server = requiring a specific set of supported hashes and feeding that back to = the client?

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com> =
Cc: Mike Jones = <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, January 4, 2013 = 3:44 PM
Subject: = Re: [OAUTH-WG] December 27, 2012 OAuth Release

If everything you want to sign can go in the = JWT there is nothing to stop that.   Otherwise you are back to = coming up with a way of doing a detached signature and putting a hash in = the JWT like connect is doing by putting a hash of the token in the = id_token for the "token id_token} flow.

The hard part = is figuring out what needs to be signed. =   

As for client generated JWT we = already have the JWT assertion profile.  Connect is using that as = an option to authenticate to the token = endpoint. 

Would doing a similar thing but = to the RS really work for you?

John = B.
On 2013-01-04, at 7:48 PM, William Mills <wmills_92105@yahoo.com> = wrote:

It's the core problem I see MAC solving. =  I'd be happy enough to define a JWT variant that does this if = that's easier than MAC.  What do you = think?

=
From: = Mike Jones <Michael.Jones@microsoft.com>
To: William = Mills <wmills_92105@yahoo.com>; = "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, January 4, 2013 = 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 = OAuth Release

=20 =20
There=92s no generic OAuth way = to do this.  There is a way to do it in OpenID Connect =96 see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_alg in http://openid.net/specs/openid-connect-registration-1_0-13.html#anc= hor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.
=20
 
=20
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;     -- Mike
=20
 
=20
From: William Mills [mailto:wmills_92105@yahoo.com]
Sent: Friday, December 28, 2012 6:07 PM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth = Release
=20
 
=20
Mike,
=20
 
=20
I've read through = the JWT spec and I'm curious about something.  How do I specify a = signature requirement as the server?  I didn't see it but I = probably just missed it.  I'm thinking that with very little work a JWT can do everything that MAC does with = greater flexibility, *BUT* the server needs to be able to require a = signed usage.  Something I never liked about OAuth 1.0 is that the = server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that.
=20
=  
=20
It would require = the client to be able to include client generated stuff in the = JWT.
=20
=  
=20
Thanks,
=20
=  
=20
-bill
=20=


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



=

= --Apple-Mail=_95E905EA-4532-45AD-9C6C-074E7DF382A8-- From ve7jtb@ve7jtb.com Fri Jan 4 16:13:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC721F87D6 for ; Fri, 4 Jan 2013 16:13:56 -0800 (PST) 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=[AWL=0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A544m-o85nXb for ; Fri, 4 Jan 2013 16:13:55 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B250921F84E4 for ; Fri, 4 Jan 2013 16:13:55 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so17517694vcb.3 for ; Fri, 04 Jan 2013 16:13:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ADyQ19IUT72IoMb4Uxdf39h899DCyk1B5qIQUzpvxNI=; b=U8s4qway1k7ChZ1xxLA+N/DrfcxC3c4O6Xlf5WkGmX6DLmXnOmyWIX8F1wvDNkzNzm C6VfY4MqesUvVsHGf7u/oIFxN979dpItynfFv6zCNatGeP2lCZAeNVaLInV6GNGNF8Ju lUhWTZSNJQOZ3PMRlqqEaAxcZx5sGvaIJEhWseSJi95Kz9W4xxKZ0uf3wuSk/BomHJuo rSslfHM0FdXjeD17U1eww5DHaxDoEagFaIJZvRyMvK4RPfaD3hrDvWwTkI8CBUKR0Gxm vOsNargVSwmTeY/wI84ZGe9AHl/fnRGWm4MNTjTyECBQol829rs0Q9IjgFKZD4gDtKah g15A== X-Received: by 10.52.32.229 with SMTP id m5mr68428482vdi.5.1357344835139; Fri, 04 Jan 2013 16:13:55 -0800 (PST) Received: from [192.168.1.211] (190-20-25-66.baf.movistar.cl. [190.20.25.66]) by mx.google.com with ESMTPS id z10sm47697912vds.17.2013.01.04.16.13.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:13:54 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_80A50A37-5DCC-498F-B70F-2CDE79FB1C5C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 4 Jan 2013 21:13:45 -0300 Message-Id: <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmPZkdeaJ0F5e0rAfsIdJYmVO4Tu69MIjBPagVLImS701oQ4chRlm9iELWyOu5MDQbEEync Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:13:56 -0000 --Apple-Mail=_80A50A37-5DCC-498F-B70F-2CDE79FB1C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents = unknown states if a update fails. =20 I think the always replace everything rule is simpler, though admittedly = more bandwidth is required. However bandwidth is not a significant = factor for this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones = wrote: > The client_update operation in = http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something = different than the operation upon which it was based = fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. = Specifically, while the OpenID Connect operation replaces all field = values, the OAuth operation allows only selective fields to be replaced, = designating fields to remain unchanged by specifying their value as the = empty string (=93=94). > =20 > I'm personally not happy with the change to the semantics of client = field inclusion. Updating some but not all fields is a substantially = more complicated operation than replacing all fields. Is there some use = case that motivates this? I don't think it's a substantial burden on = the registering party to remember all the field values from the initial = registration and then selectively use them for update operations, when = needed. Then the work goes to the (I suspect rare) parties that need = partial update - not to every server. It complicates the simple case, = rather than pushing the complexity to the rare case, violating the = design principle =93make simple things simple and make more complicated = things possible=94. > =20 > Is anyone opposed to updating the OAuth Registration semantics to = match the Connect registration semantics? Is so, why? > =20 > = Thanks, > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_80A50A37-5DCC-498F-B70F-2CDE79FB1C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We did discuss this issue in = the connect WG.

The decision was made to always = completely replace.   That prevents unknown states if a update = fails.   

I think the always replace = everything rule is simpler, though admittedly more bandwidth is = required.  However bandwidth is not a significant factor for this = as far as I know.

John = B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The client_update operation in  does something different = than the operation upon which it was based fromI'm personally not = happy with the change to the semantics of client field inclusion.  = Updating some but not all fields is a substantially more complicated = operation than replacing all fields.  Is there some use case that = motivates this?  I don't think it's a substantial burden on the = registering party to remember all the field values from the initial = registration and then selectively use them for update operations, when = needed.  Then the work goes to the (I suspect rare) parties that = need partial update - not to every server.  It complicates the = simple case, rather than pushing the complexity to the rare case, = violating the design principle =93make simple things simple and make = more complicated things possible=94.
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 05:55:53 -0000 ---1238014912-1157172462-1357365347=:39851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That would work. =C2=A0Register a link relation property for supported sign= ing methods.=0A=0A=0A________________________________=0A From: John Bradley= =0ATo: William Mills =0ACc: Mi= ke Jones ; "oauth@ietf.org" = =0ASent: Friday, January 4, 2013 4:09 PM=0ASubject: Re: [OAUTH-WG] December= 27, 2012 OAuth Release=0A =0A=0AIn the Connect case part of discovery is a= JSON document in .well-known that describes the servers capabilities.=C2= =A0=0ASomething similar might work. =C2=A0There is nothing JWT specific abo= ut the connect document though we do specify the JWA set of algorithms and = JWK for publishing keys.=0A=0AJohn=0A=0AOn 2013-01-04, at 8:57 PM, William = Mills wrote:=0A=0AYeah, I think it would work. Add= ing client asserted JWT payload would also nicely get out of the whole ques= tion of where the nonce, timestamp, and such go and whether they can be par= t of the query string, which was always annoying with MAC and OAuth 1.=0A>= =0A>=0A>We still have the problem that some clients don't know what order t= he query or post arguments will be generated in, but that wasn't resolved y= et anyway.=0A>=0A>=0A>How do we solve for the server requiring a specific s= et of supported hashes and feeding that back to the client?=0A>=0A>=0A>-bil= l=0A>=0A>=0A>=0A>________________________________=0A> From: John Bradley =0A>To: William Mills =0A>Cc: Mik= e Jones ; "oauth@ietf.org" = =0A>Sent: Friday, January 4, 2013 3:44 PM=0A>Subject: Re: [OAUTH-WG] Decemb= er 27, 2012 OAuth Release=0A> =0A>=0A>If everything you want to sign can go= in the JWT there is nothing to stop that. =C2=A0 Otherwise you are back to= coming up with a way of doing a detached signature and putting a hash in t= he JWT like connect is doing by putting a hash of the token in the id_token= for the "token id_token} flow.=0A>=0A>=0A>The hard part is figuring out wh= at needs to be signed. =C2=A0=C2=A0=0A>=0A>=0A>As for client generated JWT = we already have the JWT assertion profile. =C2=A0Connect is using that as a= n option to authenticate to the token endpoint.=C2=A0=0A>=0A>=0A>Would doin= g a similar thing but to the RS really work for you?=0A>=0A>=0A>John B.=0A>= =0A>On 2013-01-04, at 7:48 PM, William Mills wrote= :=0A>=0A>It's the core problem I see MAC solving. =C2=A0I'd be happy enough= to define a JWT variant that does this if that's easier than MAC. =C2=A0Wh= at do you think?=0A>>=0A>>=0A>>=0A>>________________________________=0A>> F= rom: Mike Jones =0A>>To: William Mills ; "oauth@ietf.org" =0A>>Sent: Friday, Jan= uary 4, 2013 2:35 PM=0A>>Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Re= lease=0A>> =0A>>=0A>> =0A>>There=E2=80=99s no generic OAuth way to do this.= =C2=A0 There is a way to do it in OpenID Connect =E2=80=93 see request_obje= ct_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_= algin=0Ahttp://openid.net/specs/openid-connect-registration-1_0-13.html#anc= hor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_value= s_supported, and request_object_signing_alg_values_supportedin=0Ahttp://ope= nid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.=0A>>=C2=A0=0A>>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>>=C2=A0= =0A>>From:William Mills [mailto:wmills_92105@yahoo.com] =0A>>Sent: Friday, = December 28, 2012 6:07 PM=0A>>To: Mike Jones; oauth@ietf.org=0A>>Subject: R= e: [OAUTH-WG] December 27, 2012 OAuth Release=0A>>=C2=A0=0A>>Mike,=0A>>=C2= =A0=0A>>I've read through the JWT spec and I'm curious about something. =C2= =A0How do I specify a signature requirement as the server? =C2=A0I didn't s= ee it but I probably just missed it. =C2=A0I'm thinking that with very litt= le work a JWT can do everything that MAC does with greater flexibility, *BU= T* the server needs to be able to require a signed usage. =C2=A0Something I= never liked about OAuth 1.0 is that the server must support all valid sign= ature types, even PLAINTEXT, so I want to be able to avoid that.=0A>>=C2=A0= =0A>>It would require the client to be able to include client generated stu= ff in the JWT.=0A>>=C2=A0=0A>>Thanks,=0A>>=C2=A0=0A>>-bill=0A>>=0A>>_______= ________________________________________=0A>>OAuth mailing list=0A>>OAuth@i= etf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A>=0A>=0A> ---1238014912-1157172462-1357365347=:39851 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That would work.  Register a link relation property for supported si= gning methods.

From: John Bradley <= ve7jtb@ve7jtb.com>
To:<= /b> William Mills <wmills_92105@yahoo.com>
Cc: Mike Jones <Michael.Jones@microsoft.com&g= t;; "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, January 4, 2013 4:09 PM
Subject: Re: [OAUTH-WG] December 2= 7, 2012 OAuth Release

=0A
In the Connect case part of discovery is a JSON document in .well-known = that describes the servers capabilities. 
Something similar might = work.  There is nothing JWT specific about the connect document though= we do specify the JWA set of algorithms and JWK for publishing keys.
=

John

Yeah, I think it would work. Adding client asserted J= WT payload would also nicely get out of the whole question of where the non= ce, timestamp, and such go and whether they can be part of the query string, which was always annoying with MAC and OAuth 1.

We still have the problem that some c= lients don't know what order the query or post arguments will be generated = in, but that wasn't resolved yet anyway.

How do we solve for the server requiring a specific set of supported hashes and feeding that back to the client?

-bill

=
From: John Bradley <ve7jtb@ve7jtb.com>
T= o: William Mills <wmills_92105@yaho= o.com>
Cc: Mike = Jones <Michael.Jon= es@microsoft.com>; "oauth@ietf.org" = <oauth@ietf.org>
Sent: Friday, January 4, 2013 3:44 PM
= Subject: Re: [OAUTH-WG] De= cember 27, 2012 OAuth Release

=0A
If everything you want to sign can go in the JWT there is nothing to = stop that.   Otherwise you are back to coming up with a way of doing a= detached signature and putting a hash in the JWT like connect is doing by = putting a hash of the token in the id_token for the "token id_token} flow.<= div>
The hard part is figuring out what needs to be signed. &= nbsp; 

As for client generated JWT we already= have the JWT assertion profile.  Connect is using that as an option t= o authenticate to the token endpoint. 

Would = doing a similar thing but to the RS really work for you?

John B.
On 2013-01-04, at 7:48 PM, William Mills <wmills_92105@yahoo.com> wr= ote:

=
It's the core problem I see MAC solving.  I'd be happy enough to d= efine a JWT variant that does this if that's easier than MAC.  What do= you think?

= From: Mike Jones <Michael.Jones@microsoft.co= m>
To: William M= ills <wmills_92105@yahoo.com>; "= oauth@ietf.org" <oauth@ietf.org>
Sent:= Friday, January 4, 2013 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Releas= e

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
There=E2=80=99s no generic OAuth way to do this.&= nbsp; There is a way to do it in OpenID Connect =E2=80=93 see=0Arequest_object_signing_alg,=0Auser= info_signed_response_alg, and=0Aid_token_signed_response_al= g in=0Ahttp://openid= .net/specs/openid-connect-registration-1_0-13.html#anchor3 and =0Auserinfo_signing_alg_values_supported,=0Aid_token_signin= g_alg_values_supported, and=0Arequest_object_signing_alg_values_support= ed in=0Ahttp://openi= d.net/specs/openid-connect-discovery-1_0-11.html#anchor9.
=0A<= div class=3D"yiv274277948MsoNormal">  
=0A
     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    -- Mike
=0A
  =0A
=0A
=0A
From: William Mills [mailto:wmills_92105@yahoo.com]=0A
=0ASent: Friday, Dec= ember 28, 2012 6:07 PM
=0ATo: Mike Jones; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] December 27, 2= 012 OAuth Release
=0A
=0A
=0A
 
=0A
=0A
=0A
Mike,
= =0A
=0A
=0A
 
=0A
=0A
=0A
I've read through the JWT sp= ec and I'm curious about something.  How do I specify a signature requ= irement as the server?  I didn't see it but I probably just missed it.=  I'm thinking that=0A with very little work a JWT can do everything t= hat MAC does with greater flexibility, *BUT* the server needs to be able to= require a signed usage.  Something I never liked about OAuth 1.0 is t= hat the server must support all valid signature types, even PLAINTEXT,=0A s= o I want to be able to avoid that.
=0A
=0A
=0A
 
=0A=0A
=0A
It would= require the client to be able to include client generated stuff in the JWT= .
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks,
=0A
=0A
=0A=
 
= =0A
=0A
=0A
-= bill
=0A
=0A
=0A
=0A
=0A=0A


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






John = B.

It's the core problem I see MAC solving. =  I'd be happy enough to define a JWT variant that does this if = that's easier than MAC.  What do you = think?

=
From: = Mike Jones <Michael.Jones@microsoft.com>
To: William = Mills <wmills_92105@yahoo.com>; = "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, January 4, 2013 = 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 OAuth = Release

=20 =20
There=92s no generic OAuth way = to do this.  There is a way to do it in OpenID Connect =96 see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_alg in http://openid.net/specs/openid-connect-registration-1_0-13.html#anc= hor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.
=20
 
=20
     &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;     -- Mike
=20
 
=20
From: William Mills [mailto:wmills_92105@yahoo.com]
Sent: Friday, December 28, 2012 6:07 PM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth = Release
=20
 
=20
Mike,
=20
 
=20
I've read through = the JWT spec and I'm curious about something.  How do I specify a = signature requirement as the server?  I didn't see it but I = probably just missed it.  I'm thinking that with very little work a JWT can do everything that MAC does with = greater flexibility, *BUT* the server needs to be able to require a = signed usage.  Something I never liked about OAuth 1.0 is that the = server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that.
=20
=  
=20
It would require = the client to be able to include client generated stuff in the = JWT.
=20
=  
=20
Thanks,
=20
=  
=20
-bill
=20=


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

---1238014912-1157172462-1357365347=:39851-- From jricher@mitre.org Sat Jan 5 11:36:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C121F85E0 for ; Sat, 5 Jan 2013 11:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oxiNfM46JyY for ; Sat, 5 Jan 2013 11:36:34 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE521F84F6 for ; Sat, 5 Jan 2013 11:36:33 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA79F45100A3; Sat, 5 Jan 2013 14:36:32 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BAF891F0E24; Sat, 5 Jan 2013 14:36:32 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Sat, 5 Jan 2013 14:36:32 -0500 From: "Richer, Justin P." To: John Bradley , Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN6tmRSuZCiMudYEeGs+CqEq13PJg7Gpme Date: Sat, 5 Jan 2013 19:36:31 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> In-Reply-To: <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E068701E6IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 19:36:35 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E068701E6IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bra= dley [ve7jtb@ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E068701E6IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mike, John, thanks for the feedback. I hope and anticipate that this= conversation will help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide".

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple".

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field.

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin



From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Friday, January 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Difference between client_update semantics i= n draft-ietf-oauth-dyn-reg and OpenID Connect Registration

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That preven= ts unknown states if a update fails.   

I think the always replace everything rule is simpler, though admitted= ly more bandwidth is required.  However bandwidth is not a significant= factor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

The client_update operation in <= /span>http://to= ols.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openi= d.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 
I'm personally not happy with the change to the semantics of client field i= nclusion.  Updating some but not all fields is a substantially more co= mplicated operation than replacing all fields.  Is there some use case= that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field va= lues from the initial registration and then selectively use them for update= operations, when needed.  Then the work goes to the (I suspect rare) = parties that need partial update - not to every server.  It complicates the simple case, rather than pushing= the complexity to the rare case, violating the design principle =93make si= mple things simple and make more complicated things possible=94.
 
Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics?  Is so, why?
 
            &nb= sp;            =             &nb= sp;            =             &nb= sp; Thanks,
            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E068701E6IMCMBX01MITREOR_-- From nov@matake.jp Mon Jan 7 03:54:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF621F86AC for ; Mon, 7 Jan 2013 03:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx+e90BpSlKV for ; Mon, 7 Jan 2013 03:54:04 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1520221F853C for ; Mon, 7 Jan 2013 03:54:03 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so8632289dac.40 for ; Mon, 07 Jan 2013 03:54:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer:x-gm-message-state; bh=LJ4sml1GNO5Cop5DY4nPUlVCHutOujeE282TO1OvSmM=; b=hnISxNJ0sHzlYZ+Ed88tDrNb9XqIwhrwF9A0iaSu9JflkYoF6sysaN2t/Bnk/ccW7u Otj2Jb0JmxyW8DKqGqXYZznAcd+dTPYXrzqJZkD9k7YsxoF5UcAiD7/BkLKJKh3ygfJk QU17/fy0/tGHcY/gShv+FUK42khgtAhuRpzRk5xuep2p2Q5zzDcLjVaQbTJXa/2jf5+9 +xcPzLQFsYVZ6l+CBTwNpD+CvWIhNt4zWkPpE8YtTPIBq3oxppn0JNnmf+BkCdYVHac/ JClAWGVU03nEkHESBMJ5ve9ilYL7CKcRs7CX1/MNM754b2dyuNodQnKOuHsfWgtDPxlP oh1Q== X-Received: by 10.66.82.162 with SMTP id j2mr177207175pay.13.1357559643370; Mon, 07 Jan 2013 03:54:03 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id d1sm38621117pav.6.2013.01.07.03.54.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Jan 2013 03:54:02 -0800 (PST) From: nov matake Content-Type: multipart/alternative; boundary="Apple-Mail=_BCAB65A4-22B4-4B61-A3F8-4D85AD24E594" Message-Id: <315782BC-0135-4A0C-8541-F0A002B9C30F@matake.jp> Date: Mon, 7 Jan 2013 20:53:59 +0900 To: "WG oauth@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmSLpQRO5LPLnDnw3cbgacQeOEsf4BAQ5XFQcXDUPPjM4LG20N2EziV+UNmt1NV5IeL0lCH Subject: [OAUTH-WG] Question on diff between draft31 and RFC6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 11:54:04 -0000 --Apple-Mail=_BCAB65A4-22B4-4B61-A3F8-4D85AD24E594 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I couldn't understand why "their" became "the third party's" in the diff = between draft31 and RFC6749 below. =3D=3D=3D Resource owners cannot revoke access to an individual third-party third = party without revoking access to all third-parties, third parties, and must do = so by changing their the third party's password. (from http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Drfc6749) =3D=3D=3D I read "their" as "resource owners'". Is this typo, or am I missing some point? Thanks nov= --Apple-Mail=_BCAB65A4-22B4-4B61-A3F8-4D85AD24E594 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

=3D=3D=3D
Resource = owners cannot revoke access to an individual third-party third party
without revoking = access to all third-parties, = third parties, and must do = so by
changing their= the third party's = password.


<= /body>= --Apple-Mail=_BCAB65A4-22B4-4B61-A3F8-4D85AD24E594-- From internet-drafts@ietf.org Mon Jan 7 04:00:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374D21F8763; Mon, 7 Jan 2013 04:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe7alwPoyWtr; Mon, 7 Jan 2013 04:00:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76F21F874B; Mon, 7 Jan 2013 04:00:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 04:00:57 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 12:00:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-04.txt Pages : 8 Date : 2013-01-07 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Mon Jan 7 04:08:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5F21F8477 for ; Mon, 7 Jan 2013 04:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m+WHondnItc for ; Mon, 7 Jan 2013 04:08:31 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by ietfa.amsl.com (Postfix) with ESMTP id B188621F849A for ; Mon, 7 Jan 2013 04:08:21 -0800 (PST) Received: from [79.253.14.73] (helo=[192.168.71.36]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TsBV6-0003Xy-5L for oauth@ietf.org; Mon, 07 Jan 2013 13:08:20 +0100 Message-ID: <50EABAB0.4060807@lodderstedt.net> Date: Mon, 07 Jan 2013 13:08:16 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> In-Reply-To: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 12:08:32 -0000 Hi, the new revision is based on the WGLC feedback and incorporates the following changes: - renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda) - improved formatting of section 2.1. (feedback by Amanda) - improved wording of last paragraph of section 6 (feedback by Amanda) - relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark) - replaced description of error handling by pointer to respective section of core spec (as proposed by Peter) - adopted proposed text for implementation note (as proposed by Hannes) regards, Torsten. Am 07.01.2013 13:00, 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 Working Group of the IETF. > > Title : Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-04.txt > Pages : 8 > Date : 2013-01-07 > > Abstract: > This document proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Jan 7 07:00:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B621F88AE for ; Mon, 7 Jan 2013 07:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iINi6++HmNQ8 for ; Mon, 7 Jan 2013 07:00:49 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B863E21F8812 for ; Mon, 7 Jan 2013 07:00:42 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 09A6C1F18F3; Mon, 7 Jan 2013 10:00:42 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D33D31F18F0; Mon, 7 Jan 2013 10:00:41 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 7 Jan 2013 10:00:41 -0500 Message-ID: <50EAE316.2060004@mitre.org> Date: Mon, 7 Jan 2013 10:00:38 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: nov matake References: <315782BC-0135-4A0C-8541-F0A002B9C30F@matake.jp> In-Reply-To: <315782BC-0135-4A0C-8541-F0A002B9C30F@matake.jp> Content-Type: multipart/alternative; boundary="------------030105010301000505080102" X-Originating-IP: [129.83.31.58] Cc: "WG oauth@ietf.org" Subject: Re: [OAUTH-WG] Question on diff between draft31 and RFC6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:00:50 -0000 --------------030105010301000505080102 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I believe you're correct, Nov, and that this was potentially a mistake from the RFC editor. That sentence *should* be talking about the resource owner's password. -- Justin On 01/07/2013 06:53 AM, nov matake wrote: > Hi all, > > I couldn't understand why "their" became "the third party's" in the > diff between draft31 and RFC6749 below. > > === > Resource owners cannot revoke access to an individual third-party > *third party* > without revoking access to all third-parties, *third parties,* and > must do so by > changing their *the third party's* password. > > (from http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc6749) > === > > I read "their" as "resource owners'". > Is this typo, or am I missing some point? > > Thanks > > nov > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030105010301000505080102 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I believe you're correct, Nov, and that this was potentially a mistake from the RFC editor. That sentence *should* be talking about the resource owner's password.

 -- Justin

On 01/07/2013 06:53 AM, nov matake wrote:
Hi all,

I couldn't understand why "their" became "the third party's" in the diff between draft31 and RFC6749 below.

===
Resource owners cannot revoke access to an individual third-party third party
without revoking access to all third-parties, third parties, and must do so by
changing their the third party's password.
Is this typo, or am I missing some point?

Thanks

nov


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

--------------030105010301000505080102-- From torsten@lodderstedt.net Mon Jan 7 08:18:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF84021F8994 for ; Mon, 7 Jan 2013 08:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzbxnfDkM5Wj for ; Mon, 7 Jan 2013 08:18:55 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8B09621F892E for ; Mon, 7 Jan 2013 08:18:54 -0800 (PST) Received: from [79.253.14.73] (helo=[192.168.71.36]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TsFPY-0008BK-Qv; Mon, 07 Jan 2013 17:18:52 +0100 Message-ID: <50EAF568.8000201@lodderstedt.net> Date: Mon, 07 Jan 2013 17:18:48 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: George Fletcher , OAuth WG References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> In-Reply-To: <50EAF409.80704@aol.com> Content-Type: multipart/alternative; boundary="------------060100080609050408000303" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:18:56 -0000 This is a multi-part message in MIME format. --------------060100080609050408000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi George, thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750. As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated. What do others think? regards, Torsten. Am 07.01.2013 17:12, schrieb George Fletcher: > One quick comment... > > Section 2.0: Both RFC 6750 and this specification define the > 'invalid_token' error code. > > Should this spec reference the error code from RFC 6750? > > Thanks, > George > > > On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >> Hi, >> >> the new revision is based on the WGLC feedback and incorporates the >> following changes: >> >> - renamed "access grant" to "authorization" and reworded parts of >> Abstract and Intro in order to better align with core spec wording >> (feedback by Amanda) >> - improved formatting of section 2.1. (feedback by Amanda) >> - improved wording of last paragraph of section 6 (feedback by Amanda) >> - relaxed the expected behavior regarding revocation of related >> tokens and the authorization itself in order to remove unintended >> constraints on implementations (feedback by Mark) >> - replaced description of error handling by pointer to respective >> section of core spec (as proposed by Peter) >> - adopted proposed text for implementation note (as proposed by Hannes) >> >> regards, >> Torsten. >> >> Am 07.01.2013 13:00, 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 >>> Working Group of the IETF. >>> >>> Title : Token Revocation >>> Author(s) : Torsten Lodderstedt >>> Stefanie Dronia >>> Marius Scurtescu >>> Filename : draft-ietf-oauth-revocation-04.txt >>> Pages : 8 >>> Date : 2013-01-07 >>> >>> Abstract: >>> This document proposes an additional endpoint for OAuth >>> authorization >>> servers, which allows clients to notify the authorization server >>> that >>> a previously obtained refresh or access token is no longer needed. >>> This allows the authorization server to cleanup security >>> credentials. >>> A revocation request will invalidate the actual token and, if >>> applicable, other tokens based on the same authorization. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --------------060100080609050408000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

    Title           : Token Revocation
    Author(s)       : Torsten Lodderstedt
                           Stefanie Dronia
                           Marius Scurtescu
    Filename        : draft-ietf-oauth-revocation-04.txt
    Pages           : 8
    Date            : 2013-01-07

Abstract:
    This document proposes an additional endpoint for OAuth authorization
    servers, which allows clients to notify the authorization server that
    a previously obtained refresh or access token is no longer needed.
    This allows the authorization server to cleanup security credentials.
    A revocation request will invalidate the actual token and, if
    applicable, other tokens based on the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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




--------------060100080609050408000303-- From gffletch@aol.com Mon Jan 7 08:25:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360EC11E80C5 for ; Mon, 7 Jan 2013 08:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03qLUjqKeGJv for ; Mon, 7 Jan 2013 08:25:24 -0800 (PST) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4111E80B8 for ; Mon, 7 Jan 2013 08:25:24 -0800 (PST) Received: from mtaout-mb04.r1000.mx.aol.com (mtaout-mb04.r1000.mx.aol.com [172.29.41.68]) by imr-ma06.mx.aol.com (Outbound Mail Relay) with ESMTP id 524031C0000EC; Mon, 7 Jan 2013 11:25:23 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 00A58E000099; Mon, 7 Jan 2013 11:25:22 -0500 (EST) Message-ID: <50EAF6F2.90407@aol.com> Date: Mon, 07 Jan 2013 11:25:22 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: OAuth WG References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> In-Reply-To: <50EAF568.8000201@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------000500010204090900030308" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357575923; bh=VRk1hRGWzs8mNwB+mv+NtjYXoy4F85LXVeORM6XCfMw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=RlgOgt59pm2Bx2VJqCE7H2s1rU3Fsvsa6DJ3An1Gqprv554yyBtUAXMHiy9Eqr3gI Lqqlus9TMaOkrNUt3QRzTNQr//mx6kQED/AY/U/ErwawtTvFtwNjWKvnX3RF7xLnQW ISgacWHvxdc/xbjEke2gvNn5A90LPuDOiJX3hFX8= X-AOL-SCOLL-SCORE: 0:2:523196608:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294450eaf6f211ce X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:25:25 -0000 This is a multi-part message in MIME format. --------------000500010204090900030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion. Thanks, George On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: > Hi George, > > thank you for pointing this out. Your proposal sounds reasonable > although the revocation spec does not build on top of RFC 6750. > > As refering to RFC 6750 would create a new dependency, one could also > argue it would be more robust to leave both specs separated. > > What do others think? > > regards, > Torsten. > Am 07.01.2013 17:12, schrieb George Fletcher: >> One quick comment... >> >> Section 2.0: Both RFC 6750 and this specification define the >> 'invalid_token' error code. >> >> Should this spec reference the error code from RFC 6750? >> >> Thanks, >> George >> >> >> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>> Hi, >>> >>> the new revision is based on the WGLC feedback and incorporates the >>> following changes: >>> >>> - renamed "access grant" to "authorization" and reworded parts of >>> Abstract and Intro in order to better align with core spec wording >>> (feedback by Amanda) >>> - improved formatting of section 2.1. (feedback by Amanda) >>> - improved wording of last paragraph of section 6 (feedback by Amanda) >>> - relaxed the expected behavior regarding revocation of related >>> tokens and the authorization itself in order to remove unintended >>> constraints on implementations (feedback by Mark) >>> - replaced description of error handling by pointer to respective >>> section of core spec (as proposed by Peter) >>> - adopted proposed text for implementation note (as proposed by Hannes) >>> >>> regards, >>> Torsten. >>> >>> Am 07.01.2013 13:00, 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 >>>> Working Group of the IETF. >>>> >>>> Title : Token Revocation >>>> Author(s) : Torsten Lodderstedt >>>> Stefanie Dronia >>>> Marius Scurtescu >>>> Filename : draft-ietf-oauth-revocation-04.txt >>>> Pages : 8 >>>> Date : 2013-01-07 >>>> >>>> Abstract: >>>> This document proposes an additional endpoint for OAuth >>>> authorization >>>> servers, which allows clients to notify the authorization >>>> server that >>>> a previously obtained refresh or access token is no longer needed. >>>> This allows the authorization server to cleanup security >>>> credentials. >>>> A revocation request will invalidate the actual token and, if >>>> applicable, other tokens based on the same authorization. >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --------------000500010204090900030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

    Title           : Token Revocation
    Author(s)       : Torsten Lodderstedt
                           Stefanie Dronia
                           Marius Scurtescu
    Filename        : draft-ietf-oauth-revocation-04.txt
    Pages           : 8
    Date            : 2013-01-07

Abstract:
    This document proposes an additional endpoint for OAuth authorization
    servers, which allows clients to notify the authorization server that
    a previously obtained refresh or access token is no longer needed.
    This allows the authorization server to cleanup security credentials.
    A revocation request will invalidate the actual token and, if
    applicable, other tokens based on the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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





--------------000500010204090900030308-- From tonynad@microsoft.com Mon Jan 7 09:23:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABCA21F8837 for ; Mon, 7 Jan 2013 09:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ps0YUkFPFYg for ; Mon, 7 Jan 2013 09:23:27 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id C73B221F8727 for ; Mon, 7 Jan 2013 09:23:27 -0800 (PST) Received: from BY2FFO11FD004.protection.gbl (10.1.15.200) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.586.12; Mon, 7 Jan 2013 17:23:25 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Mon, 7 Jan 2013 17:23:25 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 7 Jan 2013 17:22:43 +0000 Received: from mail69-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE024.bigfish.com (10.3.207.146) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 Jan 2013 17:21:55 +0000 Received: from mail69-am1 (localhost [127.0.0.1]) by mail69-am1-R.bigfish.com (Postfix) with ESMTP id BD2D12A01A4 for ; Mon, 7 Jan 2013 17:21:54 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zz9371I936eI542I1432Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275dh1033IL17326ahz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h) Received-SPF: softfail (mail69-am1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; LANG:en; Received: from mail69-am1 (localhost.localdomain [127.0.0.1]) by mail69-am1 (MessageSwitch) id 1357579312646788_27380; Mon, 7 Jan 2013 17:21:52 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.228]) by mail69-am1.bigfish.com (Postfix) with ESMTP id 99EA23C006B; Mon, 7 Jan 2013 17:21:52 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 Jan 2013 17:21:52 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Mon, 7 Jan 2013 17:21:52 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.586.12; Mon, 7 Jan 2013 17:21:51 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.229]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.229]) with mapi id 15.00.0586.000; Mon, 7 Jan 2013 17:21:50 +0000 From: Anthony Nadalin To: Torsten Lodderstedt , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt Thread-Index: AQHN7M7U26bRHiiOX0+TuNiBpF6Vy5g9xbsAgABXTgA= Date: Mon, 7 Jan 2013 17:21:50 +0000 Message-ID: <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> In-Reply-To: <50EABAB0.4060807@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377424002)(377454001)(13464002)(15202345001)(23726001)(76482001)(46406002)(4396001)(50466001)(56816002)(56776001)(74502001)(31966008)(74662001)(33646001)(6806001)(49866001)(47736001)(47446002)(44976002)(46102001)(5343655001)(47776002)(54356001)(59766001)(77982001)(51856001)(54316002)(47976001)(50986001)(53806001)(16676001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0719EC6A9A Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:23:28 -0000 Is "authorization" the best choice here over "access grant" since it's rea= lly not authorization that is being revoked it's the grant -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Monday, January 7, 2013 4:08 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt Hi, the new revision is based on the WGLC feedback and incorporates the followi= ng changes: - renamed "access grant" to "authorization" and reworded parts of Abstract = and Intro in order to better align with core spec wording (feedback by Aman= da) - improved formatting of section 2.1. (feedback by Amanda) - improved wording of last paragraph of section 6 (feedback by Amanda) - relaxed the expected behavior regarding revocation of related tokens and = the authorization itself in order to remove unintended constraints on imple= mentations (feedback by Mark) - replaced description of error handling by pointer to respective section o= f core spec (as proposed by Peter) - adopted proposed text for implementation note (as proposed by Hannes) regards, Torsten. Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF. > > Title : Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-04.txt > Pages : 8 > Date : 2013-01-07 > > Abstract: > This document proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Jan 7 11:24:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7611621F88D6 for ; Mon, 7 Jan 2013 11:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpTNP+9d+a1j for ; Mon, 7 Jan 2013 11:24:54 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD4A21F88CC for ; Mon, 7 Jan 2013 11:24:49 -0800 (PST) Received: from [79.253.14.73] (helo=[192.168.71.56]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TsIJS-0006yU-TF; Mon, 07 Jan 2013 20:24:47 +0100 References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary=Apple-Mail-E8FC721D-E61F-4C38-B951-1EE2DE0F3273 Content-Transfer-Encoding: 7bit Message-Id: <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net> X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Mon, 7 Jan 2013 20:24:45 +0100 To: Anthony Nadalin X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 19:24:58 -0000 --Apple-Mail-E8FC721D-E61F-4C38-B951-1EE2DE0F3273 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Access grant might be the better term. That's why previous revisions used it= . But as Amanda correctly pointed out, the core spec does not define a conce= pt of an access grant. There is just the term authorization implicitly intro= duced via other definitions. section 1.3 introduces authorization grants: "An authorization grant is a credential representing the resource owner's au= thorization (to access its protected resources) used by the client to obtain= an access token." and section 1.4 defines access tokens as follows: "An access token is a string representing an authorization issued to the cli= ent. The string is usually opaque to the client." I tried to align the draft with this terminology. Am 07.01.2013 um 18:21 schrieb Anthony Nadalin : > Is "authorization" the best choice here over "access grant" since it's re= ally not authorization that is being revoked it's the grant >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt > Sent: Monday, January 7, 2013 4:08 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt >=20 > Hi, >=20 > the new revision is based on the WGLC feedback and incorporates the follow= ing changes: >=20 > - renamed "access grant" to "authorization" and reworded parts of Abstract= and Intro in order to better align with core spec wording (feedback by Aman= da) > - improved formatting of section 2.1. (feedback by Amanda) > - improved wording of last paragraph of section 6 (feedback by Amanda) > - relaxed the expected behavior regarding revocation of related tokens and= the authorization itself in order to remove unintended constraints on imple= mentations (feedback by Mark) > - replaced description of error handling by pointer to respective section o= f core spec (as proposed by Peter) > - adopted proposed text for implementation note (as proposed by Hannes) >=20 > regards, > Torsten. >=20 > Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Web Authorization Protocol Working Grou= p of the IETF. >>=20 >> Title : Token Revocation >> Author(s) : Torsten Lodderstedt >> Stefanie Dronia >> Marius Scurtescu >> Filename : draft-ietf-oauth-revocation-04.txt >> Pages : 8 >> Date : 2013-01-07 >>=20 >> Abstract: >> This document proposes an additional endpoint for OAuth authorization >> servers, which allows clients to notify the authorization server that >> a previously obtained refresh or access token is no longer needed. >> This allows the authorization server to cleanup security credentials. >> A revocation request will invalidate the actual token and, if >> applicable, other tokens based on the same authorization. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 --Apple-Mail-E8FC721D-E61F-4C38-B951-1EE2DE0F3273 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Access grant might be the better term. That's why previous revisions us= ed it. But as Amanda correctly pointed out, the core spec does not define a c= oncept of an access grant. There is just the term authorization implicitly i= ntroduced via other definitions.

section 1= .3 introduces authorization grants:
"An authorization grant is a credential representing the r=
esource
   owner's authorization (to access its protected resources) used by the
   client to obtain an access token."

and section 1.4 defines access tokens as follow=
s:
"An
   access token is a string representing an authorization issued to the
   client.  The string is usually opaque to the client."
= 

I tried to align the draft with this ter=
minology.

Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <tonynad@microsoft.com>:

= Is "authorization" the best  choice here over "access grant" since it's= really not authorization that is being revoked it's the grant

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-= 04.txt

Hi,

the new revision is based on the WGLC feedback and incorporates the followi= ng changes:

- renamed "access grant" to "au= thorization" and reworded parts of Abstract and Intro in order to better ali= gn with core spec wording (feedback by Amanda)
- improved fo= rmatting of section 2.1. (feedback by Amanda)
- improved wor= ding of last paragraph of section 6 (feedback by Amanda)
- r= elaxed the expected behavior regarding revocation of related tokens and the a= uthorization itself in order to remove unintended constraints on implementat= ions (feedback by Mark)
- replaced description of error hand= ling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed b= y Hannes)

regards,
Torsten.=

Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol= Working Group of the IETF.

   = ;Title           : Token R= evocation
  &nb= sp;Author(s)       : Torsten Lodderstedt
    &= nbsp;            = ;         Stefanie Dronia
    &= nbsp;            = ;         Marius Scurtescu
   Filename &n= bsp;      : draft-ietf-oauth-revocation-04.txt=
   Pages &= nbsp;         : 8
   Date   &nb= sp;        : 2013-01-07

Abstract:
   This document proposes an additional endpoint= for OAuth authorization
   servers, which allows clients to notify the authoriza= tion server that
&nb= sp;  a previously obtained refresh or access token is no longer ne= eded.
  &n= bsp;This allows the authorization server to cleanup security credentials.
   A re= vocation request will invalidate the actual token and, if
   applicable, other to= kens based on the same authorization.



The IETF datatracker status page for this d= raft is:
https://datatra= cker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revo= cation-04
=
A diff from the previous ve= rsion is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:<= br>
ftp://ftp.ietf.org/internet-drafts/

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

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



= --Apple-Mail-E8FC721D-E61F-4C38-B951-1EE2DE0F3273-- From jricher@mitre.org Mon Jan 7 11:36:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692A621F89E9 for ; Mon, 7 Jan 2013 11:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljn8izwO2WuU for ; Mon, 7 Jan 2013 11:36:06 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48721F8481 for ; Mon, 7 Jan 2013 11:36:05 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F126C1F30F3; Mon, 7 Jan 2013 14:36:04 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D7AD55310949; Mon, 7 Jan 2013 14:36:04 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 7 Jan 2013 14:36:04 -0500 Message-ID: <50EB239F.2060309@mitre.org> Date: Mon, 7 Jan 2013 14:35:59 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net> In-Reply-To: <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------040809000102090901060903" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 19:36:07 -0000 --------------040809000102090901060903 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit "Access grant" was the old term that Eran came up with, and it has been replaced by "authorization grant", which I agree is also not as well defined as it could be. Both of these refer to the conceptual act of the resource owner saying "it is OK for this client to do these things". I objected to the language calling it a "credential", since that's misleading and has led to several developers I've run into thinking that it was the same thing as the access code, which it's not. To best align the terminology, "authorization grant" as defined in 1.3 is probably the best bet. -- Justin On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote: > Access grant might be the better term. That's why previous revisions > used it. But as Amanda correctly pointed out, the core spec does not > define a concept of an access grant. There is just the term > authorization implicitly introduced via other definitions. > > section 1.3 introduces authorization grants: > "An authorization grant is a credential representing the resource > owner's authorization (to access its protected resources) used by the > client to obtain an access token." > > and section 1.4 defines access tokens as follows: > "An > access token is a string representing an authorization issued to the > client. The string is usually opaque to the client." > > I tried to align the draft with this terminology. > > Am 07.01.2013 um 18:21 schrieb Anthony Nadalin >: > >> Is "authorization" the best choice here over "access grant" since >> it's really not authorization that is being revoked it's the grant >> >> -----Original Message----- >> From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt >> Sent: Monday, January 7, 2013 4:08 AM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt >> >> Hi, >> >> the new revision is based on the WGLC feedback and incorporates the >> following changes: >> >> - renamed "access grant" to "authorization" and reworded parts of >> Abstract and Intro in order to better align with core spec wording >> (feedback by Amanda) >> - improved formatting of section 2.1. (feedback by Amanda) >> - improved wording of last paragraph of section 6 (feedback by Amanda) >> - relaxed the expected behavior regarding revocation of related >> tokens and the authorization itself in order to remove unintended >> constraints on implementations (feedback by Mark) >> - replaced description of error handling by pointer to respective >> section of core spec (as proposed by Peter) >> - adopted proposed text for implementation note (as proposed by Hannes) >> >> regards, >> Torsten. >> >> Am 07.01.2013 13:00, 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 Working >>> Group of the IETF. >>> >>> Title : Token Revocation >>> Author(s) : Torsten Lodderstedt >>> Stefanie Dronia >>> Marius Scurtescu >>> Filename : draft-ietf-oauth-revocation-04.txt >>> Pages : 8 >>> Date : 2013-01-07 >>> >>> Abstract: >>> This document proposes an additional endpoint for OAuth authorization >>> servers, which allows clients to notify the authorization server that >>> a previously obtained refresh or access token is no longer needed. >>> This allows the authorization server to cleanup security credentials. >>> A revocation request will invalidate the actual token and, if >>> applicable, other tokens based on the same authorization. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040809000102090901060903 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
"Access grant" was the old term that Eran came up with, and it has been replaced by "authorization grant", which I agree is also not as well defined as it could be. Both of these refer to the conceptual act of the resource owner saying "it is OK for this client to do these things". I objected to the language calling it a "credential", since that's misleading and has led to several developers I've run into thinking that it was the same thing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined in 1.3 is probably the best bet.

 -- Justin

On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote:
Access grant might be the better term. That's why previous revisions used it. But as Amanda correctly pointed out, the core spec does not define a concept of an access grant. There is just the term authorization implicitly introduced via other definitions.

section 1.3 introduces authorization grants:
"An authorization grant is a credential representing the resource
   owner's authorization (to access its protected resources) used by the
   client to obtain an access token."


and section 1.4 defines access tokens as follows:
"An
   access token is a string representing an authorization issued to the
   client.  The string is usually opaque to the client."


I tried to align the draft with this terminology.

Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <tonynad@microsoft.com>:

Is "authorization" the best  choice here over "access grant" since it's really not authorization that is being revoked it's the grant

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

   Title           : Token Revocation
   Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
   Filename        : draft-ietf-oauth-revocation-04.txt
   Pages           : 8
   Date            : 2013-01-07

Abstract:
   This document proposes an additional endpoint for OAuth authorization
   servers, which allows clients to notify the authorization server that
   a previously obtained refresh or access token is no longer needed.
   This allows the authorization server to cleanup security credentials.
   A revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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





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

--------------040809000102090901060903-- From Michael.Jones@microsoft.com Mon Jan 7 12:13:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4321F87FF for ; Mon, 7 Jan 2013 12:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSz-SB8coLAc for ; Mon, 7 Jan 2013 12:13:09 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1521F87FA for ; Mon, 7 Jan 2013 12:13:08 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.201) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.586.12; Mon, 7 Jan 2013 20:12:59 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Mon, 7 Jan 2013 20:12:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 7 Jan 2013 20:12:37 +0000 From: Mike Jones To: Justin Richer , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt Thread-Index: AQHN7M6sQFzmPZ7iW0isfcl3YABTQZg9xbsAgABXnACAACJYgIAAAyOAgAAKINA= Date: Mon, 7 Jan 2013 20:12:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A05D7E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net> <50EB239F.2060309@mitre.org> In-Reply-To: <50EB239F.2060309@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A05D7ETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(13464002)(479174001)(24454001)(77982001)(74502001)(47446002)(46102001)(55846006)(53806001)(76482001)(44976002)(15202345001)(512954001)(54316002)(550184003)(56816002)(33656001)(50986001)(5343635001)(51856001)(16406001)(47976001)(56776001)(59766001)(74662001)(31966008)(5343655001)(16236675001)(4396001)(54356001)(47736001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0719EC6A9A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:13:10 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A05D7ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for using the same terminology as OAuth Core and Bearer From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Monday, January 07, 2013 11:36 AM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt "Access grant" was the old term that Eran came up with, and it has been rep= laced by "authorization grant", which I agree is also not as well defined a= s it could be. Both of these refer to the conceptual act of the resource ow= ner saying "it is OK for this client to do these things". I objected to the= language calling it a "credential", since that's misleading and has led to= several developers I've run into thinking that it was the same thing as th= e access code, which it's not. To best align the terminology, "authorization grant" as defined in 1.3 is p= robably the best bet. -- Justin On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote: Access grant might be the better term. That's why previous revisions used i= t. But as Amanda correctly pointed out, the core spec does not define a con= cept of an access grant. There is just the term authorization implicitly in= troduced via other definitions. section 1.3 introduces authorization grants: "An authorization grant is a credential representing the resource owner's a= uthorization (to access its protected resources) used by the client to obta= in an access token." and section 1.4 defines access tokens as follows: "An access token is a string representing an authorization issued to the cl= ient. The string is usually opaque to the client." I tried to align the draft with this terminology. Am 07.01.2013 um 18:21 schrieb Anthony Nadalin >: Is "authorization" the best choice here over "access grant" since it's rea= lly not authorization that is being revoked it's the grant -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, January 7, 2013 4:08 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt Hi, the new revision is based on the WGLC feedback and incorporates the followi= ng changes: - renamed "access grant" to "authorization" and reworded parts of Abstract = and Intro in order to better align with core spec wording (feedback by Aman= da) - improved formatting of section 2.1. (feedback by Amanda) - improved wording of last paragraph of section 6 (feedback by Amanda) - relaxed the expected behavior regarding revocation of related tokens and = the authorization itself in order to remove unintended constraints on imple= mentations (feedback by Mark) - replaced description of error handling by pointer to respective section o= f core spec (as proposed by Peter) - adopted proposed text for implementation note (as proposed by Hannes) regards, Torsten. Am 07.01.2013 13:00, 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 Working Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-04.txt Pages : 8 Date : 2013-01-07 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366A05D7ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for using the same= terminology as OAuth Core and Bearer

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Justin Richer
Sent: Monday, January 07, 2013 11:36 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.t= xt

 

"Access grant" was the old term that Eran = came up with, and it has been replaced by "authorization grant", = which I agree is also not as well defined as it could be. Both of these ref= er to the conceptual act of the resource owner saying "it is OK for this client to do these things". I objected to the= language calling it a "credential", since that's misleading and = has led to several developers I've run into thinking that it was the same t= hing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined i= n 1.3 is probably the best bet.

 -- Justin

On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote:

Access grant might be the better term. That's why pr= evious revisions used it. But as Amanda correctly pointed out, the core spe= c does not define a concept of an access grant. There is just the term auth= orization implicitly introduced via other definitions.

 

section 1.3 introduces authorization grants:

"An authorization grant is a cre=
dential representing the resource owner's authorization (to access its prot=
ected resources) used by the client to obtain an access token."=

and section 1.4 defines access tokens=
 as follows:
"An access token is a string rep=
resenting an authorization issued to the client. The string is usually opaq=
ue to the client."
I tried to align the draft with this =
terminology.


Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <tonynad@microsoft.com>:

Is "authorization" the best  choice h= ere over "access grant" since it's really not authorization that = is being revoked it's the grant

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

Hi,

the new revision is based on the WGLC feedback and incorporates the followi= ng changes:

- renamed "access grant" to "authorization" and reworde= d parts of Abstract and Intro in order to better align with core spec wordi= ng (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and = the authorization itself in order to remove unintended constraints on imple= mentations (feedback by Mark)
- replaced description of error handling by pointer to respective section o= f core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, schrieb in= ternet-drafts@ietf.org:

A New Internet-Draft is available from the on-line I= nternet-Drafts directories.

 This draft is a work item of the Web Authoriza= tion Protocol Working Group of the IETF.

 

   Title      &nb= sp;    : Token Revocation

   Author(s)      = ; : Torsten Lodderstedt

        &nbs= p;            &= nbsp;    Stefanie Dronia

        &nbs= p;            &= nbsp;    Marius Scurtescu

   Filename      =   : draft-ietf-oauth-revocation-04.txt

   Pages      &nb= sp;    : 8

   Date      &nbs= p;     : 2013-01-07

 

Abstract:

   This document proposes an addition= al endpoint for OAuth authorization

   servers, which allows clients to n= otify the authorization server that

   a previously obtained refresh or a= ccess token is no longer needed.

   This allows the authorization serv= er to cleanup security credentials.

   A revocation request will invalida= te the actual token and, if

   applicable, other tokens based on = the same authorization.

 

 

 

The IETF datatracker status page for this draft is:<= o:p>

https://datatracker.ietf.org/doc/draft-ietf-oauth-revo= cation

 

There's also a htmlized version available at:

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

 

A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oau= th-revocation-04

 

 

Internet-Drafts are also available by anonymous FTP = at:

ftp:= //ftp.ietf.org/internet-drafts/

 

_______________________________________________=

OAuth mailing list

OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth


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





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

 

--_000_4E1F6AAD24975D4BA5B168042967394366A05D7ETK5EX14MBXC283r_-- From torsten@lodderstedt.net Mon Jan 7 12:31:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA6621F88C7 for ; Mon, 7 Jan 2013 12:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0SfoLHz89P3 for ; Mon, 7 Jan 2013 12:31:35 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id B763021F8837 for ; Mon, 7 Jan 2013 12:31:33 -0800 (PST) Received: from [79.253.14.73] (helo=[192.168.71.56]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TsJM3-0005K3-3f; Mon, 07 Jan 2013 21:31:31 +0100 References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net> <50EB239F.2060309@mitre.org> <4E1F6AAD24975D4BA5B168042967394366A05D7E@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A05D7E@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-01B27F0B-936C-4B04-B6A5-0BCC7C2999D6 Content-Transfer-Encoding: 7bit Message-Id: <29DA1D90-31AB-47F3-99C4-BFBEFF5C7BAD@lodderstedt.net> X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Mon, 7 Jan 2013 21:31:30 +0100 To: Mike Jones X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:31:36 -0000 --Apple-Mail-01B27F0B-936C-4B04-B6A5-0BCC7C2999D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable But what is the same terminology? Authorization grant? I think 1.3 defines t= he authorization grant as an external representation of the authorization, n= ot the authorization itself.=20 Am 07.01.2013 um 21:12 schrieb Mike Jones : > +1 for using the same terminology as OAuth Core and Bearer > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer > Sent: Monday, January 07, 2013 11:36 AM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt > =20 > "Access grant" was the old term that Eran came up with, and it has been re= placed by "authorization grant", which I agree is also not as well defined a= s it could be. Both of these refer to the conceptual act of the resource own= er saying "it is OK for this client to do these things". I objected to the l= anguage calling it a "credential", since that's misleading and has led to se= veral developers I've run into thinking that it was the same thing as the ac= cess code, which it's not.=20 >=20 > To best align the terminology, "authorization grant" as defined in 1.3 is p= robably the best bet. >=20 > -- Justin >=20 > On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote: > Access grant might be the better term. That's why previous revisions used i= t. But as Amanda correctly pointed out, the core spec does not define a conc= ept of an access grant. There is just the term authorization implicitly intr= oduced via other definitions. > =20 > section 1.3 introduces authorization grants: > "An authorization grant is a credential representing the resource owner's a= uthorization (to access its protected resources) used by the client to obtai= n an access token." > and section 1.4 defines access tokens as follows: > "An access token is a string representing an authorization issued to the c= lient. The string is usually opaque to the client." > I tried to align the draft with this terminology. >=20 > Am 07.01.2013 um 18:21 schrieb Anthony Nadalin : >=20 > Is "authorization" the best choice here over "access grant" since it's re= ally not authorization that is being revoked it's the grant >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt > Sent: Monday, January 7, 2013 4:08 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt >=20 > Hi, >=20 > the new revision is based on the WGLC feedback and incorporates the follow= ing changes: >=20 > - renamed "access grant" to "authorization" and reworded parts of Abstract= and Intro in order to better align with core spec wording (feedback by Aman= da) > - improved formatting of section 2.1. (feedback by Amanda) > - improved wording of last paragraph of section 6 (feedback by Amanda) > - relaxed the expected behavior regarding revocation of related tokens and= the authorization itself in order to remove unintended constraints on imple= mentations (feedback by Mark) > - replaced description of error handling by pointer to respective section o= f core spec (as proposed by Peter) > - adopted proposed text for implementation note (as proposed by Hannes) >=20 > regards, > Torsten. >=20 > Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > =20 > Title : Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-04.txt > Pages : 8 > Date : 2013-01-07 > =20 > Abstract: > This document proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization. > =20 > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 > =20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 > =20 > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-01B27F0B-936C-4B04-B6A5-0BCC7C2999D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
But what is the same terminology? Authorization grant? I think 1.3 defines the authorization grant as an external representation of the authorization, not the authorization itself. 

Am 07.01.2013 um 21:12 schrieb Mike Jones <Michael.Jones@microsoft.com>:

+1 for using the same terminology as OAuth Core and Bearer

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, January 07, 2013 11:36 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

 

"Access grant" was the old term that Eran came up with, and it has been replaced by "authorization grant", which I agree is also not as well defined as it could be. Both of these refer to the conceptual act of the resource owner saying "it is OK for this client to do these things". I objected to the language calling it a "credential", since that's misleading and has led to several developers I've run into thinking that it was the same thing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined in 1.3 is probably the best bet.

 -- Justin

On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote:

Access grant might be the better term. That's why previous revisions used it. But as Amanda correctly pointed out, the core spec does not define a concept of an access grant. There is just the term authorization implicitly introduced via other definitions.

 

section 1.3 introduces authorization grants:

"An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token."
and section 1.4 defines access tokens as follows:
"An access token is a string representing an authorization issued to the client. The string is usually opaque to the client."
I tried to align the draft with this terminology.


Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <tonynad@microsoft.com>:

Is "authorization" the best  choice here over "access grant" since it's really not authorization that is being revoked it's the grant

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

 

   Title           : Token Revocation

   Author(s)       : Torsten Lodderstedt

                          Stefanie Dronia

                          Marius Scurtescu

   Filename        : draft-ietf-oauth-revocation-04.txt

   Pages           : 8

   Date            : 2013-01-07

 

Abstract:

   This document proposes an additional endpoint for OAuth authorization

   servers, which allows clients to notify the authorization server that

   a previously obtained refresh or access token is no longer needed.

   This allows the authorization server to cleanup security credentials.

   A revocation request will invalidate the actual token and, if

   applicable, other tokens based on the same authorization.

 

 

 

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

 

There's also a htmlized version available at:

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

 

A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04

 

 

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


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





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

 

--Apple-Mail-01B27F0B-936C-4B04-B6A5-0BCC7C2999D6-- From wwwrun@rfc-editor.org Mon Jan 7 13:50:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2621F8496; Mon, 7 Jan 2013 13:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqG7ZRQiGXjp; Mon, 7 Jan 2013 13:50:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA221F868D; Mon, 7 Jan 2013 13:50:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 94851B1E007; Mon, 7 Jan 2013 13:40:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130107214016.94851B1E007@rfc-editor.org> Date: Mon, 7 Jan 2013 13:40:16 -0800 (PST) Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:50:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6819 Title: OAuth 2.0 Threat Model and Security Considerations Author: T. Lodderstedt, Ed., M. McGloin, P. Hunt Status: Informational Stream: IETF Date: January 2013 Mailbox: torsten@lodderstedt.net, mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.com Pages: 71 Characters: 158332 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-v2-threatmodel-08.txt URL: http://www.rfc-editor.org/rfc/rfc6819.txt This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Web Authorization Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Jan 7 17:29:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FB321F876E for ; Mon, 7 Jan 2013 17:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChDOSasTjiGO for ; Mon, 7 Jan 2013 17:29:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3254E21F8684 for ; Mon, 7 Jan 2013 17:29:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 22098B1E007; Mon, 7 Jan 2013 17:19:35 -0800 (PST) To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com From: RFC Errata System Message-Id: <20130108011935.22098B1E007@rfc-editor.org> Date: Mon, 7 Jan 2013 17:19:35 -0800 (PST) Cc: nov@matake.jp, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:29:52 -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=3446 -------------------------------------- Type: Editorial Reported by: Nov Matake Section: 1 Original Text ------------- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password. Corrected Text -------------- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing their password. Notes ----- The text was originally "their" but changed to "the third party's" between the last draft and RFC. However, "their" means "resource owners'", not "the third party's". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nov@matake.jp Mon Jan 7 17:31:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062321F879D for ; Mon, 7 Jan 2013 17:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DAAWD+PaHFE for ; Mon, 7 Jan 2013 17:31:14 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id C96FC21F8782 for ; Mon, 7 Jan 2013 17:31:14 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so9024577dal.1 for ; Mon, 07 Jan 2013 17:31:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=GNzmYgworhZGvhCiOkqi6CR96GJ+TEmw1QNTaQWjbi0=; b=iK3yGGAvBMYX0kTr3ibXx7H1R5DfvkTFivM9HQVMHCjobk34ico9lT2dEASkmkdHU8 /pv4fu1PTB7d43cfjsMj2RryzwYh9GGAUWLXb5MdXZgzE+GzmmVNZ27EoirQNJWR6V0Q u6Y+QXCtlNI1CcV6S3A2Yf8UkYXt5iZ5OgHGmwnLzMmNyOIPttw50P+WzdPKFNXKOd62 1qXux7Udsx77/yPTbc+t93I81ShQULa9E1iCXGCa0IeAJoU1X91jn9hsSRJKb0oTXEUy p8jfPDHA7Xd+LIDPTScAojCFbmEXWZe6rcGkQEXvx8mTSuIfAy+6W4o5kLpfXXCFWpCz 9Jwg== X-Received: by 10.68.230.101 with SMTP id sx5mr6613645pbc.50.1357608674442; Mon, 07 Jan 2013 17:31:14 -0800 (PST) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id bc1sm39683408pab.3.2013.01.07.17.31.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Jan 2013 17:31:13 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D6AD47DA-5471-44D5-9B09-7E611D6B4393" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <50EAE316.2060004@mitre.org> Date: Tue, 8 Jan 2013 10:31:09 +0900 Message-Id: References: <315782BC-0135-4A0C-8541-F0A002B9C30F@matake.jp> <50EAE316.2060004@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnVBCba/J0yjDtmx65nlh63S7ZornN35vqwv/wdsyxmnH/4e0dhSyI9/AKEaLwT2PXp1Rvz Cc: "WG oauth@ietf.org" Subject: Re: [OAUTH-WG] Question on diff between draft31 and RFC6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:31:15 -0000 --Apple-Mail=_D6AD47DA-5471-44D5-9B09-7E611D6B4393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Justin, I reported this errata at RFC errata report page. On 2013/01/08, at 0:00, Justin Richer wrote: > I believe you're correct, Nov, and that this was potentially a mistake = from the RFC editor. That sentence *should* be talking about the = resource owner's password.=20 >=20 > -- Justin >=20 > On 01/07/2013 06:53 AM, nov matake wrote: >> Hi all, >>=20 >> I couldn't understand why "their" became "the third party's" in the = diff between draft31 and RFC6749 below. >>=20 >> =3D=3D=3D >> Resource owners cannot revoke access to an individual third-party = third party >> without revoking access to all third-parties, third parties, and must = do so by >> changing their the third party's password. >>=20 >> (from http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Drfc6749)= >> =3D=3D=3D >>=20 >> I read "their" as "resource owners'". >> Is this typo, or am I missing some point? >>=20 >> Thanks >>=20 >> nov >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_D6AD47DA-5471-44D5-9B09-7E611D6B4393 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Thanks Justin,
I reported this errata at RFC errata report page.

On 2013/01/08, at 0:00, Justin Richer <jricher@mitre.org> wrote:

I believe you're correct, Nov, and that this was potentially a mistake from the RFC editor. That sentence *should* be talking about the resource owner's password.

 -- Justin

On 01/07/2013 06:53 AM, nov matake wrote:
Hi all,

I couldn't understand why "their" became "the third party's" in the diff between draft31 and RFC6749 below.

===
Resource owners cannot revoke access to an individual third-party third party
without revoking access to all third-parties, third parties, and must do so by
changing their the third party's password.

===

I read "their" as "resource owners'".
Is this typo, or am I missing some point?

Thanks

nov


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


--Apple-Mail=_D6AD47DA-5471-44D5-9B09-7E611D6B4393-- From barryleiba.mailing.lists@gmail.com Mon Jan 7 18:11:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B4B21F8681 for ; Mon, 7 Jan 2013 18:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAY1lKy3LSxP for ; Mon, 7 Jan 2013 18:11:34 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6DE21F8645 for ; Mon, 7 Jan 2013 18:11:34 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id gb30so19953562vcb.26 for ; Mon, 07 Jan 2013 18:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=10D5ZTbFVX8DvkrOWObKGlzgtNNmG+H9YbNWYFZh0nU=; b=qmgzpZ7VvaYX3Q32UxBgWJ8Pnhz087O+lx4k28gdBAjxMC9It7pZWyhto4ZLGrqnGj O444MgQiY7Vat+9f0oaLbD6/0vvm1f9WPeP3RM4QsT39+kk4C2iILMQtiggdQMFxkWYz fBvLxSN61MBuWBivTx9ZiNsAaJl6oemahy/GkUdimYTO5O172AW9AK/RiRgZSH06kyoT MK2+454jqPUevmSdoQc7nthqAY0SefdZ6a+vpAnCFAHbqB4w+j8GEtXqoLNjUjXlhzME E60hueUlPnC3x7cnYOQqPv55apVNBn9Yedx6YC7vU3TW4ckur3rjpvnad5bPPth8g91N s0Ig== MIME-Version: 1.0 Received: by 10.52.88.33 with SMTP id bd1mr73474209vdb.70.1357611093809; Mon, 07 Jan 2013 18:11:33 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 7 Jan 2013 18:11:33 -0800 (PST) In-Reply-To: <20130108011935.22098B1E007@rfc-editor.org> References: <20130108011935.22098B1E007@rfc-editor.org> Date: Mon, 7 Jan 2013 21:11:33 -0500 X-Google-Sender-Auth: j2W2HG_q9hXjXLIgY7zP1WgXbNg Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Cc: nov@matake.jp, Derek Atkins , OAuth WG Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 02:11:35 -0000 > Corrected Text > -------------- > Resource owners cannot revoke access to an individual third party without revoking access > to all third parties, and must do so by changing their password. > > Notes > ----- > The text was originally "their" but changed to "the third party's" between the last draft and RFC. > However, "their" means "resource owners'", not "the third party's". Yes, this appears to be a change the RFC Editor made that the authors didn't notice in AUTH48. But the RFC Editor change it from "their" because "their" wasn't clear. Changing it back to "their" won't help that. I suggest editing the corrected text to "by changing the resource owner's password" before marking this as Verified. Barry From peter.mauritius@fun.de Tue Jan 8 14:07:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939F521F85B3 for ; Tue, 8 Jan 2013 14:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXZcykrE6kln for ; Tue, 8 Jan 2013 14:07:15 -0800 (PST) Received: from mailfwd.fun.de (fungate2.fun.de [IPv6:2a01:198:3c6:1:81:26:162:57]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95721F8550 for ; Tue, 8 Jan 2013 14:07:13 -0800 (PST) Received: from hsi-kbw-109-193-166-054.hsi7.kabel-badenwuerttemberg.de ([109.193.166.54] helo=funmiraus.local) by mailfwd.fun.de with esmtpsa (Exim 4.69 #1 (Debian)) id 1TshKA-0004DM-VE; Tue, 08 Jan 2013 23:07:11 +0100 Message-ID: <50EC988E.7070007@fun.de> Date: Tue, 08 Jan 2013 23:07:10 +0100 From: Peter Mauritius Organization: fun communications GmbH, Karlsruhe, Germany User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130102 Thunderbird/19.0a2 MIME-Version: 1.0 To: George Fletcher , OAuth WG References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> In-Reply-To: <50EAF6F2.90407@aol.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050001030004030804030000" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:07:16 -0000 This is a cryptographically signed message in MIME format. --------------ms050001030004030804030000 Content-Type: multipart/alternative; boundary="------------070606020307070207090704" This is a multi-part message in MIME format. --------------070606020307070207090704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi George, RFC6750 defines "invalid-token" for access tokens which is not the case=20 for "invalid-token" in the revocation specification. Here it is=20 applicable for refresh tokens as well. Therefore we should not simply=20 reference the "invalid-token" of RFC6750. As far as I understand both, the reviewed specification and RFC6750,=20 reference RFC6749. RFC6750 includes in section 6.1=20 OAuth Extensions Error = Registration sections according to RFC6749 section 11.4.=20 for the error codes=20 defined throughout the document including "invalid-token". I am not very experienced in the formal process but shouldn't we add=20 such sections for the two error codes defined in the revocation=20 document? Especially for "invalid-token" we should define an error=20 registration section that defines the error code for our error usage=20 location and protocol extension to distinguish it from RFC6750 and to=20 avoid confusion. Doing this I hope there is no necessity to add a=20 reference to RFC6750 or to define a new error code. What do the more experienced reviewers think? Regards Peter Am 07.01.13 17:25, schrieb George Fletcher: > My concern with leaving both specs separated is that over time the=20 > semantics of the two error codes could diverge and that would be=20 > confusing for developers. If we don't want to create a dependency on=20 > RFC 6750, then I would recommend a change to the error code name so=20 > that there is no name collision or confusion. > > Thanks, > George > > On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >> Hi George, >> >> thank you for pointing this out. Your proposal sounds reasonable=20 >> although the revocation spec does not build on top of RFC 6750. >> >> As refering to RFC 6750 would create a new dependency, one could also = >> argue it would be more robust to leave both specs separated. >> >> What do others think? >> >> regards, >> Torsten. >> Am 07.01.2013 17:12, schrieb George Fletcher: >>> One quick comment... >>> >>> Section 2.0: Both RFC 6750 and this specification define the=20 >>> 'invalid_token' error code. >>> >>> Should this spec reference the error code from RFC 6750? >>> >>> Thanks, >>> George >>> >>> >>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>> Hi, >>>> >>>> the new revision is based on the WGLC feedback and incorporates the = >>>> following changes: >>>> >>>> - renamed "access grant" to "authorization" and reworded parts of=20 >>>> Abstract and Intro in order to better align with core spec wording=20 >>>> (feedback by Amanda) >>>> - improved formatting of section 2.1. (feedback by Amanda) >>>> - improved wording of last paragraph of section 6 (feedback by Amand= a) >>>> - relaxed the expected behavior regarding revocation of related=20 >>>> tokens and the authorization itself in order to remove unintended=20 >>>> constraints on implementations (feedback by Mark) >>>> - replaced description of error handling by pointer to respective=20 >>>> section of core spec (as proposed by Peter) >>>> - adopted proposed text for implementation note (as proposed by=20 >>>> Hannes) >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 07.01.2013 13:00, 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=20 >>>>> Working Group of the IETF. >>>>> >>>>> Title : Token Revocation >>>>> Author(s) : Torsten Lodderstedt >>>>> Stefanie Dronia >>>>> Marius Scurtescu >>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>> Pages : 8 >>>>> Date : 2013-01-07 >>>>> >>>>> Abstract: >>>>> This document proposes an additional endpoint for OAuth=20 >>>>> authorization >>>>> servers, which allows clients to notify the authorization=20 >>>>> server that >>>>> a previously obtained refresh or access token is no longer=20 >>>>> needed. >>>>> This allows the authorization server to cleanup security=20 >>>>> credentials. >>>>> A revocation request will invalidate the actual token and, if >>>>> applicable, other tokens based on the same authorization. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> > --=20 Peter Mauritius Chief Technical Director Senior Consultant Tel: +49 721 96448-0 Fax: +49 721 96448-299 peter.mauritius@fun.de fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe Geschaeftsfuehrer Johannes Feulner Amtsgericht Mannheim HRB 106906 http://www.fun.de http://blogs.fun.de http://www.twitter.com/fun_de http://www.facebook.com/funcommunications --------------070606020307070207090704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,

RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.

As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in section 6.1  OAuth Extensions Error Registration sections accord= ing to RFC6= 749 section 11.4. for the error codes defined throughout the document including "invalid-token". 

I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.

What do the more experienced reviewers think?

Regards 
  Peter

Am 07.01.13 17:25, schrieb George Fletcher:
My concern with leaving= both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.
As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb Georg= e Fletcher:
One quick comment..= =2E

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda) - improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, schrieb internet-drafts@ie= tf.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 Working Group of the IETF.

    Title     =       : Token Revocation
    Author(s)    &n= bsp;  : Torsten Lodderstedt
          = ;            =      Stefanie Dronia
          = ;            =      Marius Scurtescu
    Filename    &nb= sp;   : draft-ietf-oauth-revocation-04.txt
    Pages     =       : 8
    Date     &= nbsp;      : 2013-01-07

Abstract:
    This document proposes an additional end= point for OAuth authorization
    servers, which allows clients to notify = the authorization server that
    a previously obtained refresh or access = token is no longer needed.
    This allows the authorization server to = cleanup security credentials.
    A revocation request will invalidate the= actual token and, if
    applicable, other tokens based on the sa= me authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation=

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-rev= ocation-04


Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ie= tf.org/internet-drafts/

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

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







--=20
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.d=
e

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.=
fun.de
http://bl=
ogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunications
--------------070606020307070207090704-- --------------ms050001030004030804030000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFHjCCBAagAwIBAgIRAMDelVw+LRVrknnNfAzvvwUwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTIw NDE4MDAwMDAwWhcNMTMwNDE4MjM1OTU5WjAfMR0wGwYJKoZIhvcNAQkBFg5wZXRlckBwZXRl ci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKytWhRD21yXbUdIxNODMNuD hex7ykIdXI4wn8lB7a1X4RCRUWFYrk8TOyPzuTWLjNIiWn4Vsfp3AjWpBNg+k/G4uMh1/CvZ uayFtHuUrQapyEfK8awpAlPK6zyHAp0qDF9UaVAC9i5u478EjIy5K32c/89zrznyLcDrlapk XOyr8KnQWfXcbLw7TgkO1TgYVCUXy3h10X5IbdCYYKKDFfD52+ZB0pGuYPclsVu139snkv9N XMSiyL7teOeP2b0WOVCvqpWzWRXjWHy1Kxu68bc1BvfTwI4CxdofS307xxZW3tdFjGItjPay h9Qq/0Um/LOInloJQU9kI61ykBl+DjsCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTxoptwhJcBUUr8CHVnjS5/Z0HPMjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBkG A1UdEQQSMBCBDnBldGVyQHBldGVyLmRlMA0GCSqGSIb3DQEBBQUAA4IBAQBQi+rUEFOkOvHP 8IvONRNqdaokWM9XPNpTOB1xz7bnQTvrx6niomT3il3Al9/LFSa02z44W0uDQ8dXX/n774oy Ik9pSBpVUNo4p9p+Gad7F92OTmqSVu5xvKoSG7Qht3wHukWgOAtCcvyfchRtPnZfOFWpdX0H eTCcw8jR+PoEyI1RuqIoMD9nHSiMxRURTuPv67VlLdRxCG4SuJwHtynbDOaKoqZmDEkWr0RY LZIVIcIiSnVZGoxPpDOf1U6ELli/QdlOSsgkpqDHlX1or7DiBCxRYHCYckC4g2Hz95epTTNg UjKI4WTypUnvFEGaa/rVE57mEt25HjHosSvmFoEjMYIEHDCCBBgCAQEwgakwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDA3pVcPi0Va5J5zXwM778FMAkG BSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDEwODIyMDcxMFowIwYJKoZIhvcNAQkEMRYEFOc35QbZk/Dt7rJbHcvygyoczerzMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIRAMDelVw+LRVrknnNfAzvvwUwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAwN6VXD4tFWuSec18DO+/ BTANBgkqhkiG9w0BAQEFAASCAQCo0vL8Zcvbmh3a17eZiqm7J7ZSQzuosarrNlhQ0ZW+rb6f Ijvi83AMvFeDjtQ+kY8pDhx+A1wD2siac9BugW469qDaU7oVL+39Qg+63UX1qGYLxCDsa58S /HSuIxXTXrFVK/bRnfJ3qNUT43+yp68SQ0WiOvP6aLC23HM6n5ReEZr82R8pyW7u+NHRkXfb JFfIsynshq+wLTxe9f4WWQ3A01urkxt9iLjuR7j865fjpvPe5ft7R+mu4q9PdNUh1RYbjINl L7zQBzX8F+GRA6FhGDALwG+SGwkIF6SCeqIAupxnbLham3RYljM/SzFHGYiGYyjOZ8y6jjD6 clO2iX0/AAAAAAAA --------------ms050001030004030804030000-- From internet-drafts@ietf.org Tue Jan 8 14:26:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3919E21F84DB; Tue, 8 Jan 2013 14:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmDXuW-G9W1O; Tue, 8 Jan 2013 14:26:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5D1F0CFA; Tue, 8 Jan 2013 14:26:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130108222628.27497.4360.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 14:26:28 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-04.txt Pages : 20 Date : 2013-01-08 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth Clients at an Authorization Server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 17:26:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2021F8484 for ; Tue, 8 Jan 2013 17:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JkGGW+5EgSs for ; Tue, 8 Jan 2013 17:26:33 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id EB44521F8481 for ; Tue, 8 Jan 2013 17:26:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 6715B5038C for ; Wed, 9 Jan 2013 09:26:29 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pzDxRHHs6U8i for ; Wed, 9 Jan 2013 09:26:28 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id C0CF250371 for ; Wed, 9 Jan 2013 09:26:28 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_615cbd1346c7dea246cd88ca9971fd6d" Date: Wed, 09 Jan 2013 09:26:29 +0800 From: cspzhouroc To: Message-ID: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Subject: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 01:26:34 -0000 --=_615cbd1346c7dea246cd88ca9971fd6d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Dear All: I have a question in the section 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework. It tells "which in turn directs the resource owner back to the client with the authorization code." Who can let me know the reason why is the authorization code sent to client through a redirection in resource owner's agent? Any security implications? Is it possible to let the authorization server send the authorization code to the client directly (not through resource owner's user-agent)? Best Regards Brent --=_615cbd1346c7dea246cd88ca9971fd6d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear All:

I have a question in the section 1.3.1. Authoriza= tion Code in rfc6749 The OAuth 2.0 Authorization Framework.

It tells "which in turn directs the resource owner back to the client<= /span> with the authorization code."

Who can let me know the r= eason why is the authorization code sent to client through a red= irection in resource owner's agent?  Any security implica= tions?

Is it possible to let the authorization server send the aut= horization code to the client directly (not through resource own= er's user-agent)?

Best Regards
Brent

--=_615cbd1346c7dea246cd88ca9971fd6d-- From prabath@wso2.com Tue Jan 8 22:27:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557421F865D for ; Tue, 8 Jan 2013 22:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeIFMDa3y5w7 for ; Tue, 8 Jan 2013 22:27:58 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id E088B21F8506 for ; Tue, 8 Jan 2013 22:27:52 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id ep20so1444804lab.4 for ; Tue, 08 Jan 2013 22:27:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Cfb4HHSCBuYCGOSslja+AKRPJMooBSUeZoDkonbRKhU=; b=P9dhJPtvqLIjBDRtjL/umqanRVa+XAFIWUf6YE4XZ/DD/TsAYOpeXpeGspWhm8QXMH 7lRRYSmP/uyBIiHaz3puUu6HfEjlOEPMuCX4Afy6wETqCSZkmb4qjFbYrB7aS6FbplWL bj0S9PcG4/KUkEVYJvOdnJhG1SX0nWLzow5OzD1bf6Zp9LuA2x0+TL7htfZy9M5gPbXK hYTsXUmPFW/A7/fB6ri46oYayqgh55mSDUgFTJOvGbFNU5xb4cuH6itDVccZPow+b1yd IiA4RjxZgZ9mP7i8NIsnBKVamI2I6tDct9YmlXFGAXc21uBVOBEc1mLkPnf3xsxcJEXx zC9w== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr64789478lab.47.1357712870924; Tue, 08 Jan 2013 22:27:50 -0800 (PST) Received: by 10.114.69.130 with HTTP; Tue, 8 Jan 2013 22:27:50 -0800 (PST) In-Reply-To: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Date: Wed, 9 Jan 2013 11:57:50 +0530 Message-ID: From: Prabath Siriwardena To: cspzhouroc Content-Type: multipart/alternative; boundary=f46d040891f560e33404d2d5295a X-Gm-Message-State: ALoCoQnFR5GZspgxRKisCex5S+4JH9OfGHJFUZqDRSRob62YQrGKiusIh6sxRGFRgSFGPPvJz1ik Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:27:59 -0000 --f46d040891f560e33404d2d5295a Content-Type: text/plain; charset=ISO-8859-1 Hi Brent, Few points, why this doesn't create any security implications.. 1. Authorization server maintains a binding to the Client, who the token was issued to. To exchange this to an Access token client should authenticate him self. 2. Code can only be exchanged once for an acces token. Thanks & regards, -Prabath On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote: > ** > > Dear All: > > I have a question in the section 1.3.1. Authorization Code in rfc6749 The > OAuth 2.0 Authorization Framework. > > It tells "which in turn directs the resource owner back to the client with > the authorization code." > > Who can let me know the reason why is the authorization code sent to client > through a redirection in resource owner's agent? Any security > implications? > > Is it possible to let the authorization server send the authorization code > to the client directly (not through resource owner's user-agent)? > > Best Regards > Brent > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --f46d040891f560e33404d2d5295a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brent,

Few points, why this doesn't create any se= curity implications..

1. Authorization server main= tains a binding to the Client, who the token was issued to. To exchange thi= s to an Access token client should authenticate him self.
2. Code can only be exchanged once for an acces token.

<= /div>
Thanks & regards,
-Prabath

On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <= cspzhouro= c@comp.polyu.edu.hk> wrote:

= Dear All:

I h= ave a question in the section 1.3.1. Authorization Code in rfc6749 <= span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex= t-align:start;font-style:normal;display:inline!important;font-weight:normal= ;float:none;line-height:normal;color:#222222;text-transform:none;font-size:= 14px;white-space:normal;font-family:arial,sans-serif;word-spacing:0px">The = OAuth 2.0 Authorization Framework.

It = tells "which in turn directs the resource owner back to the client with the authorization code."

Who= can let me know the reason why is the authorization code sent to clien= t through a redirection in resource owner's agent? =A0Any security = implications?

Is = it possible to let the authorization server send the authorization <= span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex= t-align:start;font-style:normal;display:inline!important;font-weight:normal= ;float:none;line-height:normal;color:#222222;text-transform:none;font-size:= 14px;white-space:normal;font-family:arial,sans-serif;word-spacing:0px">code= to the client directly (not through resource owner's user-agent)?

Bes= t Regards
Bre= nt


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




--
Thanks &= amp; Regards,
Prabath

--f46d040891f560e33404d2d5295a-- From zhou.sujing@zte.com.cn Tue Jan 8 22:37:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31B21F843C; Tue, 8 Jan 2013 22:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.55 X-Spam-Level: X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uCnBu1f6L7t; Tue, 8 Jan 2013 22:37:10 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9642721F8439; Tue, 8 Jan 2013 22:37:10 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A9588126A163; Wed, 9 Jan 2013 14:39:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r096anWL096983; Wed, 9 Jan 2013 14:36:49 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 9 Jan 2013 14:36:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-09 14:36:47, Serialize complete at 2013-01-09 14:36:47 Content-Type: multipart/alternative; boundary="=_alternative 002458A748257AEE_=" X-MAIL: mse02.zte.com.cn r096anWL096983 Cc: oauth-bounces@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1dGggMi4w?= =?gb2312?b?IEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:37:14 -0000 This is a multipart message in MIME format. --=_alternative 002458A748257AEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlbiB3aHkgbm90IGxldCBhdXRoIGNvZGUgYmUgc2VudCBkaXJlY3RseSBmcm9tIEFTIHRvIENs aWVudD8NCg0KSnVzdCB3YW50IHRvIGluZm9ybSBSTyB0aGF0IGFuIGF1dGggY29kZSBoYXMgYmVl biBkaWxpdmVyZWQgdG8gQ2xpZW50PyANCg0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIw MTMtMDEtMDkgMTQ6Mjc6NTA6DQoNCj4gSGkgQnJlbnQsDQo+IA0KPiBGZXcgcG9pbnRzLCB3aHkg dGhpcyBkb2Vzbid0IGNyZWF0ZSBhbnkgc2VjdXJpdHkgaW1wbGljYXRpb25zLi4NCj4gDQo+IDEu IEF1dGhvcml6YXRpb24gc2VydmVyIG1haW50YWlucyBhIGJpbmRpbmcgdG8gdGhlIENsaWVudCwg d2hvIHRoZSANCj4gdG9rZW4gd2FzIGlzc3VlZCB0by4gVG8gZXhjaGFuZ2UgdGhpcyB0byBhbiBB Y2Nlc3MgdG9rZW4gY2xpZW50IA0KPiBzaG91bGQgYXV0aGVudGljYXRlIGhpbSBzZWxmLg0KPiAy LiBDb2RlIGNhbiBvbmx5IGJlIGV4Y2hhbmdlZCBvbmNlIGZvciBhbiBhY2NlcyB0b2tlbi4NCj4g DQo+IFRoYW5rcyAmIHJlZ2FyZHMsDQo+IC1QcmFiYXRoDQoNCj4gT24gV2VkLCBKYW4gOSwgMjAx MyBhdCA2OjU2IEFNLCBjc3B6aG91cm9jIDxjc3B6aG91cm9jQGNvbXAucG9seXUuZWR1LmhrDQo+ ID4gd3JvdGU6DQo+IERlYXIgQWxsOg0KPiANCj4gSSBoYXZlIGEgcXVlc3Rpb24gaW4gdGhlIHNl Y3Rpb24gMS4zLjEuIEF1dGhvcml6YXRpb24gQ29kZSBpbiByZmM2NzQ5IA0KPiBUaGUgT0F1dGgg Mi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrLg0KPiANCj4gSXQgdGVsbHMgIndoaWNoIGluIHR1 cm4gZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IA0KPiB3aXRo IHRoZSBhdXRob3JpemF0aW9uIGNvZGUuIg0KPiANCj4gV2hvIGNhbiBsZXQgbWUga25vdyB0aGUg cmVhc29uIHdoeSBpcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHNlbnQgdG8gDQo+IGNsaWVudCB0 aHJvdWdoIGEgcmVkaXJlY3Rpb24gaW4gcmVzb3VyY2Ugb3duZXIncyBhZ2VudD8gIEFueSBzZWN1 cml0eSANCj4gaW1wbGljYXRpb25zPw0KPiANCj4gSXMgaXQgcG9zc2libGUgdG8gbGV0IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBzZW5kIHRoZSBhdXRob3JpemF0aW9uIA0KPiBjb2RlIHRvIHRo ZSBjbGllbnQgZGlyZWN0bHkgKG5vdCB0aHJvdWdoIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2Vu dCk/DQo+IA0KPiBCZXN0IFJlZ2FyZHMNCj4gQnJlbnQNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBP QXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCj4gDQoNCj4gDQo+IC0tIA0KPiBUaGFua3MgJiBSZWdhcmRzLA0KPiBQcmFiYXRoDQo+ IA0KPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+IA0KPiBodHRwOi8vYmxvZy5mYWNpbGVs b2dpbi5jb20NCj4gaHR0cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --=_alternative 002458A748257AEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGVuIHdoeSBub3QgbGV0IGF1dGggY29kZSBiZSBzZW50 IGRpcmVjdGx5IGZyb20gQVMNCnRvIENsaWVudD88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkp1c3Qgd2FudCB0byBpbmZvcm0gUk8gdGhhdCBhbiBhdXRoIGNvZGUgaGFz IGJlZW4NCmRpbGl2ZXJlZCB0byBDbGllbnQ/IDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDEtMDkgMTQ6Mjc6 NTA6PGJyPg0KPGJyPg0KJmd0OyBIaSBCcmVudCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBGZXcgcG9pbnRzLCB3aHkgdGhpcyBkb2Vzbid0IGNyZWF0 ZSBhbnkgc2VjdXJpdHkgaW1wbGljYXRpb25zLi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAxLiBBdXRob3JpemF0aW9uIHNlcnZlciBtYWludGFpbnMg YSBiaW5kaW5nIHRvIHRoZSBDbGllbnQsIHdobyB0aGUNCjxicj4NCiZndDsgdG9rZW4gd2FzIGlz c3VlZCB0by4gVG8gZXhjaGFuZ2UgdGhpcyB0byBhbiBBY2Nlc3MgdG9rZW4gY2xpZW50IDxicj4N CiZndDsgc2hvdWxkIGF1dGhlbnRpY2F0ZSBoaW0gc2VsZi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgMi4gQ29kZSBjYW4gb25seSBiZSBleGNoYW5nZWQgb25jZSBmb3Ig YW4gYWNjZXMNCnRva2VuLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyByZWdhcmRzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAtUHJhYmF0aDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBPbiBXZWQsIEphbiA5LCAyMDEzIGF0IDY6NTYgQU0sIGNzcHpob3Vyb2MgJmx0 O2NzcHpob3Vyb2NAY29tcC5wb2x5dS5lZHUuaGs8YnI+DQomZ3Q7ICZndDsgd3JvdGU6PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERlYXIgQWxsOjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIGhhdmUgYSBxdWVzdGlvbiBpbiB0aGUgc2VjdGlvbiAxLjMuMS4gQXV0aG9yaXph dGlvbiBDb2RlIGluIHJmYzY3NDkNCjxicj4NCiZndDsgVGhlIE9BdXRoIDIuMCBBdXRob3JpemF0 aW9uIEZyYW1ld29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgdGVsbHMgJnF1b3Q7d2hpY2gg aW4gdHVybiBkaXJlY3RzIHRoZSByZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZQ0KY2xpZW50IDxi cj4NCiZndDsgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLiZxdW90Ozxicj4NCiZndDsgPGJy Pg0KJmd0OyBXaG8gY2FuIGxldCBtZSBrbm93IHRoZSByZWFzb24gd2h5IGlzIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgc2VudA0KdG8gPGJyPg0KJmd0OyBjbGllbnQgdGhyb3VnaCBhIHJlZGlyZWN0 aW9uIGluIHJlc291cmNlIG93bmVyJ3MgYWdlbnQ/ICZuYnNwO0FueQ0Kc2VjdXJpdHkgPGJyPg0K Jmd0OyBpbXBsaWNhdGlvbnM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElzIGl0IHBvc3NpYmxlIHRv IGxldCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2VuZCB0aGUgYXV0aG9yaXphdGlvbg0KPGJy Pg0KJmd0OyBjb2RlIHRvIHRoZSBjbGllbnQgZGlyZWN0bHkgKG5vdCB0aHJvdWdoIHJlc291cmNl IG93bmVyJ3MgdXNlci1hZ2VudCk/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgUmVnYXJkczxi cj4NCiZndDsgQnJlbnQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4N CiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFRoYW5r cyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsgUHJhYmF0aDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiZuYnNw Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208YnI+DQom Z3Q7IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE9B dXRoQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 002458A748257AEE_=-- From prabath@wso2.com Tue Jan 8 22:47:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9632821F8583 for ; Tue, 8 Jan 2013 22:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAR2wCY13c+c for ; Tue, 8 Jan 2013 22:47:30 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7921F84C2 for ; Tue, 8 Jan 2013 22:47:29 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id fs13so1496633lab.9 for ; Tue, 08 Jan 2013 22:47:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qQO3nhiFZbqQIzTZgEnlYY6mPxH36MSE6A52JtxaHuc=; b=lMCN4okNgyORpAQ5+zTSRvhBzBZhxzLLxSbDpztpFQ8ZiC+ncEY9Hf2TV/hU4vQQqQ LEsgVsSonFuw6jvvdwvQp0926IiH8aiSpb83UcJnE9ErPYEsqZqHjgt4sWlNrTHUBhgX dwFxD1BbBr3v73x3grAa6v+hBQjvFw1m4x76Fl4bNGMQOBedQGXf/D0RDhiYk5rD19uU Z2GvT7Jt8CAeQUX2DvvY7kJ+Dvtga38ZJh7d84Gc8IVDfubS2VPGtgsTnSZIbBh8OiCP 1ZGGHhrt/tF1g12bJfEQEBrbX2AE/Hd3+/NKMwT4ZeW0OlZNG/B5MZ7NiXsmKYfwH3TX X9wA== MIME-Version: 1.0 Received: by 10.152.45.229 with SMTP id q5mr63916362lam.34.1357714040029; Tue, 08 Jan 2013 22:47:20 -0800 (PST) Received: by 10.114.69.130 with HTTP; Tue, 8 Jan 2013 22:47:19 -0800 (PST) In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Date: Wed, 9 Jan 2013 12:17:19 +0530 Message-ID: From: Prabath Siriwardena To: Peng Zhou Content-Type: multipart/alternative; boundary=bcaec550b3361003df04d2d56f84 X-Gm-Message-State: ALoCoQm89OZMVMPkTkN8uYTNuoPvti9DCLytvmF1O+k/VAICtLWcL9LtOpqtIyEchseGHtVHCGUg Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:47:31 -0000 --bcaec550b3361003df04d2d56f84 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: > Dear Prabath: > > Thank you very much for your responses :-) > > However, I am still not quite sure why the authorization code must be > sent to the client through the RO's user-agent? > One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. Thanks & regards, -Prabath > > Best Regards > Brent > > 2013/1/9 Prabath Siriwardena : > > Prabath > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --bcaec550b3361003df04d2d56f84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 9, 2013 at 12:09 PM, Peng Zh= ou <zpbrent@gmail.com> wrote:
Dear Prabath:

Thank you very much for your responses :-)

However, I am still not quite sure why the authorization code must be
sent to the client through the RO's user-agent?
One reason I see is, bringing the authorization code via User = Agent - links the user request to the authorization code. If AS directly se= nds the code to the Resource Server the mapping between the user request an= d the code is broken.

Thanks & regards,
-Prabath

=
=A0

Best Regards
Brent

2013/1/9 Prabath Siriwardena <prabat= h@wso2.com>:
> Prabath



--
Thanks &= Regards,
Prabath

--bcaec550b3361003df04d2d56f84-- From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 22:47:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6FE21F84C2 for ; Tue, 8 Jan 2013 22:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67cFnFBhAU9y for ; Tue, 8 Jan 2013 22:47:31 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2621F870A for ; Tue, 8 Jan 2013 22:47:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 148665039B; Wed, 9 Jan 2013 14:47:18 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9Hf9+s1ocU+y; Wed, 9 Jan 2013 14:47:16 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 10B885039A; Wed, 9 Jan 2013 14:47:16 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ef2b283525d6778f9b55f9b895e8d925" Date: Wed, 09 Jan 2013 14:47:16 +0800 From: cspzhouroc To: Prabath Siriwardena In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Message-ID: <488e52918442cab2b5bc83c2cdccf662@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:47:32 -0000 --=_ef2b283525d6778f9b55f9b895e8d925 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Dear Prabath: Thank you very much for your responses :-) However, I am still not quite sure why the authorization code must be sent to the client through the RO's user-agent? Best Regards Brent On Wed, 9 Jan 2013 11:57:50 +0530, Prabath Siriwardena wrote: > Hi Brent, > > Few points, why this doesn't create any security implications.. > > 1. Authorization server maintains a binding to the Client, who the token was issued to. To exchange this to an Access token client should authenticate him self. > 2. Code can only be exchanged once for an acces token. > > Thanks & regards, > -Prabath > > On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote: > >> Dear All: >> >> I have a question in the section 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework. >> >> It tells "which in turn directs the resource owner back to the client with the authorization code." >> >> Who can let me know the reason why is the authorization code sent to client through a redirection in resource owner's agent? Any security implications? >> >> Is it possible to let the authorization server send the authorization code to the client directly (not through resource owner's user-agent)? >> >> Best Regards >> >> Brent >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org [1] >> https://www.ietf.org/mailman/listinfo/oauth [2] > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com [4] > http://RampartFAQ.com [5] Links: ------ [1] mailto:OAuth@ietf.org [2] https://www.ietf.org/mailman/listinfo/oauth [3] mailto:cspzhouroc@comp.polyu.edu.hk [4] http://blog.facilelogin.com [5] http://RampartFAQ.com --=_ef2b283525d6778f9b55f9b895e8d925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear Prabath:

Thank you very much for your responses :-)<= /span>

However, I am still not quite sure why the authorization code must= be
sent to the client throu= gh the RO's user-agent?

Best Regards
Brent

 

On Wed, 9 Jan 2013 11:57:50 +0530, Prabath Siriwardena wrote:

Hi Brent,

Few points, why this doesn't create any security implications..
1. Authorization server maintains a binding to the Client, who the tok= en was issued to. To exchange this to an Access token client should authent= icate him self.
2. Code can only be exchanged once for an acces token.
Thanks & regards,
-Prabath

On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <cspzhouroc@comp.polyu= =2Eedu.hk> wrote:

Dear All:



I have a question in the section 1.3.1. Authorization Code i= n rfc6749 The OAuth 2.0 Authorization Framework.



It tells "which in turn directs the r= esource owner back to the client with the authorization code= =2E"



Who can let me know= the reason why is the authorization code sent to client throu= gh a redirection in resource owner's agent?  Any security implications?


Is it pos= sible to let the authorization server send the authorization c= ode to the client directly (not through resource owner's user-agent)?



Best Regards

Brent


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

--
Thanks & Regards,<= br />Prabath


--=_ef2b283525d6778f9b55f9b895e8d925-- From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 22:49:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC7921F870A; Tue, 8 Jan 2013 22:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixw2ziqPVlV3; Tue, 8 Jan 2013 22:49:04 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4921F872C; Tue, 8 Jan 2013 22:49:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 16B0A5039B; Wed, 9 Jan 2013 14:49:01 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R3Ym+Y1-TuWJ; Wed, 9 Jan 2013 14:48:59 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id C172E5039A; Wed, 9 Jan 2013 14:48:59 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a12d74b1654cfc6dec652402c6aa9444" Date: Wed, 09 Jan 2013 14:49:00 +0800 From: cspzhouroc To: In-Reply-To: References: Message-ID: <435c62cb0612b3756dbe040fa1791cdd@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?b?562U5aSNOiBSZTogIEEgcXVlc3Rpb24gb2YgMS4zLjEu?= =?utf-8?q?_Authorization_Code_in_rfc6749_The_OAuth_2=2E0_Authorization_Fr?= =?utf-8?q?amework?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:49:04 -0000 --=_a12d74b1654cfc6dec652402c6aa9444 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Dear SuJing: If it is the only reason, why we send the authorization code to the client directly and send another notification without the authorization code to the RO. This way can mitigate the chance that the authorization code is exposed to the RO's user-agent, hence protecting the authorization code from leaking to possible attackers in a higher security levle. Best Regards Brent On Wed, 9 Jan 2013 14:36:37 +0800, zhou.sujing@zte.com.cn wrote: > Then why not let auth code be sent directly from AS to Client? > > Just want to inform RO that an auth code has been dilivered to Client? > > oauth-bounces@ietf.org 2013-01-09 14:27:50: > > > Hi Brent, >> > > Few points, why this doesn't create any security implications.. >> > > 1. Authorization server maintains a binding to the Client, who the > > token was issued to. To exchange this to an Access token client > > should authenticate him self. >> 2. Code can only be exchanged once for an acces token. >> > > Thanks & regards, >> -Prabath > >> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc > > > wrote: >> Dear All: > > > > I have a question in the section 1.3.1. Authorization Code in rfc6749 > > The OAuth 2.0 Authorization Framework. > > > > It tells "which in turn directs the resource owner back to the client > > with the authorization code." > > > > Who can let me know the reason why is the authorization code sent to > > client through a redirection in resource owner's agent? Any security > > implications? > > > > Is it possible to let the authorization server send the authorization > > code to the client directly (not through resource owner's user-agent)? > > > > Best Regards > > Brent >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > -- > > Thanks & Regards, > > Prabath >> > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com_______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth --=_a12d74b1654cfc6dec652402c6aa9444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear SuJing:

If it is the only reason, why we send the auth= orization code to the
client= directly and send another notification without the
authorization code to the RO. This way can mitigate= the chance that
the authori= zation code is exposed to the RO's user-agent, hence
protecting the authorization code from leaking to = possible attackers
in a hi= gher security levle.

Best Regards
Brent

 

On Wed, 9 Jan 2013 14:36:37 +0800, zhou.sujing@zte.com.cn wrote:


The= n why not let auth code be sent directly from AS to Client?
Just want to inform RO tha= t an auth code has been dilivered to Client?

<= span style=3D"font-size: x-small;">oauth-bounces@ietf.org =E5=86=99=E4=BA= =8E 2013-01-09 14:27:50:

> Hi Brent,
<= span style=3D"font-size: x-small;">>
> Few points, why this do= esn't create any security implications..
>
> 1. Authorization server maintains= a binding to the Client, who the
> token was issued to. To excha= nge this to an Access token client
> should authenticate him self= =2E
> 2. Code = can only be exchanged once for an acces token.
>
> Thanks & regards,=
> -Prabath
> On Wed, Jan 9, = 2013 at 6:56 AM, cspzhouroc
> > wrote:
<= span style=3D"font-size: x-small;">> Dear All:
>
> I = have a question in the section 1.3.1. Authorization Code in rfc6749
= > The OAuth 2.0 Authorization Framework.
>
> It tells= "which in turn directs the resource owner back to the client
> w= ith the authorization code."
>
> Who can let me know the= reason why is the authorization code sent to
> client through a = redirection in resource owner's agent?  Any security
> impli= cations?
>
> Is it possible to let the authorization ser= ver send the authorization
> code to the client directly (not thr= ough resource owner's user-agent)?
>
> Best Regards
> Brent
>=
> _______________________________________________
> OAu= th mailing list
> OAuth@ietf.org
> https://www.ietf.org/m= ailman/listinfo/oauth
>

>
> --
> Thanks & Regards,
> Prab= ath
>
&= gt; Mobile : +94 71 809 6732 
>
> http://blog.facil= elogin.com
> http://RampartFAQ.com________________________________= _______________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

 

--=_a12d74b1654cfc6dec652402c6aa9444-- From zhou.sujing@zte.com.cn Tue Jan 8 22:52:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58521F8750; Tue, 8 Jan 2013 22:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.55 X-Spam-Level: X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJCxZBJoIOrp; Tue, 8 Jan 2013 22:52:13 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19F21F874C; Tue, 8 Jan 2013 22:52:12 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 425E9A3814; Wed, 9 Jan 2013 14:52:00 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B5735704EF4; Wed, 9 Jan 2013 14:41:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r096pmPl043583; Wed, 9 Jan 2013 14:51:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Peng Zhou MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 9 Jan 2013 14:51:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-09 14:51:45, Serialize complete at 2013-01-09 14:51:45 Content-Type: multipart/alternative; boundary="=_alternative 0025B76F48257AEE_=" X-MAIL: mse01.zte.com.cn r096pmPl043583 Cc: oauth-bounces@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgQSBxdWVzdGlv?= =?gb2312?b?biBvZiAxLjMuMS4gQXV0aG9yaXphdGlvbiBDb2RlIGluIHJmYzY3NDkgVGhl?= =?gb2312?b?IE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yaw==?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:52:17 -0000 This is a multipart message in MIME format. --=_alternative 0025B76F48257AEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBhbSBqdXN0IGd1ZXNzaW5nLi4uLi4uZXhwZWN0aW5nIG90aGVycyBhbnN3ZXIgaGVyZS4gDQpP biB0aGUgb3RoZXIgaGFuZCwgYXV0aCBjb2RlIGV4cG9zZWQgdG8gUk8gZG9lcyBub3QgaGF2ZSBz ZWN1cml0eSANCmltcGxpY2F0aW9uLCANCmFzIGZhciBhcyBJIGtub3c6DQoxLiBpZiBhdXRoIGNv ZGUgaXMgdHJhbnNwb3J0ZWQgaW4gcGxhaW50ZXh0LCBpdCBzaG91bGQgcmVxdWlyZSBDTGllbnQg DQphdXRoZW50aWNhdGlvbiB0byB1c2UgaXQuDQoyLiBpZiBhdXRoIGNvZGUgIGRvIG5vdCBuZWVk IENsaWVudCBhdXRoZW50aWNhdGlvbiAsIGF1dGggY29kZSBjb3VsZCBiZSANCnNlbnQgaW4gZW5j cnlwdGlvbg0KDQpQZW5nIFpob3UgPHpwYnJlbnRAZ21haWwuY29tPiDQtNPaIDIwMTMtMDEtMDkg MTQ6NDI6MDk6DQoNCj4gRGVhciBTdUppbmc6DQo+IA0KPiBJZiBpdCBpcyB0aGUgb25seSByZWFz b24sIHdoeSB3ZSBzZW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdG8gdGhlDQo+IGNsaWVudCBk aXJlY3RseSBhbmQgc2VuZCBhbm90aGVyIG5vdGlmaWNhdGlvbiB3aXRob3V0IHRoZQ0KPiBhdXRo b3JpemF0aW9uIGNvZGUgdG8gdGhlIFJPLiBUaGlzIHdheSBjYW4gbWl0aWdhdGUgdGhlIGNoYW5j ZSB0aGF0DQo+IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMgZXhwb3NlZCB0byB0aGUgUk8ncyB1 c2VyLWFnZW50LCBoZW5jZQ0KPiBwcm90ZWN0aW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZnJv bSBsZWFraW5nIHRvIHBvc3NpYmxlIGF0dGFja2Vycw0KPiBpbiBhIGhpZ2hlciBzZWN1cml0eSBs ZXZsZS4NCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiBCcmVudA0KPiANCj4gMjAxMy8xLzkgIDx6aG91 LnN1amluZ0B6dGUuY29tLmNuPjoNCj4gPg0KPiA+IFRoZW4gd2h5IG5vdCBsZXQgYXV0aCBjb2Rl IGJlIHNlbnQgZGlyZWN0bHkgZnJvbSBBUyB0byBDbGllbnQ/DQo+ID4NCj4gPiBKdXN0IHdhbnQg dG8gaW5mb3JtIFJPIHRoYXQgYW4gYXV0aCBjb2RlIGhhcyBiZWVuIGRpbGl2ZXJlZCB0byBDbGll bnQ/DQo+ID4NCj4gPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0wOSAxNDoy Nzo1MDoNCj4gPg0KPiA+PiBIaSBCcmVudCwNCj4gPj4NCj4gPj4gRmV3IHBvaW50cywgd2h5IHRo aXMgZG9lc24ndCBjcmVhdGUgYW55IHNlY3VyaXR5IGltcGxpY2F0aW9ucy4uDQo+ID4+DQo+ID4+ IDEuIEF1dGhvcml6YXRpb24gc2VydmVyIG1haW50YWlucyBhIGJpbmRpbmcgdG8gdGhlIENsaWVu dCwgd2hvIHRoZQ0KPiA+PiB0b2tlbiB3YXMgaXNzdWVkIHRvLiBUbyBleGNoYW5nZSB0aGlzIHRv IGFuIEFjY2VzcyB0b2tlbiBjbGllbnQNCj4gPj4gc2hvdWxkIGF1dGhlbnRpY2F0ZSBoaW0gc2Vs Zi4NCj4gPj4gMi4gQ29kZSBjYW4gb25seSBiZSBleGNoYW5nZWQgb25jZSBmb3IgYW4gYWNjZXMg dG9rZW4uDQo+ID4+DQo+ID4+IFRoYW5rcyAmIHJlZ2FyZHMsDQo+ID4+IC1QcmFiYXRoDQo+ID4N Cj4gPj4gT24gV2VkLCBKYW4gOSwgMjAxMyBhdCA2OjU2IEFNLCBjc3B6aG91cm9jIA0KPGNzcHpo b3Vyb2NAY29tcC5wb2x5dS5lZHUuaGsNCj4gPj4gPiB3cm90ZToNCj4gPj4gRGVhciBBbGw6DQo+ ID4+DQo+ID4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGluIHRoZSBzZWN0aW9uIDEuMy4xLiBBdXRob3Jp emF0aW9uIENvZGUgaW4gcmZjNjc0OQ0KPiA+PiBUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24g RnJhbWV3b3JrLg0KPiA+Pg0KPiA+PiBJdCB0ZWxscyAid2hpY2ggaW4gdHVybiBkaXJlY3RzIHRo ZSByZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZSBjbGllbnQNCj4gPj4gd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBjb2RlLiINCj4gPj4NCj4gPj4gV2hvIGNhbiBsZXQgbWUga25vdyB0aGUgcmVhc29u IHdoeSBpcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHNlbnQgdG8NCj4gPj4gY2xpZW50IHRocm91 Z2ggYSByZWRpcmVjdGlvbiBpbiByZXNvdXJjZSBvd25lcidzIGFnZW50PyAgQW55IHNlY3VyaXR5 DQo+ID4+IGltcGxpY2F0aW9ucz8NCj4gPj4NCj4gPj4gSXMgaXQgcG9zc2libGUgdG8gbGV0IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBzZW5kIHRoZSBhdXRob3JpemF0aW9uDQo+ID4+IGNvZGUg dG8gdGhlIGNsaWVudCBkaXJlY3RseSAobm90IHRocm91Z2ggcmVzb3VyY2Ugb3duZXIncyANCnVz ZXItYWdlbnQpPw0KPiA+Pg0KPiA+PiBCZXN0IFJlZ2FyZHMNCj4gPj4gQnJlbnQNCj4gPj4NCj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g T0F1dGggbWFpbGluZyBsaXN0DQo+ID4+IE9BdXRoQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+DQo+ ID4+IC0tDQo+ID4+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4+IFByYWJhdGgNCj4gPj4NCj4gPj4g TW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyDQo+ID4+DQo+ID4+IGh0dHA6Ly9ibG9nLmZhY2lsZWxv Z2luLmNvbQ0KPiA+PiBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0K PiA+PiBPQXV0aEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg== --=_alternative 0025B76F48257AEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0ganVzdCBndWVzc2luZy4u Li4uLmV4cGVjdGluZyBvdGhlcnMNCmFuc3dlciBoZXJlLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9uIHRoZSBvdGhlciBoYW5kLCBhdXRoIGNvZGUgZXhwb3Nl ZA0KdG8gUk8gZG9lcyBub3QgaGF2ZSBzZWN1cml0eSBpbXBsaWNhdGlvbiwgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcyBmYXIgYXMgSSBrbm93OjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gaWYgYXV0aCBjb2RlIGlzIHRy YW5zcG9ydGVkIGluIHBsYWludGV4dCwNCml0IHNob3VsZCByZXF1aXJlIENMaWVudCBhdXRoZW50 aWNhdGlvbiB0byB1c2UgaXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4yLiBpZiBhdXRoIGNvZGUgJm5ic3A7ZG8gbm90IG5lZWQgQ2xpZW50DQphdXRoZW50aWNh dGlvbiAsIGF1dGggY29kZSBjb3VsZCBiZSBzZW50IGluIGVuY3J5cHRpb248L2ZvbnQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QZW5nIFpob3UgJmx0O3pwYnJlbnRAZ21haWwuY29tJmd0 OyDQtNPaIDIwMTMtMDEtMDkNCjE0OjQyOjA5Ojxicj4NCjxicj4NCiZndDsgRGVhciBTdUppbmc6 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIGl0IGlzIHRoZSBvbmx5IHJlYXNvbiwgd2h5IHdlIHNl bmQgdGhlIGF1dGhvcml6YXRpb24gY29kZSB0byB0aGU8YnI+DQomZ3Q7IGNsaWVudCBkaXJlY3Rs eSBhbmQgc2VuZCBhbm90aGVyIG5vdGlmaWNhdGlvbiB3aXRob3V0IHRoZTxicj4NCiZndDsgYXV0 aG9yaXphdGlvbiBjb2RlIHRvIHRoZSBSTy4gVGhpcyB3YXkgY2FuIG1pdGlnYXRlIHRoZSBjaGFu Y2UgdGhhdDxicj4NCiZndDsgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBleHBvc2VkIHRvIHRo ZSBSTydzIHVzZXItYWdlbnQsIGhlbmNlPGJyPg0KJmd0OyBwcm90ZWN0aW5nIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgZnJvbSBsZWFraW5nIHRvIHBvc3NpYmxlIGF0dGFja2Vyczxicj4NCiZndDsg aW4gYSBoaWdoZXIgc2VjdXJpdHkgbGV2bGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgUmVn YXJkczxicj4NCiZndDsgQnJlbnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAxMy8xLzkgJm5ic3A7 Jmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBUaGVuIHdoeSBub3QgbGV0IGF1dGggY29kZSBiZSBzZW50IGRpcmVjdGx5IGZyb20gQVMg dG8gQ2xpZW50Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBKdXN0IHdhbnQgdG8gaW5m b3JtIFJPIHRoYXQgYW4gYXV0aCBjb2RlIGhhcyBiZWVuIGRpbGl2ZXJlZCB0bw0KQ2xpZW50Pzxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009og MjAxMy0wMS0wOSAxNDoyNzo1MDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEhp IEJyZW50LDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEZldyBwb2ludHMs IHdoeSB0aGlzIGRvZXNuJ3QgY3JlYXRlIGFueSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuLjxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDEuIEF1dGhvcml6YXRpb24gc2VydmVy IG1haW50YWlucyBhIGJpbmRpbmcgdG8gdGhlIENsaWVudCwNCndobyB0aGU8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHRva2VuIHdhcyBpc3N1ZWQgdG8uIFRvIGV4Y2hhbmdlIHRoaXMgdG8gYW4gQWNjZXNz IHRva2VuDQpjbGllbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNob3VsZCBhdXRoZW50aWNhdGUgaGlt IHNlbGYuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAyLiBDb2RlIGNhbiBvbmx5IGJlIGV4Y2hhbmdlZCBv bmNlIGZvciBhbiBhY2NlcyB0b2tlbi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IC1QcmFiYXRoPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiBXZWQsIEphbiA5LCAyMDEzIGF0IDY6 NTYgQU0sIGNzcHpob3Vyb2MgJmx0O2NzcHpob3Vyb2NAY29tcC5wb2x5dS5lZHUuaGs8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEZWFyIEFsbDo8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIGhhdmUgYSBxdWVzdGlvbiBpbiB0 aGUgc2VjdGlvbiAxLjMuMS4gQXV0aG9yaXphdGlvbiBDb2RlDQppbiByZmM2NzQ5PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrLjxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEl0IHRlbGxzICZxdW90O3doaWNoIGluIHR1 cm4gZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjaw0KdG8gdGhlIGNsaWVudDxicj4NCiZn dDsgJmd0OyZndDsgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLiZxdW90Ozxicj4NCiZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFdobyBjYW4gbGV0IG1lIGtub3cgdGhlIHJlYXNv biB3aHkgaXMgdGhlIGF1dGhvcml6YXRpb24gY29kZQ0Kc2VudCB0bzxicj4NCiZndDsgJmd0OyZn dDsgY2xpZW50IHRocm91Z2ggYSByZWRpcmVjdGlvbiBpbiByZXNvdXJjZSBvd25lcidzIGFnZW50 PyAmbmJzcDtBbnkNCnNlY3VyaXR5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbXBsaWNhdGlvbnM/PGJy Pg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSXMgaXQgcG9zc2libGUgdG8gbGV0 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzZW5kIHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBjb2RlIHRvIHRoZSBjbGllbnQgZGlyZWN0bHkgKG5vdCB0aHJvdWdoIHJlc291 cmNlIG93bmVyJ3MNCnVzZXItYWdlbnQpPzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IEJlc3QgUmVnYXJkczxicj4NCiZndDsgJmd0OyZndDsgQnJlbnQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBQcmFiYXRoPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0 OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCjwv Zm9udD48L3R0Pg0K --=_alternative 0025B76F48257AEE_=-- From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 22:52:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AC621F874F for ; Tue, 8 Jan 2013 22:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Doz5fHJ9paj for ; Tue, 8 Jan 2013 22:52:35 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7641721F874C for ; Tue, 8 Jan 2013 22:52:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 467F15039C; Wed, 9 Jan 2013 14:52:33 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oCVrj-02lrXk; Wed, 9 Jan 2013 14:52:30 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id A176F5039A; Wed, 9 Jan 2013 14:52:30 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9923312bff1d1b42acda22d95a0c763c" Date: Wed, 09 Jan 2013 14:52:31 +0800 From: cspzhouroc To: Prabath Siriwardena In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Message-ID: X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:52:37 -0000 --=_9923312bff1d1b42acda22d95a0c763c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Dear Prabath: But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly? Best Regards Brent On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: > On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: > >> Dear Prabath: >> >> Thank you very much for your responses :-) >> >> However, I am still not quite sure why the authorization code must be >> sent to the client through the RO's user-agent? > > One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. > > Thanks & regards, > -Prabath > >> Best Regards >> Brent >> >> 2013/1/9 Prabath Siriwardena : >> > Prabath > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com [3] > http://RampartFAQ.com [4] Links: ------ [1] mailto:prabath@wso2.com [2] mailto:zpbrent@gmail.com [3] http://blog.facilelogin.com [4] http://RampartFAQ.com --=_9923312bff1d1b42acda22d95a0c763c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear Prabath:

 

But is it possible to include the the mapping between the user request = and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> = wrote:
Dear Prabath:

Thank y= ou very much for your responses :-)

However, I am still not qui= te sure why the authorization code must be
sent to the client through= the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - = links the user request to the authorization code. If AS directly sends the = code to the Resource Server the mapping between the user request and the co= de is broken.
Thanks & regards,
-Prabath
 

Best Regards
Brent
2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

--=_9923312bff1d1b42acda22d95a0c763c-- From prabath@wso2.com Tue Jan 8 22:54:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5227621F874F for ; Tue, 8 Jan 2013 22:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQvvfvFsnKiA for ; Tue, 8 Jan 2013 22:54:43 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9AB21F874C for ; Tue, 8 Jan 2013 22:54:42 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id fr10so1502400lab.3 for ; Tue, 08 Jan 2013 22:54:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1NQKKPuwQcNVfwMd9MQD2oXQT2ZkgqfP+Xi8Wr4qQ6I=; b=W0T44k0F8ABUPomHyS1UY8MRczVMQuaoMiWBun74OeT1pH/51hHNhCCzEuKkxP+usN b/BFLVXNtFzeNEmxps9ZwTKLWmV2kNBqvxxsxwTBBeGAP6cThQpKtRNKQ7HSsqmT6quI FwufRlyzDCCW4j0fTFRdmrMj56Nvm995bAxSiPPG1b8b8mTQdh1Y/EIxxKJsBE+oloH+ yQJvtgglYlquHp9jTYZVNBcq6i9Nasdin5vaHK+q086d28qi9i2qQ90Pa+8YkFgwItZE zHFHVyG9UuM81j/xbFcrAnxFhM/bjJXn7qOYqELxquCX3K9IkBdE9t0dEan8NGoeTqXl rtiQ== MIME-Version: 1.0 Received: by 10.152.124.226 with SMTP id ml2mr63311857lab.46.1357714481695; Tue, 08 Jan 2013 22:54:41 -0800 (PST) Received: by 10.114.69.130 with HTTP; Tue, 8 Jan 2013 22:54:41 -0800 (PST) In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Date: Wed, 9 Jan 2013 12:24:41 +0530 Message-ID: From: Prabath Siriwardena To: cspzhouroc Content-Type: multipart/alternative; boundary=f46d042f96fc634d7404d2d5894a X-Gm-Message-State: ALoCoQmMOJd7Yj1QP7f3ZSnLy0s1n/u5mZcuW+NK8FArBxMjgbP5fnJojAG5rIDDAZCxtRGs2C1D Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:54:44 -0000 --f46d042f96fc634d7404d2d5894a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 9, 2013 at 12:22 PM, cspzhouroc wrote: > ** > > Dear Prabath: > > > > But is it possible to include the the mapping between the user request and > the code in the message that the AS sends to the client directly? > Nope.. We need the mapping between the request and code.. Adding user name or any identifier to the message sending from AS to Client won't help. Because browser request has to identify it self. Thanks & regards, -Prabath > > > Best Regards > > Brent > > > > On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: > > > > On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: > >> Dear Prabath: >> >> Thank you very much for your responses :-) >> >> However, I am still not quite sure why the authorization code must be >> sent to the client through the RO's user-agent? >> > One reason I see is, bringing the authorization code via User Agent - > links the user request to the authorization code. If AS directly sends the > code to the Resource Server the mapping between the user request and the > code is broken. > Thanks & regards, > -Prabath > > >> >> Best Regards >> Brent >> >> 2013/1/9 Prabath Siriwardena : >> > Prabath >> > > > > -- > Thanks & Regards, > Prabath > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --f46d042f96fc634d7404d2d5894a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 9, 2013 at 12:22 PM, cspzhou= roc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

=A0

But is it possible to include the the mapping between the user request = and the code in the message that the AS sends to the client directly?

<= /div>

Nope.. We need the mapping between th= e request and code.. Adding user name or any identifier to the message send= ing from AS to Client won't help. Because browser request has to identi= fy it self.

Thanks & regards,
-Prabath

=A0

Best Regards

Brent

=A0

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.c= om> wrote:
Dear Prabath:

Thank you very much fo= r your responses :-)

However, I am still not quite sure why the aut= horization code must be
sent to the client through the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - = links the user request to the authorization code. If AS directly sends the = code to the Resource Server the mapping between the user request and the co= de is broken.
Thanks & regards,
-Prabath
=A0

Best Regards
Brent

2013/1/9= Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

=A0




--
Thanks &= Regards,
Prabath

--f46d042f96fc634d7404d2d5894a-- From zhou.sujing@zte.com.cn Tue Jan 8 22:57:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B8421F8750; Tue, 8 Jan 2013 22:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.55 X-Spam-Level: X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usZfqf0-sp+Z; Tue, 8 Jan 2013 22:57:54 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6057B21F84DE; Tue, 8 Jan 2013 22:57:54 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id C96B3126A5CC; Wed, 9 Jan 2013 15:00:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r096vVnK053772; Wed, 9 Jan 2013 14:57:31 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 9 Jan 2013 14:57:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-09 14:57:28, Serialize complete at 2013-01-09 14:57:28 Content-Type: multipart/alternative; boundary="=_alternative 00263D7848257AEE_=" X-MAIL: mse01.zte.com.cn r096vVnK053772 Cc: Peng Zhou , oauth@ietf.org, oauth-bounces@ietf.org Subject: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1dGggMi4w?= =?gb2312?b?IEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:57:55 -0000 This is a multipart message in MIME format. --=_alternative 00263D7848257AEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2VsbCwgQVMgY291bGQgc2VuZCB0aGUgcmVxdWVzdCBhbG9uZyB3aXRoIHRoZSBhdXRoIGNvZGUu DQoNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTA5IDE0OjQ3OjE5Og0KDQo+ IA0KDQo+IE9uIFdlZCwgSmFuIDksIDIwMTMgYXQgMTI6MDkgUE0sIFBlbmcgWmhvdSA8enBicmVu dEBnbWFpbC5jb20+IHdyb3RlOg0KPiBEZWFyIFByYWJhdGg6DQo+IA0KPiBUaGFuayB5b3UgdmVy eSBtdWNoIGZvciB5b3VyIHJlc3BvbnNlcyA6LSkNCj4gDQo+IEhvd2V2ZXIsIEkgYW0gc3RpbGwg bm90IHF1aXRlIHN1cmUgd2h5IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgbXVzdCBiZQ0KPiBzZW50 IHRvIHRoZSBjbGllbnQgdGhyb3VnaCB0aGUgUk8ncyB1c2VyLWFnZW50Pw0KPiANCj4gT25lIHJl YXNvbiBJIHNlZSBpcywgYnJpbmdpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSB2aWEgVXNlciBB Z2VudCANCj4gLSBsaW5rcyB0aGUgdXNlciByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIGNv ZGUuIElmIEFTIGRpcmVjdGx5IA0KPiBzZW5kcyB0aGUgY29kZSB0byB0aGUgUmVzb3VyY2UgU2Vy dmVyIHRoZSBtYXBwaW5nIGJldHdlZW4gdGhlIHVzZXIgDQo+IHJlcXVlc3QgYW5kIHRoZSBjb2Rl IGlzIGJyb2tlbi4NCj4gDQo+IFRoYW5rcyAmIHJlZ2FyZHMsDQo+IC1QcmFiYXRoDQo+IA0KPiAg DQo+IA0KPiBCZXN0IFJlZ2FyZHMNCj4gQnJlbnQNCj4gDQo+IDIwMTMvMS85IFByYWJhdGggU2ly aXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+Og0KPiA+IFByYWJhdGgNCj4gDQoNCj4gDQo+IC0t IA0KPiBUaGFua3MgJiBSZWdhcmRzLA0KPiBQcmFiYXRoDQo+IA0KPiBNb2JpbGUgOiArOTQgNzEg ODA5IDY3MzIgDQo+IA0KPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gaHR0cDovL1Jh bXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --=_alternative 00263D7848257AEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XZWxsLCBBUyBjb3VsZCBzZW5kIHRoZSByZXF1ZXN0IGFs b25nIHdpdGggdGhlIGF1dGgNCmNvZGUuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5vYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0wOSAxNDo0NzoxOTo8 YnI+DQo8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBPbiBXZWQsIEphbiA5LCAyMDEzIGF0IDEyOjA5IFBNLCBQZW5nIFpob3UgJmx0O3pwYnJl bnRAZ21haWwuY29tJmd0Ow0Kd3JvdGU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IERlYXIgUHJhYmF0aDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgeW91ciByZXNwb25zZXMgOi0pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhvd2V2ZXIs IEkgYW0gc3RpbGwgbm90IHF1aXRlIHN1cmUgd2h5IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgbXVz dA0KYmU8YnI+DQomZ3Q7IHNlbnQgdG8gdGhlIGNsaWVudCB0aHJvdWdoIHRoZSBSTydzIHVzZXIt YWdlbnQ/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg T25lIHJlYXNvbiBJIHNlZSBpcywgYnJpbmdpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSB2aWEg VXNlciBBZ2VudA0KPGJyPg0KJmd0OyAtIGxpbmtzIHRoZSB1c2VyIHJlcXVlc3QgdG8gdGhlIGF1 dGhvcml6YXRpb24gY29kZS4gSWYgQVMgZGlyZWN0bHkNCjxicj4NCiZndDsgc2VuZHMgdGhlIGNv ZGUgdG8gdGhlIFJlc291cmNlIFNlcnZlciB0aGUgbWFwcGluZyBiZXR3ZWVuIHRoZSB1c2VyDQo8 YnI+DQomZ3Q7IHJlcXVlc3QgYW5kIHRoZSBjb2RlIGlzIGJyb2tlbi48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcyw8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLVByYWJhdGg8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBCZXN0IFJlZ2FyZHM8YnI+ DQomZ3Q7IEJyZW50PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTMvMS85IFByYWJhdGggU2lyaXdh cmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7Ojxicj4NCiZndDsgJmd0OyBQcmFiYXRoPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgVGhhbmtz ICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyBQcmFiYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyJm5ic3A7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZn dDsgaHR0cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1 dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 00263D7848257AEE_=-- From prabath@wso2.com Tue Jan 8 22:59:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8921F8756 for ; Tue, 8 Jan 2013 22:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.319 X-Spam-Level: **** X-Spam-Status: No, score=4.319 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvXvl9J316oE for ; Tue, 8 Jan 2013 22:59:16 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3121F874F for ; Tue, 8 Jan 2013 22:59:16 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id b15so323364eek.2 for ; Tue, 08 Jan 2013 22:59:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=r2CejbAeEs3NrWVUxPzVHkRcQNeD4vbk2BbxHsTltzA=; b=e4XuWcTqUnT8RhezOTVa001vLbLl4GU13ELVXfiyBTXg1EPQSMiU06+kYmeAmxAQVu M2VSRFReFZQ9eSoTHcFi41VniVXoqLSqxadGqJMweWCajrCKI6IGahGbF/qFIuAK16fV KXYWHRdCBFA6Fkn0+hbjv5UsCC+ehzNBBREVcJxSoGJmpaJ/nJ2q0POWkBcNxR7BQT7s qt4sKrGbLiMw8beltCIPW61vAr39vMd9XPkEwImEHma/xQ696FVDdHy9nI/xPoq1CbMI 3OXu3O3FIRnrUdq15el4HPOo4mQ98qsDKafjVxQw735rXvZaC5TaQhHUBqAUpu0JdjHG oxbQ== MIME-Version: 1.0 Received: by 10.14.219.3 with SMTP id l3mr178381275eep.5.1357714755329; Tue, 08 Jan 2013 22:59:15 -0800 (PST) Received: by 10.223.68.211 with HTTP; Tue, 8 Jan 2013 22:59:15 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Jan 2013 12:29:15 +0530 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b621b90b29e4104d2d599ad X-Gm-Message-State: ALoCoQnyDDCVY6e/DIaMd5t/0Pd0CoA2NRo4faNJRwS5MO73ERBmzGlRRlA8zl8uxe7ABdslOWKw Cc: Peng Zhou , oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1?= =?gb2312?b?dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:59:18 -0000 --047d7b621b90b29e4104d2d599ad Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Wed, Jan 9, 2013 at 12:27 PM, wrote: > > Well, AS could send the request along with the auth code. > Not quite that will be useful.. It will be a new request that when user is directed from AS to the client. That request should identify it self. Thanks & regards, -Prabath > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-09 14:47:19: > > > > > > On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: > > Dear Prabath: > > > > Thank you very much for your responses :-) > > > > However, I am still not quite sure why the authorization code must be > > sent to the client through the RO's user-agent? > > > > One reason I see is, bringing the authorization code via User Agent > > - links the user request to the authorization code. If AS directly > > sends the code to the Resource Server the mapping between the user > > request and the code is broken. > > > > Thanks & regards, > > -Prabath > > > > > > > > Best Regards > > Brent > > > > 2013/1/9 Prabath Siriwardena : > > > Prabath > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com_______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b621b90b29e4104d2d599ad Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 9, 2013 at 12:27 PM, <zhou.sujing@zte.com.cn> wrote:

Well, AS could send the request along with the auth code.

Not quite that will be useful.. It wil= l be a new request that when user is directed from AS to the client. That r= equest should identify it self.

Thanks & regar= ds,
-Prabath
 

o= auth-bounces@ietf.org =D0=B4=D3=DA 2013-01-09 14:47:19:

>

> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> wrote:
> Dear Prabath:
>
> Thank you very much for your responses :-)
>
> However, I am still not quite sure why the authorization code must be
> sent to the client through the RO's user-agent?
>
> One reason I see is, bringing the authorization code via User Agent
> - links the user request to the authorization code. If AS directly
> sends the code to the Resource Server the mapping between the user
> request and the code is broken.
>
> Thanks & regards,
> -Prabath
>
>  
>
> Best Regards
> Brent
>
> 2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> > Prabath
>

>
> --
> Thanks & Regards,
> Prabath
> http://RampartFAQ.com_________________________= ______________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



--
Thanks &= Regards,
Prabath

--047d7b621b90b29e4104d2d599ad-- From phil.hunt@oracle.com Tue Jan 8 23:00:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3E21F87D5 for ; Tue, 8 Jan 2013 23:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwRBtzJ8CTTx for ; Tue, 8 Jan 2013 23:00:13 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B9F7421F8756 for ; Tue, 8 Jan 2013 23:00:13 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r09708VW022982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 07:00:09 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r09707sG026984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 07:00:08 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r09706ig009375; Wed, 9 Jan 2013 01:00:06 -0600 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jan 2013 23:00:06 -0800 References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9A9F38B1-9FC3-4FC2-9736-FA5391F004C5 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Tue, 8 Jan 2013 23:00:03 -0800 To: cspzhouroc X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Peng Zhou , "oauth@ietf.org" Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 07:00:15 -0000 --Apple-Mail-9A9F38B1-9FC3-4FC2-9736-FA5391F004C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The idea is to form a bridge between a user, their user-agent, and the clien= t application while at the same time keeping the security credential and the= client app cred separate.=20 The redirect with code flow enables the separate contexts to be bound togeth= er.=20 As soon as you do this in one step, then the client app needs to be able to h= andle the users credentials (eg uid/pwd) directly. Remember that one of the o= riginal reasons for the auth flow was to eliminate the password anti-pattern= .=20 Phil Sent from my phone. On 2013-01-08, at 22:52, cspzhouroc wrote: > Dear Prabath: >=20 > =20 >=20 > But is it possible to include the the mapping between the user request and= the code in the message that the AS sends to the client directly? >=20 > =20 >=20 > Best Regards >=20 > Brent >=20 > =20 >=20 > On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >=20 >>=20 >>=20 >> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>> Dear Prabath: >>>=20 >>> Thank you very much for your responses :-) >>>=20 >>> However, I am still not quite sure why the authorization code must be >>> sent to the client through the RO's user-agent? >> One reason I see is, bringing the authorization code via User Agent - lin= ks the user request to the authorization code. If AS directly sends the code= to the Resource Server the mapping between the user request and the code is= broken. >> Thanks & regards, >> -Prabath >> =20 >>>=20 >>> Best Regards >>> Brent >>>=20 >>> 2013/1/9 Prabath Siriwardena : >>> > Prabath >>=20 >>=20 >>=20 >> --=20 >> Thanks & Regards, >> Prabath >> Mobile : +94 71 809 6732=20 >>=20 >> http://blog.facilelogin.com >> http://RampartFAQ.com > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9A9F38B1-9FC3-4FC2-9736-FA5391F004C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. 

The redirect with code flow enables the separate contexts to be bound together. 

As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. 

Phil

Sent from my phone.

Dear Prabath:

 

But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> wrote:
Dear Prabath:

Thank you very much for your responses :-)

However, I am still not quite sure why the authorization code must be
sent to the client through the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken.
Thanks & regards,
-Prabath
 

Best Regards
Brent

2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-9A9F38B1-9FC3-4FC2-9736-FA5391F004C5-- From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 23:00:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF28121F87E1; Tue, 8 Jan 2013 23:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SPEC_LEO_LINE03a=0.408, SARE_SPEC_LEO_LINE03f=0.612, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgRFFHfEpZzv; Tue, 8 Jan 2013 23:00:44 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45721F87D9; Tue, 8 Jan 2013 23:00:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 520F25039B; Wed, 9 Jan 2013 15:00:36 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hQifgPKrouUk; Wed, 9 Jan 2013 15:00:35 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id EAA9F5039A; Wed, 9 Jan 2013 15:00:34 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6e560e1d5908eee0699e774499df55d0" Date: Wed, 09 Jan 2013 15:00:35 +0800 From: cspzhouroc To: Peng Zhou In-Reply-To: References: Message-ID: X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: oauth-bounces@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] =?utf-8?b?562U5aSNOiBSZTogIEEgcXVlc3Rpb24gb2YgMS4zLjEu?= =?utf-8?q?_Authorization_Code_in_rfc6749_The_OAuth_2=2E0_Authorization_Fr?= =?utf-8?q?amework?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 07:00:45 -0000 --=_6e560e1d5908eee0699e774499df55d0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Yes, the leaking on transmission is not a security issue. However, this code could be exposed to the resource owner or other applications with access to the resource owner's user-agent. zhou.sujing@zte.com.cn 14:51 (7 ) , cspzhouroc, oauth, oauth-bounces, Prabath I am just guessing......expecting others answer here. On the other hand, auth code exposed to RO does not have security implication, as far as I know: 1. if auth code is transported in plaintext, it should require CLient authentication to use it. 2. if auth code do not need Client authentication , auth code could be sent in encryption Peng Zhou 2013-01-09 [9] 14:42:09: On Wed, 9 Jan 2013 14:42:09 +0800, Peng Zhou wrote: > Dear SuJing: > > If it is the only reason, why we send the authorization code to the > client directly and send another notification without the > authorization code to the RO. This way can mitigate the chance that > the authorization code is exposed to the RO's user-agent, hence > protecting the authorization code from leaking to possible attackers > in a higher security levle. > > Best Regards > Brent > > 2013/1/9 : >> Then why not let auth code be sent directly from AS to Client? Just want to inform RO that an auth code has been dilivered to Client? oauth-bounces@ietf.org [4] 2013-01-09 14:27:50: >> >>> Hi Brent, Few points, why this doesn't create any security implications.. 1. Authorization server maintains a binding to the Client, who the token was issued to. To exchange this to an Access token client should authenticate him self. 2. Code can only be exchanged once for an acces token. Thanks & regards, -Prabath >> >>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote: >>> Dear All: I have a question in the section 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework. It tells "which in turn directs the resource owner back to the client with the authorization code." Who can let me know the reason why is the authorization code sent to client through a redirection in resource owner's agent? Any security implications? Is it possible to let the authorization server send the authorization code to the client directly (not through resource owner's user-agent)? Best Regards Brent _______________________________________________ OAuth mailing list OAuth@ietf.org [2] https://www.ietf.org/mailman/listinfo/oauth [3] >> 00 >> ks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com [5] http://RampartFAQ.com_______________________________________________ [6] OAuth mai >> >>> /oauth">https://www.ietf.org/mailman/listinfo/oauth >> >>> Links: ------ [1] mailto:cspzhouroc@comp.polyu.edu.hk [2] mailto:OAuth@ietf.org [3] https://www.ietf.org/mailman/listinfo/oauth [4] mailto:oauth-bounces@ietf.org [5] http://blog.facilelogin.com [6] http://RampartFAQ.com_______________________________________________ [7] mailto:zhou.sujing@zte.com.cn [8] mailto:zpbrent@gmail.com [9] http://webmail.comp.polyu.edu.hk/tel:2013-01-09 --=_6e560e1d5908eee0699e774499df55d0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 

Yes, the leaking on transmissio=
n is not a security issue. However, this code could be exposed to the resou=
rce owner or other applications with access to the resource owner's user-ag=
ent.
zhou.sujing@zte.com.cn
&nb= sp;14:51 (7 =E5=88=86=E9=92=9F=E5=89=8D)
3D""
3D""
=E5=8F=91=E9=80=81=E8=87=B3 =E6=88=91, cspzhouroc, oauth, oauth-bounces= , Prabath
3D""
=E8=8B=B1=E6=96=87
=E4=B8=AD=E6=96=87
   
=E7= =BF=BB=E8=AF=91=E9=82=AE=E4=BB=B6
= =E5=AF=B9=E8=8B=B1=E6=96=87=E5=81=9C=E7=94=A8
I am just guessing......expecting others answer here. 
On the other hand, auth code exposed to RO d= oes not have security implication,&nb= sp;
as far as I know:&nbs= p;
1. if auth code is transported in plaintext, it should require CLient auth= entication to use it. 
2. i= f auth code  do not need Client authentication , auth code could be se= nt in encryption <= br />
Peng Zhou <zp= brent@gmail.com> =E5=86=99=E4=BA=8E 2013-01-09 14:42:09:

On Wed, 9 Jan 2013 14:42:09 +0800, Peng Zhou wrote:

Dear SuJing:

If it is the only reason, why we send the authorization code to the
client directly and send another notification without the
authorization code to the RO. This way can mitigate the chance that
the authorization code is exposed to the RO's user-agent, hence
protecting the authorization code from leaking to possible attackers
in a higher security levle.

Best Regards
Brent

2013/1/9  <zhou.sujing@zte.com=
=2Ecn>:


Then why not let auth code be sent directly from AS to Client?

Just want to inform RO that an auth code has been dilivered to Client?

oauth-bounces@ietf.org =E5=86=
=99=E4=BA=8E 2013-01-09 14:27:50:


Hi Brent,

Few points, why this doesn't create any security implications..

1. Authorization server maintains a binding to the Client, who the
token was issued to. To exchange this to an Access token client
should authenticate him self.
2. Code can only be exchanged once for an acces token.

Thanks & regards,
-Prabath



On Wed, Jan 9, 2013 at 6:56 AM, cspzh=
ouroc <cspzhouroc@comp=
=2Epolyu.edu.hk

wrote:

Dear All:

I have a question in the section 1.3.1. Authorization Code in rfc6749
The OAuth 2.0 Authorization Framework.

It tells "which in turn directs the resource owner back to the client
with the authorization code."

Who can let me know the reason why is the authorization code sent to
client through a redirection in resource owner's agent?  Any security
implications?

Is it possible to let the authorization server send the authorization
code to the client directly (not through resource owner's user-agent)?

Best Regards
Brent

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








--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com_______________________________________________<=
/a>



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

 

--=_6e560e1d5908eee0699e774499df55d0-- From cspzhouroc@comp.polyu.edu.hk Tue Jan 8 23:18:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0228E21F867D for ; Tue, 8 Jan 2013 23:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYvnBcWVrEjR for ; Tue, 8 Jan 2013 23:18:16 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id D5DDA21F867B for ; Tue, 8 Jan 2013 23:18:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 8EC255039B; Wed, 9 Jan 2013 15:18:12 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o8yF7q8Pt9cR; Wed, 9 Jan 2013 15:18:11 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 4674350378; Wed, 9 Jan 2013 15:18:11 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a94ec7b45af4136921b4903934bd9a74" Date: Wed, 09 Jan 2013 15:18:12 +0800 From: cspzhouroc To: Phil Hunt In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> Message-ID: <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 07:18:17 -0000 --=_a94ec7b45af4136921b4903934bd9a74 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS? On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: > The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. > > The redirect with code flow enables the separate contexts to be bound together. > > As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. > > Phil > > Sent from my phone. > > On 2013-01-08, at 22:52, cspzhouroc wrote: > >> Dear Prabath: >> >> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly? >> >> Best Regards >> >> Brent >> >> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >> >>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>> >>>> Dear Prabath: >>>> >>>> Thank you very much for your responses :-) >>>> >>>> However, I am still not quite sure why the authorization code must be >>>> sent to the client through the RO's user-agent? >>> >>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. >>> Thanks & regards, >>> -Prabath >>> >>>> Best Regards >>>> Brent >>>> >>>> 2013/1/9 Prabath Siriwardena : >>>> > Prabath >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com [3] >>> http://RampartFAQ.com [4] > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org [5] >> https://www.ietf.org/mailman/listinfo/oauth [6] Links: ------ [1] mailto:prabath@wso2.com [2] mailto:zpbrent@gmail.com [3] http://blog.facilelogin.com [4] http://RampartFAQ.com [5] mailto:OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:cspzhouroc@comp.polyu.edu.hk --=_a94ec7b45af4136921b4903934bd9a74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

Do you mean the bounding information must be presented by the RO? The cl= ient cannot trust the RO-client bounding information that is received from = AS?

 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

The idea is to form a bridge between a user, their user-agent, and the= client application while at the same time keeping the security credential = and the client app cred separate. 
The redirect with code flow enables the separate contexts to be bound = together. 
As soon as you do this in one step, then the client app needs to be ab= le to handle the users credentials (eg uid/pwd) directly. Remember that one= of the original reasons for the auth flow was to eliminate the password an= ti-pattern. 

Phil
Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

 

But is it possible to include the the mapping between the user request = and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> = wrote:
Dear Prabath:

Th= ank you very much for your responses :-)

However, I am still no= t quite sure why the authorization code must be
sent to the client th= rough the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - = links the user request to the authorization code. If AS directly sends the = code to the Resource Server the mapping between the user request and the co= de is broken.
Thanks & regards,
-Prabath
 

Best Regards
Br= ent

2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

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

 

--=_a94ec7b45af4136921b4903934bd9a74-- From phil.hunt@oracle.com Tue Jan 8 23:31:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21221F87AC for ; Tue, 8 Jan 2013 23:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awXLYx1mqDLT for ; Tue, 8 Jan 2013 23:31:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 090D821F870A for ; Tue, 8 Jan 2013 23:31:33 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r097VR6R029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 07:31:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r097VPEY019489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 07:31:25 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r097VOIY012087; Wed, 9 Jan 2013 01:31:25 -0600 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jan 2013 23:31:24 -0800 References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> Mime-Version: 1.0 (1.0) In-Reply-To: <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> Content-Type: multipart/alternative; boundary=Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C Content-Transfer-Encoding: 7bit Message-Id: <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Tue, 8 Jan 2013 23:31:22 -0800 To: cspzhouroc X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Peng Zhou , "oauth@ietf.org" Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 07:31:35 -0000 --Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The AS is independently authenticating the user and the client in separate s= teps. Thus it is the AS binding that relation between user and client together ult= imately in a scoped access token through a 3-leg process.=20 Phil Sent from my phone. On 2013-01-08, at 23:18, cspzhouroc wrote: > =20 >=20 > Do you mean the bounding information must be presented by the RO? The clie= nt cannot trust the RO-client bounding information that is received from AS?= >=20 > =20 >=20 > On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: >=20 >> The idea is to form a bridge between a user, their user-agent, and the cl= ient application while at the same time keeping the security credential and t= he client app cred separate.=20 >> The redirect with code flow enables the separate contexts to be bound tog= ether.=20 >> As soon as you do this in one step, then the client app needs to be able t= o handle the users credentials (eg uid/pwd) directly. Remember that one of t= he original reasons for the auth flow was to eliminate the password anti-pat= tern.=20 >>=20 >> Phil >> Sent from my phone. >>=20 >> On 2013-01-08, at 22:52, cspzhouroc wrote:= >>=20 >>> Dear Prabath: >>>=20 >>> =20 >>>=20 >>> But is it possible to include the the mapping between the user request a= nd the code in the message that the AS sends to the client directly? >>>=20 >>> =20 >>>=20 >>> Best Regards >>>=20 >>> Brent >>>=20 >>> =20 >>>=20 >>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>>> Dear Prabath: >>>>=20 >>>> Thank you very much for your responses :-) >>>>=20 >>>> However, I am still not quite sure why the authorization code must be >>>> sent to the client through the RO's user-agent? >>> One reason I see is, bringing the authorization code via User Agent - li= nks the user request to the authorization code. If AS directly sends the cod= e to the Resource Server the mapping between the user request and the code i= s broken. >>> Thanks & regards, >>> -Prabath >>> =20 >>>>=20 >>>> Best Regards >>>> Brent >>>>=20 >>>> 2013/1/9 Prabath Siriwardena : >>>> > Prabath >>>=20 >>>=20 >>>=20 >>> --=20 >>> Thanks & Regards, >>> Prabath >>> Mobile : +94 71 809 6732=20 >>>=20 >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The AS is independently authenticating= the user and the client in separate steps.

Thus it is the AS binding that relation between user and c= lient together ultimately in a scoped access token through a 3-leg process.&= nbsp;

Phil

Sent from my phone.
=

On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean the bounding information must be presented by the RO? The cli= ent cannot trust the RO-client bounding information that is received from AS= ?

 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

The idea is to form a bridge between a user, their user-agent, and the c= lient application while at the same time keeping the security credential and= the client app cred separate. 
The redirect with code flow enables the separate contexts to be bound t= ogether. 
As soon as you do this in one step, then the client app needs to be abl= e to handle the users credentials (eg uid/pwd) directly. Remember that one o= f the original reasons for the auth flow was to eliminate the password anti-= pattern. 

Phil
Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

 

But is it possible to include the the mapping between the user request a= nd the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou = <zpbrent@gmail.com> wr= ote:
Dear Prabath:

Thank yo= u very much for your responses :-)

However, I am still not quite sur= e why the authorization code must be
sent to the client through the RO's= user-agent?
One reason I see is, bringing the authorization code via User Agent - l= inks the user request to the authorization code. If AS directly sends the co= de to the Resource Server the mapping between the user request and the code i= s broken.
Thanks & regards,
-Prabath
 

Best Regards
Brent
2013/1/9 Prabath Siriwardena <p= rabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

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

 

= --Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C-- From cspzhouroc@comp.polyu.edu.hk Wed Jan 9 00:09:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E021F84FD for ; Wed, 9 Jan 2013 00:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub6ouXrOa7YB for ; Wed, 9 Jan 2013 00:09:30 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id AF2FA21F870A for ; Wed, 9 Jan 2013 00:09:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 1E10850387; Wed, 9 Jan 2013 16:09:23 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FkdnuLrO0nXj; Wed, 9 Jan 2013 16:09:19 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 667AF50378; Wed, 9 Jan 2013 16:09:19 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c702160e7c156ccb9fd262b2a8c602bc" Date: Wed, 09 Jan 2013 16:09:20 +0800 From: cspzhouroc To: Phil Hunt In-Reply-To: <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> Message-ID: <7c77a1b3013a22ed01efe15e741f3265@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:09:32 -0000 --=_c702160e7c156ccb9fd262b2a8c602bc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Do you mean, in the stage that AS notify the authorization code to the client through the RO, the AS has not authenticated the client yet. Therefore, the AS cannot send the authorization code to the client directly. Instead, the AS will authenticate the client when the client send the authorization code to AS for exchanging an access token? On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote: > The AS is independently authenticating the user and the client in separate steps. > > Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. > > Phil > > Sent from my phone. > > On 2013-01-08, at 23:18, cspzhouroc wrote: > >> Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS? >> >> On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: >> >>> The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. >>> The redirect with code flow enables the separate contexts to be bound together. >>> As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. >>> >>> Phil >>> Sent from my phone. >>> >>> On 2013-01-08, at 22:52, cspzhouroc wrote: >>> >>>> Dear Prabath: >>>> >>>> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly? >>>> >>>> Best Regards >>>> >>>> Brent >>>> >>>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >>>> >>>>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>>>> >>>>>> Dear Prabath: >>>>>> >>>>>> Thank you very much for your responses :-) >>>>>> >>>>>> However, I am still not quite sure why the authorization code must be >>>>>> sent to the client through the RO's user-agent? >>>>> >>>>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. >>>>> Thanks & regards, >>>>> -Prabath >>>>> >>>>>> Best Regards >>>>>> Brent >>>>>> >>>>>> 2013/1/9 Prabath Siriwardena : >>>>>> > Prabath >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Prabath >>>>> Mobile : +94 71 809 6732 >>>>> >>>>> http://blog.facilelogin.com [3] >>>>> http://RampartFAQ.com [4] >>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org [5] >>>> https://www.ietf.org/mailman/listinfo/oauth [6] Links: ------ [1] mailto:prabath@wso2.com [2] mailto:zpbrent@gmail.com [3] http://blog.facilelogin.com [4] http://RampartFAQ.com [5] mailto:OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:cspzhouroc@comp.polyu.edu.hk [8] mailto:cspzhouroc@comp.polyu.edu.hk --=_c702160e7c156ccb9fd262b2a8c602bc Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

Do you mean, in the stage that AS notify the authorization code to the c= lient through the RO, the AS has not authenticated the client yet. Therefor= e, the AS cannot send the authorization code to the client directly. Instea= d, the AS will authenticate the client when the client send the authorizati= on code to AS for exchanging an access token?

 

On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote:

The AS is independently authenticating the user and the client in sepa= rate steps.

Thus it is the AS binding that relation between user and client = together ultimately in a scoped access token through a 3-leg process. =

Phil
Sent from my phone.

On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean the bounding information must be presented by the RO? The cl= ient cannot trust the RO-client bounding information that is received from = AS?

 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

The idea is to form a bridge between a user, their user-agent, and the= client application while at the same time keeping the security credential = and the client app cred separate. 
The redirect with code flow enables the separate contexts to be bound = together. 
As soon as you do this in one step, then the client app needs to be ab= le to handle the users credentials (eg uid/pwd) directly. Remember that one= of the original reasons for the auth flow was to eliminate the password an= ti-pattern. 

Phil
Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

 

But is it possible to include the the mapping between the user request = and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> = wrote:
Dear Prabath:

Thank you very much for your responses :-)

However, I am sti= ll not quite sure why the authorization code must be
sent to the clie= nt through the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - = links the user request to the authorization code. If AS directly sends the = code to the Resource Server the mapping between the user request and the co= de is broken.
Thanks & regards,
-Prabath
 

Best Regards
Brent

2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

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

 

 

--=_c702160e7c156ccb9fd262b2a8c602bc-- From phil.hunt@oracle.com Wed Jan 9 00:11:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BC221F87C4 for ; Wed, 9 Jan 2013 00:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBz4kBWgIoxl for ; Wed, 9 Jan 2013 00:11:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1A92621F87BA for ; Wed, 9 Jan 2013 00:11:30 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r098BNGk022076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 08:11:24 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r098BMpJ026964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 08:11:23 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r098BMxZ019266; Wed, 9 Jan 2013 02:11:22 -0600 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jan 2013 00:11:22 -0800 References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> <7c77a1b3013a22ed01efe15e741f3265@comp.polyu.edu.hk> Mime-Version: 1.0 (1.0) In-Reply-To: <7c77a1b3013a22ed01efe15e741f3265@comp.polyu.edu.hk> Content-Type: multipart/alternative; boundary=Apple-Mail-3B4BBAFC-9C9F-4543-AC88-27CE84027127 Content-Transfer-Encoding: 7bit Message-Id: <76052798-FF20-4637-97F4-CED948099266@oracle.com> X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Wed, 9 Jan 2013 00:11:20 -0800 To: cspzhouroc X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Peng Zhou , "oauth@ietf.org" Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:11:31 -0000 --Apple-Mail-3B4BBAFC-9C9F-4543-AC88-27CE84027127 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes Phil Sent from my phone. On 2013-01-09, at 0:09, cspzhouroc wrote: > =20 >=20 > Do you mean, in the stage that AS notify the authorization code to the cli= ent through the RO, the AS has not authenticated the client yet. Therefore, t= he AS cannot send the authorization code to the client directly. Instead, th= e AS will authenticate the client when the client send the authorization cod= e to AS for exchanging an access token? >=20 > =20 >=20 > On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote: >=20 >> The AS is independently authenticating the user and the client in separat= e steps. >>=20 >> Thus it is the AS binding that relation between user and client together u= ltimately in a scoped access token through a 3-leg process.=20 >>=20 >> Phil >> Sent from my phone. >>=20 >> On 2013-01-08, at 23:18, cspzhouroc wrote:= >>=20 >>> =20 >>>=20 >>> Do you mean the bounding information must be presented by the RO? The cl= ient cannot trust the RO-client bounding information that is received from A= S? >>>=20 >>> =20 >>>=20 >>> On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: >>>=20 >>> The idea is to form a bridge between a user, their user-agent, and the c= lient application while at the same time keeping the security credential and= the client app cred separate.=20 >>> The redirect with code flow enables the separate contexts to be bound to= gether.=20 >>> As soon as you do this in one step, then the client app needs to be able= to handle the users credentials (eg uid/pwd) directly. Remember that one of= the original reasons for the auth flow was to eliminate the password anti-p= attern.=20 >>>=20 >>> Phil >>> Sent from my phone. >>>=20 >>> On 2013-01-08, at 22:52, cspzhouroc wrote= : >>>=20 >>> Dear Prabath: >>>=20 >>> =20 >>>=20 >>> But is it possible to include the the mapping between the user request a= nd the code in the message that the AS sends to the client directly? >>>=20 >>> =20 >>>=20 >>> Best Regards >>>=20 >>> Brent >>>=20 >>> =20 >>>=20 >>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>>> Dear Prabath: >>>>=20 >>>> Thank you very much for your responses :-) >>>>=20 >>>> However, I am still not quite sure why the authorization code must be >>>> sent to the client through the RO's user-agent? >>> One reason I see is, bringing the authorization code via User Agent - li= nks the user request to the authorization code. If AS directly sends the cod= e to the Resource Server the mapping between the user request and the code i= s broken. >>> Thanks & regards, >>> -Prabath >>> =20 >>>>=20 >>>> Best Regards >>>> Brent >>>>=20 >>>> 2013/1/9 Prabath Siriwardena : >>>> > Prabath >>>=20 >>>=20 >>>=20 >>> --=20 >>> Thanks & Regards, >>> Prabath >>> Mobile : +94 71 809 6732=20 >>>=20 >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-3B4BBAFC-9C9F-4543-AC88-27CE84027127 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yes

Phil

Sent from my phone.

On 2013-01-09, at 0:09, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean, in the stage that AS notify the authorization code to the client through the RO, the AS has not authenticated the client yet. Therefore, the AS cannot send the authorization code to the client directly. Instead, the AS will authenticate the client when the client send the authorization code to AS for exchanging an access token?

 

On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote:

The AS is independently authenticating the user and the client in separate steps.

Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. 

Phil
Sent from my phone.

On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS?

 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. 
The redirect with code flow enables the separate contexts to be bound together. 
As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. 

Phil
Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

 

But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> wrote:
Dear Prabath:

Thank you very much for your responses :-)

However, I am still not quite sure why the authorization code must be
sent to the client through the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken.
Thanks & regards,
-Prabath
 

Best Regards
Brent

2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

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

 

 

--Apple-Mail-3B4BBAFC-9C9F-4543-AC88-27CE84027127-- From cspzhouroc@comp.polyu.edu.hk Wed Jan 9 00:13:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF121F8541 for ; Wed, 9 Jan 2013 00:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJWJdYWu5hFD for ; Wed, 9 Jan 2013 00:13:42 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9521F853C for ; Wed, 9 Jan 2013 00:13:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 1649F50387; Wed, 9 Jan 2013 16:13:40 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wzr-P1vf8jEf; Wed, 9 Jan 2013 16:13:39 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 1011450378; Wed, 9 Jan 2013 16:13:39 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c23d971cd37010adba4d22002e201026" Date: Wed, 09 Jan 2013 16:13:40 +0800 From: cspzhouroc To: Phil Hunt In-Reply-To: <76052798-FF20-4637-97F4-CED948099266@oracle.com> References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk> <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> <7c77a1b3013a22ed01efe15e741f3265@comp.polyu.edu.hk> <76052798-FF20-4637-97F4-CED948099266@oracle.com> Message-ID: X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:13:45 -0000 --=_c23d971cd37010adba4d22002e201026 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Noted and thank you very much for your help :-) On Wed, 9 Jan 2013 00:11:20 -0800, Phil Hunt wrote: > Yes > > Phil > > Sent from my phone. > > On 2013-01-09, at 0:09, cspzhouroc wrote: > >> Do you mean, in the stage that AS notify the authorization code to the client through the RO, the AS has not authenticated the client yet. Therefore, the AS cannot send the authorization code to the client directly. Instead, the AS will authenticate the client when the client send the authorization code to AS for exchanging an access token? >> >> On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote: >> >>> The AS is independently authenticating the user and the client in separate steps. >>> >>> Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. >>> >>> Phil >>> Sent from my phone. >>> >>> On 2013-01-08, at 23:18, cspzhouroc wrote: >>> >>>> Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS? >>>> >>>> On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: >>>> >>>>> The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. >>>>> The redirect with code flow enables the separate contexts to be bound together. >>>>> As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. >>>>> >>>>> Phil >>>>> Sent from my phone. >>>>> >>>>> On 2013-01-08, at 22:52, cspzhouroc wrote: >>>>> >>>>>> Dear Prabath: >>>>>> >>>>>> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly? >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Brent >>>>>> >>>>>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >>>>>> >>>>>>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou wrote: >>>>>>> >>>>>>>> Dear Prabath: >>>>>>>> >>>>>>>> Thank you very much for your responses :-) >>>>>>>> >>>>>>>> However, I am still not quite sure why the authorization code must be >>>>>>>> sent to the client through the RO's user-agent? >>>>>>> >>>>>>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. >>>>>>> Thanks & regards, >>>>>>> -Prabath >>>>>>> >>>>>>>> Best Regards >>>>>>>> Brent >>>>>>>> >>>>>>>> 2013/1/9 Prabath Siriwardena : >>>>>>>> > Prabath >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> Prabath >>>>>>> Mobile : +94 71 809 6732 >>>>>>> >>>>>>> http://blog.facilelogin.com [3] >>>>>>> http://RampartFAQ.com [4] >>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org [5] >>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] Links: ------ [1] mailto:prabath@wso2.com [2] mailto:zpbrent@gmail.com [3] http://blog.facilelogin.com [4] http://RampartFAQ.com [5] mailto:OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:cspzhouroc@comp.polyu.edu.hk [8] mailto:cspzhouroc@comp.polyu.edu.hk [9] mailto:cspzhouroc@comp.polyu.edu.hk --=_c23d971cd37010adba4d22002e201026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

Noted and thank you very much for your help :-)

 

On Wed, 9 Jan 2013 00:11:20 -0800, Phil Hunt wrote:

Yes

Phil
Sent from my phone.

On 2013-01-09, at 0:09, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean, in the stage that AS notify the authorization code to the c= lient through the RO, the AS has not authenticated the client yet. Therefor= e, the AS cannot send the authorization code to the client directly. Instea= d, the AS will authenticate the client when the client send the authorizati= on code to AS for exchanging an access token?

 

On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote:

The AS is independently authenticating the user and the client in sepa= rate steps.

Thus it is the AS binding that relation between user and client = together ultimately in a scoped access token through a 3-leg process. =

Phil
Sent from my phone.

On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

 

Do you mean the bounding information must be presented by the RO? The cl= ient cannot trust the RO-client bounding information that is received from = AS?

 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

The idea is to form a bridge between a user, their user-agent, and the= client application while at the same time keeping the security credential = and the client app cred separate. 
The redirect with code flow enables the separate contexts to be bound = together. 
As soon as you do this in one step, then the client app needs to be ab= le to handle the users credentials (eg uid/pwd) directly. Remember that one= of the original reasons for the auth flow was to eliminate the password an= ti-pattern. 

Phil
Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

Dear Prabath:

 

But is it possible to include the the mapping between the user request = and the code in the message that the AS sends to the client directly?

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:



On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> = wrote:
Dear Prabath:

Thank you very much for your responses :-)

However, I a= m still not quite sure why the authorization code must be
sent to the= client through the RO's user-agent?
One reason I see is, bringing the authorization code via User Agent - = links the user request to the authorization code. If AS directly sends the = code to the Resource Server the mapping between the user request and the co= de is broken.
Thanks & regards,
-Prabath
 

Best Regard= s
Brent

2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
> Prabath



--
Thanks & Regards,
Prabath

 

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

 

 

 

--=_c23d971cd37010adba4d22002e201026-- From gffletch@aol.com Wed Jan 9 05:08:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF021F86E4 for ; Wed, 9 Jan 2013 05:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD53UOzyndCh for ; Wed, 9 Jan 2013 05:08:13 -0800 (PST) Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56621F86DC for ; Wed, 9 Jan 2013 05:08:13 -0800 (PST) Received: from mtaout-db03.r1000.mx.aol.com (mtaout-db03.r1000.mx.aol.com [172.29.51.195]) by imr-mb02.mx.aol.com (Outbound Mail Relay) with ESMTP id A50233800004D; Wed, 9 Jan 2013 08:08:12 -0500 (EST) Received: from palantir.local (unknown [64.79.50.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9113CE000117; Wed, 9 Jan 2013 08:08:11 -0500 (EST) Message-ID: <50ED6BBB.40008@aol.com> Date: Wed, 09 Jan 2013 08:08:11 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: OAuth WG References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de> In-Reply-To: <50EC988E.7070007@fun.de> Content-Type: multipart/alternative; boundary="------------070602000307040705090505" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357736892; bh=TtEI4z9ZioLrII+G42go5ldwIPc4SJ86FUWtTRZlptE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=hmsxwN2Qk5Un/MmM5hqobZNeP04r09YWCWFhUbd3tNWvJPW+jKNVYaYlz5A0lcDjF 5yJI0PgR3Zw1xK0Fui+0t/leTDUbtRv0Er82IdWv5x8ER7v/RYEW1zgG0iO3qjco6H QbBoMRBwDTTVA1XHa/6C9GyKrRrUEG5AhKZht+gE= X-AOL-SCOLL-SCORE: 1:2:522901760:93952408 X-AOL-SCOLL-URL_COUNT: 2 x-aol-sid: 3039ac1d33c350ed6bbb48fb X-AOL-IP: 64.79.50.205 Cc: Peter Mauritius Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:08:15 -0000 This is a multi-part message in MIME format. --------------070602000307040705090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec. In RFC 6750 'invalid_token' means that the authorization token for the request is invalid. In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid. I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings. I do agree that the error code used in this spec should be registered. Thanks, George On 1/8/13 5:07 PM, Peter Mauritius wrote: > Hi George, > > RFC6750 defines "invalid-token" for access tokens which is not the > case for "invalid-token" in the revocation specification. Here it is > applicable for refresh tokens as well. Therefore we should not simply > reference the "invalid-token" of RFC6750. > > As far as I understand both, the reviewed specification and RFC6750, > reference RFC6749. RFC6750 includes in section 6.1 > OAuth Extensions > Error Registration sections according to RFC6749 section 11.4. > for the error codes > defined throughout the document including "invalid-token". > > I am not very experienced in the formal process but shouldn't we add > such sections for the two error codes defined in the revocation > document? Especially for "invalid-token" we should define an error > registration section that defines the error code for our error usage > location and protocol extension to distinguish it from RFC6750 and to > avoid confusion. Doing this I hope there is no necessity to add a > reference to RFC6750 or to define a new error code. > > What do the more experienced reviewers think? > > Regards > Peter > > Am 07.01.13 17:25, schrieb George Fletcher: >> My concern with leaving both specs separated is that over time the >> semantics of the two error codes could diverge and that would be >> confusing for developers. If we don't want to create a dependency on >> RFC 6750, then I would recommend a change to the error code name so >> that there is no name collision or confusion. >> >> Thanks, >> George >> >> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >>> Hi George, >>> >>> thank you for pointing this out. Your proposal sounds reasonable >>> although the revocation spec does not build on top of RFC 6750. >>> >>> As refering to RFC 6750 would create a new dependency, one could >>> also argue it would be more robust to leave both specs separated. >>> >>> What do others think? >>> >>> regards, >>> Torsten. >>> Am 07.01.2013 17:12, schrieb George Fletcher: >>>> One quick comment... >>>> >>>> Section 2.0: Both RFC 6750 and this specification define the >>>> 'invalid_token' error code. >>>> >>>> Should this spec reference the error code from RFC 6750? >>>> >>>> Thanks, >>>> George >>>> >>>> >>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>>> Hi, >>>>> >>>>> the new revision is based on the WGLC feedback and incorporates >>>>> the following changes: >>>>> >>>>> - renamed "access grant" to "authorization" and reworded parts of >>>>> Abstract and Intro in order to better align with core spec wording >>>>> (feedback by Amanda) >>>>> - improved formatting of section 2.1. (feedback by Amanda) >>>>> - improved wording of last paragraph of section 6 (feedback by >>>>> Amanda) >>>>> - relaxed the expected behavior regarding revocation of related >>>>> tokens and the authorization itself in order to remove unintended >>>>> constraints on implementations (feedback by Mark) >>>>> - replaced description of error handling by pointer to respective >>>>> section of core spec (as proposed by Peter) >>>>> - adopted proposed text for implementation note (as proposed by >>>>> Hannes) >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> Am 07.01.2013 13:00, 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 >>>>>> Working Group of the IETF. >>>>>> >>>>>> Title : Token Revocation >>>>>> Author(s) : Torsten Lodderstedt >>>>>> Stefanie Dronia >>>>>> Marius Scurtescu >>>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>>> Pages : 8 >>>>>> Date : 2013-01-07 >>>>>> >>>>>> Abstract: >>>>>> This document proposes an additional endpoint for OAuth >>>>>> authorization >>>>>> servers, which allows clients to notify the authorization >>>>>> server that >>>>>> a previously obtained refresh or access token is no longer >>>>>> needed. >>>>>> This allows the authorization server to cleanup security >>>>>> credentials. >>>>>> A revocation request will invalidate the actual token and, if >>>>>> applicable, other tokens based on the same authorization. >>>>>> >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>> >> > > > -- > Peter Mauritius Chief Technical Director > Senior Consultant > Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.mauritius@fun.de > > fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe > Geschaeftsfuehrer Johannes Feulner > Amtsgericht Mannheim HRB 106906 > > http://www.fun.de > http://blogs.fun.de > http://www.twitter.com/fun_de > http://www.facebook.com/funcommunications --------------070602000307040705090505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Peter,

I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec.

In RFC 6750 'invalid_token' means that the authorization token for the request is invalid.

In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid.

I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings.

I do agree that the error code used in this spec should be registered.

Thanks,
George
On 1/8/13 5:07 PM, Peter Mauritius wrote:
Hi George,

RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.

As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in section 6.1  OAuth Extensions Error Registration sections according to RFC6749 section 11.4. for the error codes defined throughout the document including "invalid-token". 

I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.

What do the more experienced reviewers think?

Regards 
  Peter

Am 07.01.13 17:25, schrieb George Fletcher:
My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

    Title           : Token Revocation
    Author(s)       : Torsten Lodderstedt
                           Stefanie Dronia
                           Marius Scurtescu
    Filename        : draft-ietf-oauth-revocation-04.txt
    Pages           : 8
    Date            : 2013-01-07

Abstract:
    This document proposes an additional endpoint for OAuth authorization
    servers, which allows clients to notify the authorization server that
    a previously obtained refresh or access token is no longer needed.
    This allows the authorization server to cleanup security credentials.
    A revocation request will invalidate the actual token and, if
    applicable, other tokens based on the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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







-- 
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.de

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.fun.de
http://blogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunications

--------------070602000307040705090505-- From peter.mauritius@fun.de Wed Jan 9 05:35:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BD921F869A for ; Wed, 9 Jan 2013 05:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgvkVkDbl-ef for ; Wed, 9 Jan 2013 05:35:43 -0800 (PST) Received: from mailfwd.fun.de (fungate2.fun.de [IPv6:2a01:198:3c6:1:81:26:162:57]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEAD21F8607 for ; Wed, 9 Jan 2013 05:35:40 -0800 (PST) Received: from funstore.fun.de ([10.10.10.131] helo=mail.fun.de) by mailfwd.fun.de with esmtp (Exim 4.69 #1 (Debian)) id 1Tsvog-0006YB-Pc; Wed, 09 Jan 2013 14:35:38 +0100 Received: from fundannen.intern.fun.de [10.10.8.247] by mail.fun.de with esmtp (Exim Debian)) id 1TsvnN-00049z-00; Wed, 09 Jan 2013 14:34:17 +0100 Message-ID: <50ED71D9.5080703@fun.de> Date: Wed, 09 Jan 2013 14:34:17 +0100 From: Peter Mauritius Organization: fun communications GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: George Fletcher References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de> <50ED6BBB.40008@aol.com> In-Reply-To: <50ED6BBB.40008@aol.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090204060405070707070502" X-Scanner: exiscan *1TsvnN-00049z-00*Y57VROM/Lk.* (fun communications GmbH, Karlsruhe, Germany) Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:35:44 -0000 This is a cryptographically signed message in MIME format. --------------ms090204060405070707070502 Content-Type: multipart/alternative; boundary="------------020809050707060004050901" This is a multi-part message in MIME format. --------------020809050707060004050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ok, now I understand your intention. In oauth-revocation the token is just a = parameter not an authorization token as in RFC6750. RFC6749 uses =20 "invalid_request" for > includes an unsupported parameter value Perhaps we should drop the error-code and use invalid-request with a=20 error-description explaining the token parameter is not usable. Regards Peter On 09.01.2013 14:08, George Fletcher wrote: > Hi Peter, > > I do agree that the meanings of 'invalid_token' between the two specs=20 > (6750 and revocation) are different. After thinking about this for a=20 > while, I've determined, at least for myself, what the difference is=20 > between the 'invalid_token' error code in RFC 6750 and the revocation=20 > spec. > > In RFC 6750 'invalid_token' means that the authorization token for the = > request is invalid. > > In 'oauth-revocation', 'invalid_token' means that the parameter=20 > containing the token to be revoked is invalid. > > I am very concerned about using the same error string,=20 > 'invalid_token', to mean two different things. While the semantic=20 > difference is not great in this case, I think it sets a bad precedent=20 > for OAuth to have the same error string have two different semantic=20 > meanings. > > I do agree that the error code used in this spec should be registered. > > Thanks, > George > > On 1/8/13 5:07 PM, Peter Mauritius wrote: >> Hi George, >> >> RFC6750 defines "invalid-token" for access tokens which is not the=20 >> case for "invalid-token" in the revocation specification. Here it is=20 >> applicable for refresh tokens as well. Therefore we should not simply = >> reference the "invalid-token" of RFC6750. >> >> As far as I understand both, the reviewed specification and RFC6750,=20 >> reference RFC6749. RFC6750 includes in section 6.1=20 >> OAuth Extensions=20 >> Error Registration sections according to RFC6749 section 11.4.=20 >> for the error codes = >> defined throughout the document including "invalid-token". >> >> I am not very experienced in the formal process but shouldn't we add=20 >> such sections for the two error codes defined in the revocation=20 >> document? Especially for "invalid-token" we should define an error=20 >> registration section that defines the error code for our error usage=20 >> location and protocol extension to distinguish it from RFC6750 and to = >> avoid confusion. Doing this I hope there is no necessity to add a=20 >> reference to RFC6750 or to define a new error code. >> >> What do the more experienced reviewers think? >> >> Regards >> Peter >> >> Am 07.01.13 17:25, schrieb George Fletcher: >>> My concern with leaving both specs separated is that over time the=20 >>> semantics of the two error codes could diverge and that would be=20 >>> confusing for developers. If we don't want to create a dependency on = >>> RFC 6750, then I would recommend a change to the error code name so=20 >>> that there is no name collision or confusion. >>> >>> Thanks, >>> George >>> >>> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >>>> Hi George, >>>> >>>> thank you for pointing this out. Your proposal sounds reasonable=20 >>>> although the revocation spec does not build on top of RFC 6750. >>>> >>>> As refering to RFC 6750 would create a new dependency, one could=20 >>>> also argue it would be more robust to leave both specs separated. >>>> >>>> What do others think? >>>> >>>> regards, >>>> Torsten. >>>> Am 07.01.2013 17:12, schrieb George Fletcher: >>>>> One quick comment... >>>>> >>>>> Section 2.0: Both RFC 6750 and this specification define the=20 >>>>> 'invalid_token' error code. >>>>> >>>>> Should this spec reference the error code from RFC 6750? >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> >>>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>>>> Hi, >>>>>> >>>>>> the new revision is based on the WGLC feedback and incorporates=20 >>>>>> the following changes: >>>>>> >>>>>> - renamed "access grant" to "authorization" and reworded parts of = >>>>>> Abstract and Intro in order to better align with core spec=20 >>>>>> wording (feedback by Amanda) >>>>>> - improved formatting of section 2.1. (feedback by Amanda) >>>>>> - improved wording of last paragraph of section 6 (feedback by=20 >>>>>> Amanda) >>>>>> - relaxed the expected behavior regarding revocation of related=20 >>>>>> tokens and the authorization itself in order to remove unintended = >>>>>> constraints on implementations (feedback by Mark) >>>>>> - replaced description of error handling by pointer to respective = >>>>>> section of core spec (as proposed by Peter) >>>>>> - adopted proposed text for implementation note (as proposed by=20 >>>>>> Hannes) >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: >>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>> Internet-Drafts directories. >>>>>>> This draft is a work item of the Web Authorization Protocol=20 >>>>>>> Working Group of the IETF. >>>>>>> >>>>>>> Title : Token Revocation >>>>>>> Author(s) : Torsten Lodderstedt >>>>>>> Stefanie Dronia >>>>>>> Marius Scurtescu >>>>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>>>> Pages : 8 >>>>>>> Date : 2013-01-07 >>>>>>> >>>>>>> Abstract: >>>>>>> This document proposes an additional endpoint for OAuth=20 >>>>>>> authorization >>>>>>> servers, which allows clients to notify the authorization=20 >>>>>>> server that >>>>>>> a previously obtained refresh or access token is no longer=20 >>>>>>> needed. >>>>>>> This allows the authorization server to cleanup security=20 >>>>>>> credentials. >>>>>>> A revocation request will invalidate the actual token and, if= >>>>>>> applicable, other tokens based on the same authorization. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-04= >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> --=20 >> Peter Mauritius Chief Technical Director >> Senior Consultant >> Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.mauritius@fun.de >> >> fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe >> Geschaeftsfuehrer Johannes Feulner >> Amtsgericht Mannheim HRB 106906 >> >> http://www.fun.de >> http://blogs.fun.de >> http://www.twitter.com/fun_de >> http://www.facebook.com/funcommunications > --------------020809050707060004050901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok,

now I understand your intention. In oauth-revocation the token is just a parameter not an authorization token as in RFC6750. RFC6749 uses  "invalid_request" for 
includes an unsupported parameter value
Perhaps we should drop the error-code and use invalid-request with a error-description explaining the token parameter is not usable.

Regards
  Peter

On 09.01.2013 14:08, George Fletcher wrote:
Hi Peter,

I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec.

In RFC 6750 'invalid_token' means that the authorization token for the request is invalid.

In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid.

I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings.

I do agree that the error code used in this spec should be registered.

Thanks,
George
On 1/8/13 5:07 PM, Peter Mauritius wrote:
Hi George,

RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.
=
As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in secti= on 6.1  OAuth Extensions Error Registration sections according to RFC6= 749 section 11.4. for the error codes defined throughout the document including "invalid-token". 

I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.

What do the more experienced reviewers think?

Regards 
  Peter

Am 07.01.13 17:25, schrieb George Fletcher:
My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?<= br>
Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter) - adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, schrieb internet-draft= s@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorizati= on Protocol Working Group of the IETF.

    Title    &n= bsp;      : Token Revocation
    Author(s)   &nbs= p;   : Torsten Lodderstedt
         &= nbsp;           &n= bsp;     Stefanie Dronia
         &= nbsp;           &n= bsp;     Marius Scurtescu
    Filename    = ;    : draft-ietf-oauth-revocation-04.txt
    Pages    &n= bsp;      : 8
    Date    &nb= sp;       : 2013-01-07

Abstract:
    This document proposes an additional= endpoint for OAuth authorization
    servers, which allows clients to not= ify the authorization server that
    a previously obtained refresh or acc= ess token is no longer needed.
    This allows the authorization server= to cleanup security credentials.
    A revocation request will invalidate= the actual token and, if
    applicable, other tokens based on th= e same authorization.



The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revoca= tion

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth= -revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ft= p.ietf.org/internet-drafts/

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

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







--=20
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.de

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.fun.de
http://blogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunic=
ations

--------------020809050707060004050901-- --------------ms090204060405070707070502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFHjCCBAagAwIBAgIRAMDelVw+LRVrknnNfAzvvwUwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTIw NDE4MDAwMDAwWhcNMTMwNDE4MjM1OTU5WjAfMR0wGwYJKoZIhvcNAQkBFg5wZXRlckBwZXRl ci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKytWhRD21yXbUdIxNODMNuD hex7ykIdXI4wn8lB7a1X4RCRUWFYrk8TOyPzuTWLjNIiWn4Vsfp3AjWpBNg+k/G4uMh1/CvZ uayFtHuUrQapyEfK8awpAlPK6zyHAp0qDF9UaVAC9i5u478EjIy5K32c/89zrznyLcDrlapk XOyr8KnQWfXcbLw7TgkO1TgYVCUXy3h10X5IbdCYYKKDFfD52+ZB0pGuYPclsVu139snkv9N XMSiyL7teOeP2b0WOVCvqpWzWRXjWHy1Kxu68bc1BvfTwI4CxdofS307xxZW3tdFjGItjPay h9Qq/0Um/LOInloJQU9kI61ykBl+DjsCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTxoptwhJcBUUr8CHVnjS5/Z0HPMjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBkG A1UdEQQSMBCBDnBldGVyQHBldGVyLmRlMA0GCSqGSIb3DQEBBQUAA4IBAQBQi+rUEFOkOvHP 8IvONRNqdaokWM9XPNpTOB1xz7bnQTvrx6niomT3il3Al9/LFSa02z44W0uDQ8dXX/n774oy Ik9pSBpVUNo4p9p+Gad7F92OTmqSVu5xvKoSG7Qht3wHukWgOAtCcvyfchRtPnZfOFWpdX0H eTCcw8jR+PoEyI1RuqIoMD9nHSiMxRURTuPv67VlLdRxCG4SuJwHtynbDOaKoqZmDEkWr0RY LZIVIcIiSnVZGoxPpDOf1U6ELli/QdlOSsgkpqDHlX1or7DiBCxRYHCYckC4g2Hz95epTTNg UjKI4WTypUnvFEGaa/rVE57mEt25HjHosSvmFoEjMYIEHDCCBBgCAQEwgakwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDA3pVcPi0Va5J5zXwM778FMAkG BSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDEwOTEzMzQxN1owIwYJKoZIhvcNAQkEMRYEFLrvb409XZDnvQM2pfSaMi24HNonMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIRAMDelVw+LRVrknnNfAzvvwUwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAwN6VXD4tFWuSec18DO+/ BTANBgkqhkiG9w0BAQEFAASCAQCFys5BGZzAeTB2cg+G4QTt4Nc5dTaWnElOGZr7S3nj12rv 7hYa+Jszdjk3gjWEF1LwG1F8Hod3j7QQ7uuDZqQvZmPbUoNrmrTkKJ416w/iUEp+/5o4+owJ 6NKr8RJCn3o6kCb5vm8NKf1WT8QMggo2K3G3qpp3wcj317MZkpeZKMKn4RbDoEPydNu5K+ks 8ZsZEwWgnROqdgY0MyjNIWNI+CdXKdPKaY0eBFsqg7j2PCYf8DA0tH8qshrqd3djzRbR4Hwh TOuu1XOqSMCKCvnclLB2ffUIjq5uQs0ZjgtMl+tR/hVttomkzxXJpot8gRXnUkPXYErpL3Rc Ch7vvZgyAAAAAAAA --------------ms090204060405070707070502-- From gffletch@aol.com Wed Jan 9 07:41:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3DF21F8481 for ; Wed, 9 Jan 2013 07:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5tMVGLLm6jz for ; Wed, 9 Jan 2013 07:40:55 -0800 (PST) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7235F21F8476 for ; Wed, 9 Jan 2013 07:40:55 -0800 (PST) Received: from mtaout-ma03.r1000.mx.aol.com (mtaout-ma03.r1000.mx.aol.com [172.29.41.3]) by imr-ma03.mx.aol.com (Outbound Mail Relay) with ESMTP id CA8941C000058; Wed, 9 Jan 2013 10:40:54 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AB85DE0000AB; Wed, 9 Jan 2013 10:40:53 -0500 (EST) Message-ID: <50ED8F85.5000604@aol.com> Date: Wed, 09 Jan 2013 10:40:53 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Mauritius References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de> <50ED6BBB.40008@aol.com> <50ED71D9.5080703@fun.de> In-Reply-To: <50ED71D9.5080703@fun.de> Content-Type: multipart/alternative; boundary="------------020706040806060608070901" x-aol-global-disposition: G X-AOL-VSS-INFO: 5400.1158/87163 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357746054; bh=EqYvbNb4tFREdzg2OnjXRfQinuSgG6ToLRfghm40NB8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=x6+9K6yFBVjIFSsi/S3jAsmMfWKioFtrKdeKvK+yvHx78Rp6YcJUrx+AlxfZ7t9wB /ghawEmIs9iVMokMnkhrCszu+wlOOl8trFKVHajVG0XBgtrif1gdPHyBuzI2PP36xY v3gpVTQYzvdpgUMJRTzCh4jhp8IPUR4TtOOI6oew= X-AOL-SCOLL-SCORE: 1:2:525117280:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d290350ed8f85469b X-AOL-IP: 10.181.186.254 Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:41:00 -0000 This is a multi-part message in MIME format. --------------020706040806060608070901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While this can work, it seems like it's mixing semantics a little as well. 'invalid_request' normally mean that the request is malformed in some way. Even 'unsupported parameter value' is really addressing a malformed request (e.g. a parameter only allows values of 'true' and 'false' and the invocation uses the value 'maybe'). What about registering an error code of 'invalid_parameter_value'. Then the description could explain which parameter value is invalid and possibly why. We might even be able to shorten this to 'invalid_parameter' as 'invalid_request' handles the case of an unsupported/invalid parameter name. I did a quick check of the OpenID Connect specs and they also don't define an 'invalid_parameter' error code. Thanks, George On 1/9/13 8:34 AM, Peter Mauritius wrote: > Ok, > > now I understand your intention. In oauth-revocation the token is just > a parameter not an authorization token as in RFC6750. RFC6749 uses > "invalid_request" for >> includes an unsupported parameter value > Perhaps we should drop the error-code and use invalid-request with a > error-description explaining the token parameter is not usable. > > Regards > Peter > > On 09.01.2013 14:08, George Fletcher wrote: >> Hi Peter, >> >> I do agree that the meanings of 'invalid_token' between the two specs >> (6750 and revocation) are different. After thinking about this for a >> while, I've determined, at least for myself, what the difference is >> between the 'invalid_token' error code in RFC 6750 and the revocation >> spec. >> >> In RFC 6750 'invalid_token' means that the authorization token for >> the request is invalid. >> >> In 'oauth-revocation', 'invalid_token' means that the parameter >> containing the token to be revoked is invalid. >> >> I am very concerned about using the same error string, >> 'invalid_token', to mean two different things. While the semantic >> difference is not great in this case, I think it sets a bad precedent >> for OAuth to have the same error string have two different semantic >> meanings. >> >> I do agree that the error code used in this spec should be registered. >> >> Thanks, >> George >> >> On 1/8/13 5:07 PM, Peter Mauritius wrote: >>> Hi George, >>> >>> RFC6750 defines "invalid-token" for access tokens which is not the >>> case for "invalid-token" in the revocation specification. Here it is >>> applicable for refresh tokens as well. Therefore we should not >>> simply reference the "invalid-token" of RFC6750. >>> >>> As far as I understand both, the reviewed specification and RFC6750, >>> reference RFC6749. RFC6750 includes in section 6.1 >>> OAuth Extensions >>> Error Registration sections according to RFC6749 section 11.4. >>> for the error >>> codes defined throughout the document including "invalid-token". >>> >>> I am not very experienced in the formal process but shouldn't we add >>> such sections for the two error codes defined in the revocation >>> document? Especially for "invalid-token" we should define an error >>> registration section that defines the error code for our error usage >>> location and protocol extension to distinguish it from RFC6750 and >>> to avoid confusion. Doing this I hope there is no necessity to add a >>> reference to RFC6750 or to define a new error code. >>> >>> What do the more experienced reviewers think? >>> >>> Regards >>> Peter >>> >>> Am 07.01.13 17:25, schrieb George Fletcher: >>>> My concern with leaving both specs separated is that over time the >>>> semantics of the two error codes could diverge and that would be >>>> confusing for developers. If we don't want to create a dependency >>>> on RFC 6750, then I would recommend a change to the error code name >>>> so that there is no name collision or confusion. >>>> >>>> Thanks, >>>> George >>>> >>>> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >>>>> Hi George, >>>>> >>>>> thank you for pointing this out. Your proposal sounds reasonable >>>>> although the revocation spec does not build on top of RFC 6750. >>>>> >>>>> As refering to RFC 6750 would create a new dependency, one could >>>>> also argue it would be more robust to leave both specs separated. >>>>> >>>>> What do others think? >>>>> >>>>> regards, >>>>> Torsten. >>>>> Am 07.01.2013 17:12, schrieb George Fletcher: >>>>>> One quick comment... >>>>>> >>>>>> Section 2.0: Both RFC 6750 and this specification define the >>>>>> 'invalid_token' error code. >>>>>> >>>>>> Should this spec reference the error code from RFC 6750? >>>>>> >>>>>> Thanks, >>>>>> George >>>>>> >>>>>> >>>>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the new revision is based on the WGLC feedback and incorporates >>>>>>> the following changes: >>>>>>> >>>>>>> - renamed "access grant" to "authorization" and reworded parts >>>>>>> of Abstract and Intro in order to better align with core spec >>>>>>> wording (feedback by Amanda) >>>>>>> - improved formatting of section 2.1. (feedback by Amanda) >>>>>>> - improved wording of last paragraph of section 6 (feedback by >>>>>>> Amanda) >>>>>>> - relaxed the expected behavior regarding revocation of related >>>>>>> tokens and the authorization itself in order to remove >>>>>>> unintended constraints on implementations (feedback by Mark) >>>>>>> - replaced description of error handling by pointer to >>>>>>> respective section of core spec (as proposed by Peter) >>>>>>> - adopted proposed text for implementation note (as proposed by >>>>>>> Hannes) >>>>>>> >>>>>>> regards, >>>>>>> Torsten. >>>>>>> >>>>>>> Am 07.01.2013 13:00, 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 >>>>>>>> Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Token Revocation >>>>>>>> Author(s) : Torsten Lodderstedt >>>>>>>> Stefanie Dronia >>>>>>>> Marius Scurtescu >>>>>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>>>>> Pages : 8 >>>>>>>> Date : 2013-01-07 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This document proposes an additional endpoint for OAuth >>>>>>>> authorization >>>>>>>> servers, which allows clients to notify the authorization >>>>>>>> server that >>>>>>>> a previously obtained refresh or access token is no longer >>>>>>>> needed. >>>>>>>> This allows the authorization server to cleanup security >>>>>>>> credentials. >>>>>>>> A revocation request will invalidate the actual token and, if >>>>>>>> applicable, other tokens based on the same authorization. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Peter Mauritius Chief Technical Director >>> Senior Consultant >>> Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.mauritius@fun.de >>> >>> fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe >>> Geschaeftsfuehrer Johannes Feulner >>> Amtsgericht Mannheim HRB 106906 >>> >>> http://www.fun.de >>> http://blogs.fun.de >>> http://www.twitter.com/fun_de >>> http://www.facebook.com/funcommunications >> -- George Fletcher --------------020706040806060608070901 Content-Type: multipart/related; boundary="------------040906000708040202050302" --------------040906000708040202050302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit While this can work, it seems like it's mixing semantics a little as well. 'invalid_request' normally mean that the request is malformed in some way. Even 'unsupported parameter value' is really addressing a malformed request (e.g. a parameter only allows values of 'true' and 'false' and the invocation uses the value 'maybe').

What about registering an error code of 'invalid_parameter_value'. Then the description could explain which parameter value is invalid and possibly why. We might even be able to shorten this to 'invalid_parameter' as 'invalid_request' handles the case of an unsupported/invalid parameter name.

I did a quick check of the OpenID Connect specs and they also don't define an 'invalid_parameter' error code.

Thanks,
George
On 1/9/13 8:34 AM, Peter Mauritius wrote:
Ok,

now I understand your intention. In oauth-revocation the token is just a parameter not an authorization token as in RFC6750. RFC6749 uses  "invalid_request" for 
includes an unsupported parameter value
Perhaps we should drop the error-code and use invalid-request with a error-description explaining the token parameter is not usable.

Regards
  Peter

On 09.01.2013 14:08, George Fletcher wrote:
Hi Peter,

I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec.

In RFC 6750 'invalid_token' means that the authorization token for the request is invalid.

In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid.

I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings.

I do agree that the error code used in this spec should be registered.

Thanks,
George
On 1/8/13 5:07 PM, Peter Mauritius wrote:
Hi George,

RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.

As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in section 6.1  OAuth Extensions Error Registration sections according to RFC6749 section 11.4. for the error codes defined throughout the document including "invalid-token". 

I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.

What do the more experienced reviewers think?

Regards 
  Peter

Am 07.01.13 17:25, schrieb George Fletcher:
My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, 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 Working Group of the IETF.

    Title           : Token Revocation
    Author(s)       : Torsten Lodderstedt
                           Stefanie Dronia
                           Marius Scurtescu
    Filename        : draft-ietf-oauth-revocation-04.txt
    Pages           : 8
    Date            : 2013-01-07

Abstract:
    This document proposes an additional endpoint for OAuth authorization
    servers, which allows clients to notify the authorization server that
    a previously obtained refresh or access token is no longer needed.
    This allows the authorization server to cleanup security credentials.
    A revocation request will invalidate the actual token and, if
    applicable, other tokens based on the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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







-- 
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.de

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.fun.de
http://blogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunications


--
George Fletcher
--------------040906000708040202050302 Content-Type: image/png; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAABHNCSVQICAgIfAhkiAAAAAlw SFlzAAALEgAACxIB0t1+/AAAABx0RVh0U29mdHdhcmUAQWRvYmUgRmlyZXdvcmtzIENTNAay 06AAAAAVdEVYdENyZWF0aW9uIFRpbWUAMy8yOC8xMmDmEzUAAAANSURBVAiZY/j//z8DAAj8 Av6Fzas0AAAAAElFTkSuQmCC --------------040906000708040202050302-- --------------020706040806060608070901-- From adrian@c4media.com Mon Jan 7 16:24:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B484A21F87D6 for ; Mon, 7 Jan 2013 16:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNpodysuh5wM for ; Mon, 7 Jan 2013 16:24:55 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8214421F86F7 for ; Mon, 7 Jan 2013 16:24:55 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id k14so18982583oag.14 for ; Mon, 07 Jan 2013 16:24:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jI5E9SKxMnpyg+iEwKteYEFoNkMSBAcf3SoekKbsRUI=; b=gsmfKB9tXLtwjBQvsqf+Oea6mBOVPQIUKSYSIgfyxl4arUHZh772/gYpoQXtR5CkUa DzT7RcNnYkfFeYuVVCc8IMWytPnsZumZaLYRvgtHHkLMEFYXbAZ7brb1pT7KCD/IPE2Q eL/PEGTdzLk4rPGSX5H8y2yCItFeUp3YV8zoJ9eB/+h9TqaZLy2sBpoTnQjb3duvvrDq X1/CQOcsXFAO/LxQodIJri6mSaDBpMons9VPLQkjiZT0z/qaaqmj4tet+FmvhTL2XyZL kwPspp/MDhiaA/Thfu3GWGV5mxlamKfQxm60KkmHzy9AUirWNzIoUMriuqw2yGsm9+WF 9JAQ== MIME-Version: 1.0 Received: by 10.182.42.97 with SMTP id n1mr43758489obl.91.1357604694523; Mon, 07 Jan 2013 16:24:54 -0800 (PST) Received: by 10.60.40.232 with HTTP; Mon, 7 Jan 2013 16:24:54 -0800 (PST) In-Reply-To: <50E5ED4B.5070000@aol.com> References: <50E5ED4B.5070000@aol.com> Date: Tue, 8 Jan 2013 02:24:54 +0200 Message-ID: From: Adrian Servenschi To: George Fletcher Content-Type: multipart/alternative; boundary=14dae93998eb8fff0a04d2bbf999 X-Gm-Message-State: ALoCoQlnxR1vSpg+BHqw9o+/uqpVlgWGqHX3IRRlMRdd7SNfBHhLnPZcBdof7APR0oWVdN+idIf9 X-Mailman-Approved-At: Wed, 09 Jan 2013 09:04:08 -0800 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:24:56 -0000 --14dae93998eb8fff0a04d2bbf999 Content-Type: text/plain; charset=ISO-8859-1 Thank you George, John, William and Justin, Your responses are knowledgeable and extremely helpful. You are a great team. Thanks again. Adrian Servenschi. On Thu, Jan 3, 2013 at 10:42 PM, George Fletcher wrote: > There is no standardization of the logout flow in OAuth or OpenID (there > is in OpenID Connect as John mentioned) so your option 3... > > 3) The third option : displaying some informative text when the user sings > out from the application informing him that he/she signed out from our > application only, and not from Google/other identity provider, > seems to be the best option. > > is the best option right now. > > The problem is that as the application you don't know if the user signed > in with Google just to access your app, or if they already had gmail open. > In the first case it would be nice to sign the user out of Google since > they authenticated solely for the purpose of accessing your app. In the > second case you DON'T want to sign them out as that will kill their gmail > session which is probably not what the user (or your app) wants. > > So, informing the user that they are still logged in at Google is a good > choice. You might want to give the user the option to forgo the warning in > the future once they understand what is happening. > > Thanks, > George > > > On 1/2/13 4:25 PM, Adrian Servenschi wrote: > > Hi guys, > > I am working on implementing login/registration with common identity > providers into our application. > I am using Scribe for java library which implements the *OAuth* protocol. > > I've encountered what I consider a small security issue that I don't > know how to solve. > If I sign in into our application via let's say Google and then I sign > out, the Google session cookie remains active in the browser. > I can open Gmail afterwards in my browser and my inbox is displayed > without the need of authentication. > > Imagine that a user signs in to our application in an internet cafe, > then signs out and leaves the facility. > A different client comes at the same desk, opens Gmail and he/she sees the > inbox of the first person. > This can be a security hazard which I don't know how to solve. > I see only 3 options: > > 1) I can leave it like this --> hazardous > 2) If I use Google API to sign out the user from the Google when > performing Sign out from our application then the user will be signed out > from every Google application he has opened in his browser. > In addition I heard that the documentation for performing Sign Out via > various identity providers APIs is not quite clear. But this still needs to > be investigated. > > 3) The third option : displaying some informative text when the user > sings out from the application informing him that he/she signed out from > our application only, and not from Google/other identity provider, > seems to be the best option. > > I will highly appreciate if you can advise me regarding this issue. > Thank you very much in advance! > > Adrian Servenschi. > > P.S. This is what I found on Facebook Platform Policies page > http://developers.facebook.com/policy/ > Your website must offer an explicit "Log Out" option that also logs the > user out of Facebook. > > So indeed a form of 3) option will be the best choice? > Looking forward to your advices and suggestions. > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --14dae93998eb8fff0a04d2bbf999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you George, John, William and Justin,

Your responses are knowl= edgeable and extremely helpful.

You are a great team.
Thanks agai= n.
Adrian Servenschi.

On Thu, Jan 3, 2= 013 at 10:42 PM, George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
There is no standardization of the logout flow in OAuth or OpenID (there is in OpenID Connect as John mentioned) so your option 3...

3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider,
seems to be the best option.
is the best option right now.

The problem is that as the application you don't know if the user signed in with Google just to access your app, or if they already had gmail open. In the first case it would be nice to sign the user out of Google since they authenticated solely for the purpose of accessing your app. In the second case you DON'T want to sign them out as that will kill their gmail session which is probably not what the user (or your app) wants.

So, informing the user that they are still logged in at Google is a good choice. You might want to give the user the option to forgo the warning in the future once they understand what is happening.

Thanks,
George


On 1/2/13 4:25 PM, Adrian Servenschi wrote:
Hi guys,

I am working on implementing login/registration with common identity providers into our application.
I am using Scribe for java library which implements the OAuth= protocol.

I've encountered what I consider a small security issue that I don't know how to solve.
If I sign in into our application via let's say Google and then I sign out, the Google session cookie remains active in the browser.
I can open Gmail afterwards in my browser and my inbox is displayed without the need of authentication.

Imagine that a user signs in to our application in an internet cafe, then signs out and leaves the facility.
A different client comes at the same desk, opens Gmail and he/she sees the inbox of the first person.
This can be a security hazard which I don't know how to solve.=A0
I see only 3 options:

1) I can leave it like this --> hazardous
2) If I use Google API to sign out the user from the Google when performing Sign out from our application then the user will be signed out from every Google application he has opened in his browser.
In addition I heard that the documentation for performing Sign Out via various identity providers APIs is not quite clear. But this still needs to be investigated.

3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider,
seems to be the best option.

I will highly appreciate if you can advise me regarding this issue.
Thank you very much in advance!

Adrian Servenschi. =A0 =A0

P.S. This is what I found on Facebook Platform Policies page http://developers.facebook.com/policy/=A0
Your website must offer an explicit "Log Out" option that al= so logs the user out of Facebook.

So indeed a form of 3) option will be the best choice?
Looking forward to your advices and suggestions. 

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


--14dae93998eb8fff0a04d2bbf999-- From zpbrent@gmail.com Tue Jan 8 22:39:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36C021F87AB for ; Tue, 8 Jan 2013 22:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu9YSAdijOP4 for ; Tue, 8 Jan 2013 22:39:38 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 690D121F843C for ; Tue, 8 Jan 2013 22:39:38 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id d13so429329qak.18 for ; Tue, 08 Jan 2013 22:39:37 -0800 (PST) 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:content-type; bh=M/iFyvqfd5i4pJGUwEN1sax3ilAFutW8N04J0N0BsfQ=; b=OL+a8CBLVElWglYu0eD3xJ79YXA9wD/hr315XIedR8epuW18GdORmE3w3FfPcchB78 6fcOziGwuP0/KWqQIbx6MHa0XR0bzx9nnxfAoiIxTJgU3u7xJJMMeCUmodj7Evh47/D6 u4Epi3IoIqs1i1ufAACkgMKbf1oWuAczInUhvQjvr2aIYfCgc9277Pah5yn9Ya/jHjeo 12nIrTvI9MGviHpf4yAV2furxgztNsm6ExFIb0ESCILUm8ANFQcwsvy7c+cX7Co0ojx1 HjxdQ/oTCpE/joF9baXw5U5TEeQEm4cujoKBtJJ3J0dEOhFIE2UT8qIJOq1ojla6cRad ZdUA== Received: by 10.224.71.20 with SMTP id f20mr45469041qaj.71.1357713577849; Tue, 08 Jan 2013 22:39:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.62.34 with HTTP; Tue, 8 Jan 2013 22:39:17 -0800 (PST) In-Reply-To: References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> From: Peng Zhou Date: Wed, 9 Jan 2013 14:39:17 +0800 Message-ID: To: Prabath Siriwardena Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 09 Jan 2013 09:04:07 -0800 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:44:08 -0000 Dear Prabath: Thank you very much for your responses :-) However, I am still not quite sure why the authorization code must be sent to the client through the RO's user-agent? Best Regards Brent 2013/1/9 Prabath Siriwardena : > Prabath From zpbrent@gmail.com Tue Jan 8 22:42:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2121F86AE; Tue, 8 Jan 2013 22:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JBGm9gpoLum; Tue, 8 Jan 2013 22:42:30 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9221F86AC; Tue, 8 Jan 2013 22:42:30 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id hg5so419322qab.8 for ; Tue, 08 Jan 2013 22:42:30 -0800 (PST) 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:content-type:content-transfer-encoding; bh=0/kdDai4zm9HlNv4Qe1E/BgirdSjvaQ3D4i9OR711/c=; b=eH4bha4DQI5w1vXq+a8Y5rtkxcphket0ga+7P7EZdpIwvRIwavY/39LY0xoEN4zkLn jeEBAEjN4SFNQ4M+YCPP5zbvDgG07rB+HVxXV4hFkqrIpo7XxfLKP1LzVtBsGowebIbm CoY72VAAOQUxcEn1q2D9eSf9v5qIHwCUIupuNbTFbiHiOV+uDSxnFxzKAVBO0cCtoWK/ MdbQu3wLZ8yjWQKTCdXkgDa2098murY5HpiHNXEvfzUgZIsKGcI1S4E+XfVIsFqmkmnv 08sXbqr/BzlaRWoThW/S90npSCEarxvJovPKRTcK3StM9ZEJLFtabTzO/4IBQeKwMsNx IPNw== Received: by 10.49.105.100 with SMTP id gl4mr58549222qeb.23.1357713749946; Tue, 08 Jan 2013 22:42:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.62.34 with HTTP; Tue, 8 Jan 2013 22:42:09 -0800 (PST) In-Reply-To: References: From: Peng Zhou Date: Wed, 9 Jan 2013 14:42:09 +0800 Message-ID: To: zhou.sujing@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Jan 2013 09:04:08 -0800 Cc: oauth-bounces@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1?= =?gb2312?b?dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 06:44:18 -0000 Dear SuJing: If it is the only reason, why we send the authorization code to the client directly and send another notification without the authorization code to the RO. This way can mitigate the chance that the authorization code is exposed to the RO's user-agent, hence protecting the authorization code from leaking to possible attackers in a higher security levle. Best Regards Brent 2013/1/9 : > > Then why not let auth code be sent directly from AS to Client? > > Just want to inform RO that an auth code has been dilivered to Client? > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-09 14:27:50: > >> Hi Brent, >> >> Few points, why this doesn't create any security implications.. >> >> 1. Authorization server maintains a binding to the Client, who the >> token was issued to. To exchange this to an Access token client >> should authenticate him self. >> 2. Code can only be exchanged once for an acces token. >> >> Thanks & regards, >> -Prabath > >> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc > > wrote: >> Dear All: >> >> I have a question in the section 1.3.1. Authorization Code in rfc6749 >> The OAuth 2.0 Authorization Framework. >> >> It tells "which in turn directs the resource owner back to the client >> with the authorization code." >> >> Who can let me know the reason why is the authorization code sent to >> client through a redirection in resource owner's agent? Any security >> implications? >> >> Is it possible to let the authorization server send the authorization >> code to the client directly (not through resource owner's user-agent)? >> >> Best Regards >> Brent >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com_______________________________________________ > >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Jan 9 09:38:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8D21F84E4 for ; Wed, 9 Jan 2013 09:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62BPXqG9OUji for ; Wed, 9 Jan 2013 09:38:17 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 467BC21F8610 for ; Wed, 9 Jan 2013 09:38:10 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C24471F2763; Wed, 9 Jan 2013 12:38:09 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE8451F04A5; Wed, 9 Jan 2013 12:38:09 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 9 Jan 2013 12:38:09 -0500 Message-ID: <50EDAAFE.3050300@mitre.org> Date: Wed, 9 Jan 2013 12:38:06 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peng Zhou References: In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1dGggMi4w?= =?gb2312?b?IEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 17:38:22 -0000 Brent, If you're sending the code in the back channel directly to the Client, as I believe you're doing from your text below, I would like you to realize some things: 1) This is not OAuth, and is in fact antithetical to the OAuth way of solving the connection problem. 2) You are actually lowering your overall security because the access code is no longer bound to any particular browser session with either the client or the AS. 3) If you're sending it directly, there is no longer any point of using the code, since the Client is just going to turn around and send it to the AS again to get a token. Why not just send the token? But again, this is still not OAuth. Think about it this way: There are three connections in the common OAuth Authorization Code scenario, which is why it's known as a three-legged OAuth flow in many circles. Each of these legs has unique properties, is protected by different things, and is exposed to different pieces of knowledge at different times. 1) Client <-> User Agent: protected by a local session of the Client's choosing. For Web based clients this is often standard HTTP session cookies or similar, potentially backed by a login of some type by the user to the Client as well. This session is never exposed to the Authorization Server. 2) Authorization Server <-> User Agent: protected by a local session of the Authorization Server's choosing, normally through some kind of Primary Credential (login) that the user has a the AS. Importantly, these credentials are never exposed to the Client. 3) Client <-> Authorization Server: protected by the client credentials, which are, importantly, not exposed to the user or user agent. By sending the code as part of the redirect, the Client is able to prove that the User Agent actually went to the Authorization Server (2) and got something. The Authorization Code is then sent through the bottom leg (3) of the channel to verify that it really did come from the Authorization Server in the context of the user that was just there in (1). In other words, this mechanism that you seem to be avoiding is exactly what makes OAuth secure. If you instead send the code through (3), then the Client as no way at all of knowing that the user in (1) ever went to the authorization server via (2). All the Client knows is that they sent the user someplace and that a magic code showed up. It is very, very, very dangerous and a very, very bad idea to assume that a code coming in the back channel (3) has anything at all to do with any particular session (1). This approach does *not* mitigate any real security threats, and in fact introduces a great number of others, as described here. There are much better ways to protect the Authorization Code, and most of the best practices are enumerated in the security considerations document. Some of the most common are: 1) Make Authorization Codes one-time-use (even if you try and fail, it's thrown away) 2) Make Authorization Codes time out after a very short period (minutes or seconds) I hope this helps. -- Justin On 01/09/2013 01:42 AM, Peng Zhou wrote: > Dear SuJing: > > If it is the only reason, why we send the authorization code to the > client directly and send another notification without the > authorization code to the RO. This way can mitigate the chance that > the authorization code is exposed to the RO's user-agent, hence > protecting the authorization code from leaking to possible attackers > in a higher security levle. > > Best Regards > Brent > > 2013/1/9 : >> Then why not let auth code be sent directly from AS to Client? >> >> Just want to inform RO that an auth code has been dilivered to Client? >> >> oauth-bounces@ietf.org 2013-01-09 14:27:50: >> >>> Hi Brent, >>> >>> Few points, why this doesn't create any security implications.. >>> >>> 1. Authorization server maintains a binding to the Client, who the >>> token was issued to. To exchange this to an Access token client >>> should authenticate him self. >>> 2. Code can only be exchanged once for an acces token. >>> >>> Thanks & regards, >>> -Prabath >>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc >>> wrote: >>> Dear All: >>> >>> I have a question in the section 1.3.1. Authorization Code in rfc6749 >>> The OAuth 2.0 Authorization Framework. >>> >>> It tells "which in turn directs the resource owner back to the client >>> with the authorization code." >>> >>> Who can let me know the reason why is the authorization code sent to >>> client through a redirection in resource owner's agent? Any security >>> implications? >>> >>> Is it possible to let the authorization server send the authorization >>> code to the client directly (not through resource owner's user-agent)? >>> >>> Best Regards >>> Brent >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com_______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Jan 9 11:10:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9D21F871D for ; Wed, 9 Jan 2013 11:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb34ByG2VfWI for ; Wed, 9 Jan 2013 11:10:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1719A21F85BC for ; Wed, 9 Jan 2013 11:10:42 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 43E0A1F287A for ; Wed, 9 Jan 2013 14:10:41 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0807A1F28B7 for ; Wed, 9 Jan 2013 14:10:40 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 9 Jan 2013 14:10:40 -0500 Message-ID: <50EDC0AE.6050005@mitre.org> Date: Wed, 9 Jan 2013 14:10:38 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> In-Reply-To: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010205040108000600000701" X-Originating-IP: [129.83.31.58] Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:10:43 -0000 --------------010205040108000600000701 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA. I would like this document to become a working group item. -- Justin -------- Original Message -------- Subject: New Version Notification for draft-richer-oauth-introspection-01.txt Date: Tue, 8 Jan 2013 14:48:47 -0800 From: To: A new version of I-D, draft-richer-oauth-introspection-01.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-introspection Revision: 01 Title: OAuth Token Introspection Creation date: 2013-01-08 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 Abstract: This specification defines a method for a client or protected resource to query an OAuth authorization server to determine meta- information about an OAuth token. The IETF Secretariat --------------010205040108000600000701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


--------------010205040108000600000701-- From torsten@lodderstedt.net Wed Jan 9 11:23:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B8621F87CB for ; Wed, 9 Jan 2013 11:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdWvFXB7Ng1s for ; Wed, 9 Jan 2013 11:23:02 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF821F870A for ; Wed, 9 Jan 2013 11:23:00 -0800 (PST) Received: from [79.253.23.39] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tt1Eo-0003JN-87; Wed, 09 Jan 2013 20:22:58 +0100 References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50EDC0AE.6050005@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-F96B19A1-446E-4B08-947B-903BE933CCA8 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Wed, 9 Jan 2013 20:22:57 +0100 To: Justin Richer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:23:04 -0000 --Apple-Mail-F96B19A1-446E-4B08-947B-903BE933CCA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Justin, why is there a need for both scope and audience? I would assume the scope of= the authorization request is typically turned into an audience of an access= token. Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead o= f inventing another set of JSON elements? regards, Torsten. Am 09.01.2013 um 20:10 schrieb Justin Richer : > Updated the introspection draft with feedback from the UMA WG, who have in= corporated it into their latest revision of UMA.=20 >=20 > I would like this document to become a working group item. >=20 > -- Justin >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-richer-oauth-introspecti= on-01.txt > Date: Tue, 8 Jan 2013 14:48:47 -0800 > From: > To: >=20 > A new version of I-D, draft-richer-oauth-introspection-01.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. >=20 > Filename: draft-richer-oauth-introspection > Revision: 01 > Title: OAuth Token Introspection > Creation date: 2013-01-08 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-in= trospection-01.txt > Status: http://datatracker.ietf.org/doc/draft-richer-oauth-intros= pection > Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspecti= on-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-int= rospection-01 >=20 > Abstract: > This specification defines a method for a client or protected > resource to query an OAuth authorization server to determine meta- > information about an OAuth token. >=20 >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-F96B19A1-446E-4B08-947B-903BE933CCA8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Justin,

why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

regards,
Torsten.

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-F96B19A1-446E-4B08-947B-903BE933CCA8-- From jricher@mitre.org Wed Jan 9 11:35:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEF21F8581 for ; Wed, 9 Jan 2013 11:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csExr5Z6-ppm for ; Wed, 9 Jan 2013 11:35:06 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3566C21F8534 for ; Wed, 9 Jan 2013 11:35:06 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 897D01F28CB; Wed, 9 Jan 2013 14:35:05 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6AC061F02FC; Wed, 9 Jan 2013 14:35:05 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 9 Jan 2013 14:35:05 -0500 Message-ID: <50EDC666.6040808@mitre.org> Date: Wed, 9 Jan 2013 14:35:02 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000403030505080305090003" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:35:07 -0000 --------------000403030505080305090003 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Thanks for the review, answers inline: > why is there a need for both scope and audience? I would assume the > scope of the authorization request is typically turned into an > audience of an access token. You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field. > > Generally, wouldn't it be simpler (spec-wise) to just return a JWT > instead of inventing another set of JSON elements? What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway. So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat". Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key. -- Justin > Am 09.01.2013 um 20:10 schrieb Justin Richer >: > >> Updated the introspection draft with feedback from the UMA WG, who >> have incorporated it into their latest revision of UMA. >> >> I would like this document to become a working group item. >> >> -- Justin >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-richer-oauth-introspection-01.txt >> Date: Tue, 8 Jan 2013 14:48:47 -0800 >> From: >> To: >> >> >> >> A new version of I-D, draft-richer-oauth-introspection-01.txt >> has been successfully submitted by Justin Richer and posted to the >> IETF repository. >> >> Filename: draft-richer-oauth-introspection >> Revision: 01 >> Title: OAuth Token Introspection >> Creation date: 2013-01-08 >> WG ID: Individual Submission >> Number of pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >> >> Abstract: >> This specification defines a method for a client or protected >> resource to query an OAuth authorization server to determine meta- >> information about an OAuth token. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------000403030505080305090003 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.


Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

-- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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

--------------000403030505080305090003-- From jricher@mitre.org Wed Jan 9 12:01:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87C21F88B4 for ; Wed, 9 Jan 2013 12:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zjm5-+x6TKt for ; Wed, 9 Jan 2013 12:01:29 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6363821F88B1 for ; Wed, 9 Jan 2013 12:01:29 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B1B031F296E for ; Wed, 9 Jan 2013 15:01:28 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 77E3B1F2967 for ; Wed, 9 Jan 2013 15:01:28 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:01:28 -0500 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt Thread-Index: AQHN7e9EvMjNyotr/0GAGytZSwL3bZhBwCqA Date: Wed, 9 Jan 2013 20:01:26 +0000 Message-ID: References: <20130108222628.27497.4360.idtracker@ietfa.amsl.com> In-Reply-To: <20130108222628.27497.4360.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: text/plain; charset="us-ascii" Content-ID: <11ECB783E509674DA3D5BEE59839F061@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:01:30 -0000 Someone in the OIDC working group has proposed that we add an explicit "rea= d" function to allow a client to get its registration information from the = AS, protected by the Registration Access Token. I'm not opposed to this cha= nge, but I personally don't see much utility in it. So, question to the gro= up: Should we support this function? -- Justin On Jan 8, 2013, at 5:26 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-04.txt > Pages : 20 > Date : 2013-01-08 >=20 > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth Clients at an Authorization Server. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Jan 9 12:05:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7495311E80DC for ; Wed, 9 Jan 2013 12:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-wZEAsiHqU5 for ; Wed, 9 Jan 2013 12:05:31 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8725411E80D9 for ; Wed, 9 Jan 2013 12:05:30 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E5A0D1F2931; Wed, 9 Jan 2013 15:05:29 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D5B451F2930; Wed, 9 Jan 2013 15:05:29 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:05:29 -0500 From: "Richer, Justin P." To: John Bradley , Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN7qSrCNLV4hp/Q0Wz+S+ZZaZ4Pw== Date: Wed, 9 Jan 2013 20:05:28 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873F05IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:05:33 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06873F05IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06873F05IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: <39DB2618880F0840804B35ED1AABEEDF@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
It's been a few days now and I haven't seen any traffic from the group= about this at all, so I'll just come out and ask for opinions. The two pro= posals are:

OIDC-style:
 - inclusion of field replaces that field value on the server wit= h the new value
 - omission of field deletes that field value on the server

DynReg style:
 - inclusion of field replaces that field value on the server wit= h the new value
 - omission of field tells the server to leave its current value = alone
 - inclusion of field with an empty string value deletes/clears t= hat field value from the server


Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its c= urrent semantics? Why? Is there another option that's even better?

 -- Justin


On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

Mike,= John, thanks for the feedback. I hope and anticipate that this conversatio= n will help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin



From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7= jtb.com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That preven= ts unknown states if a update fails.   

I think the always replace everything rule is simpler, though admitted= ly more bandwidth is required.  However bandwidth is not a significant= factor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

The client_update operation in <= /span>http:= //tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://op= enid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 
I'm personally not happy with the change to the semantics of client field i= nclusion.  Updating some but not all fields is a substantially more co= mplicated operation than replacing all fields.  Is there some use case= that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field va= lues from the initial registration and then selectively use them for update= operations, when needed.  Then the work goes to the (I suspect rare) = parties that need partial update - not to every server.  It complicates the simple case, rather than pushing= the complexity to the rare case, violating the design principle =93make si= mple things simple and make more complicated things possible=94.
 
Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics?  Is so, why?
 
            &nb= sp;            =             &nb= sp;            =             &nb= sp; Thanks,
            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth

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

--_000_B33BFB58CCC8BE4998958016839DE27E06873F05IMCMBX01MITREOR_-- From torsten@lodderstedt.net Wed Jan 9 12:06:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5563111E8099 for ; Wed, 9 Jan 2013 12:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUyCqweQV8Rr for ; Wed, 9 Jan 2013 12:06:03 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id C44AC21F88B4 for ; Wed, 9 Jan 2013 12:06:02 -0800 (PST) Received: from [79.253.23.39] (helo=[192.168.71.56]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tt1uS-0001vq-FI; Wed, 09 Jan 2013 21:06:00 +0100 References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50EDC666.6040808@mitre.org> Content-Type: multipart/alternative; boundary=Apple-Mail-A309BEFC-D07C-4CFA-ACE5-279C7C9C336C Content-Transfer-Encoding: 7bit Message-Id: <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Wed, 9 Jan 2013 21:05:59 +0100 To: Justin Richer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:06:04 -0000 --Apple-Mail-A309BEFC-D07C-4CFA-ACE5-279C7C9C336C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Justin, Am 09.01.2013 um 20:35 schrieb Justin Richer : > Thanks for the review, answers inline: >> why is there a need for both scope and audience? I would assume the scope= of the authorization request is typically turned into an audience of an acc= ess token. >=20 > You can have an audience of a single server that has multiple scopes, or a= single scope that's across multiple servers. Scope is an explicit construct= in OAuth2, and while it is sometimes used for audience restriction purp= oses, they really are independent. Note that both of these are optional in t= he response -- if the AS has no notion of audience restriction in its stored= token metadata, then it just doesn't return the "audience" field. You are making an interesting point here. To differentiate the resource serv= er and the permissions of a particular at this server makes a lot of sense. B= UT: the authorization request does not allow the client to specify both in s= eparate parameters. Instead both must be folded into a single "scope" parame= ter. If I got your example correctly, the scope of the request would be scope=3Dmyserver:read whereas the results of the introspection would be scope=3Dread audience=3Dmyserver It's probably the different semantics of scope that confused me. >=20 >>=20 >> Generally, wouldn't it be simpler (spec-wise) to just return a JWT instea= d of inventing another set of JSON elements? >=20 > What would be the utility in returning a JWT? The RS/client making the cal= l isn't going to take these results and present them elsewhere, so I don't w= ant to give the impression that it's a token. (This, incidentally, is one of= the main problems I have with the Ping introspection approach, which uses t= he Token Endpoint and invents a "token type" as its return value.) Also, the= resource server would have to parse the JWT instead of raw JSON, the latter= of which is easier and far more common. Besides, I'd have to invent new cla= ims for things like "valid" and "scopes" and what not, so I'd be extending J= WT anyway.=20 >=20 > So while I think it's far preferable to use an actual JSON object, I'd be f= ine with re-using JWT claim names in the response if people prefer that. I t= ried to just use the expanded text since size constraints are not an issue o= utside of a JWT, so "issued_at" instead of "iat". >=20 > Finally, note that this is *not* the same as the old OIDC CheckId endpoint= which merely parsed and unwrapped the data inside the token itself. This me= chanism works just as well with an unstructured token as input since the AS c= an store all of the token's metadata, like expiration, separately and use th= e token's value as a lookup key. I probably didn't describe well what I meant. I would suggest to return a JW= T claim set from the introspection endpoint. That way one could use the same= claims (e.g. iat instead of issued_at) for structured and handle-based toke= ns. So the logic operating on the token data could be the same. regards, Torsten. >=20 > -- Justin >=20 >> Am 09.01.2013 um 20:10 schrieb Justin Richer : >>=20 >>> Updated the introspection draft with feedback from the UMA WG, who have i= ncorporated it into their latest revision of UMA.=20 >>>=20 >>> I would like this document to become a working group item. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-richer-oauth-introspecti= on-01.txt >>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>> From: >>> To: >>>=20 >>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>> has been successfully submitted by Justin Richer and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-richer-oauth-introspection >>> Revision: 01 >>> Title: OAuth Token Introspection >>> Creation date: 2013-01-08 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-= introspection-01.txt >>> Status: http://datatracker.ietf.org/doc/draft-richer-oauth-intr= ospection >>> Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspec= tion-01 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-i= ntrospection-01 >>>=20 >>> Abstract: >>> This specification defines a method for a client or protected >>> resource to query an OAuth authorization server to determine meta- >>> information about an OAuth token. >>>=20 >>>=20 >>> = =20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-A309BEFC-D07C-4CFA-ACE5-279C7C9C336C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.



Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.

regards,
Torsten.


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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

--Apple-Mail-A309BEFC-D07C-4CFA-ACE5-279C7C9C336C-- From Michael.Jones@microsoft.com Wed Jan 9 12:06:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB4611E8099 for ; Wed, 9 Jan 2013 12:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3JNwKcItppX for ; Wed, 9 Jan 2013 12:06:48 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BE21F88B4 for ; Wed, 9 Jan 2013 12:06:47 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.201) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 9 Jan 2013 20:06:45 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 9 Jan 2013 20:06:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 20:06:15 +0000 From: Mike Jones To: "Richer, Justin P." , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt Thread-Index: AQHN7e9TFLgrew5pC06P/kOSRWPYophBbFcAgAABFdA= Date: Wed, 9 Jan 2013 20:06:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A095BB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130108222628.27497.4360.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(51704002)(377424002)(377454001)(50854002)(13464002)(4396001)(54356001)(46406002)(51856001)(5343655001)(76482001)(31966008)(23726001)(59766001)(55846006)(47776002)(74662001)(53806001)(77982001)(16406001)(56816002)(79102001)(47736001)(33656001)(47976001)(54316002)(46102001)(74502001)(50986001)(50466001)(44976002)(15202345001)(56776001)(49866001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB038; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07215D0470 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:06:48 -0000 No. It unnecessarily increases the implementation footprint for servers wi= thout providing any essential functionality. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R= icher, Justin P. Sent: Wednesday, January 09, 2013 12:01 PM To: oauth@ietf.org WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-04.txt Someone in the OIDC working group has proposed that we add an explicit "rea= d" function to allow a client to get its registration information from the = AS, protected by the Registration Access Token. I'm not opposed to this cha= nge, but I personally don't see much utility in it. So, question to the gro= up: Should we support this function? -- Justin On Jan 8, 2013, at 5:26 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-04.txt > Pages : 20 > Date : 2013-01-08 >=20 > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth Clients at an Authorization Server. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Wed Jan 9 12:09:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836F921F884F for ; Wed, 9 Jan 2013 12:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu6DvEi-F7Tw for ; Wed, 9 Jan 2013 12:08:58 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2674E21F884A for ; Wed, 9 Jan 2013 12:08:48 -0800 (PST) Received: from BL2FFO11FD003.protection.gbl (10.173.161.202) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 9 Jan 2013 20:08:27 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 9 Jan 2013 20:08:27 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 20:07:59 +0000 From: Mike Jones To: "Richer, Justin P." , John Bradley Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN7qS/GC9Ji+fVO0CyNCIvZxYB0JhBbHag Date: Wed, 9 Jan 2013 20:07:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A095EE@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A095EETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(24454001)(377454001)(377424002)(51914002)(53806001)(51856001)(46102001)(16406001)(76482001)(5343655001)(15395725002)(54316002)(56776001)(79102001)(47736001)(512954001)(33656001)(54356001)(551934001)(5343635001)(55846006)(15202345001)(550184003)(59766001)(77982001)(31966008)(47446002)(4396001)(74662001)(49866001)(44976002)(16236675001)(5343645001)(74502001)(50986001)(47976001)(56816002)(59253001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14MLTC101.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07215D0470 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:09:03 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A095EETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Complete replacement is simpler to implement, and has fewer potential error= cases to handle than partial update. Keep it simple. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Wednesday, January 09, 2013 12:05 PM To: John Bradley; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (""). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle "make simple things simple= and make more complicated things possible". Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366A095EETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Complete replacement is s= impler to implement, and has fewer potential error cases to handle than par= tial update.  Keep it simple.

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Wednesday, January 09, 2013 12:05 PM
To: John Bradley; Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Difference between client_update semantics i= n draft-ietf-oauth-dyn-reg and OpenID Connect Registration

 

It's been a few days now and I haven't seen any traf= fic from the group about this at all, so I'll just come out and ask for opi= nions. The two proposals are:

 

OIDC-style:

 - inclusion of field replaces that field value= on the server with the new value

 - omission of field deletes that field value o= n the server

 

DynReg style:

 - inclusion of field replaces that field value= on the server with the new value

 - omission of field tells the server to leave = its current value alone

 - inclusion of field with an empty string valu= e deletes/clears that field value from the server

 

 

Should the OAuth2 Dyn Reg spec adopt the OIDC semant= ics, or keep its current semantics? Why? Is there another option that's eve= n better?

 

 -- Justin

 

 

On Jan 5, 2013, at 2:36 PM, "Richer, Justin P.&= quot; <jricher@mitre.org> wr= ote:



Mike, Joh= n, thanks for the feedback. I hope and anticipate that this conversation wi= ll help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin


From:<= /span> oauth-bounces@ie= tf.org [oauth-bounces@ietf.org] on = behalf of John Bradley [ve7jtb@ve7jtb.= com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.

 

The decision was made to always completely replace. =   That prevents unknown states if a update fails.   

 

I think the always replace everything rule is simple= r, though admittedly more bandwidth is required.  However bandwidth is= not a significant factor for this as far as I know.

 

John B.

 

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:



The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-con= nect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (“”).

 

I'm personally not happy with the chang= e to the semantics of client field inclusion.  Updating some but not a= ll fields is a substantially more complicated operation than replacing all fields.  Is there some use case that motivates this?&nb= sp; I don't think it's a substantial burden on the registering party to rem= ember all the field values from the initial registration and then selective= ly use them for update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial updat= e - not to every server.  It complicates the simple case, rather than = pushing the complexity to the rare case, violating the design principle = 220;make simple things simple and make more complicated things possible”.

 

Is anyone opposed to updating the OAuth= Registration semantics to match the Connect registration semantics?  = Is so, why?

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       Thanks,

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

 

_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366A095EETK5EX14MBXC283r_-- From jricher@mitre.org Wed Jan 9 12:11:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48A21F88B4 for ; Wed, 9 Jan 2013 12:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAKYYMwKPHPi for ; Wed, 9 Jan 2013 12:11:08 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2921F884F for ; Wed, 9 Jan 2013 12:11:07 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C6C0D1F295A; Wed, 9 Jan 2013 15:11:03 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B37DF1F2931; Wed, 9 Jan 2013 15:11:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:11:03 -0500 From: "Richer, Justin P." To: John Bradley , Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN7qVyCNLV4hp/Q0Wz+S+ZZaZ4Pw== Date: Wed, 9 Jan 2013 20:11:02 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873F69IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:11:13 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06873F69IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I prefer the DynReg style, as it keeps things simple for clients (still sup= ports the replace-all mechanics) while making it safer for them. It's also = explicit about how to handle server-asserted values that a dumb client migh= t ignore. The partial-update is a small added bonus. -- Justin On Jan 9, 2013, at 3:05 PM, Justin Richer > wrote: It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06873F69IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: <895D4AFEC1C4DC448078704DA85DDA90@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I prefer the DynReg style, as it keeps things simple for clients (still sup= ports the replace-all mechanics) while making it safer for them. It's also = explicit about how to handle server-asserted values that a dumb client migh= t ignore. The partial-update is a small added bonus.

 -- Justin

On Jan 9, 2013, at 3:05 PM, Justin Richer <jricher@mitre.org>
 wrote:

It's been a few days now and I haven't seen any traffic from the group= about this at all, so I'll just come out and ask for opinions. The two pro= posals are:

OIDC-style:
 - inclusion of field replaces that field value on the server wit= h the new value
 - omission of field deletes that field value on the server

DynReg style:
 - inclusion of field replaces that field value on the server wit= h the new value
 - omission of field tells the server to leave its current value = alone
 - inclusion of field with an empty string value deletes/clears t= hat field value from the server


Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its c= urrent semantics? Why? Is there another option that's even better?

 -- Justin


On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

Mike,= John, thanks for the feedback. I hope and anticipate that this conversatio= n will help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin



From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7= jtb.com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That preven= ts unknown states if a update fails.   

I think the always replace everything rule is simpler, though admitted= ly more bandwidth is required.  However bandwidth is not a significant= factor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

The client_update operation in <= /span>http:= //tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://op= enid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 
I'm personally not happy with the change to the semantics of client field i= nclusion.  Updating some but not all fields is a substantially more co= mplicated operation than replacing all fields.  Is there some use case= that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field va= lues from the initial registration and then selectively use them for update= operations, when needed.  Then the work goes to the (I suspect rare) = parties that need partial update - not to every server.  It complicates the simple case, rather than pushing= the complexity to the rare case, violating the design principle =93make si= mple things simple and make more complicated things possible=94.
 
Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics?  Is so, why?
 
            &nb= sp;            =             &nb= sp;            =             &nb= sp; Thanks,
            &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth

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


--_000_B33BFB58CCC8BE4998958016839DE27E06873F69IMCMBX01MITREOR_-- From jricher@mitre.org Wed Jan 9 12:12:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0B521F854C for ; Wed, 9 Jan 2013 12:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuL3iO8Ba5+c for ; Wed, 9 Jan 2013 12:12:04 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1859721F8550 for ; Wed, 9 Jan 2013 12:12:04 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A78E1F2966; Wed, 9 Jan 2013 15:12:03 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 572411F2960; Wed, 9 Jan 2013 15:12:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:12:03 -0500 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN7qWWiv3S82ZaCUiTtACVLR6VgA== Date: Wed, 9 Jan 2013 20:12:02 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394366A095EE@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A095EE@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:12:11 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This not true in my own personal implementation experience, which is where = I came up with the DynReg style. -- Justin On Jan 9, 2013, at 3:07 PM, Mike Jones > wrote: Complete replacement is simpler to implement, and has fewer potential error= cases to handle than partial update. Keep it simple. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Wednesday, January 09, 2013 12:05 PM To: John Bradley; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: <96518D96ED7F3A4E8971D2532C402772@imc.mitre.org> Content-Transfer-Encoding: quoted-printable This not true in my own personal implementation experience, which is where = I came up with the DynReg style.

 -- Justin

On Jan 9, 2013, at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Complete replacement is simpler to implement, and has few= er potential error cases to handle than partial update.  Keep it simpl= e.
 
         &nb= sp;            =             &nb= sp;            =             &nb= sp;    -- Mike
 
From:=  Richer, Justin P. [ma= ilto:jricher@mitre.org] 
Sent: Wednesday, J= anuary 09, 2013 12:05 PM
To: John Bradley; = Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration
 
It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are:
 
OIDC-style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field deletes that field value on the server=
 
DynReg style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field tells the server to leave its current value alone=
 - inclusion of field with an empty string value deletes/clears that f= ield value from the server
 
 
Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better?
 
 -- Justin
 
 
On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <

Mike, Jo= hn, thanks for the feedback. I hope and anticipate that this conversation w= ill help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin


From:=  o= auth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: o= auth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.
 
The decision was made to always completely replace.   That prevents un= known states if a update fails.   
 
I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required.  However bandwidth is not a significant fact= or for this as far as I know.
 
John B.
 
On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:


The cli= ent_update operation in <= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03" target=3D= "_blank" style=3D"color: purple; text-decoration: underline; ">http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03=  does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-= 1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 <= o:p>
I'm per= sonally not happy with the change to the semantics of client field inclusio= n.  Updating some but not all fields is a substantially more complicat= ed operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a sub= stantial burden on the registering party to remember all the field values f= rom the initial registration and then selectively use them for update opera= tions, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every se= rver.  It complicates the simple case, rather than pushing the complex= ity to the rare case, violating the design principle =93make simple things = simple and make more complicated things possible=94.
 <= o:p>
Is anyo= ne opposed to updating the OAuth Registration semantics to match the Connec= t registration semantics?  Is so, why?
 <= o:p>
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Tha= nks,
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            -- = Mike
 <= o:p>
___= ____________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=
 
___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth


--_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_-- From jricher@mitre.org Wed Jan 9 12:15:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3A21F88B4 for ; Wed, 9 Jan 2013 12:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvyNZJptrG84 for ; Wed, 9 Jan 2013 12:15:11 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0148721F88AE for ; Wed, 9 Jan 2013 12:15:11 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F08D1F2977; Wed, 9 Jan 2013 15:15:10 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 680261F2955; Wed, 9 Jan 2013 15:15:10 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:15:10 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt Thread-Index: AQHN7fJSaTtsJD7Erk6+DEfqvZzSmJhBYZUGgAAMCbeAAFZagA== Date: Wed, 9 Jan 2013 20:15:08 +0000 Message-ID: References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> In-Reply-To: <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873FA8IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:15:13 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06873FA8IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt > wrote: Hi Justin, Am 09.01.2013 um 20:35 schrieb Justin Richer >: Thanks for the review, answers inline: why is there a need for both scope and audience? I would assume the scope o= f the authorization request is typically turned into an audience of an acce= ss token. You can have an audience of a single server that has multiple scopes, or a = single scope that's across multiple servers. Scope is an explicit construct= in OAuth2, and while it is sometimes used for audience restriction purpose= s, they really are independent. Note that both of these are optional in the= response -- if the AS has no notion of audience restriction in its stored = token metadata, then it just doesn't return the "audience" field. You are making an interesting point here. To differentiate the resource ser= ver and the permissions of a particular at this server makes a lot of sense= . BUT: the authorization request does not allow the client to specify both = in separate parameters. Instead both must be folded into a single "scope" p= arameter. If I got your example correctly, the scope of the request would b= e scope=3Dmyserver:read whereas the results of the introspection would be scope=3Dread audience=3Dmyserver It's probably the different semantics of scope that confused me. No, sorry if I was unclear: scope is scope, no different semantics. In this= example case, you'd ask for scope=3Dmyserver:read and get back scope=3Dmys= erver:read. I'm not suggesting that these be split up. Since the AS in this= case knows that there's an audience, so it can return audience=3Dmyserver = as well. The fact that it knows this through the scope mechanism is entirel= y system-dependent. I agree that the lack of a method for specifying audience does make returni= ng this field a little odd for simple OAuth deployments, but since audience= restriction is a big part of clustered and enterprise deployments (in my p= ersonal experience), then it's something very useful to have the server ret= urn. Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead = of inventing another set of JSON elements? What would be the utility in returning a JWT? The RS/client making the call= isn't going to take these results and present them elsewhere, so I don't w= ant to give the impression that it's a token. (This, incidentally, is one o= f the main problems I have with the Ping introspection approach, which uses= the Token Endpoint and invents a "token type" as its return value.) Also, = the resource server would have to parse the JWT instead of raw JSON, the la= tter of which is easier and far more common. Besides, I'd have to invent ne= w claims for things like "valid" and "scopes" and what not, so I'd be exten= ding JWT anyway. So while I think it's far preferable to use an actual JSON object, I'd be f= ine with re-using JWT claim names in the response if people prefer that. I = tried to just use the expanded text since size constraints are not an issue= outside of a JWT, so "issued_at" instead of "iat". Finally, note that this is *not* the same as the old OIDC CheckId endpoint = which merely parsed and unwrapped the data inside the token itself. This me= chanism works just as well with an unstructured token as input since the AS= can store all of the token's metadata, like expiration, separately and use= the token's value as a lookup key. I probably didn't describe well what I meant. I would suggest to return a J= WT claim set from the introspection endpoint. That way one could use the sa= me claims (e.g. iat instead of issued_at) for structured and handle-based t= okens. So the logic operating on the token data could be the same. OK, I follow you now. I'd be fine with re-using the JWT claim names and ext= ending the namespace with the OAuth-specific parameters, like scope, that m= ake sense here. -- Justin regards, Torsten. -- Justin Am 09.01.2013 um 20:10 schrieb Justin Richer >: Updated the introspection draft with feedback from the UMA WG, who have inc= orporated it into their latest revision of UMA. I would like this document to become a working group item. -- Justin -------- Original Message -------- Subject: New Version Notification for draft-richer-oauth-introspecti= on-01.txt Date: Tue, 8 Jan 2013 14:48:47 -0800 From: To: A new version of I-D, draft-richer-oauth-introspection-01.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-introspection Revision: 01 Title: OAuth Token Introspection Creation date: 2013-01-08 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-int= rospection-01.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introsp= ection Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspectio= n-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-intr= ospection-01 Abstract: This specification defines a method for a client or protected resource to query an OAuth authorization server to determine meta- information about an OAuth token. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06873FA8IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: <7F4920B203E3C445AA2C657582A44AB4@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the sc= ope of the authorization request is typically turned into an audience of an= access token.

You can have an audience of a single server that has multiple scopes, or a = single scope that's across multiple servers. Scope is an explicit construct= in OAuth2, and while it is sometimes used for audience restriction purpose= s, they really are independent. Note that both of these are optional in the response -- if the AS has no n= otion of audience restriction in its stored token metadata, then it just do= esn't return the "audience" field.

You are making an interesting point here. To differentiate the resourc= e server and the permissions of a particular at this server makes a lot of = sense. BUT: the authorization request does not allow the client to specify = both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got yo= ur example correctly, the scope of the request would be

scope=3Dmyserver:read

whereas the results of the introspection would be

scope=3Dread
audience=3Dmyserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In= this example case, you'd ask for scope=3Dmyserver:read and get back scope= =3Dmyserver:read. I'm not suggesting that these be split up. Since the AS i= n this case knows that there's an audience, so it can return audience=3Dmyserver as well. The fact that it knows this = through the scope mechanism is entirely system-dependent. 

I agree that the lack of a method for specifying audience does make re= turning this field a little odd for simple OAuth deployments, but since aud= ience restriction is a big part of clustered and enterprise deployments (in= my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT ins= tead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call= isn't going to take these results and present them elsewhere, so I don't w= ant to give the impression that it's a token. (This, incidentally, is one o= f the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents= a "token type" as its return value.) Also, the resource server w= ould have to parse the JWT instead of raw JSON, the latter of which is easi= er and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes&qu= ot; and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be f= ine with re-using JWT claim names in the response if people prefer that. I = tried to just use the expanded text since size constraints are not an issue= outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint = which merely parsed and unwrapped the data inside the token itself. This me= chanism works just as well with an unstructured token as input since the AS= can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to retur= n a JWT claim set from the introspection endpoint. That way one could use t= he same claims (e.g. iat instead of issued_at) for structured and handle-ba= sed tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names an= d extending the namespace with the OAuth-specific parameters, like scope, t= hat make sense here.

 -- Justin

regards,
Torsten.


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who hav= e incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspe=
ction-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        h=
ttp://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-introspection-=
01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                           =
      =20


The IETF Secretariat


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


--_000_B33BFB58CCC8BE4998958016839DE27E06873FA8IMCMBX01MITREOR_-- From Michael.Jones@microsoft.com Wed Jan 9 12:21:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7721F8645 for ; Wed, 9 Jan 2013 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhiy0NiETASH for ; Wed, 9 Jan 2013 12:21:05 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9666021F857A for ; Wed, 9 Jan 2013 12:21:04 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.200) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 9 Jan 2013 20:21:01 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 9 Jan 2013 20:21:00 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 20:20:23 +0000 From: Mike Jones To: "Richer, Justin P." , John Bradley Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: Ac3upsBhvBtn//6mS2mSrXYtYOGjLQ== Date: Wed, 9 Jan 2013 20:20:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A0964B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A0964BTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377424002)(377454001)(51914002)(164054002)(47446002)(51856001)(5343655001)(74502001)(54316002)(31966008)(59766001)(56776001)(44976002)(53806001)(5343645001)(15202345001)(74662001)(512954001)(77982001)(46102001)(5343635001)(47736001)(76482001)(55846006)(54356001)(16236675001)(551934001)(16406001)(49866001)(33656001)(79102001)(50986001)(47976001)(15395725002)(550184003)(56816002)(4396001)(59253001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB022; H:TK5EX14MLTC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07215D0470 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:21:10 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A0964BTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that the client simplicity premise is false in this case. To per= form the initial registration, the client already had to have all the regis= tration field values. It if wants to update only some of them, it will sti= ll have the old values and can resupply them. Also, I haven't seen any motivating use case for partial update. Is there = such a concrete use case, or is this a hypothetical scenario? -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Wednesday, January 09, 2013 12:11 PM To: John Bradley; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration I prefer the DynReg style, as it keeps things simple for clients (still sup= ports the replace-all mechanics) while making it safer for them. It's also = explicit about how to handle server-asserted values that a dumb client migh= t ignore. The partial-update is a small added bonus. -- Justin On Jan 9, 2013, at 3:05 PM, Justin Richer > wrote: It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (""). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle "make simple things simple= and make more complicated things possible". Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366A0964BTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that the client= simplicity premise is false in this case.  To perform the initial reg= istration, the client already had to have all the registration field values.  It if wants to update only some of them, it will still= have the old values and can resupply them.

 <= /p>

Also, I haven’t see= n any motivating use case for partial update.  Is there such a concret= e use case, or is this a hypothetical scenario?

 <= /p>

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

 <= /p>

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Wednesday, January 09, 2013 12:11 PM
To: John Bradley; Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Difference between client_update semantics i= n draft-ietf-oauth-dyn-reg and OpenID Connect Registration

 

I prefer the DynReg style, as it keeps things simple= for clients (still supports the replace-all mechanics) while making it saf= er for them. It's also explicit about how to handle server-asserted values = that a dumb client might ignore. The partial-update is a small added bonus.

 

 -- Justin

 

On Jan 9, 2013, at 3:05 PM, Justin Richer <jricher@mitre.org>

 wrote:



It's been a few days now and I haven't seen any traf= fic from the group about this at all, so I'll just come out and ask for opi= nions. The two proposals are:

 

OIDC-style:

 - inclusion of field replaces that field value= on the server with the new value

 - omission of field deletes that field value o= n the server

 

DynReg style:

 - inclusion of field replaces that field value= on the server with the new value

 - omission of field tells the server to leave = its current value alone

 - inclusion of field with an empty string valu= e deletes/clears that field value from the server

 

 

Should the OAuth2 Dyn Reg spec adopt the OIDC semant= ics, or keep its current semantics? Why? Is there another option that's eve= n better?

 

 -- Justin

 

 

On Jan 5, 2013, at 2:36 PM, "Richer, Justin P.&= quot; <jricher@mitre.org> wr= ote:



Mike, Joh= n, thanks for the feedback. I hope and anticipate that this conversation wi= ll help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin


From:<= /span> oauth-bounces@ie= tf.org [oauth-bounces@ietf.org] on = behalf of John Bradley [ve7jtb@ve7jtb.= com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.

 

The decision was made to always completely replace. =   That prevents unknown states if a update fails.   

 

I think the always replace everything rule is simple= r, though admittedly more bandwidth is required.  However bandwidth is= not a significant factor for this as far as I know.

 

John B.

 

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:



The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-con= nect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (“”).

 

I'm personally not happy with the chang= e to the semantics of client field inclusion.  Updating some but not a= ll fields is a substantially more complicated operation than replacing all fields.  Is there some use case that motivates this?&nb= sp; I don't think it's a substantial burden on the registering party to rem= ember all the field values from the initial registration and then selective= ly use them for update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial updat= e - not to every server.  It complicates the simple case, rather than = pushing the complexity to the rare case, violating the design principle = 220;make simple things simple and make more complicated things possible”.

 

Is anyone opposed to updating the OAuth= Registration semantics to match the Connect registration semantics?  = Is so, why?

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       Thanks,

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

 

_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

 

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

 

 

--_000_4E1F6AAD24975D4BA5B168042967394366A0964BTK5EX14MBXC283r_-- From jricher@mitre.org Wed Jan 9 12:43:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A9211E80AD for ; Wed, 9 Jan 2013 12:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4eIURpbo2lx for ; Wed, 9 Jan 2013 12:43:35 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5241221F88AE for ; Wed, 9 Jan 2013 12:43:34 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2ACE1F296F; Wed, 9 Jan 2013 15:43:33 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A22881F29B4; Wed, 9 Jan 2013 15:43:33 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:43:33 -0500 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: Ac3upsBhiv3S82ZaCUiTtACVLR6VgAALSUkA Date: Wed, 9 Jan 2013 20:43:32 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366A0964B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A0964B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06874166IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:43:37 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06874166IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Not quite - the client supplies all of the fields that it knows about, and = the server will fill in the rest. This includes any the client might not kn= ow or care about. This comes into play especially because the list of field= s is now extensible by definition, which it wasn't in OIDC. It's exactly th= is extensibility that will make OIDC be able to leverage this, so the exten= sibility needs to be done right and with conscious consideration. At the point of initial registration, the client should have all of the fie= lds returned (something that both DynReg and OIDC Reg now do, per my latest= edits), so a simple client that just posts back this data model to the ser= ver every time it does an update will function exactly the same way in both= cases. So you still get the exact same post-all behavior. If instead you have a client that only stores the fields that it knows abou= t in the original registration request (it's ignorant of extensions and def= aults and doesn't save the raw JSON object), then you've got an interesting= situation. So the client registers a set of fields, the server gives a def= ault for something the client doesn't ask for (like scope), and returns tha= t JSON back. Now the client needs to be able to deal with this new field in= its local storage, even if it doesn't care about it, or else risk deleting= its server-asserted "scope" value from the server. I don't think that limiting the fields you care about is an unreasonable as= sumption for a client to make in its data model, either, but more client au= thors should chime in here and say if I'm wrong or not. With this in mind, = I don't see at all how this makes things any more complicated for a well-be= haved client in the slightest, since a client behaving in the way that OIDC= intends will get the same behavior from a server, won't it? The implementation on the server side is not complicated by these new seman= tics, as per my own personal anecdotal experience. I found it easier to do = things this way because it's much more explicit, actually. What do I do if = a client doesn't include a required field? But I'd like to hear from other = server implementors what they think. Our code to do things in the DynReg st= yle is here, for reference: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/m= aster/openid-connect-server/src/main/java/org/mitre/openid/connect/web/Clie= ntDynamicRegistrationEndpoint.java#L349 The intentional partial edit method has become a distracting side case and = is not the primary motivator for this change, so please stop bringing it up= as such. The motivation for this change was for safety from the client's p= erspective and clarity from the server's perspective in cases of unintentio= nal partial edits, like the one described above. Either way, I'm willing to go with what the Working Group wants to do here. -- Justin On Jan 9, 2013, at 3:20 PM, Mike Jones > wrote: I believe that the client simplicity premise is false in this case. To per= form the initial registration, the client already had to have all the regis= tration field values. It if wants to update only some of them, it will sti= ll have the old values and can resupply them. Also, I haven=92t seen any motivating use case for partial update. Is ther= e such a concrete use case, or is this a hypothetical scenario? -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Wednesday, January 09, 2013 12:11 PM To: John Bradley; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration I prefer the DynReg style, as it keeps things simple for clients (still sup= ports the replace-all mechanics) while making it safer for them. It's also = explicit about how to handle server-asserted values that a dumb client migh= t ignore. The partial-update is a small added bonus. -- Justin On Jan 9, 2013, at 3:05 PM, Justin Richer > wrote: It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06874166IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: <68E287387C11144894338E431B41DB09@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Not quite - the client supplies all of the fields that it knows about,= and the server will fill in the rest. This includes any the client might n= ot know or care about. This comes into play especially because the list of = fields is now extensible by definition, which it wasn't in OIDC. It's exactly this extensibility that will make OI= DC be able to leverage this, so the extensibility needs to be done right an= d with conscious consideration.

At the point of initial registration, the client should have all of th= e fields returned (something that both DynReg and OIDC Reg now do, per my l= atest edits), so a simple client that just posts back this data model to th= e server every time it does an update will function exactly the same way in both cases. So you still get the exa= ct same post-all behavior. 

If instead you have a client that only stores the fields that it knows= about in the original registration request (it's ignorant of extensions an= d defaults and doesn't save the raw JSON object), then you've got an intere= sting situation. So the client registers a set of fields, the server gives a default for something the client doesn= 't ask for (like scope), and returns that JSON back. Now the client needs t= o be able to deal with this new field in its local storage, even if it does= n't care about it, or else risk deleting its server-asserted "scope" value from the server. = ;

I don't think that limiting the fields you care about is an unreasonab= le assumption for a client to make in its data model, either, but more clie= nt authors should chime in here and say if I'm wrong or not. With this in m= ind, I don't see at all how this makes things any more complicated for a well-behaved client in the slighte= st, since a client behaving in the way that OIDC intends will get the same = behavior from a server, won't it? 

The implementation on the server side is not complicated by these new = semantics, as per my own personal anecdotal experience. I found it easier t= o do things this way because it's much more explicit, actually. What do I d= o if a client doesn't include a required field? But I'd like to hear from other server implementors what t= hey think. Our code to do things in the DynReg style is here, for reference= :


The intentional partial edit method has become a distracting side case= and is not the primary motivator for this change, so please stop bringing = it up as such. The motivation for this change was for safety from the clien= t's perspective and clarity from the server's perspective in cases of unintentional partial edits, like the= one described above.

Either way, I'm willing to go with what the Working Group wants to do = here.

 -- Justin


On Jan 9, 2013, at 3:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I believe that the client simplicity premise is false in = this case.  To perform the initial registration, the client already ha= d to have all the registration field values.  It if wants to update only some of them, it will still have the old values= and can resupply them.
 
Also, I haven=92t seen any motivating use case for partia= l update.  Is there such a concrete use case, or is this a hypothetica= l scenario?
 
         &nb= sp;            =             &nb= sp;            =              --= Mike
 
From:=  Richer, Justin P. [ma= ilto:jricher@mitre.org]&= nbsp;
Sent: Wednesday, J= anuary 09, 2013 12:11 PM
To: John Bradley; = Mike Jones
Cc: o= auth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration
 
I prefer the DynReg style, as it keeps things simple for clients (still sup= ports the replace-all mechanics) while making it safer for them. It's also = explicit about how to handle server-asserted values that a dumb client migh= t ignore. The partial-update is a small added bonus.
 
 -- Justin
 
On Jan 9, 2013, at 3:05 PM, Justin Richer <jricher@mitre= .org>
 wrote:


It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are:
 
OIDC-style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field deletes that field value on the server=
 
DynReg style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field tells the server to leave its current value alone=
 - inclusion of field with an empty string value deletes/clears that f= ield value from the server
 
 
Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better?
 
 -- Justin
 
 
On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <

Mike, Jo= hn, thanks for the feedback. I hope and anticipate that this conversation w= ill help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin


From:=  o= auth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: o= auth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.
 
The decision was made to always completely replace.   That prevents un= known states if a update fails.   
 
I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required.  However bandwidth is not a significant fact= or for this as far as I know.
 
John B.
 
On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:


The cli= ent_update operation in <= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03" target=3D= "_blank" style=3D"color: purple; text-decoration: underline; ">http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03=  does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-= 1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 <= o:p>
I'm per= sonally not happy with the change to the semantics of client field inclusio= n.  Updating some but not all fields is a substantially more complicat= ed operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a sub= stantial burden on the registering party to remember all the field values f= rom the initial registration and then selectively use them for update opera= tions, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every se= rver.  It complicates the simple case, rather than pushing the complex= ity to the rare case, violating the design principle =93make simple things = simple and make more complicated things possible=94.
 <= o:p>
Is anyo= ne opposed to updating the OAuth Registration semantics to match the Connec= t registration semantics?  Is so, why?
 <= o:p>
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Tha= nks,
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            -- = Mike
 <= o:p>
___= ____________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=
 
___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth
 


--_000_B33BFB58CCC8BE4998958016839DE27E06874166IMCMBX01MITREOR_-- From gffletch@aol.com Wed Jan 9 13:47:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4304821F8862 for ; Wed, 9 Jan 2013 13:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avg4um0YDePq for ; Wed, 9 Jan 2013 13:47:32 -0800 (PST) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4F321F885C for ; Wed, 9 Jan 2013 13:47:32 -0800 (PST) Received: from mtaout-db03.r1000.mx.aol.com (mtaout-db03.r1000.mx.aol.com [172.29.51.195]) by imr-db03.mx.aol.com (Outbound Mail Relay) with ESMTP id A257138000107; Wed, 9 Jan 2013 16:47:31 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2F7D3E0000B6; Wed, 9 Jan 2013 16:47:31 -0500 (EST) Message-ID: <50EDE573.4090308@aol.com> Date: Wed, 09 Jan 2013 16:47:31 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Richer, Justin P." References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020908060404030903090700" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357768051; bh=W+f07ER4VK0L+kozuxeWSAfZbvPt4vTBeywOgIMkSjo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=FYX9Sxqoa0sMCDe9QkodswCdoHDdzcqX58PnlOE8w1s72HUGWXH0XPmzPlQDuAG+i xw50m11JaOnM8gz0qccIMRVBhkvj/20JP9xwgSXXd6o01p8rEkS1fpUesfrNJP46Ee ihVWtGOZkW6ResAspQX4beQ+q0xyzDq9meKLbl/8= X-AOL-SCOLL-SCORE: 0:2:506903744:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c350ede573361f X-AOL-IP: 10.181.186.254 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:47:34 -0000 This is a multi-part message in MIME format. --------------020908060404030903090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project. I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope. So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes? I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'? Thanks, George On 1/9/13 3:15 PM, Richer, Justin P. wrote: > > On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt > > wrote: > >> Hi Justin, >> >> Am 09.01.2013 um 20:35 schrieb Justin Richer > >: >> >>> Thanks for the review, answers inline: >>>> why is there a need for both scope and audience? I would assume the >>>> scope of the authorization request is typically turned into an >>>> audience of an access token. >>> >>> You can have an audience of a single server that has multiple >>> scopes, or a single scope that's across multiple servers. Scope is >>> an explicit construct in OAuth2, and while it is sometimes used for >>> audience restriction purposes, they really are independent. Note >>> that both of these are optional in the response -- if the AS has no >>> notion of audience restriction in its stored token metadata, then it >>> just doesn't return the "audience" field. >> >> You are making an interesting point here. To differentiate the >> resource server and the permissions of a particular at this server >> makes a lot of sense. BUT: the authorization request does not allow >> the client to specify both in separate parameters. Instead both must >> be folded into a single "scope" parameter. If I got your example >> correctly, the scope of the request would be >> >> scope=myserver:read >> >> whereas the results of the introspection would be >> >> scope=read >> audience=myserver >> >> It's probably the different semantics of scope that confused me. > > No, sorry if I was unclear: scope is scope, no different semantics. In > this example case, you'd ask for scope=myserver:read and get back > scope=myserver:read. I'm not suggesting that these be split up. Since > the AS in this case knows that there's an audience, so it can return > audience=myserver as well. The fact that it knows this through the > scope mechanism is entirely system-dependent. > > I agree that the lack of a method for specifying audience does make > returning this field a little odd for simple OAuth deployments, but > since audience restriction is a big part of clustered and enterprise > deployments (in my personal experience), then it's something very > useful to have the server return. > >> >>> >>>> >>>> Generally, wouldn't it be simpler (spec-wise) to just return a JWT >>>> instead of inventing another set of JSON elements? >>> >>> What would be the utility in returning a JWT? The RS/client making >>> the call isn't going to take these results and present them >>> elsewhere, so I don't want to give the impression that it's a token. >>> (This, incidentally, is one of the main problems I have with the >>> Ping introspection approach, which uses the Token Endpoint and >>> invents a "token type" as its return value.) Also, the resource >>> server would have to parse the JWT instead of raw JSON, the latter >>> of which is easier and far more common. Besides, I'd have to invent >>> new claims for things like "valid" and "scopes" and what not, so I'd >>> be extending JWT anyway. >>> >>> So while I think it's far preferable to use an actual JSON object, >>> I'd be fine with re-using JWT claim names in the response if people >>> prefer that. I tried to just use the expanded text since size >>> constraints are not an issue outside of a JWT, so "issued_at" >>> instead of "iat". >>> >>> Finally, note that this is *not* the same as the old OIDC CheckId >>> endpoint which merely parsed and unwrapped the data inside the token >>> itself. This mechanism works just as well with an unstructured token >>> as input since the AS can store all of the token's metadata, like >>> expiration, separately and use the token's value as a lookup key. >> >> I probably didn't describe well what I meant. I would suggest to >> return a JWT claim set from the introspection endpoint. That way one >> could use the same claims (e.g. iat instead of issued_at) for >> structured and handle-based tokens. So the logic operating on the >> token data could be the same. >> > > OK, I follow you now. I'd be fine with re-using the JWT claim names > and extending the namespace with the OAuth-specific parameters, like > scope, that make sense here. > > -- Justin > >> regards, >> Torsten. >> >>> >>> -- Justin >>> >>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>> >: >>>> >>>>> Updated the introspection draft with feedback from the UMA WG, who >>>>> have incorporated it into their latest revision of UMA. >>>>> >>>>> I would like this document to become a working group item. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: New Version Notification for >>>>> draft-richer-oauth-introspection-01.txt >>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>> From: >>>>> To: >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>> has been successfully submitted by Justin Richer and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-richer-oauth-introspection >>>>> Revision: 01 >>>>> Title: OAuth Token Introspection >>>>> Creation date: 2013-01-08 >>>>> WG ID: Individual Submission >>>>> Number of pages: 6 >>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>> >>>>> Abstract: >>>>> This specification defines a method for a client or protected >>>>> resource to query an OAuth authorization server to determine meta- >>>>> information about an OAuth token. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020908060404030903090700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent. 

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

 -- Justin

regards,
Torsten.


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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

--------------020908060404030903090700-- From Michael.Jones@microsoft.com Wed Jan 9 13:52:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A4821F86F8 for ; Wed, 9 Jan 2013 13:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JT6GC-sRWNd for ; Wed, 9 Jan 2013 13:52:28 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id CECE921F86F7 for ; Wed, 9 Jan 2013 13:52:27 -0800 (PST) Received: from BL2FFO11FD011.protection.gbl (10.173.161.204) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 9 Jan 2013 21:52:25 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 9 Jan 2013 21:52:25 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 9 Jan 2013 21:51:43 +0000 From: Mike Jones To: Torsten Lodderstedt , Phil Hunt , "Mark Mcgloin (mark.mcgloin@ie.ibm.com)" Thread-Topic: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations Thread-Index: AQHN7SETWewWaSWp20yagcTYYxPqVphBi/xA Date: Wed, 9 Jan 2013 21:51:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A097E6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130107214016.94851B1E007@rfc-editor.org> In-Reply-To: <20130107214016.94851B1E007@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(56776001)(74662001)(46406002)(5343655001)(5343635001)(79102001)(23726001)(74502001)(53806001)(16406001)(4396001)(54316002)(33656001)(54356001)(44976002)(47776002)(50986001)(50466001)(49866001)(51856001)(76482001)(47976001)(47446002)(31966008)(47736001)(15202345001)(77982001)(56816002)(46102001)(550184003)(55846006)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB032; H:TK5EX14HUBC107.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07215D0470 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:52:28 -0000 Congratulations on this achievement, guys! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of r= fc-editor@rfc-editor.org Sent: Monday, January 07, 2013 1:40 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: oauth@ietf.org; rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Conside= rations A new Request for Comments is now available in online RFC libraries. =20 RFC 6819 Title: OAuth 2.0 Threat Model and=20 Security Considerations=20 Author: T. Lodderstedt, Ed., M. McGloin,=20 P. Hunt Status: Informational Stream: IETF Date: January 2013 Mailbox: torsten@lodderstedt.net,=20 mark.mcgloin@ie.ibm.com,=20 phil.hunt@yahoo.com Pages: 71 Characters: 158332 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-v2-threatmodel-08.txt URL: http://www.rfc-editor.org/rfc/rfc6819.txt This document gives additional security considerations for OAuth, beyond th= ose in the OAuth 2.0 specification, based on a comprehensive threat model f= or the OAuth 2.0 protocol. This document is not an Internet Standards Trac= k specification; it is published for informational purposes. This document is a product of the Web Authorization Protocol Working Group = of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From derek@ihtfp.com Wed Jan 9 15:02:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14BB21F85D9 for ; Wed, 9 Jan 2013 15:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4HQevKMxpou for ; Wed, 9 Jan 2013 15:02:47 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1A621F85D2 for ; Wed, 9 Jan 2013 15:02:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5345F260296; Wed, 9 Jan 2013 18:02:45 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29359-05; Wed, 9 Jan 2013 18:02:44 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D3BA1260226; Wed, 9 Jan 2013 18:02:43 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r09N2eXF029161; Wed, 9 Jan 2013 18:02:40 -0500 From: Derek Atkins To: Barry Leiba References: <20130108011935.22098B1E007@rfc-editor.org> Date: Wed, 09 Jan 2013 18:02:40 -0500 In-Reply-To: (Barry Leiba's message of "Mon, 7 Jan 2013 21:11:33 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: nov@matake.jp, RFC Errata System , Derek Atkins , OAuth WG Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:02:48 -0000 Barry Leiba writes: >> Corrected Text >> -------------- >> Resource owners cannot revoke access to an individual third party without revoking access >> to all third parties, and must do so by changing their password. >> >> Notes >> ----- >> The text was originally "their" but changed to "the third party's" between the last draft and RFC. >> However, "their" means "resource owners'", not "the third party's". > > Yes, this appears to be a change the RFC Editor made that the authors > didn't notice in AUTH48. But the RFC Editor change it from "their" > because "their" wasn't clear. Changing it back to "their" won't help > that. I suggest editing the corrected text to "by changing the > resource owner's password" before marking this as Verified. Yep, I suggested that same change in a private email to Stephen, so I would prefer this modification. > Barry -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From stephen.farrell@cs.tcd.ie Wed Jan 9 15:25:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C630021F86D6 for ; Wed, 9 Jan 2013 15:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPHFT9hLKUH8 for ; Wed, 9 Jan 2013 15:25:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE621F8689 for ; Wed, 9 Jan 2013 15:25:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B2B4BE33; Wed, 9 Jan 2013 23:24:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDWa2A01dVCA; Wed, 9 Jan 2013 23:24:50 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.44.78.176]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5978DBDDC; Wed, 9 Jan 2013 23:24:50 +0000 (GMT) Message-ID: <50EDFC42.40800@cs.tcd.ie> Date: Wed, 09 Jan 2013 23:24:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Derek Atkins References: <20130108011935.22098B1E007@rfc-editor.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , nov@matake.jp, RFC Errata System , OAuth WG Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:25:16 -0000 On 01/09/2013 11:02 PM, Derek Atkins wrote: > Barry Leiba writes: > >>> Corrected Text >>> -------------- >>> Resource owners cannot revoke access to an individual third party without revoking access >>> to all third parties, and must do so by changing their password. >>> >>> Notes >>> ----- >>> The text was originally "their" but changed to "the third party's" between the last draft and RFC. >>> However, "their" means "resource owners'", not "the third party's". >> >> Yes, this appears to be a change the RFC Editor made that the authors >> didn't notice in AUTH48. But the RFC Editor change it from "their" >> because "their" wasn't clear. Changing it back to "their" won't help >> that. I suggest editing the corrected text to "by changing the >> resource owner's password" before marking this as Verified. > > Yep, I suggested that same change in a private email to Stephen, so I > would prefer this modification. Ok, assuming nobody objects I'll verify this that way tomorrow. Cheers, S > >> Barry > > -derek > From matake@gmail.com Wed Jan 9 15:40:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204D11E80AE for ; Wed, 9 Jan 2013 15:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMmtFk1raxiW for ; Wed, 9 Jan 2013 15:40:30 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA5BA11E80AD for ; Wed, 9 Jan 2013 15:40:30 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rp2so1257809pbb.29 for ; Wed, 09 Jan 2013 15:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=s2ELMvBV2ndmXk+vDhH8genoB89Z8CvtZv5Lap1IA2Y=; b=s0oOfjjVDpVWTs5nNnQEXPsJCw2dywrRtSOd+pjKmjYBYGEHvkDmeXNAM9hwBPBBNU AkJUCnCc2QkBkMT9z0sJfDHo9s/A06j8ACAcKhPm4K6dHj+xwn8CxVvzNuj9rBKcrB1C +yFgElo38TWLflUNFEWV/VdxDMnU4R/BKNyYGxReV1SyDxRgFGjfWHegKvZF8E7pYbBW 619yj2h8sF0X+SRIQMUIECxs/y/wFwpLaxQSQmLXDksafRzWTbTrCHotkhiSVz/DMQHY 9Z4PSJfu2jqdUT2Ae5HH51UWIow49vuA0HhAdVN4Sw2no75A5Ws1wYlByT6ccxoKze/q PbHA== X-Received: by 10.66.79.66 with SMTP id h2mr194213795pax.31.1357774830298; Wed, 09 Jan 2013 15:40:30 -0800 (PST) Received: from [192.168.1.31] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id bf3sm80192pab.12.2013.01.09.15.40.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jan 2013 15:40:28 -0800 (PST) References: <20130108011935.22098B1E007@rfc-editor.org> <50EDFC42.40800@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <50EDFC42.40800@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <81FBD272-933E-4244-BD37-F7A2884E8ACC@gmail.com> X-Mailer: iPhone Mail (10A551) From: nov matake Date: Thu, 10 Jan 2013 08:40:23 +0900 To: Stephen Farrell Cc: "nov@matake.jp" , Barry Leiba , Derek Atkins , OAuth WG , RFC Errata System Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:40:31 -0000 thanks! nov On Jan 10, 2013, at 8:24 AM, Stephen Farrell wro= te: >=20 >=20 > On 01/09/2013 11:02 PM, Derek Atkins wrote: >> Barry Leiba writes: >>=20 >>>> Corrected Text >>>> -------------- >>>> Resource owners cannot revoke access to an individual third party witho= ut revoking access >>>> to all third parties, and must do so by changing their password. >>>>=20 >>>> Notes >>>> ----- >>>> The text was originally "their" but changed to "the third party's" betw= een the last draft and RFC. >>>> However, "their" means "resource owners'", not "the third party's". >>>=20 >>> Yes, this appears to be a change the RFC Editor made that the authors >>> didn't notice in AUTH48. But the RFC Editor change it from "their" >>> because "their" wasn't clear. Changing it back to "their" won't help >>> that. I suggest editing the corrected text to "by changing the >>> resource owner's password" before marking this as Verified. >>=20 >> Yep, I suggested that same change in a private email to Stephen, so I >> would prefer this modification. >=20 > Ok, assuming nobody objects I'll verify this that way tomorrow. >=20 > Cheers, > S >=20 >>=20 >>> Barry >>=20 >> -derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Wed Jan 9 22:28:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206B521F869F for ; Wed, 9 Jan 2013 22:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pSN+ocantIH for ; Wed, 9 Jan 2013 22:28:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B72AF21F8681 for ; Wed, 9 Jan 2013 22:28:27 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M7FLk-1T5BVc1goQ-00x3te for ; Thu, 10 Jan 2013 07:28:26 +0100 Received: (qmail invoked by alias); 10 Jan 2013 06:28:26 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 10 Jan 2013 07:28:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZuGFVcQwZlEvGAZnw695ghbuttDwohk8axImszN UjioO1iom5YrM2 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A097E6@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 10 Jan 2013 08:28:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57457A75-394C-487B-AF54-CB7A0948E703@gmx.net> References: <20130107214016.94851B1E007@rfc-editor.org> <4E1F6AAD24975D4BA5B168042967394366A097E6@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 06:28:29 -0000 Thanks for the hard work! On Jan 9, 2013, at 11:51 PM, Mike Jones wrote: > Congratulations on this achievement, guys! >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of rfc-editor@rfc-editor.org > Sent: Monday, January 07, 2013 1:40 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: oauth@ietf.org; rfc-editor@rfc-editor.org > Subject: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security = Considerations >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6819 >=20 > Title: OAuth 2.0 Threat Model and=20 > Security Considerations=20 > Author: T. Lodderstedt, Ed., > M. McGloin,=20 > P. Hunt > Status: Informational > Stream: IETF > Date: January 2013 > Mailbox: torsten@lodderstedt.net,=20 > mark.mcgloin@ie.ibm.com,=20 > phil.hunt@yahoo.com > Pages: 71 > Characters: 158332 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-oauth-v2-threatmodel-08.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6819.txt >=20 > This document gives additional security considerations for OAuth, = beyond those in the OAuth 2.0 specification, based on a comprehensive = threat model for the OAuth 2.0 protocol. This document is not an = Internet Standards Track specification; it is published for = informational purposes. >=20 > This document is a product of the Web Authorization Protocol Working = Group of the IETF. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet = community. > It does not specify an Internet standard of any kind. Distribution of = this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the = author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless = specifically noted otherwise on the RFC itself, all RFCs are for = unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jan 9 22:29:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC0121F8698 for ; Wed, 9 Jan 2013 22:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI8rcOG62s6F for ; Wed, 9 Jan 2013 22:29:15 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0817721F8681 for ; Wed, 9 Jan 2013 22:29:14 -0800 (PST) Received: from [80.187.97.83] (helo=[100.90.146.180]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TtBdU-0006TV-Pl; Thu, 10 Jan 2013 07:29:10 +0100 Date: Thu, 10 Jan 2013 07:29:05 +0100 Message-ID: Importance: normal From: Torsten Lodderstedt To: Michael.Jones@microsoft.com, phil.hunt@oracle.com, mark.mcgloin@ie.ibm.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1399802362359170" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] RFC 6819 on OAuth 2.0 Threat Model and Security Considerations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Torsten Lodderstedt List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 06:29:17 -0000 ----_com.android.email_1399802362359170 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIcKgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiBoYXQgZ2Vz Y2hyaWViZW46Q29uZ3JhdHVsYXRpb25zIG9uIHRoaXMgYWNoaWV2ZW1lbnQsIGd1eXMhCgotLSBN aWtlCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJmYy1lZGl0 b3JAcmZjLWVkaXRvci5vcmcKU2VudDogTW9uZGF5LCBKYW51YXJ5IDA3LCAyMDEzIDE6NDAgUE0K VG86IGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc7IHJmYy1kaXN0QHJmYy1lZGl0b3Iub3JnCkNjOiBv YXV0aEBpZXRmLm9yZzsgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZwpTdWJqZWN0OiBbT0FVVEgt V0ddIFJGQyA2ODE5IG9uIE9BdXRoIDIuMCBUaHJlYXQgTW9kZWwgYW5kIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zCgoKQSBuZXcgUmVxdWVzdCBmb3IgQ29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBp biBvbmxpbmUgUkZDIGxpYnJhcmllcy4KCsKgwqDCoMKgwqDCoMKgIArCoMKgwqDCoMKgwqDCoCBS RkMgNjgxOQoKwqDCoMKgwqDCoMKgwqAgVGl0bGU6wqDCoMKgwqDCoCBPQXV0aCAyLjAgVGhyZWF0 IE1vZGVsIGFuZCAKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgCsKgwqDCoMKgwqDCoMKgIEF1dGhvcjrCoMKgwqDCoCBULiBMb2Rk ZXJzdGVkdCwgRWQuLArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBNLiBN Y0dsb2luLCAKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUC4gSHVudArC oMKgwqDCoMKgwqDCoCBTdGF0dXM6wqDCoMKgwqAgSW5mb3JtYXRpb25hbArCoMKgwqDCoMKgwqDC oCBTdHJlYW06wqDCoMKgwqAgSUVURgrCoMKgwqDCoMKgwqDCoCBEYXRlOsKgwqDCoMKgwqDCoCBK YW51YXJ5IDIwMTMKwqDCoMKgwqDCoMKgwqAgTWFpbGJveDrCoMKgwqAgdG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQsIArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBtYXJrLm1j Z2xvaW5AaWUuaWJtLmNvbSwgCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHBoaWwuaHVudEB5YWhvby5jb20KwqDCoMKgwqDCoMKgwqAgUGFnZXM6wqDCoMKgwqDCoCA3MQrC oMKgwqDCoMKgwqDCoCBDaGFyYWN0ZXJzOiAxNTgzMzIKwqDCoMKgwqDCoMKgwqAgVXBkYXRlcy9P YnNvbGV0ZXMvU2VlQWxzbzrCoMKgIE5vbmUKCsKgwqDCoMKgwqDCoMKgIEktRCBUYWc6wqDCoMKg IGRyYWZ0LWlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwtMDgudHh0CgrCoMKgwqDCoMKgwqDCoCBV Ukw6wqDCoMKgwqDCoMKgwqAgaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNjgxOS50 eHQKClRoaXMgZG9jdW1lbnQgZ2l2ZXMgYWRkaXRpb25hbCBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3IgT0F1dGgsIGJleW9uZCB0aG9zZSBpbiB0aGUgT0F1dGggMi4wIHNwZWNpZmljYXRpb24s IGJhc2VkIG9uIGEgY29tcHJlaGVuc2l2ZSB0aHJlYXQgbW9kZWwgZm9yIHRoZSBPQXV0aCAyLjAg cHJvdG9jb2wuwqAgVGhpcyBkb2N1bWVudCBpcyBub3QgYW4gSW50ZXJuZXQgU3RhbmRhcmRzIFRy YWNrIHNwZWNpZmljYXRpb247IGl0IGlzIHB1Ymxpc2hlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJw b3Nlcy4KClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBXZWIgQXV0aG9yaXphdGlv biBQcm90b2NvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLgoKCklORk9STUFUSU9OQUw6IFRo aXMgbWVtbyBwcm92aWRlcyBpbmZvcm1hdGlvbiBmb3IgdGhlIEludGVybmV0IGNvbW11bml0eS4K SXQgZG9lcyBub3Qgc3BlY2lmeSBhbiBJbnRlcm5ldCBzdGFuZGFyZCBvZiBhbnkga2luZC4gRGlz dHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuCgpUaGlzIGFubm91bmNlbWVudCBp cyBzZW50IHRvIHRoZSBJRVRGLUFubm91bmNlIGFuZCByZmMtZGlzdCBsaXN0cy4KVG8gc3Vic2Ny aWJlIG9yIHVuc3Vic2NyaWJlLCBzZWUKwqAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lldGYtYW5ub3VuY2UKwqAgaHR0cDovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFp bG1hbi9saXN0aW5mby9yZmMtZGlzdAoKRm9yIHNlYXJjaGluZyB0aGUgUkZDIHNlcmllcywgc2Vl IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjc2VhcmNoLmh0bWwuCkZvciBkb3dubG9hZGlu ZyBSRkNzLCBzZWUgaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMuaHRtbC4KClJlcXVlc3Rz IGZvciBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUgYWRkcmVzc2VkIHRvIGVpdGhlciB0 aGUgYXV0aG9yIG9mIHRoZSBSRkMgaW4gcXVlc3Rpb24sIG9yIHRvIHJmYy1lZGl0b3JAcmZjLWVk aXRvci5vcmcuwqAgVW5sZXNzIHNwZWNpZmljYWxseSBub3RlZCBvdGhlcndpc2Ugb24gdGhlIFJG QyBpdHNlbGYsIGFsbCBSRkNzIGFyZSBmb3IgdW5saW1pdGVkIGRpc3RyaWJ1dGlvbi4KCgpUaGUg UkZDIEVkaXRvciBUZWFtCkFzc29jaWF0aW9uIE1hbmFnZW1lbnQgU29sdXRpb25zLCBMTEMKCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0aCBtYWls aW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo= ----_com.android.email_1399802362359170 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+VGhhbmtzISZuYnNwOzxicj5NaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7IGhhdCBnZXNjaHJpZWJl bjo8YnI+Q29uZ3JhdHVsYXRpb25zIG9uIHRoaXMgYWNoaWV2ZW1lbnQsIGd1eXMhPGJyPjxicj4J CQkJLS0gTWlrZTxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogb2F1 dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPGJyPlNlbnQ6IE1vbmRheSwgSmFudWFy eSAwNywgMjAxMyAxOjQwIFBNPGJyPlRvOiBpZXRmLWFubm91bmNlQGlldGYub3JnOyByZmMtZGlz dEByZmMtZWRpdG9yLm9yZzxicj5DYzogb2F1dGhAaWV0Zi5vcmc7IHJmYy1lZGl0b3JAcmZjLWVk aXRvci5vcmc8YnI+U3ViamVjdDogW09BVVRILVdHXSBSRkMgNjgxOSBvbiBPQXV0aCAyLjAgVGhy ZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxicj48YnI+PGJyPkEgbmV3IFJl cXVlc3QgZm9yIENvbW1lbnRzIGlzIG5vdyBhdmFpbGFibGUgaW4gb25saW5lIFJGQyBsaWJyYXJp ZXMuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSRkMgNjgxOTxicj48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCA8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQXV0aG9yOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBULiBMb2RkZXJz dGVkdCwgRWQuLDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTS4gTWNHbG9pbiwgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQLiBIdW50PGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEluZm9ybWF0aW9uYWw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFN0cmVhbTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUVURjxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZTombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSmFudWFyeSAyMDEzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBNYWlsYm94OiZuYnNwOyZuYnNwOyZuYnNwOyB0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldCwgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBtYXJrLm1jZ2xvaW5AaWUuaWJtLmNvbSwgPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaGlsLmh1 bnRAeWFob28uY29tPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBQYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzE8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYXJhY3RlcnM6IDE1ODMzMjxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXBkYXRlcy9PYnNvbGV0ZXMv U2VlQWxzbzombmJzcDsmbmJzcDsgTm9uZTxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEktRCBUYWc6Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYt b2F1dGgtdjItdGhyZWF0bW9kZWwtMDgudHh0PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2ODE5LnR4dDxicj48 YnI+VGhpcyBkb2N1bWVudCBnaXZlcyBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGZvciBPQXV0aCwgYmV5b25kIHRob3NlIGluIHRoZSBPQXV0aCAyLjAgc3BlY2lmaWNhdGlvbiwg YmFzZWQgb24gYSBjb21wcmVoZW5zaXZlIHRocmVhdCBtb2RlbCBmb3IgdGhlIE9BdXRoIDIuMCBw cm90b2NvbC4mbmJzcDsgVGhpcyBkb2N1bWVudCBpcyBub3QgYW4gSW50ZXJuZXQgU3RhbmRhcmRz IFRyYWNrIHNwZWNpZmljYXRpb247IGl0IGlzIHB1Ymxpc2hlZCBmb3IgaW5mb3JtYXRpb25hbCBw dXJwb3Nlcy48YnI+PGJyPlRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBXZWIgQXV0 aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj48YnI+PGJy PklORk9STUFUSU9OQUw6IFRoaXMgbWVtbyBwcm92aWRlcyBpbmZvcm1hdGlvbiBmb3IgdGhlIElu dGVybmV0IGNvbW11bml0eS48YnI+SXQgZG9lcyBub3Qgc3BlY2lmeSBhbiBJbnRlcm5ldCBzdGFu ZGFyZCBvZiBhbnkga2luZC4gRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQu PGJyPjxicj5UaGlzIGFubm91bmNlbWVudCBpcyBzZW50IHRvIHRoZSBJRVRGLUFubm91bmNlIGFu ZCByZmMtZGlzdCBsaXN0cy48YnI+VG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlLCBzZWU8YnI+ Jm5ic3A7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNl PGJyPiZuYnNwOyBodHRwOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JmYy1kaXN0PGJyPjxicj5Gb3Igc2VhcmNoaW5nIHRoZSBSRkMgc2VyaWVzLCBzZWUgaHR0cDov L3d3dy5yZmMtZWRpdG9yLm9yZy9yZmNzZWFyY2guaHRtbC48YnI+Rm9yIGRvd25sb2FkaW5nIFJG Q3MsIHNlZSBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy5odG1sLjxicj48YnI+UmVxdWVz dHMgZm9yIHNwZWNpYWwgZGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVy IHRoZSBhdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVzdGlvbiwgb3IgdG8gcmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZy4mbmJzcDsgVW5sZXNzIHNwZWNpZmljYWxseSBub3RlZCBvdGhlcndpc2Ugb24g dGhlIFJGQyBpdHNlbGYsIGFsbCBSRkNzIGFyZSBmb3IgdW5saW1pdGVkIGRpc3RyaWJ1dGlvbi48 YnI+PGJyPjxicj5UaGUgUkZDIEVkaXRvciBUZWFtPGJyPkFzc29jaWF0aW9uIE1hbmFnZW1lbnQg U29sdXRpb25zLCBMTEM8YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8 YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48L2JvZHk+ ----_com.android.email_1399802362359170-- From cspzhouroc@comp.polyu.edu.hk Wed Jan 9 23:18:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E121F8799 for ; Wed, 9 Jan 2013 23:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMDXMCnrTD6G for ; Wed, 9 Jan 2013 23:18:43 -0800 (PST) Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0086A21F890D for ; Wed, 9 Jan 2013 23:18:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 7CC2650383 for ; Thu, 10 Jan 2013 15:18:38 +0800 (HKT) X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DsHEW8NpwrIu for ; Thu, 10 Jan 2013 15:18:36 +0800 (HKT) Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id EBF7B503A3 for ; Thu, 10 Jan 2013 15:18:36 +0800 (HKT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ede66aaf18a739ab069cd63457f2b07f" Date: Thu, 10 Jan 2013 15:18:37 +0800 From: cspzhouroc To: In-Reply-To: <50EDAAFE.3050300@mitre.org> References: <50EDAAFE.3050300@mitre.org> Message-ID: <3e3e5aae3fdb16e72c26c64809f3165d@comp.polyu.edu.hk> X-Sender: cspzhouroc@comp.polyu.edu.hk User-Agent: RoundCube Webmail/10.5 Subject: Re: [OAUTH-WG] =?utf-8?b?562U5aSNOiBSZTogIEEgcXVlc3Rpb24gb2YgMS4zLjEu?= =?utf-8?q?_Authorization_Code_in_rfc6749_The_OAuth_2=2E0_Authorization_Fr?= =?utf-8?q?amework?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:18:45 -0000 --=_ede66aaf18a739ab069cd63457f2b07f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Dear Justin: Your answer is comprehensive and very helpful :-) Great thanks :-) Best Regards Brent On Wed, 9 Jan 2013 12:38:06 -0500, Justin Richer wrote: > Brent, > > If you're sending the code in the back channel directly to the Client, > as I believe you're doing from your text below, I would like you to > realize some things: > > 1) This is not OAuth, and is in fact antithetical to the OAuth way of > solving the connection problem. > 2) You are actually lowering your overall security because the access > code is no longer bound to any particular browser session with either > the client or the AS. > 3) If you're sending it directly, there is no longer any point of using > the code, since the Client is just going to turn around and send it to > the AS again to get a token. Why not just send the token? But again, > this is still not OAuth. > > Think about it this way: There are three connections in the common OAuth > Authorization Code scenario, which is why it's known as a three-legged > OAuth flow in many circles. Each of these legs has unique properties, is > protected by different things, and is exposed to different pieces of > knowledge at different times. > > 1) Client User Agent: protected by a local session of the Client's > choosing. For Web based clients this is often standard HTTP session > cookies or similar, potentially backed by a login of some type by the > user to the Client as well. This session is never exposed to the > Authorization Server. > 2) Authorization Server User Agent: protected by a local session of > the Authorization Server's choosing, normally through some kind of > Primary Credential (login) that the user has a the AS. Importantly, > these credentials are never exposed to the Client. > 3) Client Authorization Server: protected by the client credentials, > which are, importantly, not exposed to the user or user agent. > > By sending the code as part of the redirect, the Client is able to prove > that the User Agent actually went to the Authorization Server (2) and > got something. The Authorization Code is then sent through the bottom > leg (3) of the channel to verify that it really did come from the > Authorization Server in the context of the user that was just there in > (1). In other words, this mechanism that you seem to be avoiding is > exactly what makes OAuth secure. > > If you instead send the code through (3), then the Client as no way at > all of knowing that the user in (1) ever went to the authorization > server via (2). All the Client knows is that they sent the user > someplace and that a magic code showed up. It is very, very, very > dangerous and a very, very bad idea to assume that a code coming in the > back channel (3) has anything at all to do with any particular session (1). > > This approach does *not* mitigate any real security threats, and in fact > introduces a great number of others, as described here. There are much > better ways to protect the Authorization Code, and most of the best > practices are enumerated in the security considerations document. Some > of the most common are: > > 1) Make Authorization Codes one-time-use (even if you try and fail, it's > thrown away) > 2) Make Authorization Codes time out after a very short period (minutes > or seconds) > > I hope this helps. > > -- Justin > > On 01/09/2013 01:42 AM, Peng Zhou wrote: >> Dear SuJing: >> >> If it is the only reason, why we send the authorization code to the >> client directly and send another notification without the >> authorization code to the RO. This way can mitigate the chance that >> the authorization code is exposed to the RO's user-agent, hence >> protecting the authorization code from leaking to possible attackers >> in a higher security levle. >> >> Best Regards >> Brent >> >> 2013/1/9 : >> >>> Then why not let auth code be sent directly from AS to Client? >>> >>> Just want to inform RO that an auth code has been dilivered to Client? >>> >>> oauth-bounces@ietf.org [8] 2013-01-09 14:27:50: >>> >>>> Hi Brent, >>>> >>>> Few points, why this doesn't create any security implications.. >>>> >>>> 1. Authorization server maintains a binding to the Client, who the >>>> token was issued to. To exchange this to an Access token client >>>> should authenticate him self. >>>> 2. Code can only be exchanged once for an acces token. >>>> >>>> Thanks & regards, >>>> -Prabath >>>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote: >>>> Dear All: >>>> >>>> I have a question in the section 1.3.1. Authorization Code in rfc6749 >>>> The OAuth 2.0 Authorization Framework. >>>> >>>> It tells "which in turn directs the resource owner back to the client >>>> with the authorization code." >>>> >>>> Who can let me know the reason why is the authorization code sent to >>>> client through a redirection in resource owner's agent? Any security >>>> implications? >>>> >>>> Is it possible to let the authorization server send the authorization >>>> code to the client directly (not through resource owner's user-agent)? >>>> >>>> Best Regards >>>> Brent >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org [2] >>>> https://www.ietf.org/mailman/listinfo/oauth [3] >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com [4] >>>> http://RampartFAQ.com_______________________________________________ [5] >>>> OAuth mailing list >>>> OAuth@ietf.org [6] >>>> https://www.ietf.org/mailman/listinfo/oauth [7] >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org [10] >> https://www.ietf.org/mailman/listinfo/oauth [11] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org [12] > https://www.ietf.org/mailman/listinfo/oauth [13] Links: ------ [1] mailto:cspzhouroc@comp.polyu.edu.hk [2] mailto:OAuth@ietf.org [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://blog.facilelogin.com [5] http://RampartFAQ.com_______________________________________________ [6] mailto:OAuth@ietf.org [7] https://www.ietf.org/mailman/listinfo/oauth [8] mailto:oauth-bounces@ietf.org [9] mailto:zhou.sujing@zte.com.cn [10] mailto:OAuth@ietf.org [11] https://www.ietf.org/mailman/listinfo/oauth [12] mailto:OAuth@ietf.org [13] https://www.ietf.org/mailman/listinfo/oauth --=_ede66aaf18a739ab069cd63457f2b07f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear Justin:

 

Your answer is comprehensive and very helpful :-)

Great thanks :-)

 

Best Regards

Brent

 

On Wed, 9 Jan 2013 12:38:06 -0500, Justin Richer wrote:

Brent,

If you're sending the code in the back channel direc=
tly to the Client,
as I believe you're doing from your text below, I w=
ould like you to
realize some things:

1) This is not OAuth,=
 and is in fact antithetical to the OAuth way of
solving the connectio=
n problem.
2) You are actually lowering your overall security because =
the access
code is no longer bound to any particular browser session w=
ith either
the client or the AS.
3) If you're sending it directly=
, there is no longer any point of using
the code, since the Client is =
just going to turn around and send it to
the AS again to get a token=
=2E Why not just send the token? But again,
this is still not OAuth.

Think about it this way: There are three connections in the=
 common OAuth
Authorization Code scenario, which is why it's known as =
a three-legged
OAuth flow in many circles. Each of these legs has uniq=
ue properties, is
protected by different things, and is exposed to dif=
ferent pieces of
knowledge at different times.

1) Client &l=
t;-> User Agent: protected by a local session of the Client's
choos=
ing. For Web based clients this is often standard HTTP session
cookies=
 or similar, potentially backed by a login of some type by the
user to=
 the Client as well. This session is never exposed to the
Authorizatio=
n Server.
2) Authorization Server <-> User Agent: protected by a=
 local session of
the Authorization Server's choosing, normally throug=
h some kind of
Primary Credential (login) that the user has a the AS=
=2E Importantly,
these credentials are never exposed to the Client.3) Client <-> Authorization Server: protected by the client creden=
tials,
which are, importantly, not exposed to the user or user agent=
=2E

By sending the code as part of the redirect, the Client is a=
ble to prove
that the User Agent actually went to the Authorization Se=
rver (2) and
got something. The Authorization Code is then sent throug=
h the bottom
leg (3) of the channel to verify that it really did come =
from the
Authorization Server in the context of the user that was just=
 there in
(1). In other words, this mechanism that you seem to be avoi=
ding is
exactly what makes OAuth secure.

If you instead sen=
d the code through (3), then the Client as no way at
all of knowing th=
at the user in (1) ever went to the authorization
server via (2). All =
the Client knows is that they sent the user
someplace and that a magic=
 code showed up. It is very, very, very
dangerous and a very, very bad=
 idea to assume that a code coming in the
back channel (3) has anythin=
g at all to do with any particular session (1).

This approach do=
es *not* mitigate any real security threats, and in fact
introduces a =
great number of others, as described here. There are much
better ways =
to protect the Authorization Code, and most of the best
practices are =
enumerated in the security considerations document. Some
of the most c=
ommon are:

1) Make Authorization Codes one-time-use (even if you=
 try and fail, it's
thrown away)
2) Make Authorization Codes time=
 out after a very short period (minutes
or seconds)


I=
 hope this helps.

-- Justin



On 01/09/2013=
 01:42 AM, Peng Zhou wrote:
Dear=
 SuJing:

If it is the only reason, why we send the authorization=
 code to the
client directly and send another notification without the=

authorization code to the RO. This way can mitigate the chance thatthe authorization code is exposed to the RO's user-agent, hence
pr=
otecting the authorization code from leaking to possible attackers
in =
a higher security levle.

Best Regards
Brent

2013=
/1/9  <zhou.sujing@zte.com.cn<=
/a>>:
Then why not let auth c=
ode be sent directly from AS to Client?

Just want to inform RO t=
hat an auth code has been dilivered to Client?

oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2013=
-01-09 14:27:50:

Hi Brent,=


Few points, why this doesn't create any security implications=
=2E.

1. Authorization server maintains a binding to the Client, =
who the
token was issued to. To exchange this to an Access token clien=
t
should authenticate him self.
2. Code can only be exchanged onc=
e for an acces token.

Thanks & regards,
-Prabath
O=
n Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <cspzhouroc@comp.polyu.edu.hk
wrote:
Dear All:

I have =
a question in the section 1.3.1. Authorization Code in rfc6749
The OAu=
th 2.0 Authorization Framework.

It tells "which in turn directs =
the resource owner back to the client
with the authorization code."
Who can let me know the reason why is the authorization code sent =
to
client through a redirection in resource owner's agent?  Any securi=
ty
implications?

Is it possible to let the authorization se=
rver send the authorization
code to the client directly (not through r=
esource owner's user-agent)?

Best Regards
Brent

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi=
nfo/oauth
--
Thanks & Regards,
Prabath

Mo=
bile : +94 71 809 6732

h=
ttp://blog.facilelogin.com
http://RampartFAQ.com____________=
___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth
___________________________________=
____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list<=
br />OAuth@ietf.org
https://www.ietf.org/mailman/li=
stinfo/oauth

 

--=_ede66aaf18a739ab069cd63457f2b07f-- From sberyozkin@gmail.com Thu Jan 10 03:05:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87F21F8678 for ; Thu, 10 Jan 2013 03:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JutHWo9SOv-2 for ; Thu, 10 Jan 2013 03:05:30 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id B7C1321F85A4 for ; Thu, 10 Jan 2013 03:05:29 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id ge1so379063lbb.12 for ; Thu, 10 Jan 2013 03:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nv0O3iM7HbvCpLZcx65/qMrJJsvKJJQUTQpIJWDzkfo=; b=BOHHWPgJiqJo1lr84xwprr6tcrr4s6vbgCXkFVKO31X/z7DXOJgH61ztLM2heH9Kcv sYYc07MXNIfYRbLgY1hPg2iSm+YvFyhwzlgE/TJAlkG5gA+9Qq9NJnU7GHaEngJQjrDA mKK8ZsBGm04j2dvhfFzujZsXeio1FdOaq0HCYyG0fEyhaeEh2WGTc6Sf1NnVqyLLyNst orSVgMtg4RkJz7DV57HGS3/cVToZNX33e5YSlV+FQVaygMrytOuqS35F/x7JFJGN+/XT c2MFU+MJpyKa1vQGJ508PgARDprdLf3G762QHisyMwaNlL7rm302O9qAvFANZt/bkFLK orOQ== X-Received: by 10.152.122.39 with SMTP id lp7mr68492548lab.0.1357815928181; Thu, 10 Jan 2013 03:05:28 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id hq9sm522370lab.8.2013.01.10.03.05.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 03:05:27 -0800 (PST) Message-ID: <50EEA074.20702@gmail.com> Date: Thu, 10 Jan 2013 11:05:24 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> In-Reply-To: <50EDE573.4090308@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 11:05:34 -0000 Hi On 09/01/13 21:47, George Fletcher wrote: > I had the same confusion about "what is 'audience' in OAuth?" today > working on a completely different project. > > I think for the default OAuth2 deployment, scopes take the place of > audience because the scopes identify the authorization grant(s) at the > resource servers affiliated with the Authorization Server. The client > can present the token to any resource server and if the necessary > authorization grant(s) are present, the protected resource is returned. > The client doesn't have to explicitly call out that it is going to > present the token to the 'mail service', it just needs to ask for the > 'readMail' scope. > That was my understanding too Cheers, Sergey > So, in regards to an AS implementation of the introspection endpoint, > what are the expectations for how the AS fills in the 'audience' field. > Should the AS not return the field if there is no audience? Should the > AS return "itself" as the audience? If a token has scopes of 'readMail > writeMail readBuddyList sendIM' then what is the correct 'audience' of > the token? Should it be an array of the resource servers that depend on > those scopes? > > I can see value in the chaining scenario of a client asking the AS for a > token that it will give to another party to present and storing that > intermediate party in the token. But for the default OAuth2 case, should > audience be omitted? or be the same value as 'client_id'? > > Thanks, > George > > On 1/9/13 3:15 PM, Richer, Justin P. wrote: >> >> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >> > wrote: >> >>> Hi Justin, >>> >>> Am 09.01.2013 um 20:35 schrieb Justin Richer >> >: >>> >>>> Thanks for the review, answers inline: >>>>> why is there a need for both scope and audience? I would assume the >>>>> scope of the authorization request is typically turned into an >>>>> audience of an access token. >>>> >>>> You can have an audience of a single server that has multiple >>>> scopes, or a single scope that's across multiple servers. Scope is >>>> an explicit construct in OAuth2, and while it is sometimes used for >>>> audience restriction purposes, they really are independent. Note >>>> that both of these are optional in the response -- if the AS has no >>>> notion of audience restriction in its stored token metadata, then it >>>> just doesn't return the "audience" field. >>> >>> You are making an interesting point here. To differentiate the >>> resource server and the permissions of a particular at this server >>> makes a lot of sense. BUT: the authorization request does not allow >>> the client to specify both in separate parameters. Instead both must >>> be folded into a single "scope" parameter. If I got your example >>> correctly, the scope of the request would be >>> >>> scope=myserver:read >>> >>> whereas the results of the introspection would be >>> >>> scope=read >>> audience=myserver >>> >>> It's probably the different semantics of scope that confused me. >> >> No, sorry if I was unclear: scope is scope, no different semantics. In >> this example case, you'd ask for scope=myserver:read and get back >> scope=myserver:read. I'm not suggesting that these be split up. Since >> the AS in this case knows that there's an audience, so it can return >> audience=myserver as well. The fact that it knows this through the >> scope mechanism is entirely system-dependent. >> >> I agree that the lack of a method for specifying audience does make >> returning this field a little odd for simple OAuth deployments, but >> since audience restriction is a big part of clustered and enterprise >> deployments (in my personal experience), then it's something very >> useful to have the server return. >> >>> >>>> >>>>> >>>>> Generally, wouldn't it be simpler (spec-wise) to just return a JWT >>>>> instead of inventing another set of JSON elements? >>>> >>>> What would be the utility in returning a JWT? The RS/client making >>>> the call isn't going to take these results and present them >>>> elsewhere, so I don't want to give the impression that it's a token. >>>> (This, incidentally, is one of the main problems I have with the >>>> Ping introspection approach, which uses the Token Endpoint and >>>> invents a "token type" as its return value.) Also, the resource >>>> server would have to parse the JWT instead of raw JSON, the latter >>>> of which is easier and far more common. Besides, I'd have to invent >>>> new claims for things like "valid" and "scopes" and what not, so I'd >>>> be extending JWT anyway. >>>> >>>> So while I think it's far preferable to use an actual JSON object, >>>> I'd be fine with re-using JWT claim names in the response if people >>>> prefer that. I tried to just use the expanded text since size >>>> constraints are not an issue outside of a JWT, so "issued_at" >>>> instead of "iat". >>>> >>>> Finally, note that this is *not* the same as the old OIDC CheckId >>>> endpoint which merely parsed and unwrapped the data inside the token >>>> itself. This mechanism works just as well with an unstructured token >>>> as input since the AS can store all of the token's metadata, like >>>> expiration, separately and use the token's value as a lookup key. >>> >>> I probably didn't describe well what I meant. I would suggest to >>> return a JWT claim set from the introspection endpoint. That way one >>> could use the same claims (e.g. iat instead of issued_at) for >>> structured and handle-based tokens. So the logic operating on the >>> token data could be the same. >>> >> >> OK, I follow you now. I'd be fine with re-using the JWT claim names >> and extending the namespace with the OAuth-specific parameters, like >> scope, that make sense here. >> >> -- Justin >> >>> regards, >>> Torsten. >>> >>>> >>>> -- Justin >>>> >>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>> >: >>>>> >>>>>> Updated the introspection draft with feedback from the UMA WG, who >>>>>> have incorporated it into their latest revision of UMA. >>>>>> >>>>>> I would like this document to become a working group item. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: New Version Notification for >>>>>> draft-richer-oauth-introspection-01.txt >>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>> From: >>>>>> To: >>>>>> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-richer-oauth-introspection >>>>>> Revision: 01 >>>>>> Title: OAuth Token Introspection >>>>>> Creation date: 2013-01-08 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>> >>>>>> Abstract: >>>>>> This specification defines a method for a client or protected >>>>>> resource to query an OAuth authorization server to determine meta- >>>>>> information about an OAuth token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Thu Jan 10 05:33:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E436021F87AC for ; Thu, 10 Jan 2013 05:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1lhv1mwDLUE for ; Thu, 10 Jan 2013 05:33:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id E0C7A21F87A3 for ; Thu, 10 Jan 2013 05:32:59 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MCeiK-1Tjyau2XB4-009Lj9 for ; Thu, 10 Jan 2013 14:32:58 +0100 Received: (qmail 11268 invoked by uid 0); 10 Jan 2013 13:32:58 -0000 Received: from 194.251.119.199 by www002.gmx.net with HTTP; Thu, 10 Jan 2013 14:32:56 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Thu, 10 Jan 2013 14:32:56 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20130110133256.50250@gmx.net> MIME-Version: 1.0 References: <20121203175642.17014.49025.idtracker@ietfa.amsl.com> To: Derek Atkins , oauth@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/1sVhUh+z1cRXuWb3af0Y4p61pAnaugBYu4aV/ri sxabMkcTGlQPsGD4cjOq5Vv/T9KLiNkjuzcg== Content-Transfer-Encoding: 8bit X-GMX-UID: X6accMVyeSEqMpIAqXUhpFl+IGRvbwA8 Subject: [OAUTH-WG] Reminder: OAuth WG Conference Call, 11 January 2013 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 13:33:01 -0000 We will have our next OAuth conference call tomorrow at 1pm EST (for roughly one hour). John & Nat kindly offered their conference bridge: https://www3.gotomeeting.com/join/695548174 Here are the notes from the last meeting: http://www.ietf.org/mail-archive/web/oauth/current/msg10279.html Here is the link to the updated document: http://tools.ietf.org/html/draft-tschofenig-oauth-security-01 Ciao Hannes & Derek From jricher@mitre.org Thu Jan 10 06:18:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD421F862E for ; Thu, 10 Jan 2013 06:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.445 X-Spam-Level: X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l7+UZaH+Kqh for ; Thu, 10 Jan 2013 06:18:34 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3B21F85EA for ; Thu, 10 Jan 2013 06:18:33 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC88E1F2EED; Thu, 10 Jan 2013 09:18:32 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 834E51F2EBD; Thu, 10 Jan 2013 09:18:32 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 09:18:32 -0500 Message-ID: <50EECDB4.3090708@mitre.org> Date: Thu, 10 Jan 2013 09:18:28 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: George Fletcher References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> In-Reply-To: <50EDE573.4090308@aol.com> Content-Type: multipart/alternative; boundary="------------060302090502040403040603" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 14:18:36 -0000 --------------060302090502040403040603 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason. As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend. So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't. -- Justin On 01/09/2013 04:47 PM, George Fletcher wrote: > I had the same confusion about "what is 'audience' in OAuth?" today > working on a completely different project. > > I think for the default OAuth2 deployment, scopes take the place of > audience because the scopes identify the authorization grant(s) at the > resource servers affiliated with the Authorization Server. The client > can present the token to any resource server and if the necessary > authorization grant(s) are present, the protected resource is > returned. The client doesn't have to explicitly call out that it is > going to present the token to the 'mail service', it just needs to ask > for the 'readMail' scope. > > So, in regards to an AS implementation of the introspection endpoint, > what are the expectations for how the AS fills in the 'audience' > field. Should the AS not return the field if there is no audience? > Should the AS return "itself" as the audience? If a token has scopes > of 'readMail writeMail readBuddyList sendIM' then what is the correct > 'audience' of the token? Should it be an array of the resource servers > that depend on those scopes? > > I can see value in the chaining scenario of a client asking the AS for > a token that it will give to another party to present and storing that > intermediate party in the token. But for the default OAuth2 case, > should audience be omitted? or be the same value as 'client_id'? > > Thanks, > George > > On 1/9/13 3:15 PM, Richer, Justin P. wrote: >> >> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >> > wrote: >> >>> Hi Justin, >>> >>> Am 09.01.2013 um 20:35 schrieb Justin Richer >> >: >>> >>>> Thanks for the review, answers inline: >>>>> why is there a need for both scope and audience? I would assume >>>>> the scope of the authorization request is typically turned into an >>>>> audience of an access token. >>>> >>>> You can have an audience of a single server that has multiple >>>> scopes, or a single scope that's across multiple servers. Scope is >>>> an explicit construct in OAuth2, and while it is sometimes used for >>>> audience restriction purposes, they really are independent. Note >>>> that both of these are optional in the response -- if the AS has no >>>> notion of audience restriction in its stored token metadata, then >>>> it just doesn't return the "audience" field. >>> >>> You are making an interesting point here. To differentiate the >>> resource server and the permissions of a particular at this server >>> makes a lot of sense. BUT: the authorization request does not allow >>> the client to specify both in separate parameters. Instead both must >>> be folded into a single "scope" parameter. If I got your example >>> correctly, the scope of the request would be >>> >>> scope=myserver:read >>> >>> whereas the results of the introspection would be >>> >>> scope=read >>> audience=myserver >>> >>> It's probably the different semantics of scope that confused me. >> >> No, sorry if I was unclear: scope is scope, no different semantics. >> In this example case, you'd ask for scope=myserver:read and get back >> scope=myserver:read. I'm not suggesting that these be split up. Since >> the AS in this case knows that there's an audience, so it can return >> audience=myserver as well. The fact that it knows this through the >> scope mechanism is entirely system-dependent. >> >> I agree that the lack of a method for specifying audience does make >> returning this field a little odd for simple OAuth deployments, but >> since audience restriction is a big part of clustered and enterprise >> deployments (in my personal experience), then it's something very >> useful to have the server return. >> >>> >>>> >>>>> >>>>> Generally, wouldn't it be simpler (spec-wise) to just return a JWT >>>>> instead of inventing another set of JSON elements? >>>> >>>> What would be the utility in returning a JWT? The RS/client making >>>> the call isn't going to take these results and present them >>>> elsewhere, so I don't want to give the impression that it's a >>>> token. (This, incidentally, is one of the main problems I have with >>>> the Ping introspection approach, which uses the Token Endpoint and >>>> invents a "token type" as its return value.) Also, the resource >>>> server would have to parse the JWT instead of raw JSON, the latter >>>> of which is easier and far more common. Besides, I'd have to invent >>>> new claims for things like "valid" and "scopes" and what not, so >>>> I'd be extending JWT anyway. >>>> >>>> So while I think it's far preferable to use an actual JSON object, >>>> I'd be fine with re-using JWT claim names in the response if people >>>> prefer that. I tried to just use the expanded text since size >>>> constraints are not an issue outside of a JWT, so "issued_at" >>>> instead of "iat". >>>> >>>> Finally, note that this is *not* the same as the old OIDC CheckId >>>> endpoint which merely parsed and unwrapped the data inside the >>>> token itself. This mechanism works just as well with an >>>> unstructured token as input since the AS can store all of the >>>> token's metadata, like expiration, separately and use the token's >>>> value as a lookup key. >>> >>> I probably didn't describe well what I meant. I would suggest to >>> return a JWT claim set from the introspection endpoint. That way one >>> could use the same claims (e.g. iat instead of issued_at) for >>> structured and handle-based tokens. So the logic operating on the >>> token data could be the same. >>> >> >> OK, I follow you now. I'd be fine with re-using the JWT claim names >> and extending the namespace with the OAuth-specific parameters, like >> scope, that make sense here. >> >> -- Justin >> >>> regards, >>> Torsten. >>> >>>> >>>> -- Justin >>>> >>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>> >: >>>>> >>>>>> Updated the introspection draft with feedback from the UMA WG, >>>>>> who have incorporated it into their latest revision of UMA. >>>>>> >>>>>> I would like this document to become a working group item. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: New Version Notification for >>>>>> draft-richer-oauth-introspection-01.txt >>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>> From: >>>>>> To: >>>>>> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-richer-oauth-introspection >>>>>> Revision: 01 >>>>>> Title: OAuth Token Introspection >>>>>> Creation date: 2013-01-08 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>> >>>>>> Abstract: >>>>>> This specification defines a method for a client or protected >>>>>> resource to query an OAuth authorization server to determine meta- >>>>>> information about an OAuth token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------060302090502040403040603 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

 -- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent. 

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

 -- Justin

regards,
Torsten.


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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


--------------060302090502040403040603-- From jricher@mitre.org Thu Jan 10 06:40:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACAC21F88BC for ; Thu, 10 Jan 2013 06:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73-QbB9yGP9g for ; Thu, 10 Jan 2013 06:40:50 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 073F421F88D1 for ; Thu, 10 Jan 2013 06:40:50 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 491BD1F3363; Thu, 10 Jan 2013 09:40:49 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 270245311545; Thu, 10 Jan 2013 09:40:49 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 09:40:48 -0500 Message-ID: <50EED2ED.80905@mitre.org> Date: Thu, 10 Jan 2013 09:40:45 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hannes Tschofenig References: <20121203175642.17014.49025.idtracker@ietfa.amsl.com> <20130110133256.50250@gmx.net> In-Reply-To: <20130110133256.50250@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Derek Atkins , oauth@ietf.org Subject: Re: [OAUTH-WG] Reminder: OAuth WG Conference Call, 11 January 2013 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 14:40:51 -0000 Use cases that I was asked to collect are detailed here: http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html -- Justin On 01/10/2013 08:32 AM, Hannes Tschofenig wrote: > We will have our next OAuth conference call tomorrow at 1pm EST (for roughly one hour). > > John & Nat kindly offered their conference bridge: > https://www3.gotomeeting.com/join/695548174 > > Here are the notes from the last meeting: > http://www.ietf.org/mail-archive/web/oauth/current/msg10279.html > > Here is the link to the updated document: > http://tools.ietf.org/html/draft-tschofenig-oauth-security-01 > > Ciao > Hannes & Derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Thu Jan 10 08:52:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827221F894E for ; Thu, 10 Jan 2013 08:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsFt1JNHMjwk for ; Thu, 10 Jan 2013 08:52:55 -0800 (PST) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63121F882B for ; Thu, 10 Jan 2013 08:52:54 -0800 (PST) Received: from mtaout-ma01.r1000.mx.aol.com (mtaout-ma01.r1000.mx.aol.com [172.29.41.1]) by imr-da03.mx.aol.com (Outbound Mail Relay) with ESMTP id 901411C000060; Thu, 10 Jan 2013 11:52:53 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2727EE0000CB; Thu, 10 Jan 2013 11:52:53 -0500 (EST) Message-ID: <50EEF1E4.1000200@aol.com> Date: Thu, 10 Jan 2013 11:52:52 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Justin Richer References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> <50EECDB4.3090708@mitre.org> In-Reply-To: <50EECDB4.3090708@mitre.org> Content-Type: multipart/alternative; boundary="------------080201000604010406070208" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357836773; bh=9/JCdBgpe065d02YLkxxculHLDVISShQCAWEEtJluGw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=w3DdqWsSkscYThNmdW5jrFaBYPasV8nMIHBsMRYJSm3DYtke0rv7D6h+3RTogd8Rs XoZz2rfdSpTXcfdtln7EcNB2S60N27rBx8OB3AOxkVc2GeWdPmJ/t/c32tKwuNmVNK gDELH9nwj9BT5OiQswQ+AzmxTNySvUCEZriZlHCw= X-AOL-SCOLL-SCORE: 0:2:504239616:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290150eef1e452f6 X-AOL-IP: 10.181.186.254 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:52:57 -0000 This is a multi-part message in MIME format. --------------080201000604010406070208 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit So in the default case I see two options for an AS that wants to implement this endpoint... 1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields. 2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id. Any thoughts as to which is the best option? For now I'm going with option 2. Thanks, George On 1/10/13 9:18 AM, Justin Richer wrote: > In traditional OAuth, there really isn't a baked-in notion of > 'audience' since the AS<->PR connection is completely out of scope. > However, in practice, when you've got more than one PR per AS, you'll > have some notion of 'audience'. It's definitely possible to handle > this with 'scope', especially if you want the client to have a say in > the matter. But since you could have your scopes and audiences defined > independently (one scope across several audiences, one audience with > many scopes, and any other combination thereof) I think it makes sense > to at least define a place for the AS to express this back to the PR. > JWT has the exact same claim for the exact same reason. > > As George points out below, this also really comes into play in the > chaining case, where you've got one PR calling another PR and you need > to keep things straight in a large backend. > > So while I agree it'd be better if OAuth had an 'audience' concept all > the way through, I don't think it should be precluded from the > introspection response just because it doesn't. > > -- Justin > > > On 01/09/2013 04:47 PM, George Fletcher wrote: >> I had the same confusion about "what is 'audience' in OAuth?" today >> working on a completely different project. >> >> I think for the default OAuth2 deployment, scopes take the place of >> audience because the scopes identify the authorization grant(s) at >> the resource servers affiliated with the Authorization Server. The >> client can present the token to any resource server and if the >> necessary authorization grant(s) are present, the protected resource >> is returned. The client doesn't have to explicitly call out that it >> is going to present the token to the 'mail service', it just needs to >> ask for the 'readMail' scope. >> >> So, in regards to an AS implementation of the introspection endpoint, >> what are the expectations for how the AS fills in the 'audience' >> field. Should the AS not return the field if there is no audience? >> Should the AS return "itself" as the audience? If a token has scopes >> of 'readMail writeMail readBuddyList sendIM' then what is the correct >> 'audience' of the token? Should it be an array of the resource >> servers that depend on those scopes? >> >> I can see value in the chaining scenario of a client asking the AS >> for a token that it will give to another party to present and storing >> that intermediate party in the token. But for the default OAuth2 >> case, should audience be omitted? or be the same value as 'client_id'? >> >> Thanks, >> George >> >> On 1/9/13 3:15 PM, Richer, Justin P. wrote: >>> >>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >>> > wrote: >>> >>>> Hi Justin, >>>> >>>> Am 09.01.2013 um 20:35 schrieb Justin Richer >>> >: >>>> >>>>> Thanks for the review, answers inline: >>>>>> why is there a need for both scope and audience? I would assume >>>>>> the scope of the authorization request is typically turned into >>>>>> an audience of an access token. >>>>> >>>>> You can have an audience of a single server that has multiple >>>>> scopes, or a single scope that's across multiple servers. Scope is >>>>> an explicit construct in OAuth2, and while it is sometimes used >>>>> for audience restriction purposes, they really are independent. >>>>> Note that both of these are optional in the response -- if the AS >>>>> has no notion of audience restriction in its stored token >>>>> metadata, then it just doesn't return the "audience" field. >>>> >>>> You are making an interesting point here. To differentiate the >>>> resource server and the permissions of a particular at this server >>>> makes a lot of sense. BUT: the authorization request does not allow >>>> the client to specify both in separate parameters. Instead both >>>> must be folded into a single "scope" parameter. If I got your >>>> example correctly, the scope of the request would be >>>> >>>> scope=myserver:read >>>> >>>> whereas the results of the introspection would be >>>> >>>> scope=read >>>> audience=myserver >>>> >>>> It's probably the different semantics of scope that confused me. >>> >>> No, sorry if I was unclear: scope is scope, no different semantics. >>> In this example case, you'd ask for scope=myserver:read and get back >>> scope=myserver:read. I'm not suggesting that these be split up. >>> Since the AS in this case knows that there's an audience, so it can >>> return audience=myserver as well. The fact that it knows this >>> through the scope mechanism is entirely system-dependent. >>> >>> I agree that the lack of a method for specifying audience does make >>> returning this field a little odd for simple OAuth deployments, but >>> since audience restriction is a big part of clustered and enterprise >>> deployments (in my personal experience), then it's something very >>> useful to have the server return. >>> >>>> >>>>> >>>>>> >>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a >>>>>> JWT instead of inventing another set of JSON elements? >>>>> >>>>> What would be the utility in returning a JWT? The RS/client making >>>>> the call isn't going to take these results and present them >>>>> elsewhere, so I don't want to give the impression that it's a >>>>> token. (This, incidentally, is one of the main problems I have >>>>> with the Ping introspection approach, which uses the Token >>>>> Endpoint and invents a "token type" as its return value.) Also, >>>>> the resource server would have to parse the JWT instead of raw >>>>> JSON, the latter of which is easier and far more common. Besides, >>>>> I'd have to invent new claims for things like "valid" and "scopes" >>>>> and what not, so I'd be extending JWT anyway. >>>>> >>>>> So while I think it's far preferable to use an actual JSON object, >>>>> I'd be fine with re-using JWT claim names in the response if >>>>> people prefer that. I tried to just use the expanded text since >>>>> size constraints are not an issue outside of a JWT, so "issued_at" >>>>> instead of "iat". >>>>> >>>>> Finally, note that this is *not* the same as the old OIDC CheckId >>>>> endpoint which merely parsed and unwrapped the data inside the >>>>> token itself. This mechanism works just as well with an >>>>> unstructured token as input since the AS can store all of the >>>>> token's metadata, like expiration, separately and use the token's >>>>> value as a lookup key. >>>> >>>> I probably didn't describe well what I meant. I would suggest to >>>> return a JWT claim set from the introspection endpoint. That way >>>> one could use the same claims (e.g. iat instead of issued_at) for >>>> structured and handle-based tokens. So the logic operating on the >>>> token data could be the same. >>>> >>> >>> OK, I follow you now. I'd be fine with re-using the JWT claim names >>> and extending the namespace with the OAuth-specific parameters, like >>> scope, that make sense here. >>> >>> -- Justin >>> >>>> regards, >>>> Torsten. >>>> >>>>> >>>>> -- Justin >>>>> >>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>>> >: >>>>>> >>>>>>> Updated the introspection draft with feedback from the UMA WG, >>>>>>> who have incorporated it into their latest revision of UMA. >>>>>>> >>>>>>> I would like this document to become a working group item. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: New Version Notification for >>>>>>> draft-richer-oauth-introspection-01.txt >>>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>>> From: >>>>>>> To: >>>>>>> >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-richer-oauth-introspection >>>>>>> Revision: 01 >>>>>>> Title: OAuth Token Introspection >>>>>>> Creation date: 2013-01-08 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification defines a method for a client or protected >>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>> information about an OAuth token. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > --------------080201000604010406070208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit So in the default case I see two options for an AS that wants to implement this endpoint...

1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields.

2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id.

Any thoughts as to which is the best option? For now I'm going with option 2.

Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

-- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent.

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

-- Justin

regards,
Torsten.


-- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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



--------------080201000604010406070208-- From jricher@mitre.org Thu Jan 10 08:53:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8E021F885C for ; Thu, 10 Jan 2013 08:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJSSi25XTta4 for ; Thu, 10 Jan 2013 08:53:51 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBEB21F882B for ; Thu, 10 Jan 2013 08:53:50 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 392571F0BB7; Thu, 10 Jan 2013 11:53:49 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2C42C1F0BA9; Thu, 10 Jan 2013 11:53:49 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 11:53:48 -0500 Message-ID: <50EEF219.2070708@mitre.org> Date: Thu, 10 Jan 2013 11:53:45 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: George Fletcher References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> <50EECDB4.3090708@mitre.org> <50EEF1E4.1000200@aol.com> In-Reply-To: <50EEF1E4.1000200@aol.com> Content-Type: multipart/alternative; boundary="------------020404010301050606040207" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:53:54 -0000 --------------020404010301050606040207 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit I'm leaning towards 1 because the client is more the "authorized presenter" of the token, not its audience. -- Justin On 01/10/2013 11:52 AM, George Fletcher wrote: > So in the default case I see two options for an AS that wants to > implement this endpoint... > > 1. Omit 'audience' from the response: The rationale here is that there > really isn't an explicit audience and what clients need to protect > against things like "confused deputy" is the client_id which is > already one of the response fields. > > 2. Make the 'audience' value the same as the 'client_id' value: The > rationale here is that the "audience" of the token is the entity for > which the token was minted which in the default OAuth2 case is the > client_id. > > Any thoughts as to which is the best option? For now I'm going with > option 2. > > Thanks, > George > > On 1/10/13 9:18 AM, Justin Richer wrote: >> In traditional OAuth, there really isn't a baked-in notion of >> 'audience' since the AS<->PR connection is completely out of scope. >> However, in practice, when you've got more than one PR per AS, you'll >> have some notion of 'audience'. It's definitely possible to handle >> this with 'scope', especially if you want the client to have a say in >> the matter. But since you could have your scopes and audiences >> defined independently (one scope across several audiences, one >> audience with many scopes, and any other combination thereof) I think >> it makes sense to at least define a place for the AS to express this >> back to the PR. JWT has the exact same claim for the exact same reason. >> >> As George points out below, this also really comes into play in the >> chaining case, where you've got one PR calling another PR and you >> need to keep things straight in a large backend. >> >> So while I agree it'd be better if OAuth had an 'audience' concept >> all the way through, I don't think it should be precluded from the >> introspection response just because it doesn't. >> >> -- Justin >> >> >> On 01/09/2013 04:47 PM, George Fletcher wrote: >>> I had the same confusion about "what is 'audience' in OAuth?" today >>> working on a completely different project. >>> >>> I think for the default OAuth2 deployment, scopes take the place of >>> audience because the scopes identify the authorization grant(s) at >>> the resource servers affiliated with the Authorization Server. The >>> client can present the token to any resource server and if the >>> necessary authorization grant(s) are present, the protected resource >>> is returned. The client doesn't have to explicitly call out that it >>> is going to present the token to the 'mail service', it just needs >>> to ask for the 'readMail' scope. >>> >>> So, in regards to an AS implementation of the introspection >>> endpoint, what are the expectations for how the AS fills in the >>> 'audience' field. Should the AS not return the field if there is no >>> audience? Should the AS return "itself" as the audience? If a token >>> has scopes of 'readMail writeMail readBuddyList sendIM' then what is >>> the correct 'audience' of the token? Should it be an array of the >>> resource servers that depend on those scopes? >>> >>> I can see value in the chaining scenario of a client asking the AS >>> for a token that it will give to another party to present and >>> storing that intermediate party in the token. But for the default >>> OAuth2 case, should audience be omitted? or be the same value as >>> 'client_id'? >>> >>> Thanks, >>> George >>> >>> On 1/9/13 3:15 PM, Richer, Justin P. wrote: >>>> >>>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >>>> > wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer >>>> >: >>>>> >>>>>> Thanks for the review, answers inline: >>>>>>> why is there a need for both scope and audience? I would assume >>>>>>> the scope of the authorization request is typically turned into >>>>>>> an audience of an access token. >>>>>> >>>>>> You can have an audience of a single server that has multiple >>>>>> scopes, or a single scope that's across multiple servers. Scope >>>>>> is an explicit construct in OAuth2, and while it is sometimes >>>>>> used for audience restriction purposes, they really are >>>>>> independent. Note that both of these are optional in the response >>>>>> -- if the AS has no notion of audience restriction in its stored >>>>>> token metadata, then it just doesn't return the "audience" field. >>>>> >>>>> You are making an interesting point here. To differentiate the >>>>> resource server and the permissions of a particular at this server >>>>> makes a lot of sense. BUT: the authorization request does not >>>>> allow the client to specify both in separate parameters. Instead >>>>> both must be folded into a single "scope" parameter. If I got your >>>>> example correctly, the scope of the request would be >>>>> >>>>> scope=myserver:read >>>>> >>>>> whereas the results of the introspection would be >>>>> >>>>> scope=read >>>>> audience=myserver >>>>> >>>>> It's probably the different semantics of scope that confused me. >>>> >>>> No, sorry if I was unclear: scope is scope, no different semantics. >>>> In this example case, you'd ask for scope=myserver:read and get >>>> back scope=myserver:read. I'm not suggesting that these be split >>>> up. Since the AS in this case knows that there's an audience, so it >>>> can return audience=myserver as well. The fact that it knows this >>>> through the scope mechanism is entirely system-dependent. >>>> >>>> I agree that the lack of a method for specifying audience does make >>>> returning this field a little odd for simple OAuth deployments, but >>>> since audience restriction is a big part of clustered and >>>> enterprise deployments (in my personal experience), then it's >>>> something very useful to have the server return. >>>> >>>>> >>>>>> >>>>>>> >>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a >>>>>>> JWT instead of inventing another set of JSON elements? >>>>>> >>>>>> What would be the utility in returning a JWT? The RS/client >>>>>> making the call isn't going to take these results and present >>>>>> them elsewhere, so I don't want to give the impression that it's >>>>>> a token. (This, incidentally, is one of the main problems I have >>>>>> with the Ping introspection approach, which uses the Token >>>>>> Endpoint and invents a "token type" as its return value.) Also, >>>>>> the resource server would have to parse the JWT instead of raw >>>>>> JSON, the latter of which is easier and far more common. Besides, >>>>>> I'd have to invent new claims for things like "valid" and >>>>>> "scopes" and what not, so I'd be extending JWT anyway. >>>>>> >>>>>> So while I think it's far preferable to use an actual JSON >>>>>> object, I'd be fine with re-using JWT claim names in the response >>>>>> if people prefer that. I tried to just use the expanded text >>>>>> since size constraints are not an issue outside of a JWT, so >>>>>> "issued_at" instead of "iat". >>>>>> >>>>>> Finally, note that this is *not* the same as the old OIDC CheckId >>>>>> endpoint which merely parsed and unwrapped the data inside the >>>>>> token itself. This mechanism works just as well with an >>>>>> unstructured token as input since the AS can store all of the >>>>>> token's metadata, like expiration, separately and use the token's >>>>>> value as a lookup key. >>>>> >>>>> I probably didn't describe well what I meant. I would suggest to >>>>> return a JWT claim set from the introspection endpoint. That way >>>>> one could use the same claims (e.g. iat instead of issued_at) for >>>>> structured and handle-based tokens. So the logic operating on the >>>>> token data could be the same. >>>>> >>>> >>>> OK, I follow you now. I'd be fine with re-using the JWT claim names >>>> and extending the namespace with the OAuth-specific parameters, >>>> like scope, that make sense here. >>>> >>>> -- Justin >>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>>>> >: >>>>>>> >>>>>>>> Updated the introspection draft with feedback from the UMA WG, >>>>>>>> who have incorporated it into their latest revision of UMA. >>>>>>>> >>>>>>>> I would like this document to become a working group item. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-richer-oauth-introspection-01.txt >>>>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>>>> From: >>>>>>>> To: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-richer-oauth-introspection >>>>>>>> Revision: 01 >>>>>>>> Title: OAuth Token Introspection >>>>>>>> Creation date: 2013-01-08 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 6 >>>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This specification defines a method for a client or protected >>>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>>> information about an OAuth token. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > --------------020404010301050606040207 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
I'm leaning towards 1 because the client is more the "authorized presenter" of the token, not its audience.

-- Justin

On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to implement this endpoint...

1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields.

2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id.

Any thoughts as to which is the best option? For now I'm going with option 2.

Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

-- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent.

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

-- Justin

regards,
Torsten.


-- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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




--------------020404010301050606040207-- From gffletch@aol.com Thu Jan 10 08:59:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A518721F894E for ; Thu, 10 Jan 2013 08:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqkMvSbvlqoz for ; Thu, 10 Jan 2013 08:59:38 -0800 (PST) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id B13F621F8939 for ; Thu, 10 Jan 2013 08:59:37 -0800 (PST) Received: from mtaout-ma02.r1000.mx.aol.com (mtaout-ma02.r1000.mx.aol.com [172.29.41.2]) by imr-ma03.mx.aol.com (Outbound Mail Relay) with ESMTP id 0ADCA1C0001BB; Thu, 10 Jan 2013 11:59:37 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3133CE0000B3; Thu, 10 Jan 2013 11:59:36 -0500 (EST) Message-ID: <50EEF377.8030207@aol.com> Date: Thu, 10 Jan 2013 11:59:35 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> <50EECDB4.3090708@mitre.org> <50EEF1E4.1000200@aol.com> <50EEF219.2070708@mitre.org> In-Reply-To: <50EEF219.2070708@mitre.org> Content-Type: multipart/alternative; boundary="------------090603030902060308070900" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357837176; bh=19a8Ydky0P7GpCMkYNnK0d/tYfW9U6NIV75PQ/hEIMQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ybLrzAggtjb13WcQ9CdwmftI8wMirkI0qBJB8UeoWIu1UaCHu3CLn32X/R76tp+12 rP1Us54dUNfDAsGsFM1xUqrrJ7V9B4B/aJosC7PB+dNQeYoHB9s5lr5riv+8kgRyeH eYWZE5CG2tkBHA1M3U6uIR/xWzvQjYLs4sl/SuPA= X-AOL-SCOLL-SCORE: 0:2:501499776:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290250eef3781d38 X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:59:39 -0000 This is a multi-part message in MIME format. --------------090603030902060308070900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit That makes sense as well:) Hopefully some others will chime in as I think this is an area that could use some "best practice" guidelines. Thanks, George On 1/10/13 11:53 AM, Justin Richer wrote: > I'm leaning towards 1 because the client is more the "authorized > presenter" of the token, not its audience. > > -- Justin > > On 01/10/2013 11:52 AM, George Fletcher wrote: >> So in the default case I see two options for an AS that wants to >> implement this endpoint... >> >> 1. Omit 'audience' from the response: The rationale here is that >> there really isn't an explicit audience and what clients need to >> protect against things like "confused deputy" is the client_id which >> is already one of the response fields. >> >> 2. Make the 'audience' value the same as the 'client_id' value: The >> rationale here is that the "audience" of the token is the entity for >> which the token was minted which in the default OAuth2 case is the >> client_id. >> >> Any thoughts as to which is the best option? For now I'm going with >> option 2. >> >> Thanks, >> George >> >> On 1/10/13 9:18 AM, Justin Richer wrote: >>> In traditional OAuth, there really isn't a baked-in notion of >>> 'audience' since the AS<->PR connection is completely out of scope. >>> However, in practice, when you've got more than one PR per AS, >>> you'll have some notion of 'audience'. It's definitely possible to >>> handle this with 'scope', especially if you want the client to have >>> a say in the matter. But since you could have your scopes and >>> audiences defined independently (one scope across several audiences, >>> one audience with many scopes, and any other combination thereof) I >>> think it makes sense to at least define a place for the AS to >>> express this back to the PR. JWT has the exact same claim for the >>> exact same reason. >>> >>> As George points out below, this also really comes into play in the >>> chaining case, where you've got one PR calling another PR and you >>> need to keep things straight in a large backend. >>> >>> So while I agree it'd be better if OAuth had an 'audience' concept >>> all the way through, I don't think it should be precluded from the >>> introspection response just because it doesn't. >>> >>> -- Justin >>> >>> >>> On 01/09/2013 04:47 PM, George Fletcher wrote: >>>> I had the same confusion about "what is 'audience' in OAuth?" today >>>> working on a completely different project. >>>> >>>> I think for the default OAuth2 deployment, scopes take the place of >>>> audience because the scopes identify the authorization grant(s) at >>>> the resource servers affiliated with the Authorization Server. The >>>> client can present the token to any resource server and if the >>>> necessary authorization grant(s) are present, the protected >>>> resource is returned. The client doesn't have to explicitly call >>>> out that it is going to present the token to the 'mail service', it >>>> just needs to ask for the 'readMail' scope. >>>> >>>> So, in regards to an AS implementation of the introspection >>>> endpoint, what are the expectations for how the AS fills in the >>>> 'audience' field. Should the AS not return the field if there is no >>>> audience? Should the AS return "itself" as the audience? If a token >>>> has scopes of 'readMail writeMail readBuddyList sendIM' then what >>>> is the correct 'audience' of the token? Should it be an array of >>>> the resource servers that depend on those scopes? >>>> >>>> I can see value in the chaining scenario of a client asking the AS >>>> for a token that it will give to another party to present and >>>> storing that intermediate party in the token. But for the default >>>> OAuth2 case, should audience be omitted? or be the same value as >>>> 'client_id'? >>>> >>>> Thanks, >>>> George >>>> >>>> On 1/9/13 3:15 PM, Richer, Justin P. wrote: >>>>> >>>>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >>>>> > wrote: >>>>> >>>>>> Hi Justin, >>>>>> >>>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer >>>>> >: >>>>>> >>>>>>> Thanks for the review, answers inline: >>>>>>>> why is there a need for both scope and audience? I would assume >>>>>>>> the scope of the authorization request is typically turned into >>>>>>>> an audience of an access token. >>>>>>> >>>>>>> You can have an audience of a single server that has multiple >>>>>>> scopes, or a single scope that's across multiple servers. Scope >>>>>>> is an explicit construct in OAuth2, and while it is sometimes >>>>>>> used for audience restriction purposes, they really are >>>>>>> independent. Note that both of these are optional in the >>>>>>> response -- if the AS has no notion of audience restriction in >>>>>>> its stored token metadata, then it just doesn't return the >>>>>>> "audience" field. >>>>>> >>>>>> You are making an interesting point here. To differentiate the >>>>>> resource server and the permissions of a particular at this >>>>>> server makes a lot of sense. BUT: the authorization request does >>>>>> not allow the client to specify both in separate parameters. >>>>>> Instead both must be folded into a single "scope" parameter. If I >>>>>> got your example correctly, the scope of the request would be >>>>>> >>>>>> scope=myserver:read >>>>>> >>>>>> whereas the results of the introspection would be >>>>>> >>>>>> scope=read >>>>>> audience=myserver >>>>>> >>>>>> It's probably the different semantics of scope that confused me. >>>>> >>>>> No, sorry if I was unclear: scope is scope, no different >>>>> semantics. In this example case, you'd ask for scope=myserver:read >>>>> and get back scope=myserver:read. I'm not suggesting that these be >>>>> split up. Since the AS in this case knows that there's an >>>>> audience, so it can return audience=myserver as well. The fact >>>>> that it knows this through the scope mechanism is entirely >>>>> system-dependent. >>>>> >>>>> I agree that the lack of a method for specifying audience does >>>>> make returning this field a little odd for simple OAuth >>>>> deployments, but since audience restriction is a big part of >>>>> clustered and enterprise deployments (in my personal experience), >>>>> then it's something very useful to have the server return. >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a >>>>>>>> JWT instead of inventing another set of JSON elements? >>>>>>> >>>>>>> What would be the utility in returning a JWT? The RS/client >>>>>>> making the call isn't going to take these results and present >>>>>>> them elsewhere, so I don't want to give the impression that it's >>>>>>> a token. (This, incidentally, is one of the main problems I have >>>>>>> with the Ping introspection approach, which uses the Token >>>>>>> Endpoint and invents a "token type" as its return value.) Also, >>>>>>> the resource server would have to parse the JWT instead of raw >>>>>>> JSON, the latter of which is easier and far more common. >>>>>>> Besides, I'd have to invent new claims for things like "valid" >>>>>>> and "scopes" and what not, so I'd be extending JWT anyway. >>>>>>> >>>>>>> So while I think it's far preferable to use an actual JSON >>>>>>> object, I'd be fine with re-using JWT claim names in the >>>>>>> response if people prefer that. I tried to just use the expanded >>>>>>> text since size constraints are not an issue outside of a JWT, >>>>>>> so "issued_at" instead of "iat". >>>>>>> >>>>>>> Finally, note that this is *not* the same as the old OIDC >>>>>>> CheckId endpoint which merely parsed and unwrapped the data >>>>>>> inside the token itself. This mechanism works just as well with >>>>>>> an unstructured token as input since the AS can store all of the >>>>>>> token's metadata, like expiration, separately and use the >>>>>>> token's value as a lookup key. >>>>>> >>>>>> I probably didn't describe well what I meant. I would suggest to >>>>>> return a JWT claim set from the introspection endpoint. That way >>>>>> one could use the same claims (e.g. iat instead of issued_at) for >>>>>> structured and handle-based tokens. So the logic operating on the >>>>>> token data could be the same. >>>>>> >>>>> >>>>> OK, I follow you now. I'd be fine with re-using the JWT claim >>>>> names and extending the namespace with the OAuth-specific >>>>> parameters, like scope, that make sense here. >>>>> >>>>> -- Justin >>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>>>>> >: >>>>>>>> >>>>>>>>> Updated the introspection draft with feedback from the UMA WG, >>>>>>>>> who have incorporated it into their latest revision of UMA. >>>>>>>>> >>>>>>>>> I would like this document to become a working group item. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> -------- Original Message -------- >>>>>>>>> Subject: New Version Notification for >>>>>>>>> draft-richer-oauth-introspection-01.txt >>>>>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>>>>> From: >>>>>>>>> To: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>>>> IETF repository. >>>>>>>>> >>>>>>>>> Filename: draft-richer-oauth-introspection >>>>>>>>> Revision: 01 >>>>>>>>> Title: OAuth Token Introspection >>>>>>>>> Creation date: 2013-01-08 >>>>>>>>> WG ID: Individual Submission >>>>>>>>> Number of pages: 6 >>>>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> This specification defines a method for a client or protected >>>>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>>>> information about an OAuth token. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF Secretariat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> > --------------090603030902060308070900 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit That makes sense as well:)

Hopefully some others will chime in as I think this is an area that could use some "best practice" guidelines.

Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning towards 1 because the client is more the "authorized presenter" of the token, not its audience.

-- Justin

On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to implement this endpoint...

1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields.

2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id.

Any thoughts as to which is the best option? For now I'm going with option 2.

Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

-- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent.

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

-- Justin

regards,
Torsten.


-- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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





--------------090603030902060308070900-- From vanni156@yahoo.com.vn Thu Jan 10 09:01:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BFA21F8992 for ; Thu, 10 Jan 2013 09:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjbn8jr7stZE for ; Thu, 10 Jan 2013 09:01:07 -0800 (PST) Received: from nm32-vm3.bullet.mail.bf1.yahoo.com (nm32-vm3.bullet.mail.bf1.yahoo.com [72.30.239.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9A21F89FC for ; Thu, 10 Jan 2013 09:01:06 -0800 (PST) Received: from [98.139.212.144] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2013 17:01:05 -0000 Received: from [98.136.86.249] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2013 17:01:05 -0000 Received: from [127.0.0.1] by smtp118-mob.biz.mail.ac4.yahoo.com with NNFMP; 10 Jan 2013 17:01:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.vn; s=s1024; t=1357837265; bh=H/Ni+5dFdklCrv8Fr7oJl0Cd7LRhBBQXEyygqi1Cy4M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:From:Date:Content-Type:MIME-Version; b=2HslQ4uERWf+Bi934fE40WsXmRGPviatlg1P5upi8QkoTyr3Jd2gHhya3Us1xAdQV2IebXn7NaLNK3PcMleNzZQSJhwxtYZUDJJnhutgA+RhZ/F/1Yw1aGZrE97FQBdKBIajpbiO7mfbXBVBz/oAdgLhVlmC2xk4sIquJAho3mE= X-Yahoo-Newman-Id: 324590.42633.bm@smtp118-mob.biz.mail.ac4.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p9zhaHsVM1n0XKb6UFDdnWTHXjj8mmaKOD8Q3jElN3KG3Ih dpMQZMvVAbIT6bL6YFS0Luf89V09d9cj6C.H7q3Dfh3THyEnzU8En_KecgW2 Yi7jtk3Ji04Jg3JSgJ8_c0xsG.rekco_32TepaVnJUbWar8BunaKOHW_C2.F tG7TGG3656ZUqYjLFcIcR1cyzkjADJPKlRa_5r_p.3zmYZPMLAsvpyXPN_Hf Ug8o1pRLz9IEBwGu_W69s4nXlKvK9MLWPIr3t8lZpMOBwACQahhkZuUf7jkg ebyKxklJZAX9PS_.h7PcqhR5mTc.UsM7EU5MTj4UhumL62D9l9LVXyBKb2IM gNmNP7cc1AZCqgt3NfJAY0DtTdUqih7jUXPVWtPu9BbiZltjOI0WRGZ4Tj3i ww4n6Sly4rcMf_3lWVvLuPdDVxE9UPGXdBt4zEbNQY483nltj4s.OnOBwIYk uYoRD6sl2hDg- X-Yahoo-SMTP: CQnEgimswBAaOuU_hrhhAc8WBEkC Received: from b15.c6.bise3.blackberry (vanni156@216.9.250.74 with xymcookie) by smtp118-mob.biz.mail.ac4.yahoo.com with SMTP; 10 Jan 2013 09:01:05 -0800 PST X-rim-org-msg-ref-id: 1146277199 Message-ID: <1146277199-1357837262-cardhu_decombobulator_blackberry.rim.net-1310810208-@b1.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal To: oauth@ietf.org From: "LuongKhanhVan" Date: Thu, 10 Jan 2013 17:03:42 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Digest, Vol 51, Issue 34 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: vanni156@yahoo.com.vn List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:01:09 -0000 DQpTZW50IGZyb20gbXkgQmxhY2tCZXJyea4gc21hcnRwaG9uZQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogb2F1dGgtcmVxdWVzdEBpZXRmLm9yZw0KU2VuZGVyOiBvYXV0aC1i b3VuY2VzQGlldGYub3JnDQpEYXRlOiBUaHUsIDEwIEphbiAyMDEzIDA4OjU5OjQwIA0KVG86IDxv YXV0aEBpZXRmLm9yZz4NClJlcGx5LVRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogT0F1dGgg RGlnZXN0LCBWb2wgNTEsIElzc3VlIDM0DQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZGln ZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UNCmF0dGFjaG1lbnRzIHlvdSB3 aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0DQpzdWJz Y3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8gDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlv bnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdl c3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBmb3IgYWxs IHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCg0KDQoNClNlbmQg T0F1dGggbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQoJb2F1dGhAaWV0Zi5vcmcNCg0KVG8g c3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQoJ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0Kb3IsIHZpYSBlbWFp bCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQoJb2F1dGgt cmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhl IGxpc3QgYXQNCglvYXV0aC1vd25lckBpZXRmLm9yZw0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2Ug ZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTog Q29udGVudHMgb2YgT0F1dGggZGlnZXN0Li4uIg0KDQoNClRvZGF5J3MgVG9waWNzOg0KDQogICAx LiBSZTogRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQogICAgICBkcmFmdC1yaWNo ZXItb2F1dGgtaW50cm9zcGVjdGlvbi0wMS50eHQgKEdlb3JnZSBGbGV0Y2hlcikNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6IFRodSwgMTAgSmFuIDIwMTMgMTE6NTk6MzUg LTA1MDANCkZyb206IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbT4NClRvOiAib2F1 dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KCWRyYWZ0LXJpY2hlci1vYXV0aC1pbnRy b3NwZWN0aW9uLTAxLnR4dA0KTWVzc2FnZS1JRDogPDUwRUVGMzc3LjgwMzAyMDdAYW9sLmNvbT4N CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0id2luZG93cy0xMjUyIjsgRm9ybWF0 PSJmbG93ZWQiDQoNClRoYXQgbWFrZXMgc2Vuc2UgYXMgd2VsbDopDQoNCkhvcGVmdWxseSBzb21l IG90aGVycyB3aWxsIGNoaW1lIGluIGFzIEkgdGhpbmsgdGhpcyBpcyBhbiBhcmVhIHRoYXQgDQpj b3VsZCB1c2Ugc29tZSAiYmVzdCBwcmFjdGljZSIgZ3VpZGVsaW5lcy4NCg0KVGhhbmtzLA0KR2Vv cmdlDQoNCk9uIDEvMTAvMTMgMTE6NTMgQU0sIEp1c3RpbiBSaWNoZXIgd3JvdGU6DQo+IEknbSBs ZWFuaW5nIHRvd2FyZHMgMSBiZWNhdXNlIHRoZSBjbGllbnQgaXMgbW9yZSB0aGUgImF1dGhvcml6 ZWQgDQo+IHByZXNlbnRlciIgb2YgdGhlIHRva2VuLCBub3QgaXRzIGF1ZGllbmNlLg0KPg0KPiAg LS0gSnVzdGluDQo+DQo+IE9uIDAxLzEwLzIwMTMgMTE6NTIgQU0sIEdlb3JnZSBGbGV0Y2hlciB3 cm90ZToNCj4+IFNvIGluIHRoZSBkZWZhdWx0IGNhc2UgSSBzZWUgdHdvIG9wdGlvbnMgZm9yIGFu IEFTIHRoYXQgd2FudHMgdG8gDQo+PiBpbXBsZW1lbnQgdGhpcyBlbmRwb2ludC4uLg0KPj4NCj4+ IDEuIE9taXQgJ2F1ZGllbmNlJyBmcm9tIHRoZSByZXNwb25zZTogVGhlIHJhdGlvbmFsZSBoZXJl IGlzIHRoYXQgDQo+PiB0aGVyZSByZWFsbHkgaXNuJ3QgYW4gZXhwbGljaXQgYXVkaWVuY2UgYW5k IHdoYXQgY2xpZW50cyBuZWVkIHRvIA0KPj4gcHJvdGVjdCBhZ2FpbnN0IHRoaW5ncyBsaWtlICJj b25mdXNlZCBkZXB1dHkiIGlzIHRoZSBjbGllbnRfaWQgd2hpY2ggDQo+PiBpcyBhbHJlYWR5IG9u ZSBvZiB0aGUgcmVzcG9uc2UgZmllbGRzLg0KPj4NCj4+IDIuIE1ha2UgdGhlICdhdWRpZW5jZScg dmFsdWUgdGhlIHNhbWUgYXMgdGhlICdjbGllbnRfaWQnIHZhbHVlOiBUaGUgDQo+PiByYXRpb25h bGUgaGVyZSBpcyB0aGF0IHRoZSAiYXVkaWVuY2UiIG9mIHRoZSB0b2tlbiBpcyB0aGUgZW50aXR5 IGZvciANCj4+IHdoaWNoIHRoZSB0b2tlbiB3YXMgbWludGVkIHdoaWNoIGluIHRoZSBkZWZhdWx0 IE9BdXRoMiBjYXNlIGlzIHRoZSANCj4+IGNsaWVudF9pZC4NCj4+DQo+PiBBbnkgdGhvdWdodHMg YXMgdG8gd2hpY2ggaXMgdGhlIGJlc3Qgb3B0aW9uPyBGb3Igbm93IEknbSBnb2luZyB3aXRoIA0K Pj4gb3B0aW9uIDIuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gR2VvcmdlDQo+Pg0KPj4gT24gMS8xMC8x MyA5OjE4IEFNLCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KPj4+IEluIHRyYWRpdGlvbmFsIE9BdXRo LCB0aGVyZSByZWFsbHkgaXNuJ3QgYSBiYWtlZC1pbiBub3Rpb24gb2YgDQo+Pj4gJ2F1ZGllbmNl JyBzaW5jZSB0aGUgQVM8LT5QUiBjb25uZWN0aW9uIGlzIGNvbXBsZXRlbHkgb3V0IG9mIHNjb3Bl LiANCj4+PiBIb3dldmVyLCBpbiBwcmFjdGljZSwgd2hlbiB5b3UndmUgZ290IG1vcmUgdGhhbiBv bmUgUFIgcGVyIEFTLCANCj4+PiB5b3UnbGwgaGF2ZSBzb21lIG5vdGlvbiBvZiAnYXVkaWVuY2Un LiBJdCdzIGRlZmluaXRlbHkgcG9zc2libGUgdG8gDQo+Pj4gaGFuZGxlIHRoaXMgd2l0aCAnc2Nv cGUnLCBlc3BlY2lhbGx5IGlmIHlvdSB3YW50IHRoZSBjbGllbnQgdG8gaGF2ZSANCj4+PiBhIHNh eSBpbiB0aGUgbWF0dGVyLiBCdXQgc2luY2UgeW91IGNvdWxkIGhhdmUgeW91ciBzY29wZXMgYW5k IA0KPj4+IGF1ZGllbmNlcyBkZWZpbmVkIGluZGVwZW5kZW50bHkgKG9uZSBzY29wZSBhY3Jvc3Mg c2V2ZXJhbCBhdWRpZW5jZXMsIA0KPj4+IG9uZSBhdWRpZW5jZSB3aXRoIG1hbnkgc2NvcGVzLCBh bmQgYW55IG90aGVyIGNvbWJpbmF0aW9uIHRoZXJlb2YpIEkgDQo+Pj4gdGhpbmsgaXQgbWFrZXMg c2Vuc2UgdG8gYXQgbGVhc3QgZGVmaW5lIGEgcGxhY2UgZm9yIHRoZSBBUyB0byANCj4+PiBleHBy ZXNzIHRoaXMgYmFjayB0byB0aGUgUFIuIEpXVCBoYXMgdGhlIGV4YWN0IHNhbWUgY2xhaW0gZm9y IHRoZSANCj4+PiBleGFjdCBzYW1lIHJlYXNvbi4NCj4+Pg0KPj4+IEFzIEdlb3JnZSBwb2ludHMg b3V0IGJlbG93LCB0aGlzIGFsc28gcmVhbGx5IGNvbWVzIGludG8gcGxheSBpbiB0aGUgDQo+Pj4g Y2hhaW5pbmcgY2FzZSwgd2hlcmUgeW91J3ZlIGdvdCBvbmUgUFIgY2FsbGluZyBhbm90aGVyIFBS IGFuZCB5b3UgDQo+Pj4gbmVlZCB0byBrZWVwIHRoaW5ncyBzdHJhaWdodCBpbiBhIGxhcmdlIGJh Y2tlbmQuDQo+Pj4NCj4+PiBTbyB3aGlsZSBJIGFncmVlIGl0J2QgYmUgYmV0dGVyIGlmIE9BdXRo IGhhZCBhbiAnYXVkaWVuY2UnIGNvbmNlcHQgDQo+Pj4gYWxsIHRoZSB3YXkgdGhyb3VnaCwgSSBk b24ndCB0aGluayBpdCBzaG91bGQgYmUgcHJlY2x1ZGVkIGZyb20gdGhlIA0KPj4+IGludHJvc3Bl Y3Rpb24gcmVzcG9uc2UganVzdCBiZWNhdXNlIGl0IGRvZXNuJ3QuDQo+Pj4NCj4+PiAgLS0gSnVz dGluDQo+Pj4NCj4+Pg0KPj4+IE9uIDAxLzA5LzIwMTMgMDQ6NDcgUE0sIEdlb3JnZSBGbGV0Y2hl ciB3cm90ZToNCj4+Pj4gSSBoYWQgdGhlIHNhbWUgY29uZnVzaW9uIGFib3V0ICJ3aGF0IGlzICdh dWRpZW5jZScgaW4gT0F1dGg/IiB0b2RheSANCj4+Pj4gd29ya2luZyBvbiBhIGNvbXBsZXRlbHkg ZGlmZmVyZW50IHByb2plY3QuDQo+Pj4+DQo+Pj4+IEkgdGhpbmsgZm9yIHRoZSBkZWZhdWx0IE9B dXRoMiBkZXBsb3ltZW50LCBzY29wZXMgdGFrZSB0aGUgcGxhY2Ugb2YgDQo+Pj4+IGF1ZGllbmNl IGJlY2F1c2UgdGhlIHNjb3BlcyBpZGVudGlmeSB0aGUgYXV0aG9yaXphdGlvbiBncmFudChzKSBh dCANCj4+Pj4gdGhlIHJlc291cmNlIHNlcnZlcnMgYWZmaWxpYXRlZCB3aXRoIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlci4gVGhlIA0KPj4+PiBjbGllbnQgY2FuIHByZXNlbnQgdGhlIHRva2VuIHRv IGFueSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGlmIHRoZSANCj4+Pj4gbmVjZXNzYXJ5IGF1dGhvcml6 YXRpb24gZ3JhbnQocykgYXJlIHByZXNlbnQsIHRoZSBwcm90ZWN0ZWQgDQo+Pj4+IHJlc291cmNl IGlzIHJldHVybmVkLiBUaGUgY2xpZW50IGRvZXNuJ3QgaGF2ZSB0byBleHBsaWNpdGx5IGNhbGwg DQo+Pj4+IG91dCB0aGF0IGl0IGlzIGdvaW5nIHRvIHByZXNlbnQgdGhlIHRva2VuIHRvIHRoZSAn bWFpbCBzZXJ2aWNlJywgaXQgDQo+Pj4+IGp1c3QgbmVlZHMgdG8gYXNrIGZvciB0aGUgJ3JlYWRN YWlsJyBzY29wZS4NCj4+Pj4NCj4+Pj4gU28sIGluIHJlZ2FyZHMgdG8gYW4gQVMgaW1wbGVtZW50 YXRpb24gb2YgdGhlIGludHJvc3BlY3Rpb24gDQo+Pj4+IGVuZHBvaW50LCB3aGF0IGFyZSB0aGUg ZXhwZWN0YXRpb25zIGZvciBob3cgdGhlIEFTIGZpbGxzIGluIHRoZSANCj4+Pj4gJ2F1ZGllbmNl JyBmaWVsZC4gU2hvdWxkIHRoZSBBUyBub3QgcmV0dXJuIHRoZSBmaWVsZCBpZiB0aGVyZSBpcyBu byANCj4+Pj4gYXVkaWVuY2U/IFNob3VsZCB0aGUgQVMgcmV0dXJuICJpdHNlbGYiIGFzIHRoZSBh dWRpZW5jZT8gSWYgYSB0b2tlbiANCj4+Pj4gaGFzIHNjb3BlcyBvZiAncmVhZE1haWwgd3JpdGVN YWlsIHJlYWRCdWRkeUxpc3Qgc2VuZElNJyB0aGVuIHdoYXQgDQo+Pj4+IGlzIHRoZSBjb3JyZWN0 ICdhdWRpZW5jZScgb2YgdGhlIHRva2VuPyBTaG91bGQgaXQgYmUgYW4gYXJyYXkgb2YgDQo+Pj4+ IHRoZSByZXNvdXJjZSBzZXJ2ZXJzIHRoYXQgZGVwZW5kIG9uIHRob3NlIHNjb3Blcz8NCj4+Pj4N Cj4+Pj4gSSBjYW4gc2VlIHZhbHVlIGluIHRoZSBjaGFpbmluZyBzY2VuYXJpbyBvZiBhIGNsaWVu dCBhc2tpbmcgdGhlIEFTIA0KPj4+PiBmb3IgYSB0b2tlbiB0aGF0IGl0IHdpbGwgZ2l2ZSB0byBh bm90aGVyIHBhcnR5IHRvIHByZXNlbnQgYW5kIA0KPj4+PiBzdG9yaW5nIHRoYXQgaW50ZXJtZWRp YXRlIHBhcnR5IGluIHRoZSB0b2tlbi4gQnV0IGZvciB0aGUgZGVmYXVsdCANCj4+Pj4gT0F1dGgy IGNhc2UsIHNob3VsZCBhdWRpZW5jZSBiZSBvbWl0dGVkPyBvciBiZSB0aGUgc2FtZSB2YWx1ZSBh cyANCj4+Pj4gJ2NsaWVudF9pZCc/DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gR2VvcmdlDQo+ Pj4+DQo+Pj4+IE9uIDEvOS8xMyAzOjE1IFBNLCBSaWNoZXIsIEp1c3RpbiBQLiB3cm90ZToNCj4+ Pj4+DQo+Pj4+PiBPbiBKYW4gOSwgMjAxMywgYXQgMzowNSBQTSwgVG9yc3RlbiBMb2RkZXJzdGVk dCANCj4+Pj4+IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCA8bWFpbHRvOnRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Pj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4+IEhpIEp1c3RpbiwNCj4+Pj4+Pg0KPj4+ Pj4+IEFtIDA5LjAxLjIwMTMgdW0gMjA6MzUgc2NocmllYiBKdXN0aW4gUmljaGVyIDxqcmljaGVy QG1pdHJlLm9yZyANCj4+Pj4+PiA8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj46DQo+Pj4+Pj4N Cj4+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3LCBhbnN3ZXJzIGlubGluZToNCj4+Pj4+Pj4+ IHdoeSBpcyB0aGVyZSBhIG5lZWQgZm9yIGJvdGggc2NvcGUgYW5kIGF1ZGllbmNlPyBJIHdvdWxk IGFzc3VtZSANCj4+Pj4+Pj4+IHRoZSBzY29wZSBvZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0 IGlzIHR5cGljYWxseSB0dXJuZWQgaW50byANCj4+Pj4+Pj4+IGFuIGF1ZGllbmNlIG9mIGFuIGFj Y2VzcyB0b2tlbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gWW91IGNhbiBoYXZlIGFuIGF1ZGllbmNlIG9m IGEgc2luZ2xlIHNlcnZlciB0aGF0IGhhcyBtdWx0aXBsZSANCj4+Pj4+Pj4gc2NvcGVzLCBvciBh IHNpbmdsZSBzY29wZSB0aGF0J3MgYWNyb3NzIG11bHRpcGxlIHNlcnZlcnMuIFNjb3BlIA0KPj4+ Pj4+PiBpcyBhbiBleHBsaWNpdCBjb25zdHJ1Y3QgaW4gT0F1dGgyLCBhbmQgd2hpbGUgaXQgaXMg c29tZXRpbWVzIA0KPj4+Pj4+PiB1c2VkIGZvciBhdWRpZW5jZSByZXN0cmljdGlvbiBwdXJwb3Nl cywgdGhleSByZWFsbHkgYXJlIA0KPj4+Pj4+PiBpbmRlcGVuZGVudC4gTm90ZSB0aGF0IGJvdGgg b2YgdGhlc2UgYXJlIG9wdGlvbmFsIGluIHRoZSANCj4+Pj4+Pj4gcmVzcG9uc2UgLS0gaWYgdGhl IEFTIGhhcyBubyBub3Rpb24gb2YgYXVkaWVuY2UgcmVzdHJpY3Rpb24gaW4gDQo+Pj4+Pj4+IGl0 cyBzdG9yZWQgdG9rZW4gbWV0YWRhdGEsIHRoZW4gaXQganVzdCBkb2Vzbid0IHJldHVybiB0aGUg DQo+Pj4+Pj4+ICJhdWRpZW5jZSIgZmllbGQuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3UgYXJlIG1ha2lu ZyBhbiBpbnRlcmVzdGluZyBwb2ludCBoZXJlLiBUbyBkaWZmZXJlbnRpYXRlIHRoZSANCj4+Pj4+ PiByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRoZSBwZXJtaXNzaW9ucyBvZiBhIHBhcnRpY3VsYXIgYXQg dGhpcyANCj4+Pj4+PiBzZXJ2ZXIgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UuIEJVVDogdGhlIGF1dGhv cml6YXRpb24gcmVxdWVzdCBkb2VzIA0KPj4+Pj4+IG5vdCBhbGxvdyB0aGUgY2xpZW50IHRvIHNw ZWNpZnkgYm90aCBpbiBzZXBhcmF0ZSBwYXJhbWV0ZXJzLiANCj4+Pj4+PiBJbnN0ZWFkIGJvdGgg bXVzdCBiZSBmb2xkZWQgaW50byBhIHNpbmdsZSAic2NvcGUiIHBhcmFtZXRlci4gSWYgSSANCj4+ Pj4+PiBnb3QgeW91ciBleGFtcGxlIGNvcnJlY3RseSwgdGhlIHNjb3BlIG9mIHRoZSByZXF1ZXN0 IHdvdWxkIGJlDQo+Pj4+Pj4NCj4+Pj4+PiBzY29wZT1teXNlcnZlcjpyZWFkDQo+Pj4+Pj4NCj4+ Pj4+PiB3aGVyZWFzIHRoZSByZXN1bHRzIG9mIHRoZSBpbnRyb3NwZWN0aW9uIHdvdWxkIGJlDQo+ Pj4+Pj4NCj4+Pj4+PiBzY29wZT1yZWFkDQo+Pj4+Pj4gYXVkaWVuY2U9bXlzZXJ2ZXINCj4+Pj4+ Pg0KPj4+Pj4+IEl0J3MgcHJvYmFibHkgdGhlIGRpZmZlcmVudCBzZW1hbnRpY3Mgb2Ygc2NvcGUg dGhhdCBjb25mdXNlZCBtZS4NCj4+Pj4+DQo+Pj4+PiBObywgc29ycnkgaWYgSSB3YXMgdW5jbGVh cjogc2NvcGUgaXMgc2NvcGUsIG5vIGRpZmZlcmVudCANCj4+Pj4+IHNlbWFudGljcy4gSW4gdGhp cyBleGFtcGxlIGNhc2UsIHlvdSdkIGFzayBmb3Igc2NvcGU9bXlzZXJ2ZXI6cmVhZCANCj4+Pj4+ IGFuZCBnZXQgYmFjayBzY29wZT1teXNlcnZlcjpyZWFkLiBJJ20gbm90IHN1Z2dlc3RpbmcgdGhh dCB0aGVzZSBiZSANCj4+Pj4+IHNwbGl0IHVwLiBTaW5jZSB0aGUgQVMgaW4gdGhpcyBjYXNlIGtu b3dzIHRoYXQgdGhlcmUncyBhbiANCj4+Pj4+IGF1ZGllbmNlLCBzbyBpdCBjYW4gcmV0dXJuIGF1 ZGllbmNlPW15c2VydmVyIGFzIHdlbGwuIFRoZSBmYWN0IA0KPj4+Pj4gdGhhdCBpdCBrbm93cyB0 aGlzIHRocm91Z2ggdGhlIHNjb3BlIG1lY2hhbmlzbSBpcyBlbnRpcmVseSANCj4+Pj4+IHN5c3Rl bS1kZXBlbmRlbnQuDQo+Pj4+Pg0KPj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZSBsYWNrIG9mIGEgbWV0 aG9kIGZvciBzcGVjaWZ5aW5nIGF1ZGllbmNlIGRvZXMgDQo+Pj4+PiBtYWtlIHJldHVybmluZyB0 aGlzIGZpZWxkIGEgbGl0dGxlIG9kZCBmb3Igc2ltcGxlIE9BdXRoIA0KPj4+Pj4gZGVwbG95bWVu dHMsIGJ1dCBzaW5jZSBhdWRpZW5jZSByZXN0cmljdGlvbiBpcyBhIGJpZyBwYXJ0IG9mIA0KPj4+ Pj4gY2x1c3RlcmVkIGFuZCBlbnRlcnByaXNlIGRlcGxveW1lbnRzIChpbiBteSBwZXJzb25hbCBl eHBlcmllbmNlKSwgDQo+Pj4+PiB0aGVuIGl0J3Mgc29tZXRoaW5nIHZlcnkgdXNlZnVsIHRvIGhh dmUgdGhlIHNlcnZlciByZXR1cm4uDQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gR2VuZXJhbGx5LCB3b3VsZG4ndCBpdCBiZSBzaW1wbGVyIChzcGVjLXdpc2UpIHRv IGp1c3QgcmV0dXJuIGEgDQo+Pj4+Pj4+PiBKV1QgaW5zdGVhZCBvZiBpbnZlbnRpbmcgYW5vdGhl ciBzZXQgb2YgSlNPTiBlbGVtZW50cz8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gV2hhdCB3b3VsZCBiZSB0 aGUgdXRpbGl0eSBpbiByZXR1cm5pbmcgYSBKV1Q/IFRoZSBSUy9jbGllbnQgDQo+Pj4+Pj4+IG1h a2luZyB0aGUgY2FsbCBpc24ndCBnb2luZyB0byB0YWtlIHRoZXNlIHJlc3VsdHMgYW5kIHByZXNl bnQgDQo+Pj4+Pj4+IHRoZW0gZWxzZXdoZXJlLCBzbyBJIGRvbid0IHdhbnQgdG8gZ2l2ZSB0aGUg aW1wcmVzc2lvbiB0aGF0IGl0J3MgDQo+Pj4+Pj4+IGEgdG9rZW4uIChUaGlzLCBpbmNpZGVudGFs bHksIGlzIG9uZSBvZiB0aGUgbWFpbiBwcm9ibGVtcyBJIGhhdmUgDQo+Pj4+Pj4+IHdpdGggdGhl IFBpbmcgaW50cm9zcGVjdGlvbiBhcHByb2FjaCwgd2hpY2ggdXNlcyB0aGUgVG9rZW4gDQo+Pj4+ Pj4+IEVuZHBvaW50IGFuZCBpbnZlbnRzIGEgInRva2VuIHR5cGUiIGFzIGl0cyByZXR1cm4gdmFs dWUuKSBBbHNvLCANCj4+Pj4+Pj4gdGhlIHJlc291cmNlIHNlcnZlciB3b3VsZCBoYXZlIHRvIHBh cnNlIHRoZSBKV1QgaW5zdGVhZCBvZiByYXcgDQo+Pj4+Pj4+IEpTT04sIHRoZSBsYXR0ZXIgb2Yg d2hpY2ggaXMgZWFzaWVyIGFuZCBmYXIgbW9yZSBjb21tb24uIA0KPj4+Pj4+PiBCZXNpZGVzLCBJ J2QgaGF2ZSB0byBpbnZlbnQgbmV3IGNsYWltcyBmb3IgdGhpbmdzIGxpa2UgInZhbGlkIiANCj4+ Pj4+Pj4gYW5kICJzY29wZXMiIGFuZCB3aGF0IG5vdCwgc28gSSdkIGJlIGV4dGVuZGluZyBKV1Qg YW55d2F5Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTbyB3aGlsZSBJIHRoaW5rIGl0J3MgZmFyIHByZWZl cmFibGUgdG8gdXNlIGFuIGFjdHVhbCBKU09OIA0KPj4+Pj4+PiBvYmplY3QsIEknZCBiZSBmaW5l IHdpdGggcmUtdXNpbmcgSldUIGNsYWltIG5hbWVzIGluIHRoZSANCj4+Pj4+Pj4gcmVzcG9uc2Ug aWYgcGVvcGxlIHByZWZlciB0aGF0LiBJIHRyaWVkIHRvIGp1c3QgdXNlIHRoZSBleHBhbmRlZCAN Cj4+Pj4+Pj4gdGV4dCBzaW5jZSBzaXplIGNvbnN0cmFpbnRzIGFyZSBub3QgYW4gaXNzdWUgb3V0 c2lkZSBvZiBhIEpXVCwgDQo+Pj4+Pj4+IHNvICJpc3N1ZWRfYXQiIGluc3RlYWQgb2YgImlhdCIu DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZpbmFsbHksIG5vdGUgdGhhdCB0aGlzIGlzICpub3QqIHRoZSBz YW1lIGFzIHRoZSBvbGQgT0lEQyANCj4+Pj4+Pj4gQ2hlY2tJZCBlbmRwb2ludCB3aGljaCBtZXJl bHkgcGFyc2VkIGFuZCB1bndyYXBwZWQgdGhlIGRhdGEgDQo+Pj4+Pj4+IGluc2lkZSB0aGUgdG9r ZW4gaXRzZWxmLiBUaGlzIG1lY2hhbmlzbSB3b3JrcyBqdXN0IGFzIHdlbGwgd2l0aCANCj4+Pj4+ Pj4gYW4gdW5zdHJ1Y3R1cmVkIHRva2VuIGFzIGlucHV0IHNpbmNlIHRoZSBBUyBjYW4gc3RvcmUg YWxsIG9mIHRoZSANCj4+Pj4+Pj4gdG9rZW4ncyBtZXRhZGF0YSwgbGlrZSBleHBpcmF0aW9uLCBz ZXBhcmF0ZWx5IGFuZCB1c2UgdGhlIA0KPj4+Pj4+PiB0b2tlbidzIHZhbHVlIGFzIGEgbG9va3Vw IGtleS4NCj4+Pj4+Pg0KPj4+Pj4+IEkgcHJvYmFibHkgZGlkbid0IGRlc2NyaWJlIHdlbGwgd2hh dCBJIG1lYW50LiBJIHdvdWxkIHN1Z2dlc3QgdG8gDQo+Pj4+Pj4gcmV0dXJuIGEgSldUIGNsYWlt IHNldCBmcm9tIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50LiBUaGF0IHdheSANCj4+Pj4+PiBv bmUgY291bGQgdXNlIHRoZSBzYW1lIGNsYWltcyAoZS5nLiBpYXQgaW5zdGVhZCBvZiBpc3N1ZWRf YXQpIGZvciANCj4+Pj4+PiBzdHJ1Y3R1cmVkIGFuZCBoYW5kbGUtYmFzZWQgdG9rZW5zLiBTbyB0 aGUgbG9naWMgb3BlcmF0aW5nIG9uIHRoZSANCj4+Pj4+PiB0b2tlbiBkYXRhIGNvdWxkIGJlIHRo ZSBzYW1lLg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT0ssIEkgZm9sbG93IHlvdSBub3cuIEknZCBi ZSBmaW5lIHdpdGggcmUtdXNpbmcgdGhlIEpXVCBjbGFpbSANCj4+Pj4+IG5hbWVzIGFuZCBleHRl bmRpbmcgdGhlIG5hbWVzcGFjZSB3aXRoIHRoZSBPQXV0aC1zcGVjaWZpYyANCj4+Pj4+IHBhcmFt ZXRlcnMsIGxpa2Ugc2NvcGUsIHRoYXQgbWFrZSBzZW5zZSBoZXJlLg0KPj4+Pj4NCj4+Pj4+ICAt LSBKdXN0aW4NCj4+Pj4+DQo+Pj4+Pj4gcmVnYXJkcywNCj4+Pj4+PiBUb3JzdGVuLg0KPj4+Pj4+ DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAtLSBKdXN0aW4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFtIDA5LjAx LjIwMTMgdW0gMjA6MTAgc2NocmllYiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJlLm9yZyAN Cj4+Pj4+Pj4+IDxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PjoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gVXBkYXRlZCB0aGUgaW50cm9zcGVjdGlvbiBkcmFmdCB3aXRoIGZlZWRiYWNrIGZyb20gdGhl IFVNQSBXRywgDQo+Pj4+Pj4+Pj4gd2hvIGhhdmUgaW5jb3Jwb3JhdGVkIGl0IGludG8gdGhlaXIg bGF0ZXN0IHJldmlzaW9uIG9mIFVNQS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgd291bGQgbGlr ZSB0aGlzIGRvY3VtZW50IHRvIGJlY29tZSBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+ICAtLSBKdXN0aW4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KPj4+Pj4+Pj4+IFN1YmplY3Q6IAlO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4+Pj4+Pj4+IGRyYWZ0LXJpY2hlci1vYXV0 aC1pbnRyb3NwZWN0aW9uLTAxLnR4dA0KPj4+Pj4+Pj4+IERhdGU6IAlUdWUsIDggSmFuIDIwMTMg MTQ6NDg6NDcgLTA4MDANCj4+Pj4+Pj4+PiBGcm9tOiAJPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NCj4+Pj4+Pj4+PiBUbzogCTxqcmljaGVyQG1pdHJlLm9yZz4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmlj aGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDEudHh0DQo+Pj4+Pj4+Pj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBKdXN0aW4gUmljaGVyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+ Pj4+Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRmlsZW5hbWU6CSBk cmFmdC1yaWNoZXItb2F1dGgtaW50cm9zcGVjdGlvbg0KPj4+Pj4+Pj4+IFJldmlzaW9uOgkgMDEN Cj4+Pj4+Pj4+PiBUaXRsZToJCSBPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uDQo+Pj4+Pj4+Pj4g Q3JlYXRpb24gZGF0ZToJIDIwMTMtMDEtMDgNCj4+Pj4+Pj4+PiBXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCj4+Pj4+Pj4+PiBOdW1iZXIgb2YgcGFnZXM6IDYNCj4+Pj4+Pj4+PiBVUkw6 aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmljaGVyLW9hdXRoLWlu dHJvc3BlY3Rpb24tMDEudHh0DQo+Pj4+Pj4+Pj4gU3RhdHVzOmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24NCj4+Pj4+Pj4+PiBI dG1saXplZDpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtaW50 cm9zcGVjdGlvbi0wMQ0KPj4+Pj4+Pj4+IERpZmY6aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rpb24tMDENCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+Pj4+ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5l cyBhIG1ldGhvZCBmb3IgYSBjbGllbnQgb3IgcHJvdGVjdGVkDQo+Pj4+Pj4+Pj4gICAgIHJlc291 cmNlIHRvIHF1ZXJ5IGFuIE9BdXRoIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGRldGVybWluZSBt ZXRhLQ0KPj4+Pj4+Pj4+ICAgICBpbmZvcm1hdGlvbiBhYm91dCBhbiBPQXV0aCB0b2tlbi4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcg bGlzdA0KPj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4g T0F1dGhAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCj4+Pj4NCj4+Pg0KPj4NCj4NCg0KLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0t LS0tLS0tLS0tLS0tDQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uDQpVUkw6IDxo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvYXR0YWNobWVudHMvMjAx MzAxMTAvZjFkZWE1ZDAvYXR0YWNobWVudC5odG0+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkVuZCBvZiBPQXV0aCBEaWdlc3QsIFZvbCA1 MSwgSXNzdWUgMzQNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== From igor.faynberg@alcatel-lucent.com Thu Jan 10 09:08:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5FA21F8A06 for ; Thu, 10 Jan 2013 09:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.998 X-Spam-Level: X-Spam-Status: No, score=-8.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT03krEw57uV for ; Thu, 10 Jan 2013 09:08:42 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A39BB21F8A0D for ; Thu, 10 Jan 2013 09:08:42 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r0AH8fiv000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Jan 2013 11:08:41 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0AH8elB001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Jan 2013 11:08:41 -0600 Received: from [135.222.232.243] (USMUYN0L055118.mh.lucent.com [135.222.232.243]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0AH8d1s020586; Thu, 10 Jan 2013 11:08:40 -0600 (CST) Message-ID: <50EEF597.6070407@alcatel-lucent.com> Date: Thu, 10 Jan 2013 12:08:39 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> <50EECDB4.3090708@mitre.org> <50EEF1E4.1000200@aol.com> <50EEF219.2070708@mitre.org> <50EEF377.8030207@aol.com> In-Reply-To: <50EEF377.8030207@aol.com> Content-Type: multipart/alternative; boundary="------------080702050805070909010106" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:08:44 -0000 This is a multi-part message in MIME format. --------------080702050805070909010106 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I chime in in support of option 1. Rationale: nothing is worse than the presence of an obscure parameter. (Not only it pollutes the environment, but it is a potential attack vector.) So rather than invent an acceptable value for it, I would remove it. Igor On 1/10/2013 11:59 AM, George Fletcher wrote: > That makes sense as well:) > > Hopefully some others will chime in as I think this is an area that > could use some "best practice" guidelines. > > Thanks, > George > > On 1/10/13 11:53 AM, Justin Richer wrote: >> I'm leaning towards 1 because the client is more the "authorized >> presenter" of the token, not its audience. >> >> -- Justin >> >> On 01/10/2013 11:52 AM, George Fletcher wrote: >>> So in the default case I see two options for an AS that wants to >>> implement this endpoint... >>> >>> 1. Omit 'audience' from the response: The rationale here is that >>> there really isn't an explicit audience and what clients need to >>> protect against things like "confused deputy" is the client_id which >>> is already one of the response fields. >>> >>> 2. Make the 'audience' value the same as the 'client_id' value: The >>> rationale here is that the "audience" of the token is the entity for >>> which the token was minted which in the default OAuth2 case is the >>> client_id. >>> >>> Any thoughts as to which is the best option? For now I'm going with >>> option 2. >>> >>> Thanks, >>> George >>> >>> On 1/10/13 9:18 AM, Justin Richer wrote: >>>> In traditional OAuth, there really isn't a baked-in notion of >>>> 'audience' since the AS<->PR connection is completely out of scope. >>>> However, in practice, when you've got more than one PR per AS, >>>> you'll have some notion of 'audience'. It's definitely possible to >>>> handle this with 'scope', especially if you want the client to have >>>> a say in the matter. But since you could have your scopes and >>>> audiences defined independently (one scope across several >>>> audiences, one audience with many scopes, and any other combination >>>> thereof) I think it makes sense to at least define a place for the >>>> AS to express this back to the PR. JWT has the exact same claim for >>>> the exact same reason. >>>> >>>> As George points out below, this also really comes into play in the >>>> chaining case, where you've got one PR calling another PR and you >>>> need to keep things straight in a large backend. >>>> >>>> So while I agree it'd be better if OAuth had an 'audience' concept >>>> all the way through, I don't think it should be precluded from the >>>> introspection response just because it doesn't. >>>> >>>> -- Justin >>>> >>>> >>>> On 01/09/2013 04:47 PM, George Fletcher wrote: >>>>> I had the same confusion about "what is 'audience' in OAuth?" >>>>> today working on a completely different project. >>>>> >>>>> I think for the default OAuth2 deployment, scopes take the place >>>>> of audience because the scopes identify the authorization grant(s) >>>>> at the resource servers affiliated with the Authorization Server. >>>>> The client can present the token to any resource server and if the >>>>> necessary authorization grant(s) are present, the protected >>>>> resource is returned. The client doesn't have to explicitly call >>>>> out that it is going to present the token to the 'mail service', >>>>> it just needs to ask for the 'readMail' scope. >>>>> >>>>> So, in regards to an AS implementation of the introspection >>>>> endpoint, what are the expectations for how the AS fills in the >>>>> 'audience' field. Should the AS not return the field if there is >>>>> no audience? Should the AS return "itself" as the audience? If a >>>>> token has scopes of 'readMail writeMail readBuddyList sendIM' then >>>>> what is the correct 'audience' of the token? Should it be an array >>>>> of the resource servers that depend on those scopes? >>>>> >>>>> I can see value in the chaining scenario of a client asking the AS >>>>> for a token that it will give to another party to present and >>>>> storing that intermediate party in the token. But for the default >>>>> OAuth2 case, should audience be omitted? or be the same value as >>>>> 'client_id'? >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 1/9/13 3:15 PM, Richer, Justin P. wrote: >>>>>> >>>>>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >>>>>> > wrote: >>>>>> >>>>>>> Hi Justin, >>>>>>> >>>>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer >>>>>> >: >>>>>>> >>>>>>>> Thanks for the review, answers inline: >>>>>>>>> why is there a need for both scope and audience? I would >>>>>>>>> assume the scope of the authorization request is typically >>>>>>>>> turned into an audience of an access token. >>>>>>>> >>>>>>>> You can have an audience of a single server that has multiple >>>>>>>> scopes, or a single scope that's across multiple servers. Scope >>>>>>>> is an explicit construct in OAuth2, and while it is sometimes >>>>>>>> used for audience restriction purposes, they really are >>>>>>>> independent. Note that both of these are optional in the >>>>>>>> response -- if the AS has no notion of audience restriction in >>>>>>>> its stored token metadata, then it just doesn't return the >>>>>>>> "audience" field. >>>>>>> >>>>>>> You are making an interesting point here. To differentiate the >>>>>>> resource server and the permissions of a particular at this >>>>>>> server makes a lot of sense. BUT: the authorization request does >>>>>>> not allow the client to specify both in separate parameters. >>>>>>> Instead both must be folded into a single "scope" parameter. If >>>>>>> I got your example correctly, the scope of the request would be >>>>>>> >>>>>>> scope=myserver:read >>>>>>> >>>>>>> whereas the results of the introspection would be >>>>>>> >>>>>>> scope=read >>>>>>> audience=myserver >>>>>>> >>>>>>> It's probably the different semantics of scope that confused me. >>>>>> >>>>>> No, sorry if I was unclear: scope is scope, no different >>>>>> semantics. In this example case, you'd ask for >>>>>> scope=myserver:read and get back scope=myserver:read. I'm not >>>>>> suggesting that these be split up. Since the AS in this case >>>>>> knows that there's an audience, so it can return >>>>>> audience=myserver as well. The fact that it knows this through >>>>>> the scope mechanism is entirely system-dependent. >>>>>> >>>>>> I agree that the lack of a method for specifying audience does >>>>>> make returning this field a little odd for simple OAuth >>>>>> deployments, but since audience restriction is a big part of >>>>>> clustered and enterprise deployments (in my personal experience), >>>>>> then it's something very useful to have the server return. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a >>>>>>>>> JWT instead of inventing another set of JSON elements? >>>>>>>> >>>>>>>> What would be the utility in returning a JWT? The RS/client >>>>>>>> making the call isn't going to take these results and present >>>>>>>> them elsewhere, so I don't want to give the impression that >>>>>>>> it's a token. (This, incidentally, is one of the main problems >>>>>>>> I have with the Ping introspection approach, which uses the >>>>>>>> Token Endpoint and invents a "token type" as its return value.) >>>>>>>> Also, the resource server would have to parse the JWT instead >>>>>>>> of raw JSON, the latter of which is easier and far more common. >>>>>>>> Besides, I'd have to invent new claims for things like "valid" >>>>>>>> and "scopes" and what not, so I'd be extending JWT anyway. >>>>>>>> >>>>>>>> So while I think it's far preferable to use an actual JSON >>>>>>>> object, I'd be fine with re-using JWT claim names in the >>>>>>>> response if people prefer that. I tried to just use the >>>>>>>> expanded text since size constraints are not an issue outside >>>>>>>> of a JWT, so "issued_at" instead of "iat". >>>>>>>> >>>>>>>> Finally, note that this is *not* the same as the old OIDC >>>>>>>> CheckId endpoint which merely parsed and unwrapped the data >>>>>>>> inside the token itself. This mechanism works just as well with >>>>>>>> an unstructured token as input since the AS can store all of >>>>>>>> the token's metadata, like expiration, separately and use the >>>>>>>> token's value as a lookup key. >>>>>>> >>>>>>> I probably didn't describe well what I meant. I would suggest to >>>>>>> return a JWT claim set from the introspection endpoint. That way >>>>>>> one could use the same claims (e.g. iat instead of issued_at) >>>>>>> for structured and handle-based tokens. So the logic operating >>>>>>> on the token data could be the same. >>>>>>> >>>>>> >>>>>> OK, I follow you now. I'd be fine with re-using the JWT claim >>>>>> names and extending the namespace with the OAuth-specific >>>>>> parameters, like scope, that make sense here. >>>>>> >>>>>> -- Justin >>>>>> >>>>>>> regards, >>>>>>> Torsten. >>>>>>> >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>>>>>>> >: >>>>>>>>> >>>>>>>>>> Updated the introspection draft with feedback from the UMA >>>>>>>>>> WG, who have incorporated it into their latest revision of UMA. >>>>>>>>>> >>>>>>>>>> I would like this document to become a working group item. >>>>>>>>>> >>>>>>>>>> -- Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------- Original Message -------- >>>>>>>>>> Subject: New Version Notification for >>>>>>>>>> draft-richer-oauth-introspection-01.txt >>>>>>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>>>>>> From: >>>>>>>>>> To: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>>>>> IETF repository. >>>>>>>>>> >>>>>>>>>> Filename: draft-richer-oauth-introspection >>>>>>>>>> Revision: 01 >>>>>>>>>> Title: OAuth Token Introspection >>>>>>>>>> Creation date: 2013-01-08 >>>>>>>>>> WG ID: Individual Submission >>>>>>>>>> Number of pages: 6 >>>>>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>>>>>> >>>>>>>>>> Abstract: >>>>>>>>>> This specification defines a method for a client or protected >>>>>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>>>>> information about an OAuth token. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The IETF Secretariat >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080702050805070909010106 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I chime in in support of option 1. Rationale: nothing is worse than the presence of an obscure parameter. (Not only it pollutes the environment, but it is a potential attack vector.) So rather than invent an acceptable value for it, I would remove it.

Igor

On 1/10/2013 11:59 AM, George Fletcher wrote:
That makes sense as well:)

Hopefully some others will chime in as I think this is an area that could use some "best practice" guidelines.

Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning towards 1 because the client is more the "authorized presenter" of the token, not its audience.

-- Justin

On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to implement this endpoint...

1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields.

2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id.

Any thoughts as to which is the best option? For now I'm going with option 2.

Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

-- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent.

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

-- Justin

regards,
Torsten.


-- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

-- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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







_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------080702050805070909010106-- From jricher@mitre.org Thu Jan 10 09:14:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9079621F88E1 for ; Thu, 10 Jan 2013 09:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFCvtjdwznkR for ; Thu, 10 Jan 2013 09:14:13 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5802721F8694 for ; Thu, 10 Jan 2013 09:14:13 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 101E043901B2; Thu, 10 Jan 2013 12:14:12 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7A0931F342A; Thu, 10 Jan 2013 12:14:03 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 12:14:02 -0500 Message-ID: <50EEF6D7.4090705@mitre.org> Date: Thu, 10 Jan 2013 12:13:59 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50EDC666.6040808@mitre.org> <4F910A7E-75EB-4A39-906B-A892A6ED85B4@lodderstedt.net> <50EDE573.4090308@aol.com> <50EECDB4.3090708@mitre.org> <50EEF1E4.1000200@aol.com> <50EEF219.2070708@mitre.org> <50EEF377.8030207@aol.com> <50EEF597.6070407@alcatel-lucent.com> In-Reply-To: <50EEF597.6070407@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------090500000905030105010102" X-Originating-IP: [129.83.31.58] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:14:19 -0000 --------------090500000905030105010102 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Igor, The question is not whether to remove the parameter from the spec, but rather what one would expect as a "default" behavior from a "normal" OAuth2 provider. Option1 says that the default is to leave it out of the response. But it'll still be there in cases where the AS and PR know what the value means. -- Justin On 01/10/2013 12:08 PM, Igor Faynberg wrote: > I chime in in support of option 1. Rationale: nothing is worse > than the presence of an obscure parameter. (Not only it pollutes the > environment, but it is a potential attack vector.) So rather than > invent an acceptable value for it, I would remove it. > > Igor > > On 1/10/2013 11:59 AM, George Fletcher wrote: >> That makes sense as well:) >> >> Hopefully some others will chime in as I think this is an area that >> could use some "best practice" guidelines. >> >> Thanks, >> George >> >> On 1/10/13 11:53 AM, Justin Richer wrote: >>> I'm leaning towards 1 because the client is more the "authorized >>> presenter" of the token, not its audience. >>> >>> -- Justin >>> >>> On 01/10/2013 11:52 AM, George Fletcher wrote: >>>> So in the default case I see two options for an AS that wants to >>>> implement this endpoint... >>>> >>>> 1. Omit 'audience' from the response: The rationale here is that >>>> there really isn't an explicit audience and what clients need to >>>> protect against things like "confused deputy" is the client_id >>>> which is already one of the response fields. >>>> >>>> 2. Make the 'audience' value the same as the 'client_id' value: The >>>> rationale here is that the "audience" of the token is the entity >>>> for which the token was minted which in the default OAuth2 case is >>>> the client_id. >>>> >>>> Any thoughts as to which is the best option? For now I'm going with >>>> option 2. >>>> >>>> Thanks, >>>> George >>>> >>>> On 1/10/13 9:18 AM, Justin Richer wrote: >>>>> In traditional OAuth, there really isn't a baked-in notion of >>>>> 'audience' since the AS<->PR connection is completely out of >>>>> scope. However, in practice, when you've got more than one PR per >>>>> AS, you'll have some notion of 'audience'. It's definitely >>>>> possible to handle this with 'scope', especially if you want the >>>>> client to have a say in the matter. But since you could have your >>>>> scopes and audiences defined independently (one scope across >>>>> several audiences, one audience with many scopes, and any other >>>>> combination thereof) I think it makes sense to at least define a >>>>> place for the AS to express this back to the PR. JWT has the exact >>>>> same claim for the exact same reason. >>>>> >>>>> As George points out below, this also really comes into play in >>>>> the chaining case, where you've got one PR calling another PR and >>>>> you need to keep things straight in a large backend. >>>>> >>>>> So while I agree it'd be better if OAuth had an 'audience' concept >>>>> all the way through, I don't think it should be precluded from the >>>>> introspection response just because it doesn't. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> On 01/09/2013 04:47 PM, George Fletcher wrote: >>>>>> I had the same confusion about "what is 'audience' in OAuth?" >>>>>> today working on a completely different project. >>>>>> >>>>>> I think for the default OAuth2 deployment, scopes take the place >>>>>> of audience because the scopes identify the authorization >>>>>> grant(s) at the resource servers affiliated with the >>>>>> Authorization Server. The client can present the token to any >>>>>> resource server and if the necessary authorization grant(s) are >>>>>> present, the protected resource is returned. The client doesn't >>>>>> have to explicitly call out that it is going to present the token >>>>>> to the 'mail service', it just needs to ask for the 'readMail' scope. >>>>>> >>>>>> So, in regards to an AS implementation of the introspection >>>>>> endpoint, what are the expectations for how the AS fills in the >>>>>> 'audience' field. Should the AS not return the field if there is >>>>>> no audience? Should the AS return "itself" as the audience? If a >>>>>> token has scopes of 'readMail writeMail readBuddyList sendIM' >>>>>> then what is the correct 'audience' of the token? Should it be an >>>>>> array of the resource servers that depend on those scopes? >>>>>> >>>>>> I can see value in the chaining scenario of a client asking the >>>>>> AS for a token that it will give to another party to present and >>>>>> storing that intermediate party in the token. But for the default >>>>>> OAuth2 case, should audience be omitted? or be the same value as >>>>>> 'client_id'? >>>>>> >>>>>> Thanks, >>>>>> George >>>>>> >>>>>> On 1/9/13 3:15 PM, Richer, Justin P. wrote: >>>>>>> >>>>>>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer >>>>>>> >: >>>>>>>> >>>>>>>>> Thanks for the review, answers inline: >>>>>>>>>> why is there a need for both scope and audience? I would >>>>>>>>>> assume the scope of the authorization request is typically >>>>>>>>>> turned into an audience of an access token. >>>>>>>>> >>>>>>>>> You can have an audience of a single server that has multiple >>>>>>>>> scopes, or a single scope that's across multiple servers. >>>>>>>>> Scope is an explicit construct in OAuth2, and while it is >>>>>>>>> sometimes used for audience restriction purposes, they really >>>>>>>>> are independent. Note that both of these are optional in the >>>>>>>>> response -- if the AS has no notion of audience restriction in >>>>>>>>> its stored token metadata, then it just doesn't return the >>>>>>>>> "audience" field. >>>>>>>> >>>>>>>> You are making an interesting point here. To differentiate the >>>>>>>> resource server and the permissions of a particular at this >>>>>>>> server makes a lot of sense. BUT: the authorization request >>>>>>>> does not allow the client to specify both in separate >>>>>>>> parameters. Instead both must be folded into a single "scope" >>>>>>>> parameter. If I got your example correctly, the scope of the >>>>>>>> request would be >>>>>>>> >>>>>>>> scope=myserver:read >>>>>>>> >>>>>>>> whereas the results of the introspection would be >>>>>>>> >>>>>>>> scope=read >>>>>>>> audience=myserver >>>>>>>> >>>>>>>> It's probably the different semantics of scope that confused me. >>>>>>> >>>>>>> No, sorry if I was unclear: scope is scope, no different >>>>>>> semantics. In this example case, you'd ask for >>>>>>> scope=myserver:read and get back scope=myserver:read. I'm not >>>>>>> suggesting that these be split up. Since the AS in this case >>>>>>> knows that there's an audience, so it can return >>>>>>> audience=myserver as well. The fact that it knows this through >>>>>>> the scope mechanism is entirely system-dependent. >>>>>>> >>>>>>> I agree that the lack of a method for specifying audience does >>>>>>> make returning this field a little odd for simple OAuth >>>>>>> deployments, but since audience restriction is a big part of >>>>>>> clustered and enterprise deployments (in my personal >>>>>>> experience), then it's something very useful to have the server >>>>>>> return. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return >>>>>>>>>> a JWT instead of inventing another set of JSON elements? >>>>>>>>> >>>>>>>>> What would be the utility in returning a JWT? The RS/client >>>>>>>>> making the call isn't going to take these results and present >>>>>>>>> them elsewhere, so I don't want to give the impression that >>>>>>>>> it's a token. (This, incidentally, is one of the main problems >>>>>>>>> I have with the Ping introspection approach, which uses the >>>>>>>>> Token Endpoint and invents a "token type" as its return >>>>>>>>> value.) Also, the resource server would have to parse the JWT >>>>>>>>> instead of raw JSON, the latter of which is easier and far >>>>>>>>> more common. Besides, I'd have to invent new claims for things >>>>>>>>> like "valid" and "scopes" and what not, so I'd be extending >>>>>>>>> JWT anyway. >>>>>>>>> >>>>>>>>> So while I think it's far preferable to use an actual JSON >>>>>>>>> object, I'd be fine with re-using JWT claim names in the >>>>>>>>> response if people prefer that. I tried to just use the >>>>>>>>> expanded text since size constraints are not an issue outside >>>>>>>>> of a JWT, so "issued_at" instead of "iat". >>>>>>>>> >>>>>>>>> Finally, note that this is *not* the same as the old OIDC >>>>>>>>> CheckId endpoint which merely parsed and unwrapped the data >>>>>>>>> inside the token itself. This mechanism works just as well >>>>>>>>> with an unstructured token as input since the AS can store all >>>>>>>>> of the token's metadata, like expiration, separately and use >>>>>>>>> the token's value as a lookup key. >>>>>>>> >>>>>>>> I probably didn't describe well what I meant. I would suggest >>>>>>>> to return a JWT claim set from the introspection endpoint. That >>>>>>>> way one could use the same claims (e.g. iat instead of >>>>>>>> issued_at) for structured and handle-based tokens. So the logic >>>>>>>> operating on the token data could be the same. >>>>>>>> >>>>>>> >>>>>>> OK, I follow you now. I'd be fine with re-using the JWT claim >>>>>>> names and extending the namespace with the OAuth-specific >>>>>>> parameters, like scope, that make sense here. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer >>>>>>>>>> >: >>>>>>>>>> >>>>>>>>>>> Updated the introspection draft with feedback from the UMA >>>>>>>>>>> WG, who have incorporated it into their latest revision of UMA. >>>>>>>>>>> >>>>>>>>>>> I would like this document to become a working group item. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>>> draft-richer-oauth-introspection-01.txt >>>>>>>>>>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>>>>>>>>>> From: >>>>>>>>>>> To: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>>>>>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>>>>>> IETF repository. >>>>>>>>>>> >>>>>>>>>>> Filename: draft-richer-oauth-introspection >>>>>>>>>>> Revision: 01 >>>>>>>>>>> Title: OAuth Token Introspection >>>>>>>>>>> Creation date: 2013-01-08 >>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>>> Number of pages: 6 >>>>>>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>>>>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>>>>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>>>>>>>>>> >>>>>>>>>>> Abstract: >>>>>>>>>>> This specification defines a method for a client or protected >>>>>>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>>>>>> information about an OAuth token. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The IETF Secretariat >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090500000905030105010102 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Igor,

The question is not whether to remove the parameter from the spec, but rather what one would expect as a "default" behavior from a "normal" OAuth2 provider. Option1 says that the default is to leave it out of the response. But it'll still be there in cases where the AS and PR know what the value means.

 -- Justin

On 01/10/2013 12:08 PM, Igor Faynberg wrote:
 I  chime in in support of option 1.   Rationale: nothing is worse than the presence of an obscure parameter. (Not only it pollutes the environment, but it is a potential attack vector.) So rather than invent an acceptable value for it, I would remove it.

Igor

On 1/10/2013 11:59 AM, George Fletcher wrote:
That makes sense as well:)

Hopefully some others will chime in as I think this is an area that could use some "best practice" guidelines.

Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning towards 1 because the client is more the "authorized presenter" of the token, not its audience.

 -- Justin

On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to implement this endpoint...

1. Omit 'audience' from the response: The rationale here is that there really isn't an explicit audience and what clients need to protect against things like "confused deputy" is the client_id which is already one of the response fields.

2. Make the 'audience' value the same as the 'client_id' value: The rationale here is that the "audience" of the token is the entity for which the token was minted which in the default OAuth2 case is the client_id.

Any thoughts as to which is the best option? For now I'm going with option 2.

Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of 'audience' since the AS<->PR connection is completely out of scope. However, in practice, when you've got more than one PR per AS, you'll have some notion of 'audience'. It's definitely possible to handle this with 'scope', especially if you want the client to have a say in the matter. But since you could have your scopes and audiences defined independently (one scope across several audiences, one audience with many scopes, and any other combination thereof) I think it makes sense to at least define a place for the AS to express this back to the PR. JWT has the exact same claim for the exact same reason.

As George points out below, this also really comes into play in the chaining case, where you've got one PR calling another PR and you need to keep things straight in a large backend.

So while I agree it'd be better if OAuth had an 'audience' concept all the way through, I don't think it should be precluded from the introspection response just because it doesn't.

 -- Justin


On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today working on a completely different project.

I think for the default OAuth2 deployment, scopes take the place of audience because the scopes identify the authorization grant(s) at the resource servers affiliated with the Authorization Server. The client can present the token to any resource server and if the necessary authorization grant(s) are present, the protected resource is returned. The client doesn't have to explicitly call out that it is going to present the token to the 'mail service', it just needs to ask for the 'readMail' scope.

So, in regards to an AS implementation of the introspection endpoint, what are the expectations for how the AS fills in the 'audience' field. Should the AS not return the field if there is no audience? Should the AS return "itself" as the audience? If a token has scopes of 'readMail writeMail readBuddyList sendIM' then what is the correct 'audience' of the token? Should it be an array of the resource servers that depend on those scopes?

I can see value in the chaining scenario of a client asking the AS for a token that it will give to another party to present and storing that intermediate party in the token. But for the default OAuth2 case, should audience be omitted? or be the same value as 'client_id'?

Thanks,
George

On 1/9/13 3:15 PM, Richer, Justin P. wrote:

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <jricher@mitre.org>:

Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the scope of the authorization request is typically turned into an audience of an access token.

You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be

scope=myserver:read

whereas the results of the introspection would be

scope=read
audience=myserver

It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent. 

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.




Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway.

So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat".

Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.


OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

 -- Justin

regards,
Torsten.


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org>:

Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA.

I would like this document to become a working group item.

 -- Justin


-------- Original Message --------
Subject: New Version Notification for draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-drafts@ietf.org>
To: <jricher@mitre.org> 


A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 01
Title:		 OAuth Token Introspection
Creation date:	 2013-01-08
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.


                                                                                  


The IETF Secretariat


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




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







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



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

--------------090500000905030105010102-- From torsten@lodderstedt.net Thu Jan 10 10:17:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401FD21F84D8 for ; Thu, 10 Jan 2013 10:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCzjcYjif8uL for ; Thu, 10 Jan 2013 10:17:52 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0621F89CB for ; Thu, 10 Jan 2013 10:17:51 -0800 (PST) Received: from [79.253.24.185] (helo=[192.168.71.56]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TtMhI-0007v0-So; Thu, 10 Jan 2013 19:17:49 +0100 References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com> <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-295525A9-1065-4FF1-9B1F-FA90023BCFA5 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Thu, 10 Jan 2013 19:17:50 +0100 To: "Richer, Justin P." X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:17:54 -0000 --Apple-Mail-295525A9-1065-4FF1-9B1F-FA90023BCFA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on a conversion with one of our developers I would prefer the DynReg s= tyle. regards, Torsten. Am 09.01.2013 um 21:05 schrieb "Richer, Justin P." : > It's been a few days now and I haven't seen any traffic from the group abo= ut this at all, so I'll just come out and ask for opinions. The two proposal= s are: >=20 > OIDC-style: > - inclusion of field replaces that field value on the server with the new= value > - omission of field deletes that field value on the server >=20 > DynReg style: > - inclusion of field replaces that field value on the server with the new= value > - omission of field tells the server to leave its current value alone > - inclusion of field with an empty string value deletes/clears that field= value from the server >=20 >=20 > Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curre= nt semantics? Why? Is there another option that's even better? >=20 > -- Justin >=20 >=20 > On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." wrote:= >=20 >> Mike, John, thanks for the feedback. I hope and anticipate that this conv= ersation will help improve both drafts. >>=20 >> I disagree with the assessment here that it makes things more complicated= in the simple case. How? The way that DynReg is currently written, if the c= lient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it s= till behaves as expected. Doesn't it? There's nothing in the draft that REQU= IRES an incomplete POST, it just ALLOWS it to happen and defines what to do w= hen it does. Furthermore, it makes it *safer* if the client POSTs something t= hat is incomplete from the *server's* perspective, since the semantics are n= ow, explicitly, to leave alone any values that are left out. In other words,= it's my view that this actually makes things far simpler for clients wantin= g to do simple things, and makes more complex things possible. This is espec= ially in light of the requirement of the server to echo out the actual full s= tate of the client during the transaction. Having implemented this myself, i= t's really not very complex from either side. The server is marginally more c= omplex, but it leaves fewer cases undefined or "up to the server to decide".= =20 >>=20 >> Part of the motivation I had for changing this here was to cope with the c= ases where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was s= imple and programmatic to implement from both sides. In other words, it's as= suming that the *server* has the most complete picture of the client's state= , not the *client*, which is the assumption made in OIDC and by Mike and Joh= n's comments below. Let's take this example as a concrete case (formatting a= nd parameter names are notional and might be off, I'm typing from memory): >>=20 >> Client registers with params: >>=20 >> client_name=3DFoo >> token_endpoint_auth_type=3Dclient_secret_basic >>=20 >> Server sends back to the client: >> { >> client_name: Foo >> client_secret: super-secret-secret >> token_endpoint_auth_type: client_secret_basic >> scope: read open dennis >> registration_access_token: TOKEN >> } >>=20 >> So the client never asked for scope restriction, but the server decided (= however it wanted to, probably by a defaulting mechanism) to give the client= three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at l= east is changing). Even if it did know about this parameter, it didn't ask f= or anything in particular in that field, so it now has to keep around someth= ing that it doesn't really know what to do with. So with that in mind, the c= lient decides to change its name and sends back all the parameters that it k= nows about: >>=20 >> client_name=3DBar >> token_endpoint_auth_type=3Dclient_secret_basic >> access_token=3DTOKEN >>=20 >> Now in the OIDC definition of the semantics, this tells the server to cle= ar out the existing "scope" value, because it's not included in the request.= But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to t= reat it special. But then the server would have to track which fields are st= ill in a "defaulted" state, or keep some kind of programming logic that says= "a blank on an update actually means something else". Which fields does thi= s apply to? Neither of those are "simple".=20 >>=20 >> In the current definition of the DynReg spec, the client not only knows t= he fields and can do something about them if it wants to, it can also *safel= y* ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now h= as an unambiguous message when the client omits the "scope" field.=20 >>=20 >> With this behavior, though, we do need the equivalent of "set to null" in= order to explicitly empty out the value of an existing field. I took the ap= proach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this p= art of it, but this was the best I could come up with. >>=20 >> Finally, it's not a bandwidth issue at all, so let's just ignore that par= ticular red herring. :) >>=20 >> -- Justin >>=20 >>=20 >>=20 >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John B= radley [ve7jtb@ve7jtb.com] >> Sent: Friday, January 04, 2013 7:13 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Difference between client_update semantics in dra= ft-ietf-oauth-dyn-reg and OpenID Connect Registration >>=20 >> We did discuss this issue in the connect WG. >>=20 >> The decision was made to always completely replace. That prevents unkno= wn states if a update fails. =20 >>=20 >> I think the always replace everything rule is simpler, though admittedly m= ore bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. >>=20 >> John B. >>=20 >> On 2013-01-04, at 8:55 PM, Mike Jones wrote= : >>=20 >>> The client_update operation in http://tools.ietf.org/html/draft-ietf-oau= th-dyn-reg-03 does something different than the operation upon which it was b= ased fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, t= he OAuth operation allows only selective fields to be replaced, designating f= ields to remain unchanged by specifying their value as the empty string (=E2= =80=9C=E2=80=9D). >>> =20 >>> I'm personally not happy with the change to the semantics of client fiel= d inclusion. Updating some but not all fields is a substantially more compl= icated operation than replacing all fields. Is there some use case that mot= ivates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then s= electively use them for update operations, when needed. Then the work goes t= o the (I suspect rare) parties that need partial update - not to every serve= r. It complicates the simple case, rather than pushing the complexity to th= e rare case, violating the design principle =E2=80=9Cmake simple things simp= le and make more complicated things possible=E2=80=9D. >>> =20 >>> Is anyone opposed to updating the OAuth Registration semantics to match t= he Connect registration semantics? Is so, why? >>> =20 >>> Thanks, >>> -- Mike >>> =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 --Apple-Mail-295525A9-1065-4FF1-9B1F-FA90023BCFA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

based= on a conversion with one of our developers I would prefer the DynReg style.=

regards,
Torsten.

Am 09.01.2013 u= m 21:05 schrieb "Richer, Justin P." <jricher@mitre.org>:

It's been a few days now and I haven't seen any traffic from the group a= bout this at all, so I'll just come out and ask for opinions. The two propos= als are:

OIDC-style:
 - inclusion of field replaces that field value on the server with= the new value
 - omission of field deletes that field value on the server

DynReg style:
 - inclusion of field replaces that field value on the server with= the new value
 - omission of field tells the server to leave its current value a= lone
 - inclusion of field with an empty string value deletes/clears th= at field value from the server


Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its cu= rrent semantics? Why? Is there another option that's even better?

 -- Justin


On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

Mike, J= ohn, thanks for the feedback. I hope and anticipate that this conversation w= ill help improve both drafts.

I disagree with the assessment here that it makes things more complicated in= the simple case. How? The way that DynReg is currently written, if the clie= nt simply POSTs back the entire set of information that it has about itself e= very time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn't= it? There's nothing in the draft that REQUIRES an incomplete POST, it just A= LLOWS it to happen and defines what to do when it does. Furthermore, it make= s it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the sem= antics are now, explicitly, to leave alone any values that are left out. In o= ther words, it's my view that this actually makes things far simpler for cli= ents wanting to do simple things, and makes more complex things possible. This is especially in light of the r= equirement of the server to echo out the actual full state of the client dur= ing the transaction. Having implemented this myself, it's really not very co= mplex from either side. The server is marginally more complex, but it leaves fewer cases undefined or "= up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the cas= es where the server asserts things about the client that the client doesn't r= egister about itself in the first place, and I wanted something that was sim= ple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the mo= st complete picture of the client's state, not the *client*, which is the as= sumption made in OIDC and by Mike and John's comments below. Let's take this= example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory):=

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (how= ever it wanted to, probably by a defaulting mechanism) to give the client th= ree scopes. In the current OIDC spec, the client would never even know this h= appened because this information isn't ever echoed back (though this at least is changing). Even if it did k= now about this parameter, it didn't ask for anything in particular in that f= ield, so it now has to keep around something that it doesn't really know wha= t to do with. So with that in mind, the client decides to change its name and sends back all the paramete= rs that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear o= ut the existing "scope" value, because it's not included in the request. But= the server really shouldn't do that, should it? You could argue that becaus= e it's a server-defaulted parameter and that the server should know to treat it special. But then the server wo= uld have to track which fields are still in a "defaulted" state, or keep som= e kind of programming logic that says "a blank on an update actually means s= omething else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the f= ields and can do something about them if it wants to, it can also *safely* i= gnore them in responses. If the client sends back the same set above, dealin= g only in the parameters that it knows and cares about, the server now has an unambiguous message when th= e client omits the "scope" field. = ;

With this behavior, though, we do need the equivalent of "set to null" in or= der to explicitly empty out the value of an existing field. I took the appro= ach of using a blank value -- expressed in HTTP forms as an empty string. I'= m open to other suggestions if there's a better/cleaner approach to this part of it, but this was the best= I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that partic= ular red herring. :)

 -- Justin



From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7j= tb.com]
Sent: Friday, Janua= ry 04, 2013 7:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH= -WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg a= nd OpenID Connect Registration

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That prevent= s unknown states if a update fails.   

I think the always replace everything rule is simpler, though admittedl= y more bandwidth is required.  However bandwidth is not a significant f= actor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrot= e:

The client_update operation in http://t= ools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openid.= net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values,= the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string (= =E2=80=9C=E2=80=9D).
 
I'm personally not happy with the change to the semantics of client field in= clusion.  Updating some but not all fields is a substantially more comp= licated operation than replacing all fields.  Is there some use case th= at motivates this?  I don't think it's a substantial burden on the registering party to remember all the field val= ues from the initial registration and then selectively use them for update o= perations, when needed.  Then the work goes to the (I suspect rare) par= ties that need partial update - not to every server.  It complicates the simple case, rather than pushing t= he complexity to the rare case, violating the design principle =E2=80=9Cmake= simple things simple and make more complicated things possible=E2=80=9D.
 
Is anyone opposed to updating the OAuth Registration semantics to match the C= onnect registration semantics?  Is so, why?
 
            &nbs= p;            &n= bsp;            =             &nbs= p;             T= hanks,
            &nbs= p;            &n= bsp;            =             &nbs= p;             -= - Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth

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

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-295525A9-1065-4FF1-9B1F-FA90023BCFA5-- From ve7jtb@ve7jtb.com Thu Jan 10 11:22:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DA721F8947 for ; Thu, 10 Jan 2013 11:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw65PspMzW3g for ; Thu, 10 Jan 2013 11:22:48 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5721F8939 for ; Thu, 10 Jan 2013 11:22:47 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id j15so1977296qaq.18 for ; Thu, 10 Jan 2013 11:22:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=cDrGwXkbq9R4fhmInYLHdZ+Lms23wd/4mCX3Tf77bck=; b=ffOjecWVnjCfbPK6ptxFcA54txGr0vn/otxqaS16cuNJL0U1ubWUNE6fj11kb5RtNc to4Yxr13prfxGHEoBovvw8Q9iRXYWItJuH/tIUUTHHYry6GxjvrvB+lF/4wnN4ZGRfTF TgW2weY2i5pNm64sNWQ906sNradduAeVH9w3jSR9GvJ/ajlHbLrIxswYb6FxJsjRg7cb rpCDQ836LeifIDxJS9kY0gAJE78zsY+Mf95qBY1G6YtTRuT9kECGEYCBdOI2DoAOy/QM csQttddXbgpIuVPfKGWT5TBGcLVaTLjwH2YnsswyqYRw2m4sU59MdmiBK5leGnLRxsfM tCFQ== X-Received: by 10.229.201.101 with SMTP id ez37mr12974021qcb.99.1357845766971; Thu, 10 Jan 2013 11:22:46 -0800 (PST) Received: from [192.168.1.213] (190-20-60-167.baf.movistar.cl. [190.20.60.167]) by mx.google.com with ESMTPS id h4sm2072575qav.22.2013.01.10.11.22.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 11:22:45 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B032F5A-434E-4EEB-BF4B-356DDB423A34" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 10 Jan 2013 16:22:36 -0300 Message-Id: <00E975D3-461B-4130-AD77-58BFD99452F4@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366A0964B@TK5EX14MBXC283.redmond.corp.microsoft.com> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk/6XFk+9zX4g9QjD8swt3fb9eG5OGAgwlyGDDeGu9088oEH4qp8HmRTfiKuIWt7qUkrmLr Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:22:50 -0000 --Apple-Mail=_1B032F5A-434E-4EEB-BF4B-356DDB423A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 One issue is that some of the top level elements like redirect_uri may = be arrays. I wouldn't want to start specifying partial replacement for = that. DynReg should replace all of an array or object. I suspect that is the = intent anyway. I see the benefit of returning the entire configuration in the response, = that allows the client to learn about the defaults a server has set, and = perhaps update them even if they were not part of the initial = registration. With the current OIDC defined behavior a missing parameter is taken to = be a reset to the default. With DynReg the missing parameter is taken = to not change the setting. Sort of 6 of one half a dozen of the other. I am assuming that a client isn't going to be changing defaults it = doesn't care about in the first instance. The disadvantage of the DynReg approach is that the client explicitly = needs to reset something to a default as opposed to it happening each = time. I don't see much difference in actual use from a client. I suspect = that the OIDC approach is easier to program on the server side. =20 I don't hate the DynReg approach, however I am still trying to see the = part where it is better. John B. On 2013-01-09, at 5:43 PM, "Richer, Justin P." = wrote: > Not quite - the client supplies all of the fields that it knows about, = and the server will fill in the rest. This includes any the client might = not know or care about. This comes into play especially because the list = of fields is now extensible by definition, which it wasn't in OIDC. It's = exactly this extensibility that will make OIDC be able to leverage this, = so the extensibility needs to be done right and with conscious = consideration. >=20 > At the point of initial registration, the client should have all of = the fields returned (something that both DynReg and OIDC Reg now do, per = my latest edits), so a simple client that just posts back this data = model to the server every time it does an update will function exactly = the same way in both cases. So you still get the exact same post-all = behavior.=20 >=20 > If instead you have a client that only stores the fields that it knows = about in the original registration request (it's ignorant of extensions = and defaults and doesn't save the raw JSON object), then you've got an = interesting situation. So the client registers a set of fields, the = server gives a default for something the client doesn't ask for (like = scope), and returns that JSON back. Now the client needs to be able to = deal with this new field in its local storage, even if it doesn't care = about it, or else risk deleting its server-asserted "scope" value from = the server.=20 >=20 > I don't think that limiting the fields you care about is an = unreasonable assumption for a client to make in its data model, either, = but more client authors should chime in here and say if I'm wrong or = not. With this in mind, I don't see at all how this makes things any = more complicated for a well-behaved client in the slightest, since a = client behaving in the way that OIDC intends will get the same behavior = from a server, won't it?=20 >=20 > The implementation on the server side is not complicated by these new = semantics, as per my own personal anecdotal experience. I found it = easier to do things this way because it's much more explicit, actually. = What do I do if a client doesn't include a required field? But I'd like = to hear from other server implementors what they think. Our code to do = things in the DynReg style is here, for reference: >=20 > = https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/= master/openid-connect-server/src/main/java/org/mitre/openid/connect/web/Cl= ientDynamicRegistrationEndpoint.java#L349 >=20 > The intentional partial edit method has become a distracting side case = and is not the primary motivator for this change, so please stop = bringing it up as such. The motivation for this change was for safety = from the client's perspective and clarity from the server's perspective = in cases of unintentional partial edits, like the one described above. >=20 > Either way, I'm willing to go with what the Working Group wants to do = here. >=20 > -- Justin >=20 >=20 > On Jan 9, 2013, at 3:20 PM, Mike Jones = wrote: >=20 >> I believe that the client simplicity premise is false in this case. = To perform the initial registration, the client already had to have all = the registration field values. It if wants to update only some of them, = it will still have the old values and can resupply them. >> =20 >> Also, I haven=92t seen any motivating use case for partial update. = Is there such a concrete use case, or is this a hypothetical scenario? >> =20 >> -- Mike >> =20 >> From: Richer, Justin P. [mailto:jricher@mitre.org]=20 >> Sent: Wednesday, January 09, 2013 12:11 PM >> To: John Bradley; Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Difference between client_update semantics in = draft-ietf-oauth-dyn-reg and OpenID Connect Registration >> =20 >> I prefer the DynReg style, as it keeps things simple for clients = (still supports the replace-all mechanics) while making it safer for = them. It's also explicit about how to handle server-asserted values that = a dumb client might ignore. The partial-update is a small added bonus. >> =20 >> -- Justin >> =20 >> On Jan 9, 2013, at 3:05 PM, Justin Richer >> wrote: >>=20 >>=20 >> It's been a few days now and I haven't seen any traffic from the = group about this at all, so I'll just come out and ask for opinions. The = two proposals are: >> =20 >> OIDC-style: >> - inclusion of field replaces that field value on the server with = the new value >> - omission of field deletes that field value on the server >> =20 >> DynReg style: >> - inclusion of field replaces that field value on the server with = the new value >> - omission of field tells the server to leave its current value = alone >> - inclusion of field with an empty string value deletes/clears that = field value from the server >> =20 >> =20 >> Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its = current semantics? Why? Is there another option that's even better? >> =20 >> -- Justin >> =20 >> =20 >> On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." = wrote: >>=20 >>=20 >> Mike, John, thanks for the feedback. I hope and anticipate that this = conversation will help improve both drafts. >>=20 >> I disagree with the assessment here that it makes things more = complicated in the simple case. How? The way that DynReg is currently = written, if the client simply POSTs back the entire set of information = that it has about itself every time, which I anticipate the most simple = clients will do, then it still behaves as expected. Doesn't it? There's = nothing in the draft that REQUIRES an incomplete POST, it just ALLOWS it = to happen and defines what to do when it does. Furthermore, it makes it = *safer* if the client POSTs something that is incomplete from the = *server's* perspective, since the semantics are now, explicitly, to = leave alone any values that are left out. In other words, it's my view = that this actually makes things far simpler for clients wanting to do = simple things, and makes more complex things possible. This is = especially in light of the requirement of the server to echo out the = actual full state of the client during the transaction. Having = implemented this myself, it's really not very complex from either side. = The server is marginally more complex, but it leaves fewer cases = undefined or "up to the server to decide".=20 >>=20 >> Part of the motivation I had for changing this here was to cope with = the cases where the server asserts things about the client that the = client doesn't register about itself in the first place, and I wanted = something that was simple and programmatic to implement from both sides. = In other words, it's assuming that the *server* has the most complete = picture of the client's state, not the *client*, which is the assumption = made in OIDC and by Mike and John's comments below. Let's take this = example as a concrete case (formatting and parameter names are notional = and might be off, I'm typing from memory): >>=20 >> Client registers with params: >>=20 >> client_name=3DFoo >> token_endpoint_auth_type=3Dclient_secret_basic >>=20 >> Server sends back to the client: >> { >> client_name: Foo >> client_secret: super-secret-secret >> token_endpoint_auth_type: client_secret_basic >> scope: read open dennis >> registration_access_token: TOKEN >> } >>=20 >> So the client never asked for scope restriction, but the server = decided (however it wanted to, probably by a defaulting mechanism) to = give the client three scopes. In the current OIDC spec, the client would = never even know this happened because this information isn't ever echoed = back (though this at least is changing). Even if it did know about this = parameter, it didn't ask for anything in particular in that field, so it = now has to keep around something that it doesn't really know what to do = with. So with that in mind, the client decides to change its name and = sends back all the parameters that it knows about: >>=20 >> client_name=3DBar >> token_endpoint_auth_type=3Dclient_secret_basic >> access_token=3DTOKEN >>=20 >> Now in the OIDC definition of the semantics, this tells the server to = clear out the existing "scope" value, because it's not included in the = request. But the server really shouldn't do that, should it? You could = argue that because it's a server-defaulted parameter and that the server = should know to treat it special. But then the server would have to track = which fields are still in a "defaulted" state, or keep some kind of = programming logic that says "a blank on an update actually means = something else". Which fields does this apply to? Neither of those are = "simple".=20 >>=20 >> In the current definition of the DynReg spec, the client not only = knows the fields and can do something about them if it wants to, it can = also *safely* ignore them in responses. If the client sends back the = same set above, dealing only in the parameters that it knows and cares = about, the server now has an unambiguous message when the client omits = the "scope" field.=20 >>=20 >> With this behavior, though, we do need the equivalent of "set to = null" in order to explicitly empty out the value of an existing field. I = took the approach of using a blank value -- expressed in HTTP forms as = an empty string. I'm open to other suggestions if there's a = better/cleaner approach to this part of it, but this was the best I = could come up with. >>=20 >> Finally, it's not a bandwidth issue at all, so let's just ignore that = particular red herring. :) >>=20 >> -- Justin >>=20 >>=20 >>=20 >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of = John Bradley [ve7jtb@ve7jtb.com] >> Sent: Friday, January 04, 2013 7:13 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Difference between client_update semantics in = draft-ietf-oauth-dyn-reg and OpenID Connect Registration >>=20 >> We did discuss this issue in the connect WG. >> =20 >> The decision was made to always completely replace. That prevents = unknown states if a update fails. =20 >> =20 >> I think the always replace everything rule is simpler, though = admittedly more bandwidth is required. However bandwidth is not a = significant factor for this as far as I know. >> =20 >> John B. >> =20 >> On 2013-01-04, at 8:55 PM, Mike Jones = wrote: >>=20 >>=20 >> The client_update operation in = http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something = different than the operation upon which it was based = fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. = Specifically, while the OpenID Connect operation replaces all field = values, the OAuth operation allows only selective fields to be replaced, = designating fields to remain unchanged by specifying their value as the = empty string (=93=94). >> =20 >> I'm personally not happy with the change to the semantics of client = field inclusion. Updating some but not all fields is a substantially = more complicated operation than replacing all fields. Is there some use = case that motivates this? I don't think it's a substantial burden on = the registering party to remember all the field values from the initial = registration and then selectively use them for update operations, when = needed. Then the work goes to the (I suspect rare) parties that need = partial update - not to every server. It complicates the simple case, = rather than pushing the complexity to the rare case, violating the = design principle =93make simple things simple and make more complicated = things possible=94. >> =20 >> Is anyone opposed to updating the OAuth Registration semantics to = match the Connect registration semantics? Is so, why? >> =20 >> = Thanks, >> -- = Mike >> =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 --Apple-Mail=_1B032F5A-434E-4EEB-BF4B-356DDB423A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 One = issue is that some of the top level elements like redirect_uri may be = arrays.  I wouldn't want to start specifying partial replacement = for that.

DynReg should replace all of an array or = object.  I suspect that is the intent = anyway.

I see the benefit of returning the entire = configuration in the response, that allows the client to learn about the = defaults a server has set, and perhaps update them even if they were not = part of the initial registration.

With the = current OIDC defined behavior a missing parameter is taken to be a reset = to the default.   With DynReg the missing parameter is taken to not = change the setting.  Sort of 6 of one half a dozen of the = other.

I am assuming that a client isn't going = to be changing defaults it doesn't care about in the first = instance.

The disadvantage of the DynReg = approach is that the client explicitly needs to reset something to a = default as opposed to it happening each time.

I = don't see much difference in actual use from a client.   I suspect = that the OIDC approach is easier to program on the server side. =  

I don't hate the DynReg approach, = however I am still trying to see the part where it is = better.

John = B.


On 2013-01-09, at = 5:43 PM, "Richer, Justin P." <jricher@mitre.org> = wrote:

Not quite - the client supplies all of the fields that it knows = about, and the server will fill in the rest. This includes any the = client might not know or care about. This comes into play especially = because the list of fields is now extensible by definition, which it wasn't in OIDC. It's exactly this extensibility that will make = OIDC be able to leverage this, so the extensibility needs to be done = right and with conscious consideration.

At the point of initial registration, the client should have all of = the fields returned (something that both DynReg and OIDC Reg now do, per = my latest edits), so a simple client that just posts back this data = model to the server every time it does an update will function exactly the same way in both cases. So you still get the = exact same post-all behavior. 

If instead you have a client that only stores the fields that it = knows about in the original registration request (it's ignorant of = extensions and defaults and doesn't save the raw JSON object), then = you've got an interesting situation. So the client registers a set of fields, the server gives a default for something the client = doesn't ask for (like scope), and returns that JSON back. Now the client = needs to be able to deal with this new field in its local storage, even = if it doesn't care about it, or else risk deleting its server-asserted "scope" value from the server. 

I don't think that limiting the fields you care about is an = unreasonable assumption for a client to make in its data model, either, = but more client authors should chime in here and say if I'm wrong or = not. With this in mind, I don't see at all how this makes things any more complicated for a well-behaved client in the = slightest, since a client behaving in the way that OIDC intends will get = the same behavior from a server, won't it? 

The implementation on the server side is not complicated by these = new semantics, as per my own personal anecdotal experience. I found it = easier to do things this way because it's much more explicit, actually. = What do I do if a client doesn't include a required field? But I'd like to hear from other server implementors = what they think. Our code to do things in the DynReg style is here, for = reference:


The intentional partial edit method has become a distracting side = case and is not the primary motivator for this change, so please stop = bringing it up as such. The motivation for this change was for safety = from the client's perspective and clarity from the server's perspective in cases of unintentional partial edits, like = the one described above.

Either way, I'm willing to go with what the Working Group wants to = do here.

 -- Justin


On Jan 9, 2013, at 3:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I believe that the client simplicity premise is = false in this case.  To perform the initial registration, the = client already had to have all the registration field values.  It if wants to update only some of them, it will still have the old = values and can resupply them.
 
Also, I haven=92t seen any motivating use case for = partial update.  Is there such a concrete use case, or is this a = hypothetical scenario?
 
 
 Richer, = Justin P. [mailto:jricher@mitre.org] 
Sent: Wednesday, = January 09, 2013 12:11 PM
To: John = Bradley; Mike Jones
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Difference between client_update semantics in = draft-ietf-oauth-dyn-reg and OpenID Connect = Registration
 
I prefer the DynReg style, as it keeps things simple for clients (still = supports the replace-all mechanics) while making it safer for them. It's = also explicit about how to handle server-asserted values that a dumb = client might ignore. The partial-update is a small added bonus.
 
 -- Justin
 
On Jan 9, 2013, at 3:05 PM, Justin Richer <jricher@mitre.org>
 wrote:


It's been a few days now and I haven't seen any traffic from the group = about this at all, so I'll just come out and ask for opinions. The two = proposals are:
 
OIDC-style:
 - inclusion of field replaces that field value on the server with = the new value
 - omission of field deletes that field value on the = server
 
DynReg style:
 - inclusion of field replaces that field value on the server with = the new value
 - omission of field tells the server to leave its current value = alone
 - inclusion of field with an empty string value deletes/clears = that field value from the server
 
 
Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its = current semantics? Why? Is there another option that's even = better?
 
 -- Justin
 
 
On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jricher@mitre.org> = wrote:


Mike, = John, thanks for the feedback. I hope and anticipate that this = conversation will help improve both drafts.

I disagree with the assessment here that it makes things more = complicated in the simple case. How? The way that DynReg is currently = written, if the client simply POSTs back the entire set of information = that it has about itself every time, which I anticipate the most simple clients will do, then it still behaves as expected. = Doesn't it? There's nothing in the draft that REQUIRES an incomplete = POST, it just ALLOWS it to happen and defines what to do when it does. = Furthermore, it makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the = semantics are now, explicitly, to leave alone any values that are left = out. In other words, it's my view that this actually makes things far = simpler for clients wanting to do simple things, and makes more complex things possible. This is especially in light of = the requirement of the server to echo out the actual full state of the = client during the transaction. Having implemented this myself, it's = really not very complex from either side. The server is marginally more complex, but it leaves fewer cases undefined = or "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the = cases where the server asserts things about the client that the client = doesn't register about itself in the first place, and I wanted something = that was simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has = the most complete picture of the client's state, not the *client*, which = is the assumption made in OIDC and by Mike and John's comments below. = Let's take this example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from = memory):

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided = (however it wanted to, probably by a defaulting mechanism) to give the = client three scopes. In the current OIDC spec, the client would never = even know this happened because this information isn't ever echoed back (though this at least is changing). Even if it = did know about this parameter, it didn't ask for anything in particular = in that field, so it now has to keep around something that it doesn't = really know what to do with. So with that in mind, the client decides to change its name and sends back all the = parameters that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to = clear out the existing "scope" value, because it's not included in the = request. But the server really shouldn't do that, should it? You could = argue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the = server would have to track which fields are still in a "defaulted" = state, or keep some kind of programming logic that says "a blank on an = update actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows = the fields and can do something about them if it wants to, it can also = *safely* ignore them in responses. If the client sends back the same set = above, dealing only in the parameters that it knows and cares about, the server now has an unambiguous message = when the client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null" = in order to explicitly empty out the value of an existing field. I took = the approach of using a blank value -- expressed in HTTP forms as an = empty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the = best I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that = particular red herring. :)

 -- Justin


 [oauth-bounces@ietf.org] on behalf of John Bradley [ Friday, = January 04, 2013 7:13 PM
To: Mike = Jones
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Difference between client_update semantics in = draft-ietf-oauth-dyn-reg and OpenID Connect = Registration

We did discuss this issue in the connect WG.
 
The decision was made to always completely replace.   That prevents = unknown states if a update fails.   
 
I think the always replace everything rule is simpler, though admittedly = more bandwidth is required.  However bandwidth is not a significant = factor for this as far as I know.
 
John B.
 
On 2013-01-04, at 8:55 PM, Mike Jones <

The = client_update operation in  does something different than the operation upon which it was based from I'm = personally not happy with the change to the semantics of client field = inclusion.  Updating some but not all fields is a substantially = more complicated operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a = substantial burden on the registering party to remember all the field = values from the initial registration and then selectively use them for = update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every = server.  It complicates the simple case, rather than pushing the = complexity to the rare case, violating the design principle =93make = simple things simple and make more complicated things possible=94.
Is = anyone opposed to updating the OAuth Registration semantics to match the = Connect registration semantics?  Is so, = why?
 



= --Apple-Mail=_1B032F5A-434E-4EEB-BF4B-356DDB423A34-- From jricher@mitre.org Thu Jan 10 11:47:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B321F8583 for ; Thu, 10 Jan 2013 11:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7RdudO4EFH8 for ; Thu, 10 Jan 2013 11:47:53 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1204921F85AC for ; Thu, 10 Jan 2013 11:47:53 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 741AF1F0DC6; Thu, 10 Jan 2013 14:47:52 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 576F61F0DDD; Thu, 10 Jan 2013 14:47:52 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 14:47:51 -0500 Message-ID: <50EF1AE4.10301@mitre.org> Date: Thu, 10 Jan 2013 14:47:48 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Bradley References: <4E1F6AAD24975D4BA5B168042967394366A0964B@TK5EX14MBXC283.redmond.corp.microsoft.com> <00E975D3-461B-4130-AD77-58BFD99452F4@ve7jtb.com> In-Reply-To: <00E975D3-461B-4130-AD77-58BFD99452F4@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------030702090308000203040606" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:47:56 -0000 --------------030702090308000203040606 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit > One issue is that some of the top level elements like redirect_uri may > be arrays. I wouldn't want to start specifying partial replacement > for that. > > DynReg should replace all of an array or object. I suspect that is > the intent anyway. For values within the metadata, that's absolutely true, and I agree that you don't want to get into PATCH-style specifics of sub-objects and elements. To that end, DynReg is explicit about doing just what you describe. See the language from 3.3 about how fields are handled on update, which is the real crux of this whole discussion: This [client_update] request MAY include any fields described in Client Metadata [client-metadata]. If included in the request, valid values of Client Metadata fields in this request MUST replace, not augment, the values previously associated with this Client. Empty values in Client Metadata MUST be taken as a request to clear any existing value of that field. Omitted values in the Client Metadata MUST remain unchanged by the Authorization Server. The Authorization Server MAY replace any invalid values with suitable values. > > I see the benefit of returning the entire configuration in the > response, that allows the client to learn about the defaults a server > has set, and perhaps update them even if they were not part of the > initial registration. > > With the current OIDC defined behavior a missing parameter is taken to > be a reset to the default. With DynReg the missing parameter is > taken to not change the setting. Sort of 6 of one half a dozen of the > other. > I don't believe that's actually true -- if it were, we'd be saying nearly the same thing and I'd be less adamant about my position. As it's written right now, OIDC isn't actually clear on what to do if a client fails to provide a field. However, the obvious implication, and this is reading between the lines, is that the server deletes/clears the value. This comes from the idea that the client MUST provide an entire data object to the server every time. If something's not included in the data object, that's telling the server to remove it, is it not? The server is of course at liberty to say that an empty value isn't OK for a given field and fill in a default. But I think this gets convoluted quickly in implementation because you've got to track if a field is emptyable by a client or if it was given a default in the first place, etc. > I am assuming that a client isn't going to be changing defaults it > doesn't care about in the first instance. My assumption as well, which is why I wanted to make the non-explicit case a "safe" operation. > > The disadvantage of the DynReg approach is that the client explicitly > needs to reset something to a default as opposed to it happening each > time. I see that as an advantage. As a client, I wouldn't want things getting reset on me without my asking for it. Again, it's an argument for safety. > > I don't see much difference in actual use from a client. I suspect > that the OIDC approach is easier to program on the server side. Having programmed both on a server, I found DynReg simpler to build. It's a very deterministic formula and all fields are handled the same way. I agree that the client side is basically the same in both cases. -- Justin > > I don't hate the DynReg approach, however I am still trying to see the > part where it is better. > > John B. > > > On 2013-01-09, at 5:43 PM, "Richer, Justin P." > wrote: > >> Not quite - the client supplies all of the fields that it knows >> about, and the server will fill in the rest. This includes any the >> client might not know or care about. This comes into play especially >> because the list of fields is now extensible by definition, which it >> wasn't in OIDC. It's exactly this extensibility that will make OIDC >> be able to leverage this, so the extensibility needs to be done right >> and with conscious consideration. >> >> At the point of initial registration, the client should have all of >> the fields returned (something that both DynReg and OIDC Reg now do, >> per my latest edits), so a simple client that just posts back this >> data model to the server every time it does an update will function >> exactly the same way in both cases. So you still get the exact same >> post-all behavior. >> >> If instead you have a client that only stores the fields that it >> knows about in the original registration request (it's ignorant of >> extensions and defaults and doesn't save the raw JSON object), then >> you've got an interesting situation. So the client registers a set of >> fields, the server gives a default for something the client doesn't >> ask for (like scope), and returns that JSON back. Now the client >> needs to be able to deal with this new field in its local storage, >> even if it doesn't care about it, or else risk deleting its >> server-asserted "scope" value from the server. >> >> I don't think that limiting the fields you care about is an >> unreasonable assumption for a client to make in its data model, >> either, but more client authors should chime in here and say if I'm >> wrong or not. With this in mind, I don't see at all how this makes >> things any more complicated for a well-behaved client in the >> slightest, since a client behaving in the way that OIDC intends will >> get the same behavior from a server, won't it? >> >> The implementation on the server side is not complicated by these new >> semantics, as per my own personal anecdotal experience. I found it >> easier to do things this way because it's much more explicit, >> actually. What do I do if a client doesn't include a required field? >> But I'd like to hear from other server implementors what they think. >> Our code to do things in the DynReg style is here, for reference: >> >> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/web/ClientDynamicRegistrationEndpoint.java#L349 >> >> The intentional partial edit method has become a distracting side >> case and is not the primary motivator for this change, so please stop >> bringing it up as such. The motivation for this change was for safety >> from the client's perspective and clarity from the server's >> perspective in cases of unintentional partial edits, like the one >> described above. >> >> Either way, I'm willing to go with what the Working Group wants to do >> here. >> >> -- Justin >> >> >> On Jan 9, 2013, at 3:20 PM, Mike Jones > > wrote: >> >>> I believe that the client simplicity premise is false in this case. >>> To perform the initial registration, the client already had to have >>> all the registration field values. It if wants to update only some >>> of them, it will still have the old values and can resupply them. >>> Also, I havent seen any motivating use case for partial update. Is >>> there such a concrete use case, or is this a hypothetical scenario? >>> -- Mike >>> *From:*Richer, Justin P. [mailto:jricher@mitre.org ] >>> *Sent:*Wednesday, January 09, 2013 12:11 PM >>> *To:*John Bradley; Mike Jones >>> *Cc:*oauth@ietf.org >>> *Subject:*Re: [OAUTH-WG] Difference between client_update semantics >>> in draft-ietf-oauth-dyn-reg and OpenID Connect Registration >>> I prefer the DynReg style, as it keeps things simple for clients >>> (still supports the replace-all mechanics) while making it safer for >>> them. It's also explicit about how to handle server-asserted values >>> that a dumb client might ignore. The partial-update is a small added >>> bonus. >>> -- Justin >>> On Jan 9, 2013, at 3:05 PM, Justin Richer >> > >>> wrote: >>> >>> >>> It's been a few days now and I haven't seen any traffic from the >>> group about this at all, so I'll just come out and ask for opinions. >>> The two proposals are: >>> OIDC-style: >>> - inclusion of field replaces that field value on the server with >>> the new value >>> - omission of field deletes that field value on the server >>> DynReg style: >>> - inclusion of field replaces that field value on the server with >>> the new value >>> - omission of field tells the server to leave its current value alone >>> - inclusion of field with an empty string value deletes/clears that >>> field value from the server >>> Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its >>> current semantics? Why? Is there another option that's even better? >>> -- Justin >>> On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." >> > wrote: >>> >>> >>> Mike, John, thanks for the feedback. I hope and anticipate that this >>> conversation will help improve both drafts. >>> >>> I disagree with the assessment here that it makes things more >>> complicated in the simple case. How? The way that DynReg is >>> currently written, if the client simply POSTs back the entire set of >>> information that it has about itself every time, which I anticipate >>> the most simple clients will do, then it still behaves as expected. >>> Doesn't it? There's nothing in the draft that REQUIRES an incomplete >>> POST, it just ALLOWS it to happen and defines what to do when it >>> does. Furthermore, it makes it *safer* if the client POSTs something >>> that is incomplete from the *server's* perspective, since the >>> semantics are now, explicitly, to leave alone any values that are >>> left out. In other words, it's my view that this actually makes >>> things far simpler for clients wanting to do simple things, and >>> makes more complex things possible. This is especially in light of >>> the requirement of the server to echo out the actual full state of >>> the client during the transaction. Having implemented this myself, >>> it's really not very complex from either side. The server is >>> marginally more complex, but it leaves fewer cases undefined or "up >>> to the server to decide". >>> >>> Part of the motivation I had for changing this here was to cope with >>> the cases where the server asserts things about the client that the >>> client doesn't register about itself in the first place, and I >>> wanted something that was simple and programmatic to implement from >>> both sides. In other words, it's assuming that the *server* has the >>> most complete picture of the client's state, not the *client*, which >>> is the assumption made in OIDC and by Mike and John's comments >>> below. Let's take this example as a concrete case (formatting and >>> parameter names are notional and might be off, I'm typing from memory): >>> >>> Client registers with params: >>> >>> client_name=Foo >>> token_endpoint_auth_type=client_secret_basic >>> >>> Server sends back to the client: >>> { >>> client_name: Foo >>> client_secret: super-secret-secret >>> token_endpoint_auth_type: client_secret_basic >>> scope: read open dennis >>> registration_access_token: TOKEN >>> } >>> >>> So the client never asked for scope restriction, but the server >>> decided (however it wanted to, probably by a defaulting mechanism) >>> to give the client three scopes. In the current OIDC spec, the >>> client would never even know this happened because this information >>> isn't ever echoed back (though this at least is changing). Even if >>> it did know about this parameter, it didn't ask for anything in >>> particular in that field, so it now has to keep around something >>> that it doesn't really know what to do with. So with that in mind, >>> the client decides to change its name and sends back all the >>> parameters that it knows about: >>> >>> client_name=Bar >>> token_endpoint_auth_type=client_secret_basic >>> access_token=TOKEN >>> >>> Now in the OIDC definition of the semantics, this tells the server >>> to clear out the existing "scope" value, because it's not included >>> in the request. But the server really shouldn't do that, should it? >>> You could argue that because it's a server-defaulted parameter and >>> that the server should know to treat it special. But then the server >>> would have to track which fields are still in a "defaulted" state, >>> or keep some kind of programming logic that says "a blank on an >>> update actually means something else". Which fields does this apply >>> to? Neither of those are "simple". >>> >>> In the current definition of the DynReg spec, the client not only >>> knows the fields and can do something about them if it wants to, it >>> can also *safely* ignore them in responses. If the client sends back >>> the same set above, dealing only in the parameters that it knows and >>> cares about, the server now has an unambiguous message when the >>> client omits the "scope" field. >>> >>> With this behavior, though, we do need the equivalent of "set to >>> null" in order to explicitly empty out the value of an existing >>> field. I took the approach of using a blank value -- expressed in >>> HTTP forms as an empty string. I'm open to other suggestions if >>> there's a better/cleaner approach to this part of it, but this was >>> the best I could come up with. >>> >>> Finally, it's not a bandwidth issue at all, so let's just ignore >>> that particular red herring. :) >>> >>> -- Justin >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*oauth-bounces@ietf.org >>> [oauth-bounces@ietf.org >>> ] on behalf of John Bradley >>> [ve7jtb@ve7jtb.com ] >>> *Sent:*Friday, January 04, 2013 7:13 PM >>> *To:*Mike Jones >>> *Cc:*oauth@ietf.org >>> *Subject:*Re: [OAUTH-WG] Difference between client_update semantics >>> in draft-ietf-oauth-dyn-reg and OpenID Connect Registration >>> >>> We did discuss this issue in the connect WG. >>> The decision was made to always completely replace. That prevents >>> unknown states if a update fails. >>> I think the always replace everything rule is simpler, though >>> admittedly more bandwidth is required. However bandwidth is not a >>> significant factor for this as far as I know. >>> John B. >>> On 2013-01-04, at 8:55 PM, Mike Jones >> > wrote: >>> >>> >>> The client_update operation >>> inhttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03does >>> something different than the operation upon which it was based >>> fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. >>> Specifically, while the OpenID Connect operation replaces all field >>> values, the OAuth operation allows only selective fields to be >>> replaced, designating fields to remain unchanged by specifying their >>> value as the empty string (). >>> I'm personally not happy with the change to the semantics of client >>> field inclusion. Updating some but not all fields is a substantially >>> more complicated operation than replacing all fields. Is there some >>> use case that motivates this? I don't think it's a substantial >>> burden on the registering party to remember all the field values >>> from the initial registration and then selectively use them for >>> update operations, when needed. Then the work goes to the (I >>> suspect rare) parties that need partial update - not to every >>> server. It complicates the simple case, rather than pushing the >>> complexity to the rare case, violating the design principle make >>> simple things simple and make more complicated things possible. >>> Is anyone opposed to updating the OAuth Registration semantics to >>> match the Connect registration semantics? Is so, why? >>> Thanks, >>> -- Mike >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > --------------030702090308000203040606 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

One issue is that some of the top level elements like redirect_uri may be arrays. I wouldn't want to start specifying partial replacement for that.

DynReg should replace all of an array or object. I suspect that is the intent anyway.

For values within the metadata, that's absolutely true, and I agree that you don't want to get into PATCH-style specifics of sub-objects and elements. To that end, DynReg is explicit about doing just what you describe. See the language from 3.3 about how fields are handled on update, which is the real crux of this whole discussion:

This [client_update] request MAY include any fields described in Client Metadata [client-metadata]. If included in the request, valid values of Client Metadata fields in this request MUST replace, not augment, the values previously associated with this Client. Empty values in Client Metadata MUST be taken as a request to clear any existing value of that field. Omitted values in the Client Metadata MUST remain unchanged by the Authorization Server. The Authorization Server MAY replace any invalid values with suitable values.


I see the benefit of returning the entire configuration in the response, that allows the client to learn about the defaults a server has set, and perhaps update them even if they were not part of the initial registration.

With the current OIDC defined behavior a missing parameter is taken to be a reset to the default. With DynReg the missing parameter is taken to not change the setting. Sort of 6 of one half a dozen of the other.

I don't believe that's actually true -- if it were, we'd be saying nearly the same thing and I'd be less adamant about my position. As it's written right now, OIDC isn't actually clear on what to do if a client fails to provide a field. However, the obvious implication, and this is reading between the lines, is that the server deletes/clears the value. This comes from the idea that the client MUST provide an entire data object to the server every time. If something's not included in the data object, that's telling the server to remove it, is it not?

The server is of course at liberty to say that an empty value isn't OK for a given field and fill in a default. But I think this gets convoluted quickly in implementation because you've got to track if a field is emptyable by a client or if it was given a default in the first place, etc.

I am assuming that a client isn't going to be changing defaults it doesn't care about in the first instance.

My assumption as well, which is why I wanted to make the non-explicit case a "safe" operation.


The disadvantage of the DynReg approach is that the client explicitly needs to reset something to a default as opposed to it happening each time.

I see that as an advantage. As a client, I wouldn't want things getting reset on me without my asking for it. Again, it's an argument for safety.


I don't see much difference in actual use from a client. I suspect that the OIDC approach is easier to program on the server side.

Having programmed both on a server, I found DynReg simpler to build. It's a very deterministic formula and all fields are handled the same way. I agree that the client side is basically the same in both cases.


-- Justin


I don't hate the DynReg approach, however I am still trying to see the part where it is better.

John B.


On 2013-01-09, at 5:43 PM, "Richer, Justin P." <jricher@mitre.org> wrote:

Not quite - the client supplies all of the fields that it knows about, and the server will fill in the rest. This includes any the client might not know or care about. This comes into play especially because the list of fields is now extensible by definition, which it wasn't in OIDC. It's exactly this extensibility that will make OIDC be able to leverage this, so the extensibility needs to be done right and with conscious consideration.

At the point of initial registration, the client should have all of the fields returned (something that both DynReg and OIDC Reg now do, per my latest edits), so a simple client that just posts back this data model to the server every time it does an update will function exactly the same way in both cases. So you still get the exact same post-all behavior.

If instead you have a client that only stores the fields that it knows about in the original registration request (it's ignorant of extensions and defaults and doesn't save the raw JSON object), then you've got an interesting situation. So the client registers a set of fields, the server gives a default for something the client doesn't ask for (like scope), and returns that JSON back. Now the client needs to be able to deal with this new field in its local storage, even if it doesn't care about it, or else risk deleting its server-asserted "scope" value from the server.

I don't think that limiting the fields you care about is an unreasonable assumption for a client to make in its data model, either, but more client authors should chime in here and say if I'm wrong or not. With this in mind,I don't see at all how this makes things any more complicated for a well-behaved client in the slightest, since a client behaving in the way that OIDC intends will get the same behavior from a server, won't it?

The implementation on the server side is not complicated by these new semantics, as per my own personal anecdotal experience. I found it easier to do things this way because it's much more explicit, actually. What do I do if a client doesn't include a required field? But I'd like to hear from other server implementors what they think. Our code to do things in the DynReg style is here, for reference:


The intentional partial edit method has become a distracting side case and is not the primary motivator for this change, so please stop bringing it up as such. The motivation for this change was for safety from the client's perspective and clarity from the server's perspective in cases of unintentional partial edits, like the one described above.

Either way, I'm willing to go with what the Working Group wants to do here.

-- Justin


On Jan 9, 2013, at 3:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I believe that the client simplicity premise is false in this case. To perform the initial registration, the client already had to have all the registration field values. It if wants to update only some of them, it will still have the old values and can resupply them.
Also, I havent seen any motivating use case for partial update. Is there such a concrete use case, or is this a hypothetical scenario?
-- Mike
From:Richer, Justin P. [mailto:jricher@mitre.org]
Sent:Wednesday, January 09, 2013 12:11 PM
To:John Bradley; Mike Jones
Cc:oauth@ietf.org
Subject:Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration
I prefer the DynReg style, as it keeps things simple for clients (still supports the replace-all mechanics) while making it safer for them. It's also explicit about how to handle server-asserted values that a dumb client might ignore. The partial-update is a small added bonus.
-- Justin
On Jan 9, 2013, at 3:05 PM, Justin Richer <jricher@mitre.org>
wrote:


It's been a few days now and I haven't seen any traffic from the group about this at all, so I'll just come out and ask for opinions. The two proposals are:
OIDC-style:
- inclusion of field replaces that field value on the server with the new value
- omission of field deletes that field value on the server
DynReg style:
- inclusion of field replaces that field value on the server with the new value
- omission of field tells the server to leave its current value alone
- inclusion of field with an empty string value deletes/clears that field value from the server
Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its current semantics? Why? Is there another option that's even better?
-- Justin
On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jricher@mitre.org> wrote:


Mike, John, thanks for the feedback. I hope and anticipate that this conversation will help improve both drafts.

I disagree with the assessment here that it makes things more complicated in the simple case. How? The way that DynReg is currently written, if the client simply POSTs back the entire set of information that it has about itself every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn't it? There's nothing in the draft that REQUIRES an incomplete POST, it just ALLOWS it to happen and defines what to do when it does. Furthermore, it makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the semantics are now, explicitly, to leave alone any values that are left out. In other words, it's my view that this actually makes things far simpler for clients wanting to do simple things, and makes more complex things possible. This is especially in light of the requirement of the server to echo out the actual full state of the client during the transaction. Having implemented this myself, it's really not very complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or "up to the server to decide".

Part of the motivation I had for changing this here was to cope with the cases where the server asserts things about the client that the client doesn't register about itself in the first place, and I wanted something that was simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the most complete picture of the client's state, not the *client*, which is the assumption made in OIDC and by Mike and John's comments below. Let's take this example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory):

Client registers with params:

client_name=Foo
token_endpoint_auth_type=client_secret_basic

Server sends back to the client:
{
client_name: Foo
client_secret: super-secret-secret
token_endpoint_auth_type: client_secret_basic
scope: read open dennis
registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (however it wanted to, probably by a defaulting mechanism) to give the client three scopes. In the current OIDC spec, the client would never even know this happened because this information isn't ever echoed back (though this at least is changing). Even if it did know about this parameter, it didn't ask for anything in particular in that field, so it now has to keep around something that it doesn't really know what to do with. So with that in mind, the client decides to change its name and sends back all the parameters that it knows about:

client_name=Bar
token_endpoint_auth_type=client_secret_basic
access_token=TOKEN

Now in the OIDC definition of the semantics, this tells the server to clear out the existing "scope" value, because it's not included in the request. But the server really shouldn't do that, should it? You could argue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server would have to track which fields are still in a "defaulted" state, or keep some kind of programming logic that says "a blank on an update actually means something else". Which fields does this apply to? Neither of those are "simple".

In the current definition of the DynReg spec, the client not only knows the fields and can do something about them if it wants to, it can also *safely* ignore them in responses. If the client sends back the same set above, dealing only in the parameters that it knows and cares about, the server now has an unambiguous message when the client omits the "scope" field.

With this behavior, though, we do need the equivalent of "set to null" in order to explicitly empty out the value of an existing field. I took the approach of using a blank value -- expressed in HTTP forms as an empty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the best I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that particular red herring. :)

-- Justin


From:oauth-bounces@ietf.org[oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent:Friday, January 04, 2013 7:13 PM
To:Mike Jones
Cc:oauth@ietf.org
Subject:Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

We did discuss this issue in the connect WG.
The decision was made to always completely replace. That prevents unknown states if a update fails.
I think the always replace everything rule is simpler, though admittedly more bandwidth is required. However bandwidth is not a significant factor for this as far as I know.
John B.
On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:


The client_update operation inhttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. Specifically, while the OpenID Connect operation replaces all field values, the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifying their value as the empty string ().
I'm personally not happy with the change to the semantics of client field inclusion. Updating some but not all fields is a substantially more complicated operation than replacing all fields. Is there some use case that motivates this? I don't think it's a substantial burden on the registering party to remember all the field values from the initial registration and then selectively use them for update operations, when needed. Then the work goes to the (I suspect rare) parties that need partial update - not to every server. It complicates the simple case, rather than pushing the complexity to the rare case, violating the design principle make simple things simple and make more complicated things possible.
Is anyone opposed to updating the OAuth Registration semantics to match the Connect registration semantics? Is so, why?
Thanks,
-- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--------------030702090308000203040606-- From peter.mauritius@fun.de Thu Jan 10 13:37:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629EB21F85EA for ; Thu, 10 Jan 2013 13:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXW8l9jwIJjw for ; Thu, 10 Jan 2013 13:37:19 -0800 (PST) Received: from mailfwd.fun.de (fungate2.fun.de [IPv6:2a01:198:3c6:1:81:26:162:57]) by ietfa.amsl.com (Postfix) with ESMTP id BBB3E21F85D7 for ; Thu, 10 Jan 2013 13:37:15 -0800 (PST) Received: from hsi-kbw-109-193-164-118.hsi7.kabel-badenwuerttemberg.de ([109.193.164.118] helo=funmiraus.local) by mailfwd.fun.de with esmtpsa (Exim 4.69 #1 (Debian)) id 1TtPoE-0006Ts-9d; Thu, 10 Jan 2013 22:37:10 +0100 Message-ID: <50EF348B.4080104@fun.de> Date: Thu, 10 Jan 2013 22:37:15 +0100 From: Peter Mauritius Organization: fun communications GmbH, Karlsruhe, Germany User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0a2 MIME-Version: 1.0 To: George Fletcher References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de> <50ED6BBB.40008@aol.com> <50ED71D9.5080703@fun.de> <50ED8F85.5000604@aol.com> In-Reply-To: <50ED8F85.5000604@aol.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010101050705010407030501" Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:37:21 -0000 This is a cryptographically signed message in MIME format. --------------ms010101050705010407030501 Content-Type: multipart/alternative; boundary="------------030708050708080103070907" This is a multi-part message in MIME format. --------------030708050708080103070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi George, I am with you and support your suggestion. An "invalid_parameter" error=20 code would be a practical solution that would allow to distinguish=20 between token usage and token as parameter. Regards Peter Am 09.01.13 16:40, schrieb George Fletcher: > While this can work, it seems like it's mixing semantics a little as=20 > well. 'invalid_request' normally mean that the request is malformed in = > some way. Even 'unsupported parameter value' is really addressing a=20 > malformed request (e.g. a parameter only allows values of 'true' and=20 > 'false' and the invocation uses the value 'maybe'). > > What about registering an error code of 'invalid_parameter_value'.=20 > Then the description could explain which parameter value is invalid=20 > and possibly why. We might even be able to shorten this to=20 > 'invalid_parameter' as 'invalid_request' handles the case of an=20 > unsupported/invalid parameter name. > > I did a quick check of the OpenID Connect specs and they also don't=20 > define an 'invalid_parameter' error code. > > Thanks, > George > > On 1/9/13 8:34 AM, Peter Mauritius wrote: >> Ok, >> >> now I understand your intention. In oauth-revocation the token is=20 >> just a parameter not an authorization token as in RFC6750. RFC6749=20 >> uses "invalid_request" for >>> includes an unsupported parameter value >> Perhaps we should drop the error-code and use invalid-request with a=20 >> error-description explaining the token parameter is not usable. >> >> Regards >> Peter >> >> On 09.01.2013 14:08, George Fletcher wrote: >>> Hi Peter, >>> >>> I do agree that the meanings of 'invalid_token' between the two=20 >>> specs (6750 and revocation) are different. After thinking about this = >>> for a while, I've determined, at least for myself, what the=20 >>> difference is between the 'invalid_token' error code in RFC 6750 and = >>> the revocation spec. >>> >>> In RFC 6750 'invalid_token' means that the authorization token for=20 >>> the request is invalid. >>> >>> In 'oauth-revocation', 'invalid_token' means that the parameter=20 >>> containing the token to be revoked is invalid. >>> >>> I am very concerned about using the same error string,=20 >>> 'invalid_token', to mean two different things. While the semantic=20 >>> difference is not great in this case, I think it sets a bad=20 >>> precedent for OAuth to have the same error string have two different = >>> semantic meanings. >>> >>> I do agree that the error code used in this spec should be registered= =2E >>> >>> Thanks, >>> George >>> >>> On 1/8/13 5:07 PM, Peter Mauritius wrote: >>>> Hi George, >>>> >>>> RFC6750 defines "invalid-token" for access tokens which is not the=20 >>>> case for "invalid-token" in the revocation specification. Here it=20 >>>> is applicable for refresh tokens as well. Therefore we should not=20 >>>> simply reference the "invalid-token" of RFC6750. >>>> >>>> As far as I understand both, the reviewed specification and=20 >>>> RFC6750, reference RFC6749. RFC6750 includes in section 6.1=20 >>>> OAuth Extensions=20 >>>> Error Registration sections according to RFC6749 section 11.4.=20 >>>> for the error=20 >>>> codes defined throughout the document including "invalid-token". >>>> >>>> I am not very experienced in the formal process but shouldn't we=20 >>>> add such sections for the two error codes defined in the revocation = >>>> document? Especially for "invalid-token" we should define an error=20 >>>> registration section that defines the error code for our error=20 >>>> usage location and protocol extension to distinguish it from=20 >>>> RFC6750 and to avoid confusion. Doing this I hope there is no=20 >>>> necessity to add a reference to RFC6750 or to define a new error cod= e. >>>> >>>> What do the more experienced reviewers think? >>>> >>>> Regards >>>> Peter >>>> >>>> Am 07.01.13 17:25, schrieb George Fletcher: >>>>> My concern with leaving both specs separated is that over time the = >>>>> semantics of the two error codes could diverge and that would be=20 >>>>> confusing for developers. If we don't want to create a dependency=20 >>>>> on RFC 6750, then I would recommend a change to the error code=20 >>>>> name so that there is no name collision or confusion. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >>>>>> Hi George, >>>>>> >>>>>> thank you for pointing this out. Your proposal sounds reasonable=20 >>>>>> although the revocation spec does not build on top of RFC 6750. >>>>>> >>>>>> As refering to RFC 6750 would create a new dependency, one could=20 >>>>>> also argue it would be more robust to leave both specs separated. >>>>>> >>>>>> What do others think? >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> Am 07.01.2013 17:12, schrieb George Fletcher: >>>>>>> One quick comment... >>>>>>> >>>>>>> Section 2.0: Both RFC 6750 and this specification define the=20 >>>>>>> 'invalid_token' error code. >>>>>>> >>>>>>> Should this spec reference the error code from RFC 6750? >>>>>>> >>>>>>> Thanks, >>>>>>> George >>>>>>> >>>>>>> >>>>>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the new revision is based on the WGLC feedback and incorporates = >>>>>>>> the following changes: >>>>>>>> >>>>>>>> - renamed "access grant" to "authorization" and reworded parts=20 >>>>>>>> of Abstract and Intro in order to better align with core spec=20 >>>>>>>> wording (feedback by Amanda) >>>>>>>> - improved formatting of section 2.1. (feedback by Amanda) >>>>>>>> - improved wording of last paragraph of section 6 (feedback by=20 >>>>>>>> Amanda) >>>>>>>> - relaxed the expected behavior regarding revocation of related = >>>>>>>> tokens and the authorization itself in order to remove=20 >>>>>>>> unintended constraints on implementations (feedback by Mark) >>>>>>>> - replaced description of error handling by pointer to=20 >>>>>>>> respective section of core spec (as proposed by Peter) >>>>>>>> - adopted proposed text for implementation note (as proposed by = >>>>>>>> Hannes) >>>>>>>> >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: >>>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>>> Internet-Drafts directories. >>>>>>>>> This draft is a work item of the Web Authorization Protocol=20 >>>>>>>>> Working Group of the IETF. >>>>>>>>> >>>>>>>>> Title : Token Revocation >>>>>>>>> Author(s) : Torsten Lodderstedt >>>>>>>>> Stefanie Dronia >>>>>>>>> Marius Scurtescu >>>>>>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>>>>>> Pages : 8 >>>>>>>>> Date : 2013-01-07 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> This document proposes an additional endpoint for OAuth=20 >>>>>>>>> authorization >>>>>>>>> servers, which allows clients to notify the authorization=20 >>>>>>>>> server that >>>>>>>>> a previously obtained refresh or access token is no longer = >>>>>>>>> needed. >>>>>>>>> This allows the authorization server to cleanup security=20 >>>>>>>>> credentials. >>>>>>>>> A revocation request will invalidate the actual token and, = if >>>>>>>>> applicable, other tokens based on the same authorization. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>>>>>> >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-= 04 >>>>>>>>> >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> --=20 >>>> Peter Mauritius Chief Technical Director >>>> Senior Consultant >>>> Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.mauritius@fun.de >>>> >>>> fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe >>>> Geschaeftsfuehrer Johannes Feulner >>>> Amtsgericht Mannheim HRB 106906 >>>> >>>> http://www.fun.de >>>> http://blogs.fun.de >>>> http://www.twitter.com/fun_de >>>> http://www.facebook.com/funcommunications >>> > > --=20 > George Fletcher --=20 Peter Mauritius Chief Technical Director Senior Consultant Tel: +49 721 96448-0 Fax: +49 721 96448-299 peter.mauritius@fun.de fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe Geschaeftsfuehrer Johannes Feulner Amtsgericht Mannheim HRB 106906 http://www.fun.de http://blogs.fun.de http://www.twitter.com/fun_de http://www.facebook.com/funcommunications --------------030708050708080103070907 Content-Type: multipart/related; boundary="------------080607010905030100010307" --------------080607010905030100010307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,

I am with you and support your suggestion. An "invalid_parameter" error code would be a practical solution that would allow to distinguish between token usage and token as parameter.

Regards
  Peter

Am 09.01.13 16:40, schrieb George Fletcher:
While this can work, it= seems like it's mixing semantics a little as well. 'invalid_request' normally mean that the request is malformed in some way. Even 'unsupported parameter value' is really addressing a malformed request (e.g. a parameter only allows values of 'true' and 'false' and the invocation uses the value 'maybe').

What about registering an error code of 'invalid_parameter_value'. Then the description could explain which parameter value is invalid and possibly why. We might even be able to shorten this to 'invalid_parameter' as 'invalid_request' handles the case of an unsupported/invalid parameter name.

I did a quick check of the OpenID Connect specs and they also don't define an 'invalid_parameter' error code.

Thanks,
George
On 1/9/13 8:34 AM, Peter Mauritius wrote:
Ok,

now I understand your intention. In oauth-revocation the token is just a parameter not an authorization token as in RFC6750. RFC6749 uses  "invalid_request" for 
includes an unsupported parameter value =
Perhaps we should drop the error-code and use invalid-request with a error-description explaining the token parameter is not usable.

Regards
  Peter

On 09.01.2013 14:08, George Fletcher wrote:
Hi Peter,

I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec.

In RFC 6750 'invalid_token' means that the authorization token for the request is invalid.

In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid.
=
I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings.

I do agree that the error code used in this spec should be registered.

Thanks,
George
On 1/8/13 5:07 PM, Peter Mauritius wrote:
=
Hi George,

RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.

As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in s= ection 6.1  OAuth Extensions Error Registration section= s according to = RFC6749 section 11.4. for the error codes defined throughout the document including "invalid-token". 

I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.

What do the more experienced reviewers think?

Regards 
  Peter

Am 07.01.13 17:25, schrieb George Fletcher:
My concern with= leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.

Thanks,
George
On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
Hi George,

thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.

As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.

What do others think?

regards,
Torsten.
Am 07.01.2013 17:12, schrieb George Fletcher:
One quick comment...

Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.

Should this spec reference the error code from RFC 6750?

Thanks,
George
On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
Hi,

the new revision is based on the WGLC feedback and incorporates the following changes:

- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)
- improved formatting of section 2.1. (feedback by Amanda)
- improved wording of last paragraph of section 6 (feedback by Amanda)
- relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark)
- replaced description of error handling by pointer to respective section of core spec (as proposed by Peter)
- adopted proposed text for implementation note (as proposed by Hannes)

regards,
Torsten.

Am 07.01.2013 13:00, schrieb internet-d= rafts@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 Working Group of the IETF.

    Title   &nbs= p;       : Token Revocation
    Author(s)   =     : Torsten Lodderstedt
        &nb= sp;           &nbs= p;      Stefanie Dronia
        &nb= sp;           &nbs= p;      Marius Scurtescu
    Filename   &= nbsp;    : draft-ietf-oauth-revocation-04.txt
    Pages   &nbs= p;       : 8
    Date    = ;        : 2013-01-07

Abstract:
    This document proposes an additi= onal endpoint for OAuth authorization
    servers, which allows clients to= notify the authorization server that
    a previously obtained refresh or= access token is no longer needed.
    This allows the authorization se= rver to cleanup security credentials.
    A revocation request will invali= date the actual token and, if
    applicable, other tokens based o= n the same authorization.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-re= vocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-= 04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-o= auth-revocation-04


Internet-Drafts are also available by anonymous FTP at:
ftp:= //ftp.ietf.org/internet-drafts/

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

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







--=20
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.de

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.fun.de
http://blogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunic=
ations


--
3D"George


--=20
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   peter.mauritius@fun.d=
e

fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
Geschaeftsfuehrer Johannes Feulner
Amtsgericht Mannheim HRB 106906

http://www.=
fun.de
http://bl=
ogs.fun.de
http://www.twitter.com/fun_de
http://www.facebook.com/funcommunications
--------------080607010905030100010307 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAABHNCSVQICAgIfAhkiAAAAAlw SFlzAAALEgAACxIB0t1+/AAAABx0RVh0U29mdHdhcmUAQWRvYmUgRmlyZXdvcmtzIENTNAay 06AAAAAVdEVYdENyZWF0aW9uIFRpbWUAMy8yOC8xMmDmEzUAAAANSURBVAiZY/j//z8DAAj8 Av6Fzas0AAAAAElFTkSuQmCC --------------080607010905030100010307-- --------------030708050708080103070907-- --------------ms010101050705010407030501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFHjCCBAagAwIBAgIRAMDelVw+LRVrknnNfAzvvwUwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTIw NDE4MDAwMDAwWhcNMTMwNDE4MjM1OTU5WjAfMR0wGwYJKoZIhvcNAQkBFg5wZXRlckBwZXRl ci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKytWhRD21yXbUdIxNODMNuD hex7ykIdXI4wn8lB7a1X4RCRUWFYrk8TOyPzuTWLjNIiWn4Vsfp3AjWpBNg+k/G4uMh1/CvZ uayFtHuUrQapyEfK8awpAlPK6zyHAp0qDF9UaVAC9i5u478EjIy5K32c/89zrznyLcDrlapk XOyr8KnQWfXcbLw7TgkO1TgYVCUXy3h10X5IbdCYYKKDFfD52+ZB0pGuYPclsVu139snkv9N XMSiyL7teOeP2b0WOVCvqpWzWRXjWHy1Kxu68bc1BvfTwI4CxdofS307xxZW3tdFjGItjPay h9Qq/0Um/LOInloJQU9kI61ykBl+DjsCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTxoptwhJcBUUr8CHVnjS5/Z0HPMjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBkG A1UdEQQSMBCBDnBldGVyQHBldGVyLmRlMA0GCSqGSIb3DQEBBQUAA4IBAQBQi+rUEFOkOvHP 8IvONRNqdaokWM9XPNpTOB1xz7bnQTvrx6niomT3il3Al9/LFSa02z44W0uDQ8dXX/n774oy Ik9pSBpVUNo4p9p+Gad7F92OTmqSVu5xvKoSG7Qht3wHukWgOAtCcvyfchRtPnZfOFWpdX0H eTCcw8jR+PoEyI1RuqIoMD9nHSiMxRURTuPv67VlLdRxCG4SuJwHtynbDOaKoqZmDEkWr0RY LZIVIcIiSnVZGoxPpDOf1U6ELli/QdlOSsgkpqDHlX1or7DiBCxRYHCYckC4g2Hz95epTTNg UjKI4WTypUnvFEGaa/rVE57mEt25HjHosSvmFoEjMYIEHDCCBBgCAQEwgakwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDA3pVcPi0Va5J5zXwM778FMAkG BSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDExMDIxMzcxNVowIwYJKoZIhvcNAQkEMRYEFB6aBf1QhLLQ+j31zeACMLP2tfWMMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIRAMDelVw+LRVrknnNfAzvvwUwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAwN6VXD4tFWuSec18DO+/ BTANBgkqhkiG9w0BAQEFAASCAQBOtcarzn6KgANmFUccZAO45hvOKfQ3zK5faStFsG8bpgWF I9qx2PUZ1B85c/W4XcR+k3NKroEjqs4LY5244I8Sv7oB6guES8ItbRiRfyEo4JEaf8rR3NFG CQfovPtyyDMHwgxzl0rm+ffNg0JWmGuG+P598QTThYGg7UFUMqEH1aV8Ob4SpEcNCsLlEsso viFIxDm+fohNVRI0V+Nzm0rFBTa6vWKer2q8tmR/tagAjmVHTOOkNh5JfNnipAdfswkGaxzO l30uJw+cTqsiQxKnn06/0U+A79/1WMMkfkJMjVv2uTNf+yKRUFADKXWkVmuYIs+cUe508yl4 ZamR0DFYAAAAAAAA --------------ms010101050705010407030501-- From jricher@mitre.org Thu Jan 10 13:38:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D68521F88E8 for ; Thu, 10 Jan 2013 13:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVVSne4Hj8WN for ; Thu, 10 Jan 2013 13:38:53 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 123F421F8765 for ; Thu, 10 Jan 2013 13:38:53 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 732771F34BA; Thu, 10 Jan 2013 16:38:52 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5A1231F34BB; Thu, 10 Jan 2013 16:38:52 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 16:38:52 -0500 From: "Richer, Justin P." To: "Boone, Keith W (GE Healthcare)" Thread-Topic: Mail regarding draft-ietf-oauth-dyn-reg Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMA Date: Thu, 10 Jan 2013 21:38:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0687614DIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:38:54 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0687614DIMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting use case, and not dissimilar to some others I've heard. How wou= ld you go about tracking this? Why would the instances need to know about e= ach other? One possible approach would be to use a common initializing Request Access = Token that is used to call client_register on all instances of a given clie= nt. They wouldn't know about each other, per se, but the Authorization Serv= er would at least know enough to be able to tie them together. There's also the OAuth2 Instance Information extension that I had tried to = push a few years ago that comes up every now and again, that might be of us= e here with some modifications: http://tools.ietf.org/html/draft-richer-oauth-instance-00 I think I'd like to know more about your concerns and the parameters of you= r use case first. I am CC'ing the IETF OAuth Working Group email list, where this draft is be= ing discussed and worked on. -- Justin On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" > wrote: I would like to be able to use this protocol to dynamically register client= s, but am challenged by the fact that there could be multiple instances of = a public client, each unaware of what others have done. The current protoc= ol doesn't seem to address this. Keith _________________________________ Keith W. Boone Standards Architect GE Healthcare M +1 617 640 7007 keith.boone@ge.com www.gehealthcare.com 116 Huntington Ave Boston, MA 02116 USA GE imagination at work --_000_B33BFB58CCC8BE4998958016839DE27E0687614DIMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Interesting use case, and not dissimilar to some others I've heard. How wou= ld you go about tracking this? Why would the instances need to know about e= ach other?

One possible approach would be to use a common initializing Request Ac= cess Token that is used to call client_register on all instances of a given= client. They wouldn't know about each other, per se, but the Authorization= Server would at least know enough to be able to tie them together.

There's also the OAuth2 Instance Information extension that I had trie= d to push a few years ago that comes up every now and again, that might be = of use here with some modifications:


I think I'd like to know more about your concerns and the parameters o= f your use case first. 

I am CC'ing the IETF OAuth Working Group email list, where this draft = is being discussed and worked on.

 -- Justin

On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)"= ; <keith.boone@ge.com> wrot= e:

I would l= ike to be able to use this protocol to dynamically register clients, but am= challenged by the fact that there could be multiple instances of a public = client, each unaware of what others have done.  The current protocol doesn't seem to address this.

            Keith
___= ______________________________
Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007
keith.boone@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work
 

--_000_B33BFB58CCC8BE4998958016839DE27E0687614DIMCMBX01MITREOR_-- From hannes.tschofenig@gmx.net Fri Jan 11 00:18:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007C621F8A50 for ; Fri, 11 Jan 2013 00:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjUDFCt7c7Nd for ; Fri, 11 Jan 2013 00:18:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAD21F8A08 for ; Fri, 11 Jan 2013 00:18:15 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MOV9X-1Twckt2Ylx-005uS7 for ; Fri, 11 Jan 2013 09:18:14 +0100 Received: (qmail invoked by alias); 11 Jan 2013 08:18:14 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 11 Jan 2013 09:18:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18l9F0Q3e0l/ISfW8S/q3Bxbvr37tqwjFrYeu68Jp gb+Q/bfS33LOsv From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2013 10:18:13 +0200 Message-Id: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:18:17 -0000 Thank you Torsten for updating the document.=20 Two issues have been raised: 1) Terminology: Authorization vs. access grant vs. authorization grant There is a little bit of email exchange on that topic: http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html I personally don't have an opinion on the terminology in this case.=20 2) invalid_token error code As mentioned on the list, a new error code has to be registered (which = is not a big deal). Re-using an error code with different semantic is of = course confusing.=20 Re-using an already defined error code and to provide additional text in = the error_description is fine as long as the description relates to the = originally defined error description. In the case of the invalid_request = error code RFC 6749 defines it as=20 invalid_request The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. and RFC 6750 says: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code. Let us know how you want to proceed on these two issues.=20 Ciao Hannes =20= From hannes.tschofenig@gmx.net Fri Jan 11 00:18:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3802521F8A50 for ; Fri, 11 Jan 2013 00:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJfDs-wUf9wR for ; Fri, 11 Jan 2013 00:18:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66021F8A08 for ; Fri, 11 Jan 2013 00:18:48 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MJHgy-1Tqofd1lHu-002sf4 for ; Fri, 11 Jan 2013 09:18:47 +0100 Received: (qmail invoked by alias); 11 Jan 2013 08:18:47 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 11 Jan 2013 09:18:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19bzFk5MkFbjNHHUSCLFSB7ptLmAEU46AEQNfds5F VU9l2F+xxC8VvZ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jan 2013 10:18:46 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:18:49 -0000 Hi guys,=20 Thanks for updating the assertion document and for incorporating the = comments received on the mailing list.=20 There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): " Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. " Since the value in the audience field is used to by the authorization = server in a comparison operation (see Section 5.2) I believe the current = text will lead to interoperability problems. Not only is the comparision = operation unspecified but even the value that is contained in the field = is left open. The RFC 2119 MAY does not really give a lot of hints of = what should be put in there.=20 Without having a clear description of what identifier is contained in = this field and how the comparison works it is either possible that a = legitimate client is rejected by the authorization server (which is = annoying) or an assertion with an incorrect assertion is accepted (which = is a security problem).=20 Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents.=20 Note that there are two documents that provide input to this problem = space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this = field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? Ciao Hannes From hannes.tschofenig@gmx.net Fri Jan 11 00:40:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C821F86D2 for ; Fri, 11 Jan 2013 00:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGg3r1XO--5H for ; Fri, 11 Jan 2013 00:40:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B378721F86CD for ; Fri, 11 Jan 2013 00:40:49 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MeNF3-1TcBm33N0R-00QFku for ; Fri, 11 Jan 2013 09:40:48 +0100 Received: (qmail invoked by alias); 11 Jan 2013 08:40:48 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 11 Jan 2013 09:40:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18uCQ4+LwMulXHBItBi2CAateWQNMZIUaFuB1m2EV CdJDPcK5VSW9xC Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50E41F8F.4060903@mnt.se> Date: Fri, 11 Jan 2013 10:40:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <369E6160-9FA0-4B9A-8F3D-74B1F62F717B@gmx.net> References: <50E41F8F.4060903@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] review http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:40:50 -0000 Hi Leif,=20 thanks for the timely review.=20 On Jan 2, 2013, at 1:52 PM, Leif Johansson wrote: >=20 > Some comments in the order I discovered them... >=20 > - the term holder-of-_the_-key (my ascii-emphasis) is used when > the normal terminology is just "holder-of-key", not sure what is > added by the definite form... In the meanwhile I am convinced that the entire holder-of*-key = terminology is confusing.=20 > - s/incredients/ingredients/g > - say "a mechanism for secure and scalable key management" in 1 (1) > instead of using the word "dynamic" which is pretty vague. What I tried to express is that the keying material is distributed as = part of the protocol exchange rather than provisioned out of band.=20 But adding secure, and scalable is certainly also desirable.=20 > - the wording in 3.1 makes it a bit hard to tell when you're talking = about > HotK or stock OAUTH. Certainly true. In that section I am talking about the enhanced OAuth = version.=20 > - "profile" seems like too generic term to spend what is essentially a > choice of key format. OK.=20 > - in the example authz request you should clearly state that the 'id' > parameter is use to carry the key identifier (just to improve > readability). Perhaps > change 'hotk' to 'hotk_id'. OK.=20 > - why do key identifiers, profile names etc need their own ABNF (end > of 3.1.1)? Newly defined parameters need to follow some syntax.=20 > - when computing the signature, don't you want to hash over the > entire request string so that you include the HTTP version? At least > in theory the semantics of the method is tied to the version... What to include in the computation of the keyed message digest is up for = discussion.=20 I am OK with including the HTTP version as well. > - what does "put into the body of the HTTP request." mean? Are > you using any particular mime-type for instance? I should have been more precise.=20 Actually, I would like to leave that open for discussion of where to put = the JWS structure. It may not always be best to put it into the body of = the message.=20 > - have you investigated the deployability of 3.2.2? I would expect = that > using signatures (JWS) would be a lot easer to code for in practice. = Its > a strange world. I fully agree with you. A solution that utilized TLS is certainly more = difficult to deploy than a JSON-based variant. The main purpose of the = writeup was to illustrate the solution space.=20 It might actually make sense two separate the two variants into two = different documents since they are so different.=20 Ciao Hannes >=20 > Cheers Leif > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From keith.boone@ge.com Thu Jan 10 13:54:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2314121F88B1 for ; Thu, 10 Jan 2013 13:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R26ievRn-1or for ; Thu, 10 Jan 2013 13:54:17 -0800 (PST) Received: from exprod5og117.obsmtp.com (exprod5og117.obsmtp.com [64.18.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C621F8834 for ; Thu, 10 Jan 2013 13:54:16 -0800 (PST) Received: from cinmlip12.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob117.postini.com ([64.18.4.12]) with SMTP ID DSNKUO84iIqGzaUhEVXqnHx9oCVwOCO1aLeP@postini.com; Thu, 10 Jan 2013 13:54:17 PST Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by cinmlip12.e2k.ad.ge.com with ESMTP; 10 Jan 2013 16:54:15 -0500 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 16:54:14 -0500 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 16:54:12 -0500 Received: from CINURCNA08.e2k.ad.ge.com (3.159.212.125) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 16:54:11 -0500 Received: from CINURCNA03.e2k.ad.ge.com ([169.254.3.149]) by CINURCNA08.e2k.ad.ge.com ([169.254.2.43]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 16:54:11 -0500 From: "Boone, Keith W (GE Healthcare)" To: "Richer, Justin P." Thread-Topic: Mail regarding draft-ietf-oauth-dyn-reg Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMAAApcswA= Date: Thu, 10 Jan 2013 21:54:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.188] Content-Type: multipart/alternative; boundary="_000_C41EE4B7616F774CBF466291DC59746F0BCD33CINURCNA03e2kadge_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2013 21:54:12.0695 (UTC) FILETIME=[06C22670:01CDEF7D] X-Mailman-Approved-At: Fri, 11 Jan 2013 00:43:40 -0800 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 22:00:24 -0000 --_000_C41EE4B7616F774CBF466291DC59746F0BCD33CINURCNA03e2kadge_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The challenge is that we project an environment where there could be thousa= nds of applications conforming to a particular API (see http://wiki.siframe= work.org/ABBI+Pull+Workgroup), with thousands of data holders making data a= vailable through those APIs, and several authorizers (in the OAuth 2.0 sens= e). For public (locally installed or web-browser based applications), we'd= like to avoid what I call the million registration problem (i= gnore the technical details), which would require thousands of developers t= o manually register their applications with all of the authorizers. Because this is healthcare data, it is entirely possible that data holders = will INSIST on being authorizers, which makes the problem even more challen= ging. The issue that the ABBI Pull workgroup has been asked to address is to ensu= re that there is some way to manage bad actors in this eco-system, e.g., th= rough a black-list, white-list or other trust-mechanism. This wouldn't nec= essarily be required to be used, but would help an authorizer make an appli= cation access control decision. The challenge with a public application using dynamic registration is that a) The application cannot keep it's credentials secret, and so must ret= rieve them in some way securely b) If the client_id is not tied back to the application identity, then w= e have concerns about the trust mechanism being able to protect the environ= ment, c) And yet, we also want to protect clients from denial of service atta= cks where a client could be impersonated (to an authorizer), and obtain a c= lient_id. Imagine the case where I purchase an application and download it to my iPho= ne and to my iPad. Then I connect that application to a data holder/author= izer combination it hasn't seen before. Through dynamic client registratio= n, I could register that application for my iPhone, but the instance of tha= t same application running on my iPad would know nothing about the first re= gistration. So it would attempt to do it all over again. What happens her= e? Keith _________________________________ Keith W. Boone Standards Architect GE Healthcare M +1 617 640 7007 keith.boone@ge.com www.gehealthcare.com 116 Huntington Ave Boston, MA 02116 USA GE imagination at work From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Thursday, January 10, 2013 4:39 PM To: Boone, Keith W (GE Healthcare) Cc: oauth@ietf.org WG Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg Interesting use case, and not dissimilar to some others I've heard. How wou= ld you go about tracking this? Why would the instances need to know about e= ach other? One possible approach would be to use a common initializing Request Access = Token that is used to call client_register on all instances of a given clie= nt. They wouldn't know about each other, per se, but the Authorization Serv= er would at least know enough to be able to tie them together. There's also the OAuth2 Instance Information extension that I had tried to = push a few years ago that comes up every now and again, that might be of us= e here with some modifications: http://tools.ietf.org/html/draft-richer-oauth-instance-00 I think I'd like to know more about your concerns and the parameters of you= r use case first. I am CC'ing the IETF OAuth Working Group email list, where this draft is be= ing discussed and worked on. -- Justin On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" > wrote: I would like to be able to use this protocol to dynamically register client= s, but am challenged by the fact that there could be multiple instances of = a public client, each unaware of what others have done. The current protoc= ol doesn't seem to address this. Keith _________________________________ Keith W. Boone Standards Architect GE Healthcare M +1 617 640 7007 keith.boone@ge.com www.gehealthcare.com 116 Huntington Ave Boston, MA 02116 USA GE imagination at work --_000_C41EE4B7616F774CBF466291DC59746F0BCD33CINURCNA03e2kadge_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The challenge is that we pr= oject an environment where there could be thousands of applications conform= ing to a particular API (see http://= wiki.siframework.org/ABBI+Pull+Workgroup), with thousands of da= ta holders making data available through those APIs, and several authorizer= s (in the OAuth 2.0 sense).  For public (locally installed or web-browser based applications), we'd like to avoid what I call the million registration problem (ignore the technical details), which woul= d require thousands of developers to manually register their applications w= ith all of the authorizers. 

 

Because this is healthcare = data, it is entirely possible that data holders will INSIST on being author= izers, which makes the problem even more challenging.

 

The issue that the ABBI Pul= l workgroup has been asked to address is to ensure that there is some way t= o manage bad actors in this eco-system, e.g., through a black-list, white-list or other trust-mechanism.  This wouldn't neces= sarily be required to be used, but would help an authorizer make an applica= tion access control decision.

 

The challenge with a public= application using dynamic registration is that

a) &= nbsp;   The application can= not keep it's credentials secret, and so must retrieve them in some way sec= urely

b) &= nbsp;  If the client_id is= not tied back to the application identity, then we have concerns about the= trust mechanism being able to protect the environment,

c) &= nbsp;   And yet, we also wa= nt to protect clients from denial of service attacks where a client could b= e impersonated (to an authorizer), and obtain a client_id.

 

Imagine the case where I pu= rchase an application and download it to my iPhone and to my iPad.  Th= en I connect that application to a data holder/authorizer combination it hasn't seen before.  Through dynamic client registration, I could = register that application for my iPhone, but the instance of that same appl= ication running on my iPad would know nothing about the first registration.=   So it would attempt to do it all over again.  What happens here?

 

    &nb= sp;       Keith

_________________________________ Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.co= m

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

 

From: Richer, = Justin P. [mailto:jricher@mitre.org]
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: oauth@ietf.org WG
Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg

 

Interesting use case, and not dissimilar to some oth= ers I've heard. How would you go about tracking this? Why would the instanc= es need to know about each other?

 

One possible approach would be to use a common initi= alizing Request Access Token that is used to call client_register on all in= stances of a given client. They wouldn't know about each other, per se, but= the Authorization Server would at least know enough to be able to tie them together.

 

There's also the OAuth2 Instance Information extensi= on that I had tried to push a few years ago that comes up every now and aga= in, that might be of use here with some modifications:

 

 

I think I'd like to know more about your concerns an= d the parameters of your use case first. 

 

I am CC'ing the IETF OAuth Working Group email list,= where this draft is being discussed and worked on.

 

 -- Justin

 

On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (G= E Healthcare)" <keith.boone@g= e.com> wrote:



I would like to be able to use this proto= col to dynamically register clients, but am challenged by the fact that the= re could be multiple instances of a public client, each unaware of what others have done.  The current protocol doesn't seem = to address this.


            Keith

_________________________________ Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.com=

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

 

 

--_000_C41EE4B7616F774CBF466291DC59746F0BCD33CINURCNA03e2kadge_-- From zhou.sujing@zte.com.cn Fri Jan 11 01:30:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE621F8790 for ; Fri, 11 Jan 2013 01:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.55 X-Spam-Level: X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGQ5eyaI5Fzm for ; Fri, 11 Jan 2013 01:30:09 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4721F8445 for ; Fri, 11 Jan 2013 01:30:08 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 9B2E1127B78A; Fri, 11 Jan 2013 17:32:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0B9TXJU039038; Fri, 11 Jan 2013 17:29:33 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <50EDAAFE.3050300@mitre.org> To: Justin Richer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 11 Jan 2013 17:29:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-11 17:29:27, Serialize complete at 2013-01-11 17:29:27 Content-Type: multipart/alternative; boundary="=_alternative 003428F848257AF0_=" X-MAIL: mse01.zte.com.cn r0B9TXJU039038 Cc: Peng Zhou , oauth@ietf.org Subject: Re: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1dGggMi4w?= =?gb2312?b?IEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:30:11 -0000 This is a multipart message in MIME format. --=_alternative 003428F848257AF0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc+INC009ogMjAxMy0wMS0xMCAwMTozODow NjoNCg0KPiBCcmVudCwNCj4gDQo+IElmIHlvdSdyZSBzZW5kaW5nIHRoZSBjb2RlIGluIHRoZSBi YWNrIGNoYW5uZWwgZGlyZWN0bHkgdG8gdGhlIENsaWVudCwNCj4gYXMgSSBiZWxpZXZlIHlvdSdy ZSBkb2luZyBmcm9tIHlvdXIgdGV4dCBiZWxvdywgSSB3b3VsZCBsaWtlIHlvdSB0bw0KPiByZWFs aXplIHNvbWUgdGhpbmdzOg0KPiANCj4gMSkgVGhpcyBpcyBub3QgT0F1dGgsIGFuZCBpcyBpbiBm YWN0IGFudGl0aGV0aWNhbCB0byB0aGUgT0F1dGggd2F5IG9mDQo+IHNvbHZpbmcgdGhlIGNvbm5l Y3Rpb24gcHJvYmxlbS4NCj4gMikgWW91IGFyZSBhY3R1YWxseSBsb3dlcmluZyB5b3VyIG92ZXJh bGwgc2VjdXJpdHkgYmVjYXVzZSB0aGUgYWNjZXNzDQo+IGNvZGUgaXMgbm8gbG9uZ2VyIGJvdW5k IHRvIGFueSBwYXJ0aWN1bGFyIGJyb3dzZXIgc2Vzc2lvbiB3aXRoIGVpdGhlcg0KPiB0aGUgY2xp ZW50IG9yIHRoZSBBUy4NCj4gMykgSWYgeW91J3JlIHNlbmRpbmcgaXQgZGlyZWN0bHksIHRoZXJl IGlzIG5vIGxvbmdlciBhbnkgcG9pbnQgb2YgdXNpbmcNCj4gdGhlIGNvZGUsIHNpbmNlIHRoZSBD bGllbnQgaXMganVzdCBnb2luZyB0byB0dXJuIGFyb3VuZCBhbmQgc2VuZCBpdCB0bw0KPiB0aGUg QVMgYWdhaW4gdG8gZ2V0IGEgdG9rZW4uIFdoeSBub3QganVzdCBzZW5kIHRoZSB0b2tlbj8gQnV0 IGFnYWluLA0KPiB0aGlzIGlzIHN0aWxsIG5vdCBPQXV0aC4NCj4gDQo+IA0KPiBUaGluayBhYm91 dCBpdCB0aGlzIHdheTogVGhlcmUgYXJlIHRocmVlIGNvbm5lY3Rpb25zIGluIHRoZSBjb21tb24g T0F1dGgNCj4gQXV0aG9yaXphdGlvbiBDb2RlIHNjZW5hcmlvLCB3aGljaCBpcyB3aHkgaXQncyBr bm93biBhcyBhIHRocmVlLWxlZ2dlZA0KPiBPQXV0aCBmbG93IGluIG1hbnkgY2lyY2xlcy4gRWFj aCBvZiB0aGVzZSBsZWdzIGhhcyB1bmlxdWUgcHJvcGVydGllcywgaXMNCj4gcHJvdGVjdGVkIGJ5 IGRpZmZlcmVudCB0aGluZ3MsIGFuZCBpcyBleHBvc2VkIHRvIGRpZmZlcmVudCBwaWVjZXMgb2YN Cj4ga25vd2xlZGdlIGF0IGRpZmZlcmVudCB0aW1lcy4NCj4gDQo+IDEpIENsaWVudCA8LT4gVXNl ciBBZ2VudDogcHJvdGVjdGVkIGJ5IGEgbG9jYWwgc2Vzc2lvbiBvZiB0aGUgQ2xpZW50J3MNCj4g Y2hvb3NpbmcuIEZvciBXZWIgYmFzZWQgY2xpZW50cyB0aGlzIGlzIG9mdGVuIHN0YW5kYXJkIEhU VFAgc2Vzc2lvbg0KPiBjb29raWVzIG9yIHNpbWlsYXIsIHBvdGVudGlhbGx5IGJhY2tlZCBieSBh IGxvZ2luIG9mIHNvbWUgdHlwZSBieSB0aGUNCj4gdXNlciB0byB0aGUgQ2xpZW50IGFzIHdlbGwu IFRoaXMgc2Vzc2lvbiBpcyBuZXZlciBleHBvc2VkIHRvIHRoZQ0KPiBBdXRob3JpemF0aW9uIFNl cnZlci4NCj4gMikgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgPC0+IFVzZXIgQWdlbnQ6IHByb3RlY3Rl ZCBieSBhIGxvY2FsIHNlc3Npb24gb2YNCj4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyJ3MgY2hv b3NpbmcsIG5vcm1hbGx5IHRocm91Z2ggc29tZSBraW5kIG9mDQo+IFByaW1hcnkgQ3JlZGVudGlh bCAobG9naW4pIHRoYXQgdGhlIHVzZXIgaGFzIGEgdGhlIEFTLiBJbXBvcnRhbnRseSwNCj4gdGhl c2UgY3JlZGVudGlhbHMgYXJlIG5ldmVyIGV4cG9zZWQgdG8gdGhlIENsaWVudC4NCj4gMykgQ2xp ZW50IDwtPiBBdXRob3JpemF0aW9uIFNlcnZlcjogcHJvdGVjdGVkIGJ5IHRoZSBjbGllbnQgY3Jl ZGVudGlhbHMsDQo+IHdoaWNoIGFyZSwgaW1wb3J0YW50bHksIG5vdCBleHBvc2VkIHRvIHRoZSB1 c2VyIG9yIHVzZXIgYWdlbnQuDQo+IA0KPiBCeSBzZW5kaW5nIHRoZSBjb2RlIGFzIHBhcnQgb2Yg dGhlIHJlZGlyZWN0LCB0aGUgQ2xpZW50IGlzIGFibGUgdG8gcHJvdmUNCj4gdGhhdCB0aGUgVXNl ciBBZ2VudCBhY3R1YWxseSB3ZW50IHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciAoMikgYW5k DQo+IGdvdCBzb21ldGhpbmcuIFRoZSBBdXRob3JpemF0aW9uIENvZGUgaXMgdGhlbiBzZW50IHRo cm91Z2ggdGhlIGJvdHRvbQ0KPiBsZWcgKDMpIG9mIHRoZSBjaGFubmVsIHRvIHZlcmlmeSB0aGF0 IGl0IHJlYWxseSBkaWQgY29tZSBmcm9tIHRoZQ0KPiBBdXRob3JpemF0aW9uIFNlcnZlciBpbiB0 aGUgY29udGV4dCBvZiB0aGUgdXNlciB0aGF0IHdhcyBqdXN0IHRoZXJlIGluDQo+ICgxKS4gDQoN CkhvdyBpcyBDbGllbnQgYXNzdXJlZCB0aGUgVUEgYWN0dWFsbHkgd2VudCB0byBBUyBhbmQgZ290 IHNvbWV0aGluZyBieSB0aGUgDQpmb2xsb3dpbmcgVVJMPw0KDQpBo7oNCiBHRVQvYXV0aG9yaXpl P3Jlc3BvbnNlX3R5cGU9Y29kZSZjbGllbnRfaWQ9czZCaGRSa3F0MyZzdGF0ZT14eXogDQomcmVk aXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQpIVFRQ LzEuMSAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tDQpDOg0KSFRUUC8xLjEzMDJGb3VuZCANCkxv Y2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9jYj9jb2RlPVNwbHhsT0JlWlFRWWJZ UzZXeFNiSUEgDQomc3RhdGU9eHl6DQoNCg0KDQoNCg0KICBJbiBvdGhlciB3b3JkcywgdGhpcyBt ZWNoYW5pc20gdGhhdCB5b3Ugc2VlbSB0byBiZSBhdm9pZGluZyBpcw0KPiBleGFjdGx5IHdoYXQg bWFrZXMgT0F1dGggc2VjdXJlLg0KPiANCj4gSWYgeW91IGluc3RlYWQgc2VuZCB0aGUgY29kZSB0 aHJvdWdoICgzKSwgdGhlbiB0aGUgQ2xpZW50IGFzIG5vIHdheSBhdA0KPiBhbGwgb2Yga25vd2lu ZyB0aGF0IHRoZSB1c2VyIGluICgxKSBldmVyIHdlbnQgdG8gdGhlIGF1dGhvcml6YXRpb24NCj4g c2VydmVyIHZpYSAoMikuIEFsbCB0aGUgQ2xpZW50IGtub3dzIGlzIHRoYXQgdGhleSBzZW50IHRo ZSB1c2VyDQo+IHNvbWVwbGFjZSBhbmQgdGhhdCBhIG1hZ2ljIGNvZGUgc2hvd2VkIHVwLiBJdCBp cyB2ZXJ5LCB2ZXJ5LCB2ZXJ5DQo+IGRhbmdlcm91cyBhbmQgYSB2ZXJ5LCB2ZXJ5IGJhZCBpZGVh IHRvIGFzc3VtZSB0aGF0IGEgY29kZSBjb21pbmcgaW4gdGhlDQo+IGJhY2sgY2hhbm5lbCAoMykg aGFzIGFueXRoaW5nIGF0IGFsbCB0byBkbyB3aXRoIGFueSBwYXJ0aWN1bGFyIHNlc3Npb24gDQoo MSkuDQo+IA0KPiBUaGlzIGFwcHJvYWNoIGRvZXMgKm5vdCogbWl0aWdhdGUgYW55IHJlYWwgc2Vj dXJpdHkgdGhyZWF0cywgYW5kIGluIGZhY3QNCj4gaW50cm9kdWNlcyBhIGdyZWF0IG51bWJlciBv ZiBvdGhlcnMsIGFzIGRlc2NyaWJlZCBoZXJlLiBUaGVyZSBhcmUgbXVjaA0KPiBiZXR0ZXIgd2F5 cyB0byBwcm90ZWN0IHRoZSBBdXRob3JpemF0aW9uIENvZGUsIGFuZCBtb3N0IG9mIHRoZSBiZXN0 DQo+IHByYWN0aWNlcyBhcmUgZW51bWVyYXRlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgZG9jdW1lbnQuIFNvbWUNCj4gb2YgdGhlIG1vc3QgY29tbW9uIGFyZToNCj4gDQo+IDEpIE1h a2UgQXV0aG9yaXphdGlvbiBDb2RlcyBvbmUtdGltZS11c2UgKGV2ZW4gaWYgeW91IHRyeSBhbmQg ZmFpbCwgaXQncw0KPiB0aHJvd24gYXdheSkNCj4gMikgTWFrZSBBdXRob3JpemF0aW9uIENvZGVz IHRpbWUgb3V0IGFmdGVyIGEgdmVyeSBzaG9ydCBwZXJpb2QgKG1pbnV0ZXMNCj4gb3Igc2Vjb25k cykNCj4gDQo+IA0KPiBJIGhvcGUgdGhpcyBoZWxwcy4NCj4gDQo+IC0tIEp1c3Rpbg0KPiANCj4g DQo+IA0KPiBPbiAwMS8wOS8yMDEzIDAxOjQyIEFNLCBQZW5nIFpob3Ugd3JvdGU6DQo+ID4gRGVh ciBTdUppbmc6DQo+ID4NCj4gPiBJZiBpdCBpcyB0aGUgb25seSByZWFzb24sIHdoeSB3ZSBzZW5k IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdG8gdGhlDQo+ID4gY2xpZW50IGRpcmVjdGx5IGFuZCBz ZW5kIGFub3RoZXIgbm90aWZpY2F0aW9uIHdpdGhvdXQgdGhlDQo+ID4gYXV0aG9yaXphdGlvbiBj b2RlIHRvIHRoZSBSTy4gVGhpcyB3YXkgY2FuIG1pdGlnYXRlIHRoZSBjaGFuY2UgdGhhdA0KPiA+ IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMgZXhwb3NlZCB0byB0aGUgUk8ncyB1c2VyLWFnZW50 LCBoZW5jZQ0KPiA+IHByb3RlY3RpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmcm9tIGxlYWtp bmcgdG8gcG9zc2libGUgYXR0YWNrZXJzDQo+ID4gaW4gYSBoaWdoZXIgc2VjdXJpdHkgbGV2bGUu DQo+ID4NCj4gPiBCZXN0IFJlZ2FyZHMNCj4gPiBCcmVudA0KPiA+DQo+ID4gMjAxMy8xLzkgIDx6 aG91LnN1amluZ0B6dGUuY29tLmNuPjoNCj4gPj4gVGhlbiB3aHkgbm90IGxldCBhdXRoIGNvZGUg YmUgc2VudCBkaXJlY3RseSBmcm9tIEFTIHRvIENsaWVudD8NCj4gPj4NCj4gPj4gSnVzdCB3YW50 IHRvIGluZm9ybSBSTyB0aGF0IGFuIGF1dGggY29kZSBoYXMgYmVlbiBkaWxpdmVyZWQgdG8gDQpD bGllbnQ/DQo+ID4+DQo+ID4+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTA5 IDE0OjI3OjUwOg0KPiA+Pg0KPiA+Pj4gSGkgQnJlbnQsDQo+ID4+Pg0KPiA+Pj4gRmV3IHBvaW50 cywgd2h5IHRoaXMgZG9lc24ndCBjcmVhdGUgYW55IHNlY3VyaXR5IGltcGxpY2F0aW9ucy4uDQo+ ID4+Pg0KPiA+Pj4gMS4gQXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWFpbnRhaW5zIGEgYmluZGluZyB0 byB0aGUgQ2xpZW50LCB3aG8gdGhlDQo+ID4+PiB0b2tlbiB3YXMgaXNzdWVkIHRvLiBUbyBleGNo YW5nZSB0aGlzIHRvIGFuIEFjY2VzcyB0b2tlbiBjbGllbnQNCj4gPj4+IHNob3VsZCBhdXRoZW50 aWNhdGUgaGltIHNlbGYuDQo+ID4+PiAyLiBDb2RlIGNhbiBvbmx5IGJlIGV4Y2hhbmdlZCBvbmNl IGZvciBhbiBhY2NlcyB0b2tlbi4NCj4gPj4+DQo+ID4+PiBUaGFua3MgJiByZWdhcmRzLA0KPiA+ Pj4gLVByYWJhdGgNCj4gPj4+IE9uIFdlZCwgSmFuIDksIDIwMTMgYXQgNjo1NiBBTSwgY3Nwemhv dXJvYyANCjxjc3B6aG91cm9jQGNvbXAucG9seXUuZWR1LmhrDQo+ID4+Pj4gd3JvdGU6DQo+ID4+ PiBEZWFyIEFsbDoNCj4gPj4+DQo+ID4+PiBJIGhhdmUgYSBxdWVzdGlvbiBpbiB0aGUgc2VjdGlv biAxLjMuMS4gQXV0aG9yaXphdGlvbiBDb2RlIGluIA0KcmZjNjc0OQ0KPiA+Pj4gVGhlIE9BdXRo IDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yay4NCj4gPj4+DQo+ID4+PiBJdCB0ZWxscyAid2hp Y2ggaW4gdHVybiBkaXJlY3RzIHRoZSByZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZSANCmNsaWVu dA0KPiA+Pj4gd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLiINCj4gPj4+DQo+ID4+PiBXaG8g Y2FuIGxldCBtZSBrbm93IHRoZSByZWFzb24gd2h5IGlzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg c2VudCB0bw0KPiA+Pj4gY2xpZW50IHRocm91Z2ggYSByZWRpcmVjdGlvbiBpbiByZXNvdXJjZSBv d25lcidzIGFnZW50PyAgQW55IA0Kc2VjdXJpdHkNCj4gPj4+IGltcGxpY2F0aW9ucz8NCj4gPj4+ DQo+ID4+PiBJcyBpdCBwb3NzaWJsZSB0byBsZXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNl bmQgdGhlIA0KYXV0aG9yaXphdGlvbg0KPiA+Pj4gY29kZSB0byB0aGUgY2xpZW50IGRpcmVjdGx5 IChub3QgdGhyb3VnaCByZXNvdXJjZSBvd25lcidzIA0KdXNlci1hZ2VudCk/DQo+ID4+Pg0KPiA+ Pj4gQmVzdCBSZWdhcmRzDQo+ID4+PiBCcmVudA0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBPQXV0aCBtYWlsaW5nIGxp c3QNCj4gPj4+IE9BdXRoQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+PiAtLQ0KPiA+Pj4gVGhhbmtzICYgUmVnYXJkcywNCj4g Pj4+IFByYWJhdGgNCj4gPj4+DQo+ID4+PiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzINCj4gPj4+ DQo+ID4+PiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gPj4+IGh0dHA6Ly9SYW1wYXJ0 RkFRLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4+IE9BdXRoQGlldGYub3JnDQo+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxp c3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCj4gDQoNCg== --=_alternative 003428F848257AF0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1p dHJlLm9yZyZndDsg0LTT2iAyMDEzLTAxLTEwDQowMTozODowNjo8YnI+DQo8YnI+DQomZ3Q7IEJy ZW50LDxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiB5b3UncmUgc2VuZGluZyB0aGUgY29kZSBpbiB0 aGUgYmFjayBjaGFubmVsIGRpcmVjdGx5IHRvIHRoZSBDbGllbnQsPGJyPg0KJmd0OyBhcyBJIGJl bGlldmUgeW91J3JlIGRvaW5nIGZyb20geW91ciB0ZXh0IGJlbG93LCBJIHdvdWxkIGxpa2UgeW91 IHRvPGJyPg0KJmd0OyByZWFsaXplIHNvbWUgdGhpbmdzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAx KSBUaGlzIGlzIG5vdCBPQXV0aCwgYW5kIGlzIGluIGZhY3QgYW50aXRoZXRpY2FsIHRvIHRoZSBP QXV0aCB3YXkNCm9mPGJyPg0KJmd0OyBzb2x2aW5nIHRoZSBjb25uZWN0aW9uIHByb2JsZW0uPGJy Pg0KJmd0OyAyKSBZb3UgYXJlIGFjdHVhbGx5IGxvd2VyaW5nIHlvdXIgb3ZlcmFsbCBzZWN1cml0 eSBiZWNhdXNlIHRoZSBhY2Nlc3M8YnI+DQomZ3Q7IGNvZGUgaXMgbm8gbG9uZ2VyIGJvdW5kIHRv IGFueSBwYXJ0aWN1bGFyIGJyb3dzZXIgc2Vzc2lvbiB3aXRoIGVpdGhlcjxicj4NCiZndDsgdGhl IGNsaWVudCBvciB0aGUgQVMuPGJyPg0KJmd0OyAzKSBJZiB5b3UncmUgc2VuZGluZyBpdCBkaXJl Y3RseSwgdGhlcmUgaXMgbm8gbG9uZ2VyIGFueSBwb2ludCBvZg0KdXNpbmc8YnI+DQomZ3Q7IHRo ZSBjb2RlLCBzaW5jZSB0aGUgQ2xpZW50IGlzIGp1c3QgZ29pbmcgdG8gdHVybiBhcm91bmQgYW5k IHNlbmQgaXQNCnRvPGJyPg0KJmd0OyB0aGUgQVMgYWdhaW4gdG8gZ2V0IGEgdG9rZW4uIFdoeSBu b3QganVzdCBzZW5kIHRoZSB0b2tlbj8gQnV0IGFnYWluLDxicj4NCiZndDsgdGhpcyBpcyBzdGls bCBub3QgT0F1dGguPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpbmsgYWJvdXQg aXQgdGhpcyB3YXk6IFRoZXJlIGFyZSB0aHJlZSBjb25uZWN0aW9ucyBpbiB0aGUgY29tbW9uDQpP QXV0aDxicj4NCiZndDsgQXV0aG9yaXphdGlvbiBDb2RlIHNjZW5hcmlvLCB3aGljaCBpcyB3aHkg aXQncyBrbm93biBhcyBhIHRocmVlLWxlZ2dlZDxicj4NCiZndDsgT0F1dGggZmxvdyBpbiBtYW55 IGNpcmNsZXMuIEVhY2ggb2YgdGhlc2UgbGVncyBoYXMgdW5pcXVlIHByb3BlcnRpZXMsDQppczxi cj4NCiZndDsgcHJvdGVjdGVkIGJ5IGRpZmZlcmVudCB0aGluZ3MsIGFuZCBpcyBleHBvc2VkIHRv IGRpZmZlcmVudCBwaWVjZXMNCm9mPGJyPg0KJmd0OyBrbm93bGVkZ2UgYXQgZGlmZmVyZW50IHRp bWVzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAxKSBDbGllbnQgJmx0Oy0mZ3Q7IFVzZXIgQWdlbnQ6 IHByb3RlY3RlZCBieSBhIGxvY2FsIHNlc3Npb24gb2YgdGhlDQpDbGllbnQnczxicj4NCiZndDsg Y2hvb3NpbmcuIEZvciBXZWIgYmFzZWQgY2xpZW50cyB0aGlzIGlzIG9mdGVuIHN0YW5kYXJkIEhU VFAgc2Vzc2lvbjxicj4NCiZndDsgY29va2llcyBvciBzaW1pbGFyLCBwb3RlbnRpYWxseSBiYWNr ZWQgYnkgYSBsb2dpbiBvZiBzb21lIHR5cGUgYnkNCnRoZTxicj4NCiZndDsgdXNlciB0byB0aGUg Q2xpZW50IGFzIHdlbGwuIFRoaXMgc2Vzc2lvbiBpcyBuZXZlciBleHBvc2VkIHRvIHRoZTxicj4N CiZndDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuPGJyPg0KJmd0OyAyKSBBdXRob3JpemF0aW9uIFNl cnZlciAmbHQ7LSZndDsgVXNlciBBZ2VudDogcHJvdGVjdGVkIGJ5IGEgbG9jYWwNCnNlc3Npb24g b2Y8YnI+DQomZ3Q7IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcidzIGNob29zaW5nLCBub3JtYWxs eSB0aHJvdWdoIHNvbWUga2luZCBvZjxicj4NCiZndDsgUHJpbWFyeSBDcmVkZW50aWFsIChsb2dp bikgdGhhdCB0aGUgdXNlciBoYXMgYSB0aGUgQVMuIEltcG9ydGFudGx5LDxicj4NCiZndDsgdGhl c2UgY3JlZGVudGlhbHMgYXJlIG5ldmVyIGV4cG9zZWQgdG8gdGhlIENsaWVudC48YnI+DQomZ3Q7 IDMpIENsaWVudCAmbHQ7LSZndDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXI6IHByb3RlY3RlZCBieSB0 aGUgY2xpZW50DQpjcmVkZW50aWFscyw8YnI+DQomZ3Q7IHdoaWNoIGFyZSwgaW1wb3J0YW50bHks IG5vdCBleHBvc2VkIHRvIHRoZSB1c2VyIG9yIHVzZXIgYWdlbnQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJ5IHNlbmRpbmcgdGhlIGNvZGUgYXMgcGFydCBvZiB0aGUgcmVkaXJlY3QsIHRoZSBDbGll bnQgaXMgYWJsZSB0bw0KcHJvdmU8YnI+DQomZ3Q7IHRoYXQgdGhlIFVzZXIgQWdlbnQgYWN0dWFs bHkgd2VudCB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKDIpDQphbmQ8YnI+DQomZ3Q7IGdv dCBzb21ldGhpbmcuIFRoZSBBdXRob3JpemF0aW9uIENvZGUgaXMgdGhlbiBzZW50IHRocm91Z2gg dGhlIGJvdHRvbTxicj4NCiZndDsgbGVnICgzKSBvZiB0aGUgY2hhbm5lbCB0byB2ZXJpZnkgdGhh dCBpdCByZWFsbHkgZGlkIGNvbWUgZnJvbSB0aGU8YnI+DQomZ3Q7IEF1dGhvcml6YXRpb24gU2Vy dmVyIGluIHRoZSBjb250ZXh0IG9mIHRoZSB1c2VyIHRoYXQgd2FzIGp1c3QgdGhlcmUNCmluPGJy Pg0KJmd0OyAoMSkuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SG93 IGlzIENsaWVudCBhc3N1cmVkIHRoZSBVQSBhY3R1YWxseSB3ZW50IHRvIEFTIGFuZA0KZ290IHNv bWV0aGluZyBieSB0aGUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5mb2xsb3dp bmcgVVJMPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QaO6PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDtHRVQvYXV0aG9yaXplP3Jlc3BvbnNl X3R5cGU9Y29kZSZhbXA7Y2xpZW50X2lkPXM2QmhkUmtxdDMmYW1wO3N0YXRlPXh5eg0KJmFtcDty ZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2I8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhUVFAvMS4xICZuYnNwO0hvc3Q6IHNlcnZl ci5leGFtcGxlLmNvbTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Qzo8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhUVFAvMS4xMzAyRm91bmQgPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Mb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5j b20vY2I/Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBDQomYW1wO3N0YXRlPXh5ejwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jm5ic3A7IEluIG90aGVyIHdvcmRzLCB0aGlzIG1lY2hhbmlzbSB0aGF0IHlvdSBzZWVtDQp0byBi ZSBhdm9pZGluZyBpczxicj4NCiZndDsgZXhhY3RseSB3aGF0IG1ha2VzIE9BdXRoIHNlY3VyZS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91IGluc3RlYWQgc2VuZCB0aGUgY29kZSB0aHJvdWdo ICgzKSwgdGhlbiB0aGUgQ2xpZW50IGFzIG5vIHdheQ0KYXQ8YnI+DQomZ3Q7IGFsbCBvZiBrbm93 aW5nIHRoYXQgdGhlIHVzZXIgaW4gKDEpIGV2ZXIgd2VudCB0byB0aGUgYXV0aG9yaXphdGlvbjxi cj4NCiZndDsgc2VydmVyIHZpYSAoMikuIEFsbCB0aGUgQ2xpZW50IGtub3dzIGlzIHRoYXQgdGhl eSBzZW50IHRoZSB1c2VyPGJyPg0KJmd0OyBzb21lcGxhY2UgYW5kIHRoYXQgYSBtYWdpYyBjb2Rl IHNob3dlZCB1cC4gSXQgaXMgdmVyeSwgdmVyeSwgdmVyeTxicj4NCiZndDsgZGFuZ2Vyb3VzIGFu ZCBhIHZlcnksIHZlcnkgYmFkIGlkZWEgdG8gYXNzdW1lIHRoYXQgYSBjb2RlIGNvbWluZyBpbg0K dGhlPGJyPg0KJmd0OyBiYWNrIGNoYW5uZWwgKDMpIGhhcyBhbnl0aGluZyBhdCBhbGwgdG8gZG8g d2l0aCBhbnkgcGFydGljdWxhciBzZXNzaW9uDQooMSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo aXMgYXBwcm9hY2ggZG9lcyAqbm90KiBtaXRpZ2F0ZSBhbnkgcmVhbCBzZWN1cml0eSB0aHJlYXRz LCBhbmQgaW4NCmZhY3Q8YnI+DQomZ3Q7IGludHJvZHVjZXMgYSBncmVhdCBudW1iZXIgb2Ygb3Ro ZXJzLCBhcyBkZXNjcmliZWQgaGVyZS4gVGhlcmUgYXJlDQptdWNoPGJyPg0KJmd0OyBiZXR0ZXIg d2F5cyB0byBwcm90ZWN0IHRoZSBBdXRob3JpemF0aW9uIENvZGUsIGFuZCBtb3N0IG9mIHRoZSBi ZXN0PGJyPg0KJmd0OyBwcmFjdGljZXMgYXJlIGVudW1lcmF0ZWQgaW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGRvY3VtZW50Lg0KU29tZTxicj4NCiZndDsgb2YgdGhlIG1vc3QgY29tbW9u IGFyZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMSkgTWFrZSBBdXRob3JpemF0aW9uIENvZGVzIG9u ZS10aW1lLXVzZSAoZXZlbiBpZiB5b3UgdHJ5IGFuZCBmYWlsLA0KaXQnczxicj4NCiZndDsgdGhy b3duIGF3YXkpPGJyPg0KJmd0OyAyKSBNYWtlIEF1dGhvcml6YXRpb24gQ29kZXMgdGltZSBvdXQg YWZ0ZXIgYSB2ZXJ5IHNob3J0IHBlcmlvZCAobWludXRlczxicj4NCiZndDsgb3Igc2Vjb25kcyk8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGhvcGUgdGhpcyBoZWxwcy48YnI+DQom Z3Q7IDxicj4NCiZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBPbiAwMS8wOS8yMDEzIDAxOjQyIEFNLCBQZW5nIFpob3Ugd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7IERlYXIgU3VKaW5nOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJZiBp dCBpcyB0aGUgb25seSByZWFzb24sIHdoeSB3ZSBzZW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUN CnRvIHRoZTxicj4NCiZndDsgJmd0OyBjbGllbnQgZGlyZWN0bHkgYW5kIHNlbmQgYW5vdGhlciBu b3RpZmljYXRpb24gd2l0aG91dCB0aGU8YnI+DQomZ3Q7ICZndDsgYXV0aG9yaXphdGlvbiBjb2Rl IHRvIHRoZSBSTy4gVGhpcyB3YXkgY2FuIG1pdGlnYXRlIHRoZSBjaGFuY2UNCnRoYXQ8YnI+DQom Z3Q7ICZndDsgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBleHBvc2VkIHRvIHRoZSBSTydzIHVz ZXItYWdlbnQsIGhlbmNlPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3RpbmcgdGhlIGF1dGhvcml6YXRp b24gY29kZSBmcm9tIGxlYWtpbmcgdG8gcG9zc2libGUgYXR0YWNrZXJzPGJyPg0KJmd0OyAmZ3Q7 IGluIGEgaGlnaGVyIHNlY3VyaXR5IGxldmxlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBCZXN0IFJlZ2FyZHM8YnI+DQomZ3Q7ICZndDsgQnJlbnQ8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgMjAxMy8xLzkgJm5ic3A7Jmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7Ojxi cj4NCiZndDsgJmd0OyZndDsgVGhlbiB3aHkgbm90IGxldCBhdXRoIGNvZGUgYmUgc2VudCBkaXJl Y3RseSBmcm9tIEFTIHRvIENsaWVudD88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBKdXN0IHdhbnQgdG8gaW5mb3JtIFJPIHRoYXQgYW4gYXV0aCBjb2RlIGhhcyBiZWVuIGRp bGl2ZXJlZA0KdG8gQ2xpZW50Pzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTA5IDE0OjI3OjUwOjxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBIaSBCcmVudCw8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEZldyBwb2ludHMsIHdoeSB0aGlzIGRv ZXNuJ3QgY3JlYXRlIGFueSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuLjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgMS4gQXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWFp bnRhaW5zIGEgYmluZGluZyB0byB0aGUgQ2xpZW50LA0Kd2hvIHRoZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IHRva2VuIHdhcyBpc3N1ZWQgdG8uIFRvIGV4Y2hhbmdlIHRoaXMgdG8gYW4gQWNjZXNz IHRva2VuDQpjbGllbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBzaG91bGQgYXV0aGVudGljYXRl IGhpbSBzZWxmLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDIuIENvZGUgY2FuIG9ubHkgYmUgZXhj aGFuZ2VkIG9uY2UgZm9yIGFuIGFjY2VzIHRva2VuLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgLVByYWJhdGg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiBXZWQsIEphbiA5LCAy MDEzIGF0IDY6NTYgQU0sIGNzcHpob3Vyb2MgJmx0O2NzcHpob3Vyb2NAY29tcC5wb2x5dS5lZHUu aGs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgRGVhciBBbGw6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBJIGhhdmUgYSBxdWVzdGlvbiBpbiB0aGUgc2VjdGlvbiAxLjMuMS4gQXV0aG9yaXphdGlvbg0K Q29kZSBpbiByZmM2NzQ5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIE9BdXRoIDIuMCBBdXRo b3JpemF0aW9uIEZyYW1ld29yay48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IEl0IHRlbGxzICZxdW90O3doaWNoIGluIHR1cm4gZGlyZWN0cyB0aGUgcmVzb3Vy Y2Ugb3duZXINCmJhY2sgdG8gdGhlIGNsaWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHdpdGgg dGhlIGF1dGhvcml6YXRpb24gY29kZS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IFdobyBjYW4gbGV0IG1lIGtub3cgdGhlIHJlYXNvbiB3aHkgaXMg dGhlIGF1dGhvcml6YXRpb24NCmNvZGUgc2VudCB0bzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGNs aWVudCB0aHJvdWdoIGEgcmVkaXJlY3Rpb24gaW4gcmVzb3VyY2Ugb3duZXIncyBhZ2VudD8NCiZu YnNwO0FueSBzZWN1cml0eTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGltcGxpY2F0aW9ucz88YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IElzIGl0IHBvc3NpYmxl IHRvIGxldCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2VuZCB0aGUNCmF1dGhvcml6YXRpb248 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBjb2RlIHRvIHRoZSBjbGllbnQgZGlyZWN0bHkgKG5vdCB0 aHJvdWdoIHJlc291cmNlIG93bmVyJ3MNCnVzZXItYWdlbnQpPzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQmVzdCBSZWdhcmRzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgQnJlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg T0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgLS08YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBQcmFiYXRoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJy Pg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBPQXV0 aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 003428F848257AF0_=-- From hannes.tschofenig@gmx.net Fri Jan 11 01:33:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFAC21F8795 for ; Fri, 11 Jan 2013 01:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6XQfoSBNPsS for ; Fri, 11 Jan 2013 01:33:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1441E21F87AD for ; Fri, 11 Jan 2013 01:33:28 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MSFkr-1TQ8Gi0H4l-00TVBE for ; Fri, 11 Jan 2013 10:33:27 +0100 Received: (qmail invoked by alias); 11 Jan 2013 09:33:26 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 11 Jan 2013 10:33:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19DeMUC/eNDpC5NocnuyBSAYXlVAZRLC9GwFD54WZ NNJTKpPtuxDMWk Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50E609F6.3080904@mitre.org> Date: Fri, 11 Jan 2013 11:33:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50E609F6.3080904@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Use Cases for Signed Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:33:29 -0000 Hi Justin, thanks for the input.=20 A few minor remarks inside:=20 On Jan 4, 2013, at 12:45 AM, Justin Richer wrote: > I'd like to present two use cases for signed tokens, for input into = the ongoing MAC/HoK/higher-security discussion. Both of these are actual = cases that I've done in the past, and we've used either OAuth 1 or JW* = to solve them. I think that with the right tooling, a MAC-token-like = thing could be used here. I'll note to the crypto nerds in the group = (ahem, John) that I'm going to be using terms like "signing" and "MAC" = in a somewhat loose sense, so please don't get hung up on that because I = think you actually know what I mean. >=20 > So: >=20 > 1) Message-level signing. >=20 > In this, you protect the content of the HTTP message by signing it = with the secret part of the token, effectively what was done in OpenID = 2, OAuth1, and the MAC draft. You pick some subset of the HTTP = components, add them to your signing base in a predictable and = repeatable fashion, and sign it with your secret. You then send the = signature along with all of the bare HTTP elements across the wire, and = the far side does the same signature generation magic and you're good to = go. >=20 > The driving use case to this is security in depth. Yes, you probably = still do want everything to go over TLS, but that only protects things = in transit between endpoints. It won't protect anything as it gets = chewed through an application platform or handed around a server farm. = It's also considered "best practice" in many cases. In my experience in = the health care space, you almost always want to have multiple layers = protecting you. >=20 > An alternative approach here is to use a JW* container like a JWS or = JWE to hold all of your parameters (as claims) and sign/encrypt over = that. But if you do that, you're not really using HTTP anymore, except = as a dumb transport. This is the approach of SOAP, and I doubt that many = will come to its defense. (At least, those that don't want to sell you = something to process SOAP messages.) We've done this ourselves with a = prototype, and losing all of the processing capability that comes with = HTTP is a huge programmatic hit. I understand the value of the message level protection vs. the usage of = TLS. If you go to the extreme then you could argue that HTTP is = terminated in the HTTP stack and not at the application... This line of = argumentation wouldn't be too crazy given that some of the HTTP = parameters are not accessible through certain application development = platforms, for example.=20 If you abstract a bit then the two approaches are not so different. Here = is the story: * With an HTTP-based solution you do - put additional parameters into the header to convey the algorithm = related information, the access token, and the keyed message digest - the keyed message digested is computed over some HTTP headers and = it would be possible to repeat the value that is used as input to the = keyed message digest computation in another parameter. * With a JSON-based solution you do - put the access token and the encoded JSON structure into a header = (or alternatively into the body) - the signature or keyed message digest is computed over the JSON = structure which includes information that relates to the HTTP request. = Again, whether you repeat the values in the JSON itself or only a hash = of them has not yet been decided. During the OAuth 1.0 days some folks = argued that the values should be repeated so that one can easily detect = problems.=20 Do you see the similarity (expect for the encoding of the parameters)? >=20 > 2) Signed URL as an authorized artifact. >=20 > In this, you have party A generate a URL with parameters in it, = protected by a signature. That URL points to party B, who can validate = the signature. Party A then hands that fully baked URL to a third party, = C, who can't do anything to the parameters in the URL without messing up = the signature. =46rom party B's perspective, so long as that signature = is valid, all the parameters in the URL can be trusted and the request = can proceed. With a timestamp and nonce parameter (built in to OAuth1), = you've even got really nice replay and timeout protection. TLS doesn't = do you any good here, because there's a party in the middle who has the = full right to hold and view the artifact (URL), but does not have the = right to modify it. We've solved this in the past using OAuth1's = signature mechanism without tokens (aka, 2-legged OAuth1). We can't = currently do this with OAuth2. If we had a generalizable HTTP components = signing mechanism (which MAC *almost* is, and could become), then we = could. >=20 > Again, you could simply cram everything into a JW* container and send = *that* as the sole parameter to a URL and get almost the same result. = But then you've got to unpack that JW* container to get all of your = parameters, and you're back in SOAP land. And again I posit: nerds hate = SOAP. Let me see whether I get that idea right. In this case you put the OAuth = related parameter, access token, and keyed message digest into the URL = instead of putting it into the HTTP header (as a parameter). Is this the = main difference? If so, why do you care whether the values are carried = in the header vs. in the URL?=20 A slightly separate question: Out of curiosity, what specifically do you = dislike about SOAP (even though it has little relationship to what we do = here)? Is it the verbose nature due to the usage of XML? Is it the = header that contains values that you may not need? Is it WSDL that most = people use with SOAP? > Hopefully both of these will help inform the discussion and shed some = light onto why I think that: > * MAC tokens (or equivalent) are still a good idea for the WG to = pursue > * Channel-binding and TLS don't solve all security problems TLS and channel bindings can provide additional security features for an = application layer solution.=20 The channel binding ensures that the TLS exchange is not terminated at = an intermediary.=20 So, it might be useful to also see them as additional layer of defense = rather than as a competitor. =20 > * Abusing JOSE leads to breaking good HTTP designs I understand the philosophical argument but not necessarily the "breaks = good HTTP design". You can still use HTTP in the way you want. How are = you constrained when you use a JSON encoding as compared to a custom = encoding?=20 Ciao Hannes >=20 > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Fri Jan 11 03:31:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57D21F88EA for ; Fri, 11 Jan 2013 03:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJiBvQ1YyuF2 for ; Fri, 11 Jan 2013 03:31:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA87121F88FB for ; Fri, 11 Jan 2013 03:31:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24E9FBE56; Fri, 11 Jan 2013 11:31:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwzCnXUOyYcC; Fri, 11 Jan 2013 11:30:56 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5EC44BE25; Fri, 11 Jan 2013 11:30:56 +0000 (GMT) Message-ID: <50EFF7F0.90300@cs.tcd.ie> Date: Fri, 11 Jan 2013 11:30:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:31:26 -0000 Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: > Hi guys, > > Thanks for updating the assertion document and for incorporating the comments received on the mailing list. > > There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): > " > Audience A value that identifies the parties intended to process the > assertion. An audience value MAY be the URL of the Token Endpoint > as defined in Section 3.2 of OAuth 2.0 [RFC6749]. > " > > Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. > > Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). > > Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. > > Note that there are two documents that provide input to this problem space, namely: > http://tools.ietf.org/html/rfc6125 > http://tools.ietf.org/html/draft-iab-identifier-comparison-07 > > So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like "*.example.com") or only an equality match? Would "www.example.com" be the same as "example.com" if they resolve to the same IP address(es)? > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nazrmed@hotmail.com Fri Jan 11 05:34:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9621F8946; Fri, 11 Jan 2013 05:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gue99NuLy4cZ; Fri, 11 Jan 2013 05:34:46 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1370E21F8942; Fri, 11 Jan 2013 05:34:45 -0800 (PST) Received: from BLU156-DS2 ([65.55.111.73]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 05:34:45 -0800 X-EIP: [RZeRR53/pb1NoD8ZdJ2ThQRUGedR3m8A] X-Originating-Email: [nazrmed@hotmail.com] Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable From: "naz ahmed " To: "oauth-request@ietf.org " , "oauth@ietf.org " Date: Fri, 11 Jan 2013 13:34:45 +0000 X-OriginalArrivalTime: 11 Jan 2013 13:34:45.0208 (UTC) FILETIME=[6B284580:01CDF000] Subject: Re: [OAUTH-WG] OAuth Digest, Vol 51, Issue 41 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 13:34:46 -0000 Sent from BlackBerry=AE on Airtel -----Original Message----- From: oauth-request@ietf.org Date: Fri, 11 Jan 2013 09:33:29=20 To: Subject: OAuth Digest, Vol 51, Issue 41 =0A= If you have received this digest without all the individual message=0A= attachments you will need to update your digest options in your list=0A= subscription.=A0 To do so, go to =0A= =0A= https://www.ietf.org/mailman/listinfo/oauth=0A= =0A= Click the 'Unsubscribe or edit options' button, log in, and set "Get=0A= MIME or Plain Text Digests?" to MIME.=A0 You can set this option=0A= globally for all the list digests you receive at this point.=0A= =0A= =0A= =0A= Send OAuth mailing list submissions to=0A= =A0=A0=A0=A0=A0=A0=A0 oauth@ietf.org=0A= =0A= To subscribe or unsubscribe via the World Wide Web, visit=0A= =A0=A0=A0=A0=A0=A0=A0 https://www.ietf.org/mailman/listinfo/oauth=0A= or, via email, send a message with subject or body 'help' to=0A= =A0=A0=A0=A0=A0=A0=A0 oauth-request@ietf.org=0A= =0A= You can reach the person managing the list at=0A= =A0=A0=A0=A0=A0=A0=A0 oauth-owner@ietf.org=0A= =0A= When replying, please edit your Subject line so it is more specific=0A= than "Re: Contents of OAuth digest..." From jricher@mitre.org Fri Jan 11 06:18:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FC621F8976 for ; Fri, 11 Jan 2013 06:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-4.142, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AeaBjQWhepj for ; Fri, 11 Jan 2013 06:18:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA221F8929 for ; Fri, 11 Jan 2013 06:18:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3CCD41F136A; Fri, 11 Jan 2013 09:18:31 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 19BCC1F135F; Fri, 11 Jan 2013 09:18:31 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 09:18:30 -0500 From: "Richer, Justin P." To: " " Thread-Topic: =?gb2312?B?W09BVVRILVdHXSC08Li0OiBSZTogIEEgcXVlc3Rpb24gb2YgMS4zLjEuIEF1?= =?gb2312?B?dGhvcml6YXRpb24gQ29kZSBpbiByZmM2NzQ5IFRoZSBPQXV0aCAyLjAgQXV0?= =?gb2312?Q?horization_Framework?= Thread-Index: AQHN8AaIzFsIPN7COUSv6U5+mirJkw== Date: Fri, 11 Jan 2013 14:18:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.155] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06876286IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: Peng Zhou , "" Subject: Re: [OAUTH-WG] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIG9mIDEuMy4x?= =?gb2312?b?LiBBdXRob3JpemF0aW9uIENvZGUgaW4gcmZjNjc0OSBUaGUgT0F1dGggMi4w?= =?gb2312?b?IEF1dGhvcml6YXRpb24gRnJhbWV3b3Jr?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:18:34 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06876286IMCMBX01MITREOR_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QmVjYXVzZSB0aGV5IGdldCByZWRpcmVjdGVkIGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIGFuIEF1 dGhvcml6YXRpb24gQ29kZSB3aGljaCBpcyB0aGVuIHZlcmlmaWVkIGF0IHRoZSBUb2tlbiBFbmRw b2ludCB3aXRob3V0IHRoZSBVc2VyIEFnZW50J3MgaW52b2x2ZW1lbnQuIFN1cmUsIHRoZSBVc2Vy IEFnZW50IGNvdWxkIGhhdmUganVzdCBtYWRlIHNvbWV0aGluZyB1cCwgYnV0IHRoZW4gaXQgd291 bGRuJ3Qgd29yayBhdCB0aGUgVG9rZW4gRW5kcG9pbnQuDQoNCiAtLSBKdXN0aW4NCg0KT24gSmFu IDExLCAyMDEzLCBhdCA0OjI5IEFNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhv dS5zdWppbmdAenRlLmNvbS5jbj4+DQogd3JvdGU6DQoNCg0KDQpKdXN0aW4gUmljaGVyIDxqcmlj aGVyQG1pdHJlLm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiDQtNPaIDIwMTMtMDEtMTAg MDE6Mzg6MDY6DQoNCj4gQnJlbnQsDQo+DQo+IElmIHlvdSdyZSBzZW5kaW5nIHRoZSBjb2RlIGlu IHRoZSBiYWNrIGNoYW5uZWwgZGlyZWN0bHkgdG8gdGhlIENsaWVudCwNCj4gYXMgSSBiZWxpZXZl IHlvdSdyZSBkb2luZyBmcm9tIHlvdXIgdGV4dCBiZWxvdywgSSB3b3VsZCBsaWtlIHlvdSB0bw0K PiByZWFsaXplIHNvbWUgdGhpbmdzOg0KPg0KPiAxKSBUaGlzIGlzIG5vdCBPQXV0aCwgYW5kIGlz IGluIGZhY3QgYW50aXRoZXRpY2FsIHRvIHRoZSBPQXV0aCB3YXkgb2YNCj4gc29sdmluZyB0aGUg Y29ubmVjdGlvbiBwcm9ibGVtLg0KPiAyKSBZb3UgYXJlIGFjdHVhbGx5IGxvd2VyaW5nIHlvdXIg b3ZlcmFsbCBzZWN1cml0eSBiZWNhdXNlIHRoZSBhY2Nlc3MNCj4gY29kZSBpcyBubyBsb25nZXIg Ym91bmQgdG8gYW55IHBhcnRpY3VsYXIgYnJvd3NlciBzZXNzaW9uIHdpdGggZWl0aGVyDQo+IHRo ZSBjbGllbnQgb3IgdGhlIEFTLg0KPiAzKSBJZiB5b3UncmUgc2VuZGluZyBpdCBkaXJlY3RseSwg dGhlcmUgaXMgbm8gbG9uZ2VyIGFueSBwb2ludCBvZiB1c2luZw0KPiB0aGUgY29kZSwgc2luY2Ug dGhlIENsaWVudCBpcyBqdXN0IGdvaW5nIHRvIHR1cm4gYXJvdW5kIGFuZCBzZW5kIGl0IHRvDQo+ IHRoZSBBUyBhZ2FpbiB0byBnZXQgYSB0b2tlbi4gV2h5IG5vdCBqdXN0IHNlbmQgdGhlIHRva2Vu PyBCdXQgYWdhaW4sDQo+IHRoaXMgaXMgc3RpbGwgbm90IE9BdXRoLg0KPg0KPg0KPiBUaGluayBh Ym91dCBpdCB0aGlzIHdheTogVGhlcmUgYXJlIHRocmVlIGNvbm5lY3Rpb25zIGluIHRoZSBjb21t b24gT0F1dGgNCj4gQXV0aG9yaXphdGlvbiBDb2RlIHNjZW5hcmlvLCB3aGljaCBpcyB3aHkgaXQn cyBrbm93biBhcyBhIHRocmVlLWxlZ2dlZA0KPiBPQXV0aCBmbG93IGluIG1hbnkgY2lyY2xlcy4g RWFjaCBvZiB0aGVzZSBsZWdzIGhhcyB1bmlxdWUgcHJvcGVydGllcywgaXMNCj4gcHJvdGVjdGVk IGJ5IGRpZmZlcmVudCB0aGluZ3MsIGFuZCBpcyBleHBvc2VkIHRvIGRpZmZlcmVudCBwaWVjZXMg b2YNCj4ga25vd2xlZGdlIGF0IGRpZmZlcmVudCB0aW1lcy4NCj4NCj4gMSkgQ2xpZW50IDwtPiBV c2VyIEFnZW50OiBwcm90ZWN0ZWQgYnkgYSBsb2NhbCBzZXNzaW9uIG9mIHRoZSBDbGllbnQncw0K PiBjaG9vc2luZy4gRm9yIFdlYiBiYXNlZCBjbGllbnRzIHRoaXMgaXMgb2Z0ZW4gc3RhbmRhcmQg SFRUUCBzZXNzaW9uDQo+IGNvb2tpZXMgb3Igc2ltaWxhciwgcG90ZW50aWFsbHkgYmFja2VkIGJ5 IGEgbG9naW4gb2Ygc29tZSB0eXBlIGJ5IHRoZQ0KPiB1c2VyIHRvIHRoZSBDbGllbnQgYXMgd2Vs bC4gVGhpcyBzZXNzaW9uIGlzIG5ldmVyIGV4cG9zZWQgdG8gdGhlDQo+IEF1dGhvcml6YXRpb24g U2VydmVyLg0KPiAyKSBBdXRob3JpemF0aW9uIFNlcnZlciA8LT4gVXNlciBBZ2VudDogcHJvdGVj dGVkIGJ5IGEgbG9jYWwgc2Vzc2lvbiBvZg0KPiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIncyBj aG9vc2luZywgbm9ybWFsbHkgdGhyb3VnaCBzb21lIGtpbmQgb2YNCj4gUHJpbWFyeSBDcmVkZW50 aWFsIChsb2dpbikgdGhhdCB0aGUgdXNlciBoYXMgYSB0aGUgQVMuIEltcG9ydGFudGx5LA0KPiB0 aGVzZSBjcmVkZW50aWFscyBhcmUgbmV2ZXIgZXhwb3NlZCB0byB0aGUgQ2xpZW50Lg0KPiAzKSBD bGllbnQgPC0+IEF1dGhvcml6YXRpb24gU2VydmVyOiBwcm90ZWN0ZWQgYnkgdGhlIGNsaWVudCBj cmVkZW50aWFscywNCj4gd2hpY2ggYXJlLCBpbXBvcnRhbnRseSwgbm90IGV4cG9zZWQgdG8gdGhl IHVzZXIgb3IgdXNlciBhZ2VudC4NCj4NCj4gQnkgc2VuZGluZyB0aGUgY29kZSBhcyBwYXJ0IG9m IHRoZSByZWRpcmVjdCwgdGhlIENsaWVudCBpcyBhYmxlIHRvIHByb3ZlDQo+IHRoYXQgdGhlIFVz ZXIgQWdlbnQgYWN0dWFsbHkgd2VudCB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKDIpIGFu ZA0KPiBnb3Qgc29tZXRoaW5nLiBUaGUgQXV0aG9yaXphdGlvbiBDb2RlIGlzIHRoZW4gc2VudCB0 aHJvdWdoIHRoZSBib3R0b20NCj4gbGVnICgzKSBvZiB0aGUgY2hhbm5lbCB0byB2ZXJpZnkgdGhh dCBpdCByZWFsbHkgZGlkIGNvbWUgZnJvbSB0aGUNCj4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4g dGhlIGNvbnRleHQgb2YgdGhlIHVzZXIgdGhhdCB3YXMganVzdCB0aGVyZSBpbg0KPiAoMSkuDQoN CkhvdyBpcyBDbGllbnQgYXNzdXJlZCB0aGUgVUEgYWN0dWFsbHkgd2VudCB0byBBUyBhbmQgZ290 IHNvbWV0aGluZyBieSB0aGUNCmZvbGxvd2luZyBVUkw/DQoNCkGjug0KIEdFVC9hdXRob3JpemU/ cmVzcG9uc2VfdHlwZT1jb2RlJmNsaWVudF9pZD1zNkJoZFJrcXQzJnN0YXRlPXh5eiAmcmVkaXJl Y3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQpIVFRQLzEu MSAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tPGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20+DQpD Og0KSFRUUC8xLjEzMDJGb3VuZA0KTG9jYXRpb246IGh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29t L2NiP2NvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQSAmc3RhdGU9eHl6DQoNCg0KDQoNCg0KICBJ biBvdGhlciB3b3JkcywgdGhpcyBtZWNoYW5pc20gdGhhdCB5b3Ugc2VlbSB0byBiZSBhdm9pZGlu ZyBpcw0KPiBleGFjdGx5IHdoYXQgbWFrZXMgT0F1dGggc2VjdXJlLg0KPg0KPiBJZiB5b3UgaW5z dGVhZCBzZW5kIHRoZSBjb2RlIHRocm91Z2ggKDMpLCB0aGVuIHRoZSBDbGllbnQgYXMgbm8gd2F5 IGF0DQo+IGFsbCBvZiBrbm93aW5nIHRoYXQgdGhlIHVzZXIgaW4gKDEpIGV2ZXIgd2VudCB0byB0 aGUgYXV0aG9yaXphdGlvbg0KPiBzZXJ2ZXIgdmlhICgyKS4gQWxsIHRoZSBDbGllbnQga25vd3Mg aXMgdGhhdCB0aGV5IHNlbnQgdGhlIHVzZXINCj4gc29tZXBsYWNlIGFuZCB0aGF0IGEgbWFnaWMg Y29kZSBzaG93ZWQgdXAuIEl0IGlzIHZlcnksIHZlcnksIHZlcnkNCj4gZGFuZ2Vyb3VzIGFuZCBh IHZlcnksIHZlcnkgYmFkIGlkZWEgdG8gYXNzdW1lIHRoYXQgYSBjb2RlIGNvbWluZyBpbiB0aGUN Cj4gYmFjayBjaGFubmVsICgzKSBoYXMgYW55dGhpbmcgYXQgYWxsIHRvIGRvIHdpdGggYW55IHBh cnRpY3VsYXIgc2Vzc2lvbiAoMSkuDQo+DQo+IFRoaXMgYXBwcm9hY2ggZG9lcyAqbm90KiBtaXRp Z2F0ZSBhbnkgcmVhbCBzZWN1cml0eSB0aHJlYXRzLCBhbmQgaW4gZmFjdA0KPiBpbnRyb2R1Y2Vz IGEgZ3JlYXQgbnVtYmVyIG9mIG90aGVycywgYXMgZGVzY3JpYmVkIGhlcmUuIFRoZXJlIGFyZSBt dWNoDQo+IGJldHRlciB3YXlzIHRvIHByb3RlY3QgdGhlIEF1dGhvcml6YXRpb24gQ29kZSwgYW5k IG1vc3Qgb2YgdGhlIGJlc3QNCj4gcHJhY3RpY2VzIGFyZSBlbnVtZXJhdGVkIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBkb2N1bWVudC4gU29tZQ0KPiBvZiB0aGUgbW9zdCBjb21tb24g YXJlOg0KPg0KPiAxKSBNYWtlIEF1dGhvcml6YXRpb24gQ29kZXMgb25lLXRpbWUtdXNlIChldmVu IGlmIHlvdSB0cnkgYW5kIGZhaWwsIGl0J3MNCj4gdGhyb3duIGF3YXkpDQo+IDIpIE1ha2UgQXV0 aG9yaXphdGlvbiBDb2RlcyB0aW1lIG91dCBhZnRlciBhIHZlcnkgc2hvcnQgcGVyaW9kIChtaW51 dGVzDQo+IG9yIHNlY29uZHMpDQo+DQo+DQo+IEkgaG9wZSB0aGlzIGhlbHBzLg0KPg0KPiAtLSBK dXN0aW4NCj4NCj4NCj4NCj4gT24gMDEvMDkvMjAxMyAwMTo0MiBBTSwgUGVuZyBaaG91IHdyb3Rl Og0KPiA+IERlYXIgU3VKaW5nOg0KPiA+DQo+ID4gSWYgaXQgaXMgdGhlIG9ubHkgcmVhc29uLCB3 aHkgd2Ugc2VuZCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHRvIHRoZQ0KPiA+IGNsaWVudCBkaXJl Y3RseSBhbmQgc2VuZCBhbm90aGVyIG5vdGlmaWNhdGlvbiB3aXRob3V0IHRoZQ0KPiA+IGF1dGhv cml6YXRpb24gY29kZSB0byB0aGUgUk8uIFRoaXMgd2F5IGNhbiBtaXRpZ2F0ZSB0aGUgY2hhbmNl IHRoYXQNCj4gPiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIGV4cG9zZWQgdG8gdGhlIFJPJ3Mg dXNlci1hZ2VudCwgaGVuY2UNCj4gPiBwcm90ZWN0aW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg ZnJvbSBsZWFraW5nIHRvIHBvc3NpYmxlIGF0dGFja2Vycw0KPiA+IGluIGEgaGlnaGVyIHNlY3Vy aXR5IGxldmxlLg0KPiA+DQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4gQnJlbnQNCj4gPg0KPiA+IDIw MTMvMS85ICA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNv bS5jbj4+Og0KPiA+PiBUaGVuIHdoeSBub3QgbGV0IGF1dGggY29kZSBiZSBzZW50IGRpcmVjdGx5 IGZyb20gQVMgdG8gQ2xpZW50Pw0KPiA+Pg0KPiA+PiBKdXN0IHdhbnQgdG8gaW5mb3JtIFJPIHRo YXQgYW4gYXV0aCBjb2RlIGhhcyBiZWVuIGRpbGl2ZXJlZCB0byBDbGllbnQ/DQo+ID4+DQo+ID4+ IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+INC0 09ogMjAxMy0wMS0wOSAxNDoyNzo1MDoNCj4gPj4NCj4gPj4+IEhpIEJyZW50LA0KPiA+Pj4NCj4g Pj4+IEZldyBwb2ludHMsIHdoeSB0aGlzIGRvZXNuJ3QgY3JlYXRlIGFueSBzZWN1cml0eSBpbXBs aWNhdGlvbnMuLg0KPiA+Pj4NCj4gPj4+IDEuIEF1dGhvcml6YXRpb24gc2VydmVyIG1haW50YWlu cyBhIGJpbmRpbmcgdG8gdGhlIENsaWVudCwgd2hvIHRoZQ0KPiA+Pj4gdG9rZW4gd2FzIGlzc3Vl ZCB0by4gVG8gZXhjaGFuZ2UgdGhpcyB0byBhbiBBY2Nlc3MgdG9rZW4gY2xpZW50DQo+ID4+PiBz aG91bGQgYXV0aGVudGljYXRlIGhpbSBzZWxmLg0KPiA+Pj4gMi4gQ29kZSBjYW4gb25seSBiZSBl eGNoYW5nZWQgb25jZSBmb3IgYW4gYWNjZXMgdG9rZW4uDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzICYg cmVnYXJkcywNCj4gPj4+IC1QcmFiYXRoDQo+ID4+PiBPbiBXZWQsIEphbiA5LCAyMDEzIGF0IDY6 NTYgQU0sIGNzcHpob3Vyb2MgPGNzcHpob3Vyb2NAY29tcC5wb2x5dS5lZHUuaGs8bWFpbHRvOmNz cHpob3Vyb2NAY29tcC5wb2x5dS5lZHUuaGs+DQo+ID4+Pj4gd3JvdGU6DQo+ID4+PiBEZWFyIEFs bDoNCj4gPj4+DQo+ID4+PiBJIGhhdmUgYSBxdWVzdGlvbiBpbiB0aGUgc2VjdGlvbiAxLjMuMS4g QXV0aG9yaXphdGlvbiBDb2RlIGluIHJmYzY3NDkNCj4gPj4+IFRoZSBPQXV0aCAyLjAgQXV0aG9y aXphdGlvbiBGcmFtZXdvcmsuDQo+ID4+Pg0KPiA+Pj4gSXQgdGVsbHMgIndoaWNoIGluIHR1cm4g ZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50DQo+ID4+PiB3aXRo IHRoZSBhdXRob3JpemF0aW9uIGNvZGUuIg0KPiA+Pj4NCj4gPj4+IFdobyBjYW4gbGV0IG1lIGtu b3cgdGhlIHJlYXNvbiB3aHkgaXMgdGhlIGF1dGhvcml6YXRpb24gY29kZSBzZW50IHRvDQo+ID4+ PiBjbGllbnQgdGhyb3VnaCBhIHJlZGlyZWN0aW9uIGluIHJlc291cmNlIG93bmVyJ3MgYWdlbnQ/ ICBBbnkgc2VjdXJpdHkNCj4gPj4+IGltcGxpY2F0aW9ucz8NCj4gPj4+DQo+ID4+PiBJcyBpdCBw b3NzaWJsZSB0byBsZXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNlbmQgdGhlIGF1dGhvcml6 YXRpb24NCj4gPj4+IGNvZGUgdG8gdGhlIGNsaWVudCBkaXJlY3RseSAobm90IHRocm91Z2ggcmVz b3VyY2Ugb3duZXIncyB1c2VyLWFnZW50KT8NCj4gPj4+DQo+ID4+PiBCZXN0IFJlZ2FyZHMNCj4g Pj4+IEJyZW50DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+Pj4gT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+Pj4gLS0NCj4gPj4+IFRoYW5rcyAmIFJlZ2FyZHMs DQo+ID4+PiBQcmFiYXRoDQo+ID4+Pg0KPiA+Pj4gTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyDQo+ ID4+Pg0KPiA+Pj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+ID4+PiBodHRwOi8vUmFt cGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KPg0KDQo= --_000_B33BFB58CCC8BE4998958016839DE27E06876286IMCMBX01MITREOR_ Content-Type: text/html; charset="gb2312" Content-ID: <50808DDEF146D447842B93C7ADD7B311@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Because they get redirected back to the client with an Authorization Code w= hich is then verified at the Token Endpoint without the User Agent's involv= ement. Sure, the User Agent could have just made something up, but then it = wouldn't work at the Token Endpoint.

 -- Justin

On Jan 11, 2013, at 4:29 AM, <zhou.sujing@zte.com.cn>
 wrote:



Justin Richer <jricher@mitre.org> =D0=B4=D3=DA 2013-01-10 01:38:06:

> Brent,
>
> If you're sending the code in the back channel directly to the Client,=
> as I believe you're doing from your text below, I would like you to > realize some things:
>
> 1) This is not OAuth, and is in fact antithetical to the OAuth way of<= br> > solving the connection problem.
> 2) You are actually lowering your overall security because the access<= br> > code is no longer bound to any particular browser session with either<= br> > the client or the AS.
> 3) If you're sending it directly, there is no longer any point of usin= g
> the code, since the Client is just going to turn around and send it to=
> the AS again to get a token. Why not just send the token? But again, > this is still not OAuth.
>
>
> Think about it this way: There are three connections in the common OAu= th
> Authorization Code scenario, which is why it's known as a three-legged=
> OAuth flow in many circles. Each of these legs has unique properties, = is
> protected by different things, and is exposed to different pieces of > knowledge at different times.
>
> 1) Client <-> User Agent: protected by a local session of the Cl= ient's
> choosing. For Web based clients this is often standard HTTP session > cookies or similar, potentially backed by a login of some type by the<= br> > user to the Client as well. This session is never exposed to the
> Authorization Server.
> 2) Authorization Server <-> User Agent: protected by a local ses= sion of
> the Authorization Server's choosing, normally through some kind of
> Primary Credential (login) that the user has a the AS. Importantly, > these credentials are never exposed to the Client.
> 3) Client <-> Authorization Server: protected by the client cred= entials,
> which are, importantly, not exposed to the user or user agent.
>
> By sending the code as part of the redirect, the Client is able to pro= ve
> that the User Agent actually went to the Authorization Server (2) and<= br> > got something. The Authorization Code is then sent through the bottom<= br> > leg (3) of the channel to verify that it really did come from the
> Authorization Server in the context of the user that was just there in=
> (1).

How is Client assured the UA actually went to AS and g= ot something by the
following URL?

A=A3=BA
 GET/authorize?response_type=3Dcode&client_id= =3Ds6BhdRkqt3&state=3Dxyz &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eex= ample%2Ecom%2Fcb
HTTP/1.1  Host: server.example.com
C:
HTTP/1.1302Found
Location: https://client.example.com/cb?code=3DSplxlOBeZQQYbYS6WxSbIA &state= =3Dxyz





  In other words, this mechanism that you seem to= be avoiding is
> exactly what makes OAuth secure.
>
> If you instead send the code through (3), then the Client as no way at=
> all of knowing that the user in (1) ever went to the authorization
> server via (2). All the Client knows is that they sent the user
> someplace and that a magic code showed up. It is very, very, very
> dangerous and a very, very bad idea to assume that a code coming in th= e
> back channel (3) has anything at all to do with any particular session= (1).
>
> This approach does *not* mitigate any real security threats, and in fa= ct
> introduces a great number of others, as described here. There are much=
> better ways to protect the Authorization Code, and most of the best > practices are enumerated in the security considerations document. Some=
> of the most common are:
>
> 1) Make Authorization Codes one-time-use (even if you try and fail, it= 's
> thrown away)
> 2) Make Authorization Codes time out after a very short period (minute= s
> or seconds)
>
>
> I hope this helps.
>
> -- Justin
>
>
>
> On 01/09/2013 01:42 AM, Peng Zhou wrote:
> > Dear SuJing:
> >
> > If it is the only reason, why we send the authorization code to t= he
> > client directly and send another notification without the
> > authorization code to the RO. This way can mitigate the chance th= at
> > the authorization code is exposed to the RO's user-agent, hence > > protecting the authorization code from leaking to possible attack= ers
> > in a higher security levle.
> >
> > Best Regards
> > Brent
> >
> > 2013/1/9  <zhou= .sujing@zte.com.cn>:
> >> Then why not let auth code be sent directly from AS to Client= ?
> >>
> >> Just want to inform RO that an auth code has been dilivered t= o Client?
> >>
> >> oauth-bounces@ietf.= org =D0=B4=D3=DA 2013-01-09 14:27:50:
> >>
> >>> Hi Brent,
> >>>
> >>> Few points, why this doesn't create any security implicat= ions..
> >>>
> >>> 1. Authorization server maintains a binding to the Client= , who the
> >>> token was issued to. To exchange this to an Access token = client
> >>> should authenticate him self.
> >>> 2. Code can only be exchanged once for an acces token. > >>>
> >>> Thanks & regards,
> >>> -Prabath
> >>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <cspzhouroc@comp.polyu.edu.hk
> >>>> wrote:
> >>> Dear All:
> >>>
> >>> I have a question in the section 1.3.1. Authorization Cod= e in rfc6749
> >>> The OAuth 2.0 Authorization Framework.
> >>>
> >>> It tells "which in turn directs the resource owner b= ack to the client
> >>> with the authorization code."
> >>>
> >>> Who can let me know the reason why is the authorization c= ode sent to
> >>> client through a redirection in resource owner's agent? &= nbsp;Any security
> >>> implications?
> >>>
> >>> Is it possible to let the authorization server send the a= uthorization
> >>> code to the client directly (not through resource owner's= user-agent)?
> >>>
> >>> Best Regards
> >>> Brent
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> h= ttps://www.ietf.org/mailman/listinfo/oauth
> >>> --
> >>> Thanks & Regards,
> >>> Prabath
> >>>
> >>> Mobile : +94 71 809 6732
> >>>
> >>> http://blog.facil= elogin.com
> >>> http://RampartFAQ.com_______________________________________________ > >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> h= ttps://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
>

--_000_B33BFB58CCC8BE4998958016839DE27E06876286IMCMBX01MITREOR_-- From jricher@mitre.org Fri Jan 11 06:34:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B362321F88C7 for ; Fri, 11 Jan 2013 06:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVzfOra1BRah for ; Fri, 11 Jan 2013 06:34:48 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 45E0621F88B9 for ; Fri, 11 Jan 2013 06:34:48 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 99FC41F3561; Fri, 11 Jan 2013 09:34:47 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8986C1F354E; Fri, 11 Jan 2013 09:34:47 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 09:34:47 -0500 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Use Cases for Signed Tokens Thread-Index: AQHN7963WFcICpEMJ0uuwZkfqfPSpJhEha8A Date: Fri, 11 Jan 2013 14:34:46 +0000 Message-ID: References: <50E609F6.3080904@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.155] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CED9ED8FC08B24EADEBEFF58F62E439@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Use Cases for Signed Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:34:49 -0000 Hannes, thanks for the input. Inline: On Jan 11, 2013, at 4:33 AM, Hannes Tschofenig wrote: > Hi Justin, >=20 > thanks for the input.=20 >=20 > A few minor remarks inside:=20 >=20 > On Jan 4, 2013, at 12:45 AM, Justin Richer wrote: >=20 >> I'd like to present two use cases for signed tokens, for input into the = ongoing MAC/HoK/higher-security discussion. Both of these are actual cases = that I've done in the past, and we've used either OAuth 1 or JW* to solve t= hem. I think that with the right tooling, a MAC-token-like thing could be u= sed here. I'll note to the crypto nerds in the group (ahem, John) that I'm = going to be using terms like "signing" and "MAC" in a somewhat loose sense,= so please don't get hung up on that because I think you actually know what= I mean. >>=20 >> So: >>=20 >> 1) Message-level signing. >>=20 >> In this, you protect the content of the HTTP message by signing it with = the secret part of the token, effectively what was done in OpenID 2, OAuth1= , and the MAC draft. You pick some subset of the HTTP components, add them = to your signing base in a predictable and repeatable fashion, and sign it w= ith your secret. You then send the signature along with all of the bare HTT= P elements across the wire, and the far side does the same signature genera= tion magic and you're good to go. >>=20 >> The driving use case to this is security in depth. Yes, you probably sti= ll do want everything to go over TLS, but that only protects things in tran= sit between endpoints. It won't protect anything as it gets chewed through = an application platform or handed around a server farm. It's also considere= d "best practice" in many cases. In my experience in the health care space,= you almost always want to have multiple layers protecting you. >>=20 >> An alternative approach here is to use a JW* container like a JWS or JWE= to hold all of your parameters (as claims) and sign/encrypt over that. But= if you do that, you're not really using HTTP anymore, except as a dumb tra= nsport. This is the approach of SOAP, and I doubt that many will come to it= s defense. (At least, those that don't want to sell you something to proces= s SOAP messages.) We've done this ourselves with a prototype, and losing al= l of the processing capability that comes with HTTP is a huge programmatic = hit. >=20 > I understand the value of the message level protection vs. the usage of T= LS. Just a note that it's not necessarily "vs." in the use case, it's "in addit= ion to". Multiple layers of security are considered best practice in many c= ases, not the least of which is healthcare. Even if you have something set = up with mutual TLS, you're supposed to protect each message separately as w= ell.=20 > If you go to the extreme then you could argue that HTTP is terminated in = the HTTP stack and not at the application... This line of argumentation wou= ldn't be too crazy given that some of the HTTP parameters are not accessibl= e through certain application development platforms, for example.=20 >=20 > If you abstract a bit then the two approaches are not so different. Here = is the story: >=20 > * With an HTTP-based solution you do > - put additional parameters into the header to convey the algorithm rel= ated information, the access token, and the keyed message digest > - the keyed message digested is computed over some HTTP headers and it = would be possible to repeat the value that is used as input to the keyed me= ssage digest computation in another parameter. >=20 > * With a JSON-based solution you do > - put the access token and the encoded JSON structure into a header (or= alternatively into the body) > - the signature or keyed message digest is computed over the JSON struc= ture which includes information that relates to the HTTP request. Again, wh= ether you repeat the values in the JSON itself or only a hash of them has n= ot yet been decided. During the OAuth 1.0 days some folks argued that the v= alues should be repeated so that one can easily detect problems.=20 >=20 > Do you see the similarity (expect for the encoding of the parameters)? I do see the similarity, but the encoding of the parameters is exactly the = difference that I think is important to the argument I'm making above. I co= uld also encode all of my parameters as an ASN.1 document, or XML, or whate= ver, and I'd be in roughly the same boat. >=20 >>=20 >> 2) Signed URL as an authorized artifact. >>=20 >> In this, you have party A generate a URL with parameters in it, protecte= d by a signature. That URL points to party B, who can validate the signatur= e. Party A then hands that fully baked URL to a third party, C, who can't d= o anything to the parameters in the URL without messing up the signature. F= rom party B's perspective, so long as that signature is valid, all the para= meters in the URL can be trusted and the request can proceed. With a timest= amp and nonce parameter (built in to OAuth1), you've even got really nice r= eplay and timeout protection. TLS doesn't do you any good here, because the= re's a party in the middle who has the full right to hold and view the arti= fact (URL), but does not have the right to modify it. We've solved this in = the past using OAuth1's signature mechanism without tokens (aka, 2-legged O= Auth1). We can't currently do this with OAuth2. If we had a generalizable H= TTP components signing mechanism (which MAC *almost* is, and could become),= then we could. >>=20 >> Again, you could simply cram everything into a JW* container and send *t= hat* as the sole parameter to a URL and get almost the same result. But the= n you've got to unpack that JW* container to get all of your parameters, an= d you're back in SOAP land. And again I posit: nerds hate SOAP. >=20 > Let me see whether I get that idea right. In this case you put the OAuth = related parameter, access token, and keyed message digest into the URL inst= ead of putting it into the HTTP header (as a parameter). Is this the main d= ifference? If so, why do you care whether the values are carried in the hea= der vs. in the URL?=20 Yes that's correct - In this use case, everything goes in the URL. If every= thing goes in the URL, then you've got a single artifact that you can pass = around to different systems. You can't do that with HTTP headers, which mak= es it an untenable approach for this. >=20 > A slightly separate question: Out of curiosity, what specifically do you = dislike about SOAP (even though it has little relationship to what we do he= re)? Is it the verbose nature due to the usage of XML? Is it the header tha= t contains values that you may not need? Is it WSDL that most people use wi= th SOAP? I think you're getting hung up on the specifics of the SOAP protocol set (X= ML, WSDL) and missing my main point: SOAP doesn't make use of HTTP in the b= est way it can.=20 - ignores all aspects of HTTP like action verbs, headers, and query parame= ters in favor of putting everything in a specialty-encoded document - can't be used without complex tooling (smoke test: can I script this API= with wget?) - complex tools from different vendors don't tend to be very interoperable= with each other without significant engineering of the application >=20 >> Hopefully both of these will help inform the discussion and shed some li= ght onto why I think that: >> * MAC tokens (or equivalent) are still a good idea for the WG to pursue >> * Channel-binding and TLS don't solve all security problems >=20 > TLS and channel bindings can provide additional security features for an = application layer solution.=20 > The channel binding ensures that the TLS exchange is not terminated at an= intermediary.=20 >=20 > So, it might be useful to also see them as additional layer of defense ra= ther than as a competitor. =20 Again it's not a "one or the other" thing here. I was simply trying to make= the point that TLS channel binding, while useful at solving its own set of= issues, is not a panacea. Neither of these two use cases, for example, can= be addressed by it at all. If you do have TLS *on top of* these other appr= oaches, yes, that can make it even better. And it's exactly that independen= t modularity that makes this stuff worthwhile, in my opinion. >=20 >> * Abusing JOSE leads to breaking good HTTP designs >=20 > I understand the philosophical argument but not necessarily the "breaks g= ood HTTP design". You can still use HTTP in the way you want. How are you c= onstrained when you use a JSON encoding as compared to a custom encoding?=20 >=20 If you cram all of your verbs and parameters into a JOSE-encoded body, you'= re not using HTTP in what is today considered best practice. This philosoph= y, again, was a main failing of SOAP and what made it ultimately fail in th= e market. -- Justin > Ciao > Hannes >=20 >>=20 >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Fri Jan 11 06:37:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A921F873C for ; Fri, 11 Jan 2013 06:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6SZUcdCAJaQ for ; Fri, 11 Jan 2013 06:37:36 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7919A21F8455 for ; Fri, 11 Jan 2013 06:37:36 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EEE5E1F3566; Fri, 11 Jan 2013 09:37:35 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DDF221F356D; Fri, 11 Jan 2013 09:37:35 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 09:37:35 -0500 From: "Richer, Justin P." To: Stephen Farrell Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RL+fDQvzjad0WAuZe12tNYZphEUmcAgAA0JQA= Date: Fri, 11 Jan 2013 14:37:34 +0000 Message-ID: References: <50EFF7F0.90300@cs.tcd.ie> In-Reply-To: <50EFF7F0.90300@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.155] Content-Type: text/plain; charset="us-ascii" Content-ID: <329D781EBC3ABF43AEB6D473D3131FA3@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:37:37 -0000 It's my understanding that the general assertions claim is more of a concep= tual mapping than it is a concrete encoding, so anything more specific here= would be out of place. I would like the authors to either confirm or corre= ct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell wrote: >=20 > Hi, >=20 > Since we thought we were done with it, I put this document > on the IESG telechat agenda for Jan 24. Hannes' question > however looks like its a real one that needs an answer. >=20 > I'd appreciate it if the WG could figure out if there's any > change needed and either make that change in the next week, > or else tell me to take the draft off the telechat agenda > for now. >=20 > If discussion doesn't happen, or happens but doesn't reach > a conclusion, then I'll take the draft off the agenda in a > week's time and we can sort out if any changes are needed > later. >=20 > The reason why now+1-week matters, is that that's when > IESG members tend to do their reviews and having 'em all > review a moving target isn't a good plan. >=20 > Thanks, > S. >=20 > On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >> Hi guys,=20 >>=20 >> Thanks for updating the assertion document and for incorporating the com= ments received on the mailing list.=20 >>=20 >> There is only one issue that caught my attention. You changed the descri= ption of the audience element to the following text (in version -09 of http= ://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >> " >> Audience A value that identifies the parties intended to process the >> assertion. An audience value MAY be the URL of the Token Endpoint >> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >> " >>=20 >> Since the value in the audience field is used to by the authorization se= rver in a comparison operation (see Section 5.2) I believe the current text= will lead to interoperability problems. Not only is the comparision operat= ion unspecified but even the value that is contained in the field is left o= pen. The RFC 2119 MAY does not really give a lot of hints of what should be= put in there.=20 >>=20 >> Without having a clear description of what identifier is contained in th= is field and how the comparison works it is either possible that a legitima= te client is rejected by the authorization server (which is annoying) or an= assertion with an incorrect assertion is accepted (which is a security pro= blem).=20 >>=20 >> Btw, the same issue can also be seen in http://tools.ietf.org/html/draft= -ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml= 2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of ht= tp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim). = >From the description in the JWT document I was not quite sure whether the a= bility to carry an array of case sensitive strings for that field is also a= llowed in any of the assertion documents.=20 >>=20 >> Note that there are two documents that provide input to this problem spa= ce, namely: >> http://tools.ietf.org/html/rfc6125 >> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>=20 >> So, I would suggest to decide what type of identifier goes into this fie= ld and then to point to a document that illustrates how the comparison oper= ation would look like. Possible identifiers are domain names, IP addresses,= URIs, etc. Just as an example from RFC 6125 would you allow a wildcard mat= ch (like "*.example.com") or only an equality match? Would "www.example.com= " be the same as "example.com" if they resolve to the same IP address(es)? >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Jan 11 07:31:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B75621F8929 for ; Fri, 11 Jan 2013 07:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.394 X-Spam-Level: X-Spam-Status: No, score=-101.394 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIN0+OPNimmS for ; Fri, 11 Jan 2013 07:31:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 86CA521F88EA for ; Fri, 11 Jan 2013 07:31:15 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MCvpV-1TlgET10oF-009gmW for ; Fri, 11 Jan 2013 16:31:14 +0100 Received: (qmail invoked by alias); 11 Jan 2013 15:31:14 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp004) with SMTP; 11 Jan 2013 16:31:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ArEQgib6A1Jud6ycmablKWNsdG4ayYXFJV6cAeJ joWFYOLk/hLll8 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 11 Jan 2013 17:31:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19E29241-6AE8-4795-BFF2-0D91F49130FA@gmx.net> References: <50EFF7F0.90300@cs.tcd.ie> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:31:17 -0000 If that's the case then I would omit the RFC 2119 language and say that = the details have to be provided by the respective documents.=20 On Jan 11, 2013, at 4:37 PM, Richer, Justin P. wrote: > It's my understanding that the general assertions claim is more of a = conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. >=20 > -- Justin >=20 >=20 > On Jan 11, 2013, at 6:30 AM, Stephen Farrell = > wrote: >=20 >>=20 >> Hi, >>=20 >> Since we thought we were done with it, I put this document >> on the IESG telechat agenda for Jan 24. Hannes' question >> however looks like its a real one that needs an answer. >>=20 >> I'd appreciate it if the WG could figure out if there's any >> change needed and either make that change in the next week, >> or else tell me to take the draft off the telechat agenda >> for now. >>=20 >> If discussion doesn't happen, or happens but doesn't reach >> a conclusion, then I'll take the draft off the agenda in a >> week's time and we can sort out if any changes are needed >> later. >>=20 >> The reason why now+1-week matters, is that that's when >> IESG members tend to do their reviews and having 'em all >> review a moving target isn't a good plan. >>=20 >> Thanks, >> S. >>=20 >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>> Hi guys,=20 >>>=20 >>> Thanks for updating the assertion document and for incorporating the = comments received on the mailing list.=20 >>>=20 >>> There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>> " >>> Audience A value that identifies the parties intended to process = the >>> assertion. An audience value MAY be the URL of the Token = Endpoint >>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>> " >>>=20 >>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there.=20 >>>=20 >>> Without having a clear description of what identifier is contained = in this field and how the comparison works it is either possible that a = legitimate client is rejected by the authorization server (which is = annoying) or an assertion with an incorrect assertion is accepted (which = is a security problem).=20 >>>=20 >>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents.=20 >>>=20 >>> Note that there are two documents that provide input to this problem = space, namely: >>> http://tools.ietf.org/html/rfc6125 >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>=20 >>> So, I would suggest to decide what type of identifier goes into this = field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Fri Jan 11 07:55:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3E721F871D for ; Fri, 11 Jan 2013 07:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO9xaE06kvCg for ; Fri, 11 Jan 2013 07:55:28 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id D650B21F85E0 for ; Fri, 11 Jan 2013 07:55:27 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so1590905vbb.30 for ; Fri, 11 Jan 2013 07:55:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UjWtxComJxb6qEd1tFJgDlKrTJg908vUYizE/ZTlZiU=; b=pTcG1uWBzXBZbb+v7u2VsATQF+AYTJesi/osZxPU9K+9u/BcC37eNK+Y5zokCKrcut pPkFaHsh6BvsZODT+GqZVQCDyxrgvijta6BvO62H4C3oZ3J1skML91968D65T3LcDyxy XW3XG+P14yeQT0TmPB1cMLJxSZcnFpcTGAGG6kDUmhn4hQQTwqmNcrI0WBNcs0Y1/0YT ej9ZsRUWyNJRuAtjmXPdvBzRS/tquHJxhrZHNcH5BpN3mlEgzNyE38GBzEEa91/CZdvp lA7wug+s2I+onhQ1BAG6H8k6hIPEKzUrQov3jz6QlueYo5gT4W7IoFcWvbwDChHgemUW fUbw== X-Received: by 10.52.22.107 with SMTP id c11mr83130308vdf.73.1357919726915; Fri, 11 Jan 2013 07:55:26 -0800 (PST) Received: from [192.168.1.211] (190-20-15-50.baf.movistar.cl. [190.20.15.50]) by mx.google.com with ESMTPS id cd19sm2291231vdb.20.2013.01.11.07.55.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 07:55:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 11 Jan 2013 12:55:15 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50EFF7F0.90300@cs.tcd.ie> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkGI+rM//ToQOG0q3/z/FOqSyEs9gcJWZmHAj7w0viS76GURS84+AaNo/5jJeB98oNudKi4 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:55:29 -0000 Yes in assertions it needs to be general. It is the JWT and SAML = profiles that need to nail down what the format of the audience is. = They should probably both be the URI of the token endpoint. In both = SAML and JWT there can be multiple audiences for the token. John On 2013-01-11, at 11:37 AM, "Richer, Justin P." = wrote: > It's my understanding that the general assertions claim is more of a = conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. >=20 > -- Justin >=20 >=20 > On Jan 11, 2013, at 6:30 AM, Stephen Farrell = > wrote: >=20 >>=20 >> Hi, >>=20 >> Since we thought we were done with it, I put this document >> on the IESG telechat agenda for Jan 24. Hannes' question >> however looks like its a real one that needs an answer. >>=20 >> I'd appreciate it if the WG could figure out if there's any >> change needed and either make that change in the next week, >> or else tell me to take the draft off the telechat agenda >> for now. >>=20 >> If discussion doesn't happen, or happens but doesn't reach >> a conclusion, then I'll take the draft off the agenda in a >> week's time and we can sort out if any changes are needed >> later. >>=20 >> The reason why now+1-week matters, is that that's when >> IESG members tend to do their reviews and having 'em all >> review a moving target isn't a good plan. >>=20 >> Thanks, >> S. >>=20 >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>> Hi guys,=20 >>>=20 >>> Thanks for updating the assertion document and for incorporating the = comments received on the mailing list.=20 >>>=20 >>> There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>> " >>> Audience A value that identifies the parties intended to process = the >>> assertion. An audience value MAY be the URL of the Token = Endpoint >>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>> " >>>=20 >>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there.=20 >>>=20 >>> Without having a clear description of what identifier is contained = in this field and how the comparison works it is either possible that a = legitimate client is rejected by the authorization server (which is = annoying) or an assertion with an incorrect assertion is accepted (which = is a security problem).=20 >>>=20 >>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents.=20 >>>=20 >>> Note that there are two documents that provide input to this problem = space, namely: >>> http://tools.ietf.org/html/rfc6125 >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>=20 >>> So, I would suggest to decide what type of identifier goes into this = field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Jan 11 08:57:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C678E21F88ED for ; Fri, 11 Jan 2013 08:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye3uNgiBgABO for ; Fri, 11 Jan 2013 08:57:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 600C421F8808 for ; Fri, 11 Jan 2013 08:57:34 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LwCv2-1StgjD20Gk-0180O0 for ; Fri, 11 Jan 2013 17:57:33 +0100 Received: (qmail invoked by alias); 11 Jan 2013 16:57:33 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp001) with SMTP; 11 Jan 2013 17:57:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1851JINQGA5RCWEQMXXxdrgziJNN+iRWeFItWFSDg gYe0U/hZbqgBrT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 11 Jan 2013 18:57:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94E6F1B5-5937-4061-BAA3-4D6049B34019@gmx.net> References: <50E609F6.3080904@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Use Cases for Signed Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:57:37 -0000 Hi Justin,=20 see below.=20 On Jan 11, 2013, at 4:34 PM, Richer, Justin P. wrote: > Hannes, thanks for the input. Inline: >=20 > On Jan 11, 2013, at 4:33 AM, Hannes Tschofenig = > wrote: >=20 >> Hi Justin, >>=20 >> thanks for the input.=20 >>=20 >> A few minor remarks inside:=20 >>=20 >> On Jan 4, 2013, at 12:45 AM, Justin Richer wrote: >>=20 >>> I'd like to present two use cases for signed tokens, for input into = the ongoing MAC/HoK/higher-security discussion. Both of these are actual = cases that I've done in the past, and we've used either OAuth 1 or JW* = to solve them. I think that with the right tooling, a MAC-token-like = thing could be used here. I'll note to the crypto nerds in the group = (ahem, John) that I'm going to be using terms like "signing" and "MAC" = in a somewhat loose sense, so please don't get hung up on that because I = think you actually know what I mean. >>>=20 >>> So: >>>=20 >>> 1) Message-level signing. >>>=20 >>> In this, you protect the content of the HTTP message by signing it = with the secret part of the token, effectively what was done in OpenID = 2, OAuth1, and the MAC draft. You pick some subset of the HTTP = components, add them to your signing base in a predictable and = repeatable fashion, and sign it with your secret. You then send the = signature along with all of the bare HTTP elements across the wire, and = the far side does the same signature generation magic and you're good to = go. >>>=20 >>> The driving use case to this is security in depth. Yes, you probably = still do want everything to go over TLS, but that only protects things = in transit between endpoints. It won't protect anything as it gets = chewed through an application platform or handed around a server farm. = It's also considered "best practice" in many cases. In my experience in = the health care space, you almost always want to have multiple layers = protecting you. >>>=20 >>> An alternative approach here is to use a JW* container like a JWS or = JWE to hold all of your parameters (as claims) and sign/encrypt over = that. But if you do that, you're not really using HTTP anymore, except = as a dumb transport. This is the approach of SOAP, and I doubt that many = will come to its defense. (At least, those that don't want to sell you = something to process SOAP messages.) We've done this ourselves with a = prototype, and losing all of the processing capability that comes with = HTTP is a huge programmatic hit. >>=20 >> I understand the value of the message level protection vs. the usage = of TLS. >=20 > Just a note that it's not necessarily "vs." in the use case, it's "in = addition to". Multiple layers of security are considered best practice = in many cases, not the least of which is healthcare. Even if you have = something set up with mutual TLS, you're supposed to protect each = message separately as well.=20 I guess we agree on that aspect.=20 >=20 >> If you go to the extreme then you could argue that HTTP is terminated = in the HTTP stack and not at the application... This line of = argumentation wouldn't be too crazy given that some of the HTTP = parameters are not accessible through certain application development = platforms, for example.=20 >>=20 >> If you abstract a bit then the two approaches are not so different. = Here is the story: >>=20 >> * With an HTTP-based solution you do >> - put additional parameters into the header to convey the algorithm = related information, the access token, and the keyed message digest >> - the keyed message digested is computed over some HTTP headers and = it would be possible to repeat the value that is used as input to the = keyed message digest computation in another parameter. >>=20 >> * With a JSON-based solution you do >> - put the access token and the encoded JSON structure into a header = (or alternatively into the body) >> - the signature or keyed message digest is computed over the JSON = structure which includes information that relates to the HTTP request. = Again, whether you repeat the values in the JSON itself or only a hash = of them has not yet been decided. During the OAuth 1.0 days some folks = argued that the values should be repeated so that one can easily detect = problems.=20 >>=20 >> Do you see the similarity (expect for the encoding of the = parameters)? >=20 > I do see the similarity, but the encoding of the parameters is exactly = the difference that I think is important to the argument I'm making = above. I could also encode all of my parameters as an ASN.1 document, or = XML, or whatever, and I'd be in roughly the same boat. Good that you see the similarity. I understand that you have a = preference regarding the encoding.=20 >=20 >>=20 >>>=20 >>> 2) Signed URL as an authorized artifact. >>>=20 >>> In this, you have party A generate a URL with parameters in it, = protected by a signature. That URL points to party B, who can validate = the signature. Party A then hands that fully baked URL to a third party, = C, who can't do anything to the parameters in the URL without messing up = the signature. =46rom party B's perspective, so long as that signature = is valid, all the parameters in the URL can be trusted and the request = can proceed. With a timestamp and nonce parameter (built in to OAuth1), = you've even got really nice replay and timeout protection. TLS doesn't = do you any good here, because there's a party in the middle who has the = full right to hold and view the artifact (URL), but does not have the = right to modify it. We've solved this in the past using OAuth1's = signature mechanism without tokens (aka, 2-legged OAuth1). We can't = currently do this with OAuth2. If we had a generalizable HTTP components = signing mechanism (which MAC *almost* is, and could become), then we = could. >>>=20 >>> Again, you could simply cram everything into a JW* container and = send *that* as the sole parameter to a URL and get almost the same = result. But then you've got to unpack that JW* container to get all of = your parameters, and you're back in SOAP land. And again I posit: nerds = hate SOAP. >>=20 >> Let me see whether I get that idea right. In this case you put the = OAuth related parameter, access token, and keyed message digest into the = URL instead of putting it into the HTTP header (as a parameter). Is this = the main difference? If so, why do you care whether the values are = carried in the header vs. in the URL?=20 >=20 > Yes that's correct - In this use case, everything goes in the URL. If = everything goes in the URL, then you've got a single artifact that you = can pass around to different systems. > You can't do that with HTTP headers, which makes it an untenable = approach for this. Regarding "passing it around to different systems". Based on the = security you can only use this URL once between the client and the = resource server (for a single request). >=20 >>=20 >> A slightly separate question: Out of curiosity, what specifically do = you dislike about SOAP (even though it has little relationship to what = we do here)? Is it the verbose nature due to the usage of XML? Is it the = header that contains values that you may not need? Is it WSDL that most = people use with SOAP? >=20 > I think you're getting hung up on the specifics of the SOAP protocol = set (XML, WSDL) and missing my main point: SOAP doesn't make use of HTTP = in the best way it can.=20 > - ignores all aspects of HTTP like action verbs, headers, and query = parameters in favor of putting everything in a specialty-encoded = document > - can't be used without complex tooling (smoke test: can I script this = API with wget?) > - complex tools from different vendors don't tend to be very = interoperable with each other without significant engineering of the = application You started referring to SOAP and I was therefore wondering what exactly = the relationship to this discussion is.=20 In our case where in the discussion between MAC and a JSON-based = encoding we=20 - have no difference regarding HTTP aspects - the encoding always has to be defined (regardless of whether it is = JSON-based or a custom defined encoding as with MAC) - always requires some "complex tooling" since you cannot expect a = human to calculate a keyed message digest (at least I cannot) or a = digital signature - the interoperability comes from the specification: if everything is = correctly specified than two software packages from independent vendors = are able to compute the same keyed message digest (or digital signature) = when given the same input. =20 >=20 >>=20 >>> Hopefully both of these will help inform the discussion and shed = some light onto why I think that: >>> * MAC tokens (or equivalent) are still a good idea for the WG to = pursue >>> * Channel-binding and TLS don't solve all security problems >>=20 >> TLS and channel bindings can provide additional security features for = an application layer solution.=20 >> The channel binding ensures that the TLS exchange is not terminated = at an intermediary.=20 >>=20 >> So, it might be useful to also see them as additional layer of = defense rather than as a competitor. =20 >=20 > Again it's not a "one or the other" thing here. I was simply trying to = make the point that TLS channel binding, while useful at solving its own = set of issues, is not a panacea. I don't think anyone said that TLS, and channel binding solve all = security problems. They solve the problems they are designed for.=20 > Neither of these two use cases, for example, can be addressed by it at = all. I never said claimed they do.=20 > If you do have TLS *on top of* these other approaches, yes, that can = make it even better. Agree.=20 > And it's exactly that independent modularity that makes this stuff = worthwhile, in my opinion. Ack.=20 >=20 >>=20 >>> * Abusing JOSE leads to breaking good HTTP designs >>=20 >> I understand the philosophical argument but not necessarily the = "breaks good HTTP design". You can still use HTTP in the way you want. = How are you constrained when you use a JSON encoding as compared to a = custom encoding?=20 >>=20 >=20 > If you cram all of your verbs and parameters into a JOSE-encoded body, = you're not using HTTP in what is today considered best practice. This = philosophy, again, was a main failing of SOAP and what made it = ultimately fail in the market. You don't need to copy the HTTP parameters that serve as input to the = keyed message digest into the JSON payload, if you don't want.=20 There are various design choices. For example, with both approaches you = could, for example, list the header fields in the order they are put = into the signature string. This design is, for example, chosen by DKIM = (see http://tools.ietf.org/html/rfc4871#appendix-A.2).=20 In case you don't to include the signature string explicitly in the = message then the difference between the two approaches is:=20 (Note that I did not include the access token in the examples below.) MAC: Authorization: MAC id=3D"h480djs93hd8", ts=3D"1336363200", nonce=3D"dj83hs9s", mac=3D"bhCQXTVyfj5cmA9uKkPFx1zeOXM=3D" JSON: Authorization: MAC2 = value=3D"asdflkjasdf;lkadsdfkjskjsdfkjdsfjsfkadsfj.dBjftJeZ4CVP-mB92K27." (this value is supposed to indicate a header followed by a keyed message = digest. The header, for example, could be something like:=20 {"typ":"HOTK-SK", "alg":"HS256", "kid":"client12345@example.com", "timestamp":"2012-07-15T10:20:00.000-05:00" } =20 Ciao Hannes >=20 > -- Justin >=20 >> Ciao >> Hannes >>=20 >>>=20 >>> -- Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From jricher@mitre.org Fri Jan 11 09:10:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8A921F843C for ; Fri, 11 Jan 2013 09:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RngIzdK-FS1a for ; Fri, 11 Jan 2013 09:10:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BFCAE21F8825 for ; Fri, 11 Jan 2013 09:10:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69A3D1F368B; Fri, 11 Jan 2013 12:10:40 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2C3321F3684; Fri, 11 Jan 2013 12:10:40 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 12:10:39 -0500 From: "Richer, Justin P." To: "Boone, Keith W (GE Healthcare)" Thread-Topic: Mail regarding draft-ietf-oauth-dyn-reg Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMAAApcswAAHo/cgA== Date: Fri, 11 Jan 2013 17:10:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.162] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0687684EIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:10:45 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0687684EIMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the thorough writeup, this is definitely an interesting use case= . There are a few ways that you could go about this, from what I'm seeing, = but there are also some things to untangle first. My apologies for the wall= of text. First, public clients can keep secrets, but there's a difference in the kin= d of secret they can keep. A client_secret in the traditional pre-registere= d out-of-band OAuth case is what's considered a configuration-time secret. = This means that it effectively has to be configured with the software when = it's deployed. This includes downloading the app to a smarphone or loading = the Javascript app into the browser. The reason they can't keep these kinds= of secrets is that all copies of the app would have the same secret and it= would potentially be exposed to any end user. This is a bad thing since an= y end user could now fully impersonate the app with their own code. However= , there is another class of secret: runtime. A runtime secret is something = that the client gains after it has been configured and deployed, like the O= Auth access token or any kind of client information (including an id and se= cret) gained from dynamic registration. This still doesn't change the fact = that dynamic registration still can make sense with public clients (with no= secret), but the very nature of the operation does change the nature of th= e secrets in question. In your final example, if you're using a per-instance dynamic client regist= ration, why wouldn't you want the iPad and iPhone app to re-register itself= ? That seems to be the whole point, since they'd necessarily be getting dif= ferent client secrets. What do you see as the downside to this, especially = when it can be automated? There are some approaches that you can take to gr= oup together sets of dynamically registered clients, too. More on how this = might work in practice, below. Regarding DoS, this is something that the DynReg spec starts to touch on in= its security considerations section. You're basically going to want to do = some kind of throttling and monitoring on an open endpoint like that, espec= ially if it's internet-facing. Now, on to what I see as some possible approaches for what you want to do: 1) Use well-known client_ids for public clients. In this case, you don't use dynamic registration at all and just say that a= ll clients are public clients, and tell every Authorization Server where to= get the list of well-known client ids. You would want to take steps to pro= tect the redirect_uri's for each of these client_ids to make them less susc= eptible to hijacking, since calls to the token endpoint would no longer hav= e a client_secret to protect them. Side note: On the RHEx project (which you mention in your blog post), it's = true that we didn't profile public clients or dynamically registered client= s, but the idea here was that if you were going to do that, you would want = a different profile that called out the unique security issues that come wi= th these kinds of things. 2) Use a centralized server to register all clients. Nothing in OAuth says that each server has to have a local copy of the clie= nt credentials, especially if you're using a Client Assertion to authentica= te to the Token Endpoint. You could pretty easily accomplish this by having= a central location (or forest of them) that app developers can sign up at,= where they're given a "developer key" to embed into their applications. Th= is doesn't work very well with mobile and in-browser apps, because the deve= loper key can leak, making it ultimately unsuitable for distributed-code cl= ients like that. However, it could work just fine for any clients where the= configuration-time secrets can be kept, like web servers. And even in the distributed apps case, you do still have to have a resource= owner click "Approve" for the client to get anywhere. Your Authorization S= ervers can put in appropriate warning boxes and 3) Preregister each client as a "class", use DynReg to register the "instan= ce" of each class. This is an interesting hybrid approach that the DynReg spec (and OpenID Con= nect) are built to handle explicitly. In this, developers get a "developer = key" as in (2), but each instance of the application uses that developer ke= y (which is really just an OAuth2 access token) to call the Registration En= dpoint. This way, the Authorization Server can effectively group together m= ultiple instances of the same client, logically. It could even decide to do= something special and give them related client_ids, in order to help keep = the books straight, but each client would be able to get its very own clien= t_secret. The Authorization Server can also impose restrictions on things l= ike allowed scopes and redirect_uris for each class of client, so that you = don't have things going completely rogue on you. With this, you could take an approach like in (2) and use a centralized ser= ver (or forest) for minting these developer keys, say as a signed JWT. The = developer keys would be distributed with the applications themselves, so so= me will leak, but that's not so bad. The clients still have to register the= mselves, so you can't have your iPad impersonating your iPhone, or anybody = else's iPad for that matter. They're all ultimately unique and it's easy fo= r the AS to tell them apart (and group them together). This approach is what I am currently thinking might be the best approach fo= r your use case. Or at the very least, one to strongly consider in your app= roach. 4) UMA In an ideal world, I think this would evolve into a User Managed Access, or= UMA, type of system. I know there have been a few attempts at building out= a healthcare-centric UMA, but nothing at that scale from what I've seen. I= n UMA (which uses OAuth, DynReg, Token Introspection, OpenID Connect, and o= ther components), the different parties in OAuth are given a means of being= introduced to each other with the right humans in the loop at the right ti= me. We built the initial RHEx prototype in such a way that we could incorpo= rate UMA in future work. I even have a really big, scary diagram to that ef= fect someplace, I'll have to see if I can dig it up. While UMA is a bit mor= e complicated of a platform (tons of moving parts), it's also very flexible= and very powerful, and I'd encourage you to start looking in that directio= n, or at least get some discussion going around it. tl;dr: You've got a few viable choices depending on the kind of ecosystem y= ou want to have, but I'd recommend using a client-class approach or UMA. Hope this was helpful, and I'd be interested to hear what the rest of the W= G might think about this. -- Justin On Jan 10, 2013, at 4:54 PM, "Boone, Keith W (GE Healthcare)" > wrote: The challenge is that we project an environment where there could be thousa= nds of applications conforming to a particular API (see http://wiki.siframe= work.org/ABBI+Pull+Workgroup), with thousands of data holders making data a= vailable through those APIs, and several authorizers (in the OAuth 2.0 sens= e). For public (locally installed or web-browser based applications), we'd= like to avoid what I call the million registration problem (i= gnore the technical details), which would require thousands of developers t= o manually register their applications with all of the authorizers. Because this is healthcare data, it is entirely possible that data holders = will INSIST on being authorizers, which makes the problem even more challen= ging. The issue that the ABBI Pull workgroup has been asked to address is to ensu= re that there is some way to manage bad actors in this eco-system, e.g., th= rough a black-list, white-list or other trust-mechanism. This wouldn't nec= essarily be required to be used, but would help an authorizer make an appli= cation access control decision. The challenge with a public application using dynamic registration is that a) The application cannot keep it's credentials secret, and so must ret= rieve them in some way securely b) If the client_id is not tied back to the application identity, then w= e have concerns about the trust mechanism being able to protect the environ= ment, c) And yet, we also want to protect clients from denial of service atta= cks where a client could be impersonated (to an authorizer), and obtain a c= lient_id. Imagine the case where I purchase an application and download it to my iPho= ne and to my iPad. Then I connect that application to a data holder/author= izer combination it hasn't seen before. Through dynamic client registratio= n, I could register that application for my iPhone, but the instance of tha= t same application running on my iPad would know nothing about the first re= gistration. So it would attempt to do it all over again. What happens her= e? Keith _________________________________ Keith W. Boone Standards Architect GE Healthcare M +1 617 640 7007 keith.boone@ge.com www.gehealthcare.com 116 Huntington Ave Boston, MA 02116 USA GE imagination at work From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Thursday, January 10, 2013 4:39 PM To: Boone, Keith W (GE Healthcare) Cc: oauth@ietf.org WG Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg Interesting use case, and not dissimilar to some others I've heard. How wou= ld you go about tracking this? Why would the instances need to know about e= ach other? One possible approach would be to use a common initializing Request Access = Token that is used to call client_register on all instances of a given clie= nt. They wouldn't know about each other, per se, but the Authorization Serv= er would at least know enough to be able to tie them together. There's also the OAuth2 Instance Information extension that I had tried to = push a few years ago that comes up every now and again, that might be of us= e here with some modifications: http://tools.ietf.org/html/draft-richer-oauth-instance-00 I think I'd like to know more about your concerns and the parameters of you= r use case first. I am CC'ing the IETF OAuth Working Group email list, where this draft is be= ing discussed and worked on. -- Justin On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" > wrote: I would like to be able to use this protocol to dynamically register client= s, but am challenged by the fact that there could be multiple instances of = a public client, each unaware of what others have done. The current protoc= ol doesn't seem to address this. Keith _________________________________ Keith W. Boone Standards Architect GE Healthcare M +1 617 640 7007 keith.boone@ge.com www.gehealthcare.com 116 Huntington Ave Boston, MA 02116 USA GE imagination at work --_000_B33BFB58CCC8BE4998958016839DE27E0687684EIMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: <66339ED4F1E179408270B221433B7431@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Thanks for the thorough writeup, this is definitely an interesting use case= . There are a few ways that you could go about this, from what I'm seeing, = but there are also some things to untangle first. My apologies for the wall= of text.

First, public clients can keep secrets, but there's a difference in th= e kind of secret they can keep. A client_secret in the traditional pre-regi= stered out-of-band OAuth case is what's considered a configuration-time sec= ret. This means that it effectively has to be configured with the software when it's deployed. This includes d= ownloading the app to a smarphone or loading the Javascript app into the br= owser. The reason they can't keep these kinds of secrets is that all copies= of the app would have the same secret and it would potentially be exposed to any end user. This is a bad = thing since any end user could now fully impersonate the app with their own= code. However, there is another class of secret: runtime. A runtime secret= is something that the client gains after it has been configured and deployed, like the OAuth access token or = any kind of client information (including an id and secret) gained from dyn= amic registration. This still doesn't change the fact that dynamic registra= tion still can make sense with public clients (with no secret), but the very nature of the operation does change= the nature of the secrets in question.

In your final example, if you're using a per-instance dynamic client r= egistration, why wouldn't you want the iPad and iPhone app to re-register i= tself? That seems to be the whole point, since they'd necessarily be gettin= g different client secrets. What do you see as the downside to this, especially when it can be automated? T= here are some approaches that you can take to group together sets of dynami= cally registered clients, too. More on how this might work in practice, bel= ow.

Regarding DoS, this is something that the DynReg spec starts to touch = on in its security considerations section. You're basically going to want t= o do some kind of throttling and monitoring on an open endpoint like that, = especially if it's internet-facing.



Now, on to what I see as some possible approaches for what you want to= do:

1) Use well-known client_ids for public clients.

In this case, you don't use dynamic registration at all and just say t= hat all clients are public clients, and tell every Authorization Server whe= re to get the list of well-known client ids. You would want to take steps t= o protect the redirect_uri's for each of these client_ids to make them less susceptible to hijacking, since= calls to the token endpoint would no longer have a client_secret to protec= t them. 

Side note: On the RHEx project (which you mention in your blog post), = it's true that we didn't profile public clients or dynamically registered c= lients, but the idea here was that if you were going to do that, you would = want a different profile that called out the unique security issues that come with these kinds of things.

2) Use a centralized server to register all clients.

Nothing in OAuth says that each server has to have a local copy of the= client credentials, especially if you're using a Client Assertion to authe= nticate to the Token Endpoint. You could pretty easily accomplish this by h= aving a central location (or forest of them) that app developers can sign up at, where they're given a "d= eveloper key" to embed into their applications. This doesn't work very= well with mobile and in-browser apps, because the developer key can leak, = making it ultimately unsuitable for distributed-code clients like that. However, it could work just fine for any clients where = the configuration-time secrets can be kept, like web servers. 

And even in the distributed apps case, you do still have to have a res= ource owner click "Approve" for the client to get anywhere. Your = Authorization Servers can put in appropriate warning boxes and 

3) Preregister each client as a "class", use DynReg to regis= ter the "instance" of each class.

This is an interesting hybrid approach that the DynReg spec (and OpenI= D Connect) are built to handle explicitly. In this, developers get a "= developer key" as in (2), but each instance of the application uses th= at developer key (which is really just an OAuth2 access token) to call the Registration Endpoint. This way, the Auth= orization Server can effectively group together multiple instances of the s= ame client, logically. It could even decide to do something special and giv= e them related client_ids, in order to help keep the books straight, but each client would be able to get its = very own client_secret. The Authorization Server can also impose restrictio= ns on things like allowed scopes and redirect_uris for each class of client= , so that you don't have things going completely rogue on you.

With this, you could take an approach like in (2) and use a centralize= d server (or forest) for minting these developer keys, say as a signed JWT.= The developer keys would be distributed with the applications themselves, = so some will leak, but that's not so bad. The clients still have to register themselves, so you can't have y= our iPad impersonating your iPhone, or anybody else's iPad for that matter.= They're all ultimately unique and it's easy for the AS to tell them apart = (and group them together).

This approach is what I am currently thinking might be the best approa= ch for your use case. Or at the very least, one to strongly consider in you= r approach.

4) UMA

In an ideal world, I think this would evolve into a User Managed Acces= s, or UMA, type of system. I know there have been a few attempts at buildin= g out a healthcare-centric UMA, but nothing at that scale from what I've se= en. In UMA (which uses OAuth, DynReg, Token Introspection, OpenID Connect, and other components), the different = parties in OAuth are given a means of being introduced to each other with t= he right humans in the loop at the right time. We built the initial RHEx pr= ototype in such a way that we could incorporate UMA in future work. I even have a really big, scary diagram to= that effect someplace, I'll have to see if I can dig it up. While UMA is a= bit more complicated of a platform (tons of moving parts), it's also very = flexible and very powerful, and I'd encourage you to start looking in that direction, or at least get some= discussion going around it.



tl;dr: You've got a few viable choices depending on the kind of ecosys= tem you want to have, but I'd recommend using a client-class approach or UM= A.

Hope this was helpful, and I'd be interested to hear what the rest of = the WG might think about this.

 -- Justin

On Jan 10, 2013, at 4:54 PM, "Boone, Keith W (GE Healthcare)"= ; <keith.boone@ge.com>
 wrote:

The challenge is that we project an environment where there= could be thousands of applications conforming to a particular API (see http://wiki.siframework.org/ABBI+Pull+Workgroup<= /a>), with thousands of data holders making data available through those APIs, a= nd several authorizers (in the OAuth 2.0 sense).  For public (locally = installed or web-browser based applications), we'd like to avoid what I cal= l the million registration problem (ignore the technical details), which would require thousands of developer= s to manually register their applications with all of the authorizers. = ;
 
Because this is healthcare data, it is entirely possible th= at data holders will INSIST on being authorizers, which makes the problem e= ven more challenging.
 
The issue that the ABBI Pull workgroup has been asked to ad= dress is to ensure that there is some way to manage bad actors in this eco-= system, e.g., through a black-list, white-list or other trust-mechanism.  This wouldn't necessarily be re= quired to be used, but would help an authorizer make an application access = control decision.
 
The challenge with a public application using dynamic regis= tration is that
a)     The application cannot keep it's credentials secret, and so must retrieve them= in some way securely
b)    If the client_id is not tied back to the application identity, then we have c= oncerns about the trust mechanism being able to protect the environment,
c)     And yet, we also want to protect clients from denial of service attacks where = a client could be impersonated (to an authorizer), and obtain a client_id.<= o:p>
 
Imagine the case where I purchase an application and downlo= ad it to my iPhone and to my iPad.  Then I connect that application to= a data holder/authorizer combination it hasn't seen before.  Through dynamic client registration, I could reg= ister that application for my iPhone, but the instance of that same applica= tion running on my iPad would know nothing about the first registration.&nb= sp; So it would attempt to do it all over again.  What happens here?
 
          = ;  Keith
_________________________________
Keith W. Boone=
Standards Architect
GE Healthcare

M +1 617 640 7007
keith.boone@ge.c= om
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work
 
From:=  Richer, Justin P. [ma= ilto:jricher@mitre.org] 
Sent: Thursday, Ja= nuary 10, 2013 4:39 PM
To: Boone, Keith W= (GE Healthcare)
Cc: oauth@ietf.org WG
Subject: Re: Mail = regarding draft-ietf-oauth-dyn-reg
 
Interesting use case, and not dissimilar to some others I've heard. How wou= ld you go about tracking this? Why would the instances need to know about e= ach other?
 
One possible approach would be to use a common initializing Request Access = Token that is used to call client_register on all instances of a given clie= nt. They wouldn't know about each other, per se, but the Authorization Serv= er would at least know enough to be able to tie them together.
 
There's also the OAuth2 Instance Information extension that I had tried to = push a few years ago that comes up every now and again, that might be of us= e here with some modifications:
 
 
I think I'd like to know more about your concerns and the parameters of you= r use case first. 
 
I am CC'ing the IETF OAuth Working Group email list, where this draft is be= ing discussed and worked on.
 
 -- Justin
 
On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" <= ;keith.boone@ge.com> wrote:


I would l= ike to be able to use this protocol to dynamically register clients, but am= challenged by the fact that there could be multiple instances of a public = client, each unaware of what others have done.  The current protocol doesn't seem to address this.=

            Keith
___= ______________________________
Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007
keith.boone@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA GE imagination at work
 <= o:p>


--_000_B33BFB58CCC8BE4998958016839DE27E0687684EIMCMBX01MITREOR_-- From gffletch@aol.com Fri Jan 11 09:38:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A621F87C3 for ; Fri, 11 Jan 2013 09:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtiDsjGzVRL3 for ; Fri, 11 Jan 2013 09:38:06 -0800 (PST) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 67B2521F87B2 for ; Fri, 11 Jan 2013 09:38:02 -0800 (PST) Received: from mtaout-ma03.r1000.mx.aol.com (mtaout-ma03.r1000.mx.aol.com [172.29.41.3]) by imr-ma05.mx.aol.com (Outbound Mail Relay) with ESMTP id B1CAB1C00011D; Fri, 11 Jan 2013 12:38:01 -0500 (EST) Received: from palantir.local (unknown [10.172.6.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 557E7E0000C4; Fri, 11 Jan 2013 12:38:01 -0500 (EST) Message-ID: <50F04DF8.1070407@aol.com> Date: Fri, 11 Jan 2013 12:38:00 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> In-Reply-To: <50EDC0AE.6050005@mitre.org> Content-Type: multipart/alternative; boundary="------------080503070503080602090108" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357925881; bh=BHPU8KMOblDKFAZYTDOiDEpf9K2BsiqT7ull2JffBSs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ANaqcLljtACtPFLZuRKtnR7RIizhK9RzJSkqXGU2ueAZrLfvB03iV9hn1qtjZ4T3/ d6vYSdqkdHpX7Idv1s9wg+73vaJ0uAWeXhkqy8Io5gxXBGotCjM+KYxnohpRb1Dxk8 mB1wOXiHGw5PIeKGMmy2jwuiEWwHbqoMm1SaJUno= X-AOL-SCOLL-SCORE: 1:2:331456128:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d290350f04df94c7d X-AOL-IP: 10.172.6.217 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:38:07 -0000 This is a multi-part message in MIME format. --------------080503070503080602090108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Additional feedback on the introspection endpoint. What is the expected error response if the introspection endpoint is using client credentials as recommended in section 2.1 The endpoint SHOULD also require some form of authentication to access this endpoint, such as the Client Authentication as described in OAuth 2 Core Specification [RFC6749 ] or a separate OAuth2 Access Token. and the client credentials are invalid. It doesn't seem correct to return an HTTP 200 with a body of { "valid: false } as the endpoint probably never even tried to validate the token parameter. I can see a couple of options... 1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with the error described in JSON in the body of the response. 2. Follow RFC 6750 and return a WWW-Authenticate Response header that contains the error and optionally error_description. Thanks, George --------------080503070503080602090108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Additional feedback on the introspection endpoint.

What is the expected error response if the introspection endpoint is using client credentials as recommended in section 2.1
The endpoint SHOULD also require some form of authentication to
   access this endpoint, such as the Client Authentication as described
   in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access
   Token.
and the client credentials are invalid. It doesn't seem correct to return an HTTP 200 with a body of { "valid: false } as the endpoint probably never even tried to validate the token parameter.

I can see a couple of options...

1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with the error described in JSON in the body of the response.

2. Follow RFC 6750 and return a WWW-Authenticate Response header that contains the error and optionally error_description.

Thanks,
George

--------------080503070503080602090108-- From bcampbell@pingidentity.com Fri Jan 11 09:51:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29CA21F8994 for ; Fri, 11 Jan 2013 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3VP3ULWSv2d for ; Fri, 11 Jan 2013 09:51:46 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3748521F894C for ; Fri, 11 Jan 2013 09:51:42 -0800 (PST) Received: from mail-ob0-f198.google.com ([209.85.214.198]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUPBRLEBp37Fe7E/sDZhFNPkO1PNGIVuN@postini.com; Fri, 11 Jan 2013 09:51:42 PST Received: by mail-ob0-f198.google.com with SMTP id un3so9376301obb.1 for ; Fri, 11 Jan 2013 09:51:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=tcjr/tVpIH/9fc2AS5CgtTrFHibLEYffWdtZTTnWBfc=; b=nXjPEQRT3PAL+9+bb8m2/9oyTSUtIPNgL9Kr4Sx5wvUHJfrqEhOlnAmqR/Bw2dgzoU zvyzmTZKf8w42LtIrWegFl+ByEZTJ4vLBPFEmeioqSEj+FkkfqZ5PLBoJnPQQkJH2Tzh /Yx2nZG8zhtM9XvRhaVEX2wZvj/5Bl7vKNDvlb1utas7USij69mdv3yMP85u6ScvA5e3 jrBPxCtKjn4Vs0K38K4ZeW403tfe2P+xw06Vr+0wP8P432SwfLf7pb6tN4/si7Z2ogw0 aIQau7LIhx0zHGZZLxKZezZ9/NmNSXx2v17EKNRyxVLmU6iTawcL9TJ1sJjYFfOuF7tA 0gfg== X-Received: by 10.50.214.39 with SMTP id nx7mr2494620igc.101.1357926699737; Fri, 11 Jan 2013 09:51:39 -0800 (PST) X-Received: by 10.50.214.39 with SMTP id nx7mr2494614igc.101.1357926699581; Fri, 11 Jan 2013 09:51:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.17.134 with HTTP; Fri, 11 Jan 2013 09:51:09 -0800 (PST) In-Reply-To: References: <50EFF7F0.90300@cs.tcd.ie> From: Brian Campbell Date: Fri, 11 Jan 2013 10:51:09 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=14dae93406e38f42a304d306f21d X-Gm-Message-State: ALoCoQnBGod7CaFUt94GfIdPRPy1VpU8P8ZoeTahc+wQGCZPYgQxQk5p2aN8eTCLAG4ahW+a4htxKM38FA45ymiuDckUzUeZ+xmVWLp84JKSmhD/V/hDM9F+O8E4vEuW2ukhddOyPX2U Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:51:55 -0000 --14dae93406e38f42a304d306f21d Content-Type: text/plain; charset=ISO-8859-1 That text around audience in the framework spec changed from a SHOULD to a MAY in -09 so that it would be more consistent with the the SAML and JWT versions, which were already using a MAY in that context. Your concern is valid Hannes and your point is taken. But reality is rather messy and I don't believe it can addressed as easily as you suggest. In SAML, for example, an entity identifier is often used as a value for the audience (per spec and in practice). But an AS may not necessarily identify itself with a full blown SAML entity, in which case the token endpoint URI is more appropriate. The whole issue is also somewhat complicated in SAML too by it having both audience and recipient that are similar but not the same. I've tried to account for all of this in the SAML doc but it's admittedly somewhat awkward and complex and not as simple as saying the value has to be X and must be validated in exactly such a way. JWT doesn't have the same history and baggage of SAML but is subject to many of the same real world deployment variations. I'm definitely open to improvements with respect to the handling of audience values but I believe anything that is done needs to reflect the realities of current implementations and deployments as well as related specifications., On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrote: > Yes in assertions it needs to be general. It is the JWT and SAML profiles > that need to nail down what the format of the audience is. They should > probably both be the URI of the token endpoint. In both SAML and JWT > there can be multiple audiences for the token. > > John > On 2013-01-11, at 11:37 AM, "Richer, Justin P." wrote: > > > It's my understanding that the general assertions claim is more of a > conceptual mapping than it is a concrete encoding, so anything more > specific here would be out of place. I would like the authors to either > confirm or correct my assumptions, though. > > > > -- Justin > > > > > > On Jan 11, 2013, at 6:30 AM, Stephen Farrell > > wrote: > > > >> > >> Hi, > >> > >> Since we thought we were done with it, I put this document > >> on the IESG telechat agenda for Jan 24. Hannes' question > >> however looks like its a real one that needs an answer. > >> > >> I'd appreciate it if the WG could figure out if there's any > >> change needed and either make that change in the next week, > >> or else tell me to take the draft off the telechat agenda > >> for now. > >> > >> If discussion doesn't happen, or happens but doesn't reach > >> a conclusion, then I'll take the draft off the agenda in a > >> week's time and we can sort out if any changes are needed > >> later. > >> > >> The reason why now+1-week matters, is that that's when > >> IESG members tend to do their reviews and having 'em all > >> review a moving target isn't a good plan. > >> > >> Thanks, > >> S. > >> > >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: > >>> Hi guys, > >>> > >>> Thanks for updating the assertion document and for incorporating the > comments received on the mailing list. > >>> > >>> There is only one issue that caught my attention. You changed the > description of the audience element to the following text (in version -09 > of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): > >>> " > >>> Audience A value that identifies the parties intended to process the > >>> assertion. An audience value MAY be the URL of the Token Endpoint > >>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. > >>> " > >>> > >>> Since the value in the audience field is used to by the authorization > server in a comparison operation (see Section 5.2) I believe the current > text will lead to interoperability problems. Not only is the comparision > operation unspecified but even the value that is contained in the field is > left open. The RFC 2119 MAY does not really give a lot of hints of what > should be put in there. > >>> > >>> Without having a clear description of what identifier is contained in > this field and how the comparison works it is either possible that a > legitimate client is rejected by the authorization server (which is > annoying) or an assertion with an incorrect assertion is accepted (which is > a security problem). > >>> > >>> Btw, the same issue can also be seen in > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, > http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more > generic form also in the JWT (Section 4.1.3 of > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" > claim). From the description in the JWT document I was not quite sure > whether the ability to carry an array of case sensitive strings for that > field is also allowed in any of the assertion documents. > >>> > >>> Note that there are two documents that provide input to this problem > space, namely: > >>> http://tools.ietf.org/html/rfc6125 > >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 > >>> > >>> So, I would suggest to decide what type of identifier goes into this > field and then to point to a document that illustrates how the comparison > operation would look like. Possible identifiers are domain names, IP > addresses, URIs, etc. Just as an example from RFC 6125 would you allow a > wildcard match (like "*.example.com") or only an equality match? Would " > www.example.com" be the same as "example.com" if they resolve to the same > IP address(es)? > >>> > >>> Ciao > >>> Hannes > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --14dae93406e38f42a304d306f21d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That text around audience in the framework = spec changed from a SHOULD to a MAY in -09 so that it would be more consist= ent with the the SAML and JWT versions, which were already using a MAY in t= hat context.

Your concern is valid Hannes and your point is taken. But reality= is rather messy and I don't believe it can addressed as easily as you = suggest.=A0

In SAML, for example, an entity identifier is oft= en used as a value for the audience (per spec and in practice).=A0 But an A= S may not necessarily identify itself with a full blown SAML entity, in whi= ch case the token endpoint URI is more appropriate. The whole issue is also= somewhat complicated in SAML too by it having both audience and recipient = that are similar but not the same. I've tried to account for all of thi= s in the SAML doc but it's admittedly somewhat awkward and complex and = not as simple as saying the value has to be X and must be validated in exac= tly such a way.

JWT doesn't have the same history and baggage of SAML but is = subject to many of the same real world deployment variations.

<= div>
I'm definitely open to improvements with respect to the handli= ng of audience values but I believe anything that is done needs to reflect = the realities of current implementations and deployments as well as related= specifications.,



<= div class=3D"gmail_quote">On Fri, Jan 11, 2013 at 8:55 AM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
Yes in assertions it needs to be general. = =A0It is the JWT and SAML profiles that need to nail down what the format o= f the audience is. =A0 =A0They should probably both be the URI of the token= endpoint. =A0 In both SAML and JWT there can be multiple audiences for the= token.

John
On 2013-01-11, at 11:= 37 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> It's my understanding that the general assertions claim is more of= a conceptual mapping than it is a concrete encoding, so anything more spec= ific here would be out of place. I would like the authors to either confirm= or correct my assumptions, though.
>
> -- Justin
>
>
> On Jan 11, 2013, at 6:30 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hi,
>>
>> Since we thought we were done with it, I put this document
>> on the IESG telechat agenda for Jan 24. Hannes' question
>> however looks like its a real one that needs an answer.
>>
>> I'd appreciate it if the WG could figure out if there's an= y
>> change needed and either make that change in the next week,
>> or else tell me to take the draft off the telechat agenda
>> for now.
>>
>> If discussion doesn't happen, or happens but doesn't reach=
>> a conclusion, then I'll take the draft off the agenda in a
>> week's time and we can sort out if any changes are needed
>> later.
>>
>> The reason why now+1-week matters, is that that's when
>> IESG members tend to do their reviews and having 'em all
>> review a moving target isn't a good plan.
>>
>> Thanks,
>> S.
>>
>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote:
>>> Hi guys,
>>>
>>> Thanks for updating the assertion document and for incorporati= ng the comments received on the mailing list.
>>>
>>> There is only one issue that caught my attention. You changed = the description of the audience element to the following text (in version -= 09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-0= 9):
>>> "
>>> =A0Audience =A0A value that identifies the parties intended to= process the
>>> =A0 =A0 assertion. =A0An audience value MAY be the URL of the = Token Endpoint
>>> =A0 =A0 as defined in Section 3.2 of OAuth 2.0 [RFC6749].
>>> "
>>>
>>> Since the value in the audience field is used to by the author= ization server in a comparison operation (see Section 5.2) I believe the cu= rrent text will lead to interoperability problems. Not only is the comparis= ion operation unspecified but even the value that is contained in the field= is left open. The RFC 2119 MAY does not really give a lot of hints of what= should be put in there.
>>>
>>> Without having a clear description of what identifier is conta= ined in this field and how the comparison works it is either possible that = a legitimate client is rejected by the authorization server (which is annoy= ing) or an assertion with an incorrect assertion is accepted (which is a se= curity problem).
>>>
>>> Btw, the same issue can also be seen in http://to= ols.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http:/= /tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more gen= eric form also in the JWT (Section 4.1.3 of http://tools.i= etf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim)= . From the description in the JWT document I was not quite sure whether the= ability to carry an array of case sensitive strings for that field is also= allowed in any of the assertion documents.
>>>
>>> Note that there are two documents that provide input to this p= roblem space, namely:
>>> http://tools.ietf.org/html/rfc6125
>>> http://tools.ietf.org/html/draft-iab-identifi= er-comparison-07
>>>
>>> So, I would suggest to decide what type of identifier goes int= o this field and then to point to a document that illustrates how the compa= rison operation would look like. Possible identifiers are domain names, IP = addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wi= ldcard match (like "*.example.com") or only an equality match? Would "www.example.com" be the s= ame as "example.com" if they resolve to the same IP address(es)?
>>>
>>> Ciao
>>> Hannes
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--14dae93406e38f42a304d306f21d-- From jricher@mitre.org Fri Jan 11 10:04:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85121F892A for ; Fri, 11 Jan 2013 10:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj1-huSuZu0N for ; Fri, 11 Jan 2013 10:04:25 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AD27521F8919 for ; Fri, 11 Jan 2013 10:04:23 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E92C11F361C; Fri, 11 Jan 2013 13:04:22 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CE17A1F2F44; Fri, 11 Jan 2013 13:04:22 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 13:04:22 -0500 From: "Richer, Justin P." To: George Fletcher Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt Thread-Index: AQHN7fJSaTtsJD7Erk6+DEfqvZzSmJhEaOtPgABbK4A= Date: Fri, 11 Jan 2013 18:04:21 +0000 Message-ID: References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50F04DF8.1070407@aol.com> In-Reply-To: <50F04DF8.1070407@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.162] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06876939IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 18:04:28 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06876939IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should follow the 6749 Token Endpoint error responses for bad client cre= dentials. That's what this text at the end of 2.3 is supposed to mean: If the client credentials are invalid or there is another error, the Authorization Server responds with the appropriate error response from the OAuth2 Core. Looking at it now, it's completely non-normative and stuffed into the examp= les section, which is probably not the best way to describe it. There was some confusion about the {valid: false} response as well, so now = I'm thinking that should be pulled into an "Errors" section, perhaps? -- Justin On Jan 11, 2013, at 12:38 PM, George Fletcher > wrote: Additional feedback on the introspection endpoint. What is the expected error response if the introspection endpoint is using = client credentials as recommended in section 2.1 The endpoint SHOULD also require some form of authentication to access this endpoint, such as the Client Authentication as described in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access Token. and the client credentials are invalid. It doesn't seem correct to return a= n HTTP 200 with a body of { "valid: false } as the endpoint probably never = even tried to validate the token parameter. I can see a couple of options... 1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with= the error described in JSON in the body of the response. 2. Follow RFC 6750 and return a WWW-Authenticate Response header that conta= ins the error and optionally error_description. Thanks, George --_000_B33BFB58CCC8BE4998958016839DE27E06876939IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable It should follow the 6749 Token Endpoint error responses for bad client cre= dentials. That's what this text at the end of 2.3 is supposed to mean: 

   If the client credentials are invalid or there is=
 another error, the
   Authorization Server responds with the appropriate error response
   from the OAuth2 Core.
Looking at it now, it's completely non-normative and stuffed into the = examples section, which is probably not the best way to describe it. <= /div>

There was some confusion about the {valid: false} response as well, so= now I'm thinking that should be pulled into an "Errors" section,= perhaps?

 -- Justin

On Jan 11, 2013, at 12:38 PM, George Fletcher <gffletch@aol.com>
 wrote:

Additional feedback on the intros= pection endpoint.

What is the expected error response if the introspection endpoint is using = client credentials as recommended in section 2.1
The endpoint SHOULD also require some form of authen=
tication to
   access this endpoint, such as the Client Authentication as described
   in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access
   Token.
and the client credentials are invalid. It doesn't seem correct to return a= n HTTP 200 with a body of { "valid: false } as the endpoint probably n= ever even tried to validate the token parameter.

I can see a couple of options...

1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with= the error described in JSON in the body of the response.

2. Follow RFC 6750 and return a WWW-Authenticate Response header that conta= ins the error and optionally error_description.

Thanks,
George


--_000_B33BFB58CCC8BE4998958016839DE27E06876939IMCMBX01MITREOR_-- From gffletch@aol.com Fri Jan 11 11:57:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE30F21F8632 for ; Fri, 11 Jan 2013 11:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNkNbYtD407t for ; Fri, 11 Jan 2013 11:57:55 -0800 (PST) Received: from imr-db02.mx.aol.com (imr-db02.mx.aol.com [205.188.91.96]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2121F8610 for ; Fri, 11 Jan 2013 11:57:54 -0800 (PST) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-db02.mx.aol.com (Outbound Mail Relay) with ESMTP id 4C3081C000194; Fri, 11 Jan 2013 14:57:54 -0500 (EST) Received: from palantir.local (unknown [10.172.6.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B2802E0000FD; Fri, 11 Jan 2013 14:57:53 -0500 (EST) Message-ID: <50F06EC1.4060203@aol.com> Date: Fri, 11 Jan 2013 14:57:53 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Richer, Justin P." References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <50F04DF8.1070407@aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010305030304070705000506" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357934274; bh=B3ubhuLpxYlSd7dVBVP9ljSobHgE54tABkBfU/7fV14=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Nw6mhvnMkRH8S1SrcgHFMDbc+a2qop3nqoNhCDZ9V6P0wS0LNU1ok5T7EX3QLMhkS 96Vyy5S8AtemzZUAOUpj+6GfqOJBK3nQXtU+etx9PPJgVcSRKP88tdcPIF2CFBU11P i6NGefuLemY37RVAi/grdvlbzxmGtlJUOUi12ZGA= X-AOL-SCOLL-SCORE: 1:2:407192448:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d294250f06ec177ef X-AOL-IP: 10.172.6.217 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:57:56 -0000 This is a multi-part message in MIME format. --------------010305030304070705000506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I definitely like the idea of an Errors section that normatively defines error responses. Thanks, George On 1/11/13 1:04 PM, Richer, Justin P. wrote: > It should follow the 6749 Token Endpoint error responses for bad > client credentials. That's what this text at the end of 2.3 is > supposed to mean: > > If the client credentials are invalid or there is another error, the > Authorization Server responds with the appropriate error response > from the OAuth2 Core. > Looking at it now, it's completely non-normative and stuffed into the > examples section, which is probably not the best way to describe it. > > There was some confusion about the {valid: false} response as well, so > now I'm thinking that should be pulled into an "Errors" section, perhaps? > > -- Justin > > On Jan 11, 2013, at 12:38 PM, George Fletcher > > wrote: > >> Additional feedback on the introspection endpoint. >> >> What is the expected error response if the introspection endpoint is >> using client credentials as recommended in section 2.1 >> The endpoint SHOULD also require some form of authentication to >> access this endpoint, such as the Client Authentication as described >> in OAuth 2 Core Specification [RFC6749 ] or a separate OAuth2 Access >> Token. >> and the client credentials are invalid. It doesn't seem correct to >> return an HTTP 200 with a body of { "valid: false } as the endpoint >> probably never even tried to validate the token parameter. >> >> I can see a couple of options... >> >> 1. Follow the RFC 6749 /token endpoint and return an HTTP 40X >> response with the error described in JSON in the body of the response. >> >> 2. Follow RFC 6750 and return a WWW-Authenticate Response header that >> contains the error and optionally error_description. >> >> Thanks, >> George >> > --------------010305030304070705000506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I definitely like the idea of an Errors section that normatively defines error responses.

Thanks,
George
On 1/11/13 1:04 PM, Richer, Justin P. wrote:
It should follow the 6749 Token Endpoint error responses for bad client credentials. That's what this text at the end of 2.3 is supposed to mean: 

   If the client credentials are invalid or there is another error, the
   Authorization Server responds with the appropriate error response
   from the OAuth2 Core.
Looking at it now, it's completely non-normative and stuffed into the examples section, which is probably not the best way to describe it. 

There was some confusion about the {valid: false} response as well, so now I'm thinking that should be pulled into an "Errors" section, perhaps?

 -- Justin

 wrote:

Additional feedback on the introspection endpoint.

What is the expected error response if the introspection endpoint is using client credentials as recommended in section 2.1
The endpoint SHOULD also require some form of authentication to
   access this endpoint, such as the Client Authentication as described
   in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access
   Token.
and the client credentials are invalid. It doesn't seem correct to return an HTTP 200 with a body of { "valid: false } as the endpoint probably never even tried to validate the token parameter.

I can see a couple of options...

1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with the error described in JSON in the body of the response.

2. Follow RFC 6750 and return a WWW-Authenticate Response header that contains the error and optionally error_description.

Thanks,
George



--------------010305030304070705000506-- From hannes.tschofenig@gmx.net Sat Jan 12 11:50:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39AD21F872C for ; Sat, 12 Jan 2013 11:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.325 X-Spam-Level: X-Spam-Status: No, score=-101.325 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmO2L1GxTRH0 for ; Sat, 12 Jan 2013 11:50:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF4621F8712 for ; Sat, 12 Jan 2013 11:50:15 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lm9rr-1TKVMN40dl-00Ze8O for ; Sat, 12 Jan 2013 20:50:14 +0100 Received: (qmail invoked by alias); 12 Jan 2013 19:50:14 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp002) with SMTP; 12 Jan 2013 20:50:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19sCalDTXlsaWH+BvZ3FA8yiLyQm9LMD81xmOm+mZ iMteBD6L+aegyG Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 12 Jan 2013 21:50:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> References: <50EFF7F0.90300@cs.tcd.ie> To: Brian Campbell X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 19:50:23 -0000 Hi Brian,=20 I understand that this is challenging. Nevertheless it would make sense to describe the desired behavior in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such = a way that two versions developed by different groups would interoperate = without causing security problems or failures.=20 To move forward with draft-ietf-oauth-assertions I suggest to follow the = recommendation in = http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to = address the details in=20 draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer as = soon as possible to get these documents moving forward and completed = soon.=20 Ciao Hannes On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: > That text around audience in the framework spec changed from a SHOULD = to a MAY in -09 so that it would be more consistent with the the SAML = and JWT versions, which were already using a MAY in that context. >=20 > Your concern is valid Hannes and your point is taken. But reality is = rather messy and I don't believe it can addressed as easily as you = suggest. =20 >=20 > In SAML, for example, an entity identifier is often used as a value = for the audience (per spec and in practice). But an AS may not = necessarily identify itself with a full blown SAML entity, in which case = the token endpoint URI is more appropriate. The whole issue is also = somewhat complicated in SAML too by it having both audience and = recipient that are similar but not the same. I've tried to account for = all of this in the SAML doc but it's admittedly somewhat awkward and = complex and not as simple as saying the value has to be X and must be = validated in exactly such a way. >=20 > JWT doesn't have the same history and baggage of SAML but is subject = to many of the same real world deployment variations. >=20 > I'm definitely open to improvements with respect to the handling of = audience values but I believe anything that is done needs to reflect the = realities of current implementations and deployments as well as related = specifications., >=20 >=20 >=20 > On Fri, Jan 11, 2013 at 8:55 AM, John Bradley = wrote: > Yes in assertions it needs to be general. It is the JWT and SAML = profiles that need to nail down what the format of the audience is. = They should probably both be the URI of the token endpoint. In both = SAML and JWT there can be multiple audiences for the token. >=20 > John > On 2013-01-11, at 11:37 AM, "Richer, Justin P." = wrote: >=20 > > It's my understanding that the general assertions claim is more of a = conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. > > > > -- Justin > > > > > > On Jan 11, 2013, at 6:30 AM, Stephen Farrell = > > wrote: > > > >> > >> Hi, > >> > >> Since we thought we were done with it, I put this document > >> on the IESG telechat agenda for Jan 24. Hannes' question > >> however looks like its a real one that needs an answer. > >> > >> I'd appreciate it if the WG could figure out if there's any > >> change needed and either make that change in the next week, > >> or else tell me to take the draft off the telechat agenda > >> for now. > >> > >> If discussion doesn't happen, or happens but doesn't reach > >> a conclusion, then I'll take the draft off the agenda in a > >> week's time and we can sort out if any changes are needed > >> later. > >> > >> The reason why now+1-week matters, is that that's when > >> IESG members tend to do their reviews and having 'em all > >> review a moving target isn't a good plan. > >> > >> Thanks, > >> S. > >> > >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: > >>> Hi guys, > >>> > >>> Thanks for updating the assertion document and for incorporating = the comments received on the mailing list. > >>> > >>> There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): > >>> " > >>> Audience A value that identifies the parties intended to process = the > >>> assertion. An audience value MAY be the URL of the Token = Endpoint > >>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. > >>> " > >>> > >>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there. > >>> > >>> Without having a clear description of what identifier is contained = in this field and how the comparison works it is either possible that a = legitimate client is rejected by the authorization server (which is = annoying) or an assertion with an incorrect assertion is accepted (which = is a security problem). > >>> > >>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents. > >>> > >>> Note that there are two documents that provide input to this = problem space, namely: > >>> http://tools.ietf.org/html/rfc6125 > >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 > >>> > >>> So, I would suggest to decide what type of identifier goes into = this field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? > >>> > >>> Ciao > >>> Hannes > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Sat Jan 12 12:43:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FBE21F8853 for ; Sat, 12 Jan 2013 12:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXvEHGmmewJU for ; Sat, 12 Jan 2013 12:43:43 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id DCDBD21F8842 for ; Sat, 12 Jan 2013 12:43:27 -0800 (PST) Received: from BL2FFO11FD010.protection.gbl (10.173.161.200) by BL2FFO11HUB017.protection.gbl (10.173.160.109) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sat, 12 Jan 2013 20:43:23 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sat, 12 Jan 2013 20:43:23 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Sat, 12 Jan 2013 20:42:25 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell , Stephen Farrell Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RTcHXvPlTOOEyaLkX1rm6jbZhD/pUAgAA0JQCAABW0gIAAIGKAgAGzmACAAA5L0A== Date: Sat, 12 Jan 2013 20:42:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> In-Reply-To: <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(52604002)(13464002)(24454001)(52544001)(51704002)(164054002)(377424002)(377454001)(49866001)(47776002)(76482001)(33656001)(50466001)(59766001)(5343655001)(55846006)(53806001)(77982001)(550184003)(23726001)(54356001)(51856001)(47736001)(79102001)(46102001)(46406002)(50986001)(56776001)(74502001)(16406001)(44976002)(74662001)(47446002)(15202345001)(47976001)(5343635001)(54316002)(56816002)(4396001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB017; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0724FCD4CD Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 20:43:45 -0000 Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appr= opriate. In some use cases, a good representation of an appropriate audien= ce value is URL of the Token Endpoint. That's there in the Assertions spec= ification as guidance to writers token-type specific specs using the Assert= ions spec, as I believe it should be. That being the case, as Brian descri= bes, sometimes audience values are more abstract identifiers or identifiers= for groups of services, and we don't want to inadvertently preclude those = actual use cases. Thus, I believe that the language is appropriate as-is. Thus, I believe th= at we should proceed with the currently scheduled telechat discussion of th= e spec. Thanks all, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Saturday, January 12, 2013 11:50 AM To: Brian Campbell Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Brian,=20 I understand that this is challenging. Nevertheless it would make sense to describe the desired behavior in draft-= ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way th= at two versions developed by different groups would interoperate without ca= using security problems or failures.=20 To move forward with draft-ietf-oauth-assertions I suggest to follow the re= commendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10507= .html and to address the details in draft-ietf-oauth-jwt-bearer and in dra= ft-ietf-oauth-saml2-bearer as soon as possible to get these documents movin= g forward and completed soon.=20 Ciao Hannes On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: > That text around audience in the framework spec changed from a SHOULD to = a MAY in -09 so that it would be more consistent with the the SAML and JWT = versions, which were already using a MAY in that context. >=20 > Your concern is valid Hannes and your point is taken. But reality is rath= er messy and I don't believe it can addressed as easily as you suggest. =20 >=20 > In SAML, for example, an entity identifier is often used as a value for t= he audience (per spec and in practice). But an AS may not necessarily iden= tify itself with a full blown SAML entity, in which case the token endpoint= URI is more appropriate. The whole issue is also somewhat complicated in S= AML too by it having both audience and recipient that are similar but not t= he same. I've tried to account for all of this in the SAML doc but it's adm= ittedly somewhat awkward and complex and not as simple as saying the value = has to be X and must be validated in exactly such a way. >=20 > JWT doesn't have the same history and baggage of SAML but is subject to m= any of the same real world deployment variations. >=20 > I'm definitely open to improvements with respect to the handling of=20 > audience values but I believe anything that is done needs to reflect=20 > the realities of current implementations and deployments as well as=20 > related specifications., >=20 >=20 >=20 > On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrote: > Yes in assertions it needs to be general. It is the JWT and SAML profile= s that need to nail down what the format of the audience is. They should= probably both be the URI of the token endpoint. In both SAML and JWT the= re can be multiple audiences for the token. >=20 > John > On 2013-01-11, at 11:37 AM, "Richer, Justin P." wrote= : >=20 > > It's my understanding that the general assertions claim is more of a co= nceptual mapping than it is a concrete encoding, so anything more specific = here would be out of place. I would like the authors to either confirm or c= orrect my assumptions, though. > > > > -- Justin > > > > > > On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 > > > > wrote: > > > >> > >> Hi, > >> > >> Since we thought we were done with it, I put this document on the=20 > >> IESG telechat agenda for Jan 24. Hannes' question however looks=20 > >> like its a real one that needs an answer. > >> > >> I'd appreciate it if the WG could figure out if there's any change=20 > >> needed and either make that change in the next week, or else tell=20 > >> me to take the draft off the telechat agenda for now. > >> > >> If discussion doesn't happen, or happens but doesn't reach a=20 > >> conclusion, then I'll take the draft off the agenda in a week's=20 > >> time and we can sort out if any changes are needed later. > >> > >> The reason why now+1-week matters, is that that's when IESG members=20 > >> tend to do their reviews and having 'em all review a moving target=20 > >> isn't a good plan. > >> > >> Thanks, > >> S. > >> > >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: > >>> Hi guys, > >>> > >>> Thanks for updating the assertion document and for incorporating the = comments received on the mailing list. > >>> > >>> There is only one issue that caught my attention. You changed the des= cription of the audience element to the following text (in version -09 of h= ttp://tools.ietf.org/html/draft-ietf-oauth-assertions-09): > >>> " > >>> Audience A value that identifies the parties intended to process th= e > >>> assertion. An audience value MAY be the URL of the Token Endpoin= t > >>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. > >>> " > >>> > >>> Since the value in the audience field is used to by the authorization= server in a comparison operation (see Section 5.2) I believe the current t= ext will lead to interoperability problems. Not only is the comparision ope= ration unspecified but even the value that is contained in the field is lef= t open. The RFC 2119 MAY does not really give a lot of hints of what should= be put in there. > >>> > >>> Without having a clear description of what identifier is contained in= this field and how the comparison works it is either possible that a legit= imate client is rejected by the authorization server (which is annoying) or= an assertion with an incorrect assertion is accepted (which is a security = problem). > >>> > >>> Btw, the same issue can also be seen in http://tools.ietf.org/html/dr= aft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-s= aml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of= http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim= ). From the description in the JWT document I was not quite sure whether th= e ability to carry an array of case sensitive strings for that field is als= o allowed in any of the assertion documents. > >>> > >>> Note that there are two documents that provide input to this problem = space, namely: > >>> http://tools.ietf.org/html/rfc6125 > >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 > >>> > >>> So, I would suggest to decide what type of identifier goes into this = field and then to point to a document that illustrates how the comparison o= peration would look like. Possible identifiers are domain names, IP address= es, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard = match (like "*.example.com") or only an equality match? Would "www.example.= com" be the same as "example.com" if they resolve to the same IP address(es= )? > >>> > >>> Ciao > >>> Hannes > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > 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 From hannes.tschofenig@gmx.net Sun Jan 13 01:55:45 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB54C21F8648 for ; Sun, 13 Jan 2013 01:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPXDk7GFTcXQ for ; Sun, 13 Jan 2013 01:55:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCD21F8635 for ; Sun, 13 Jan 2013 01:55:44 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MUSkP-1TTlAC3VfH-00RF3c for ; Sun, 13 Jan 2013 10:55:43 +0100 Received: (qmail invoked by alias); 13 Jan 2013 09:55:43 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp028) with SMTP; 13 Jan 2013 10:55:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+D6VZaSrCDPXON8PaeraJwcaVeCWj4g5DyMcjVja pi3uZ4nhzjFwE6 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 13 Jan 2013 11:55:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 09:55:46 -0000 Hi Mike,=20 I understand your reasoning: you want to keep all options open in the = framework specification and you want to be more specific in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer.=20 The RFC 2119 language does not add anything but it does not hurt either. = It just says that there could essentially be anything in there, = including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific = documents. For example, draft-ietf-oauth-jwt-bearer at the moment does = not allow an interoperable deployment since it just repeats the abstract = framework text by saying "The token endpoint URL of the authorization = server MAY be used as an acceptable value for an "aud" element."=20 Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: > Hi Hannes, >=20 > For the reasons that Justin and Brian state, I believe that the MAY is = appropriate. In some use cases, a good representation of an appropriate = audience value is URL of the Token Endpoint. That's there in the = Assertions specification as guidance to writers token-type specific = specs using the Assertions spec, as I believe it should be. That being = the case, as Brian describes, sometimes audience values are more = abstract identifiers or identifiers for groups of services, and we don't = want to inadvertently preclude those actual use cases. >=20 > Thus, I believe that the language is appropriate as-is. Thus, I = believe that we should proceed with the currently scheduled telechat = discussion of the spec. >=20 > Thanks = all, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: Saturday, January 12, 2013 11:50 AM > To: Brian Campbell > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Brian,=20 >=20 > I understand that this is challenging. >=20 > Nevertheless it would make sense to describe the desired behavior in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such = a way that two versions developed by different groups would interoperate = without causing security problems or failures.=20 >=20 > To move forward with draft-ietf-oauth-assertions I suggest to follow = the recommendation in = http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to = address the details in draft-ietf-oauth-jwt-bearer and in = draft-ietf-oauth-saml2-bearer as soon as possible to get these documents = moving forward and completed soon.=20 >=20 > Ciao > Hannes >=20 > On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >=20 >> That text around audience in the framework spec changed from a SHOULD = to a MAY in -09 so that it would be more consistent with the the SAML = and JWT versions, which were already using a MAY in that context. >>=20 >> Your concern is valid Hannes and your point is taken. But reality is = rather messy and I don't believe it can addressed as easily as you = suggest. =20 >>=20 >> In SAML, for example, an entity identifier is often used as a value = for the audience (per spec and in practice). But an AS may not = necessarily identify itself with a full blown SAML entity, in which case = the token endpoint URI is more appropriate. The whole issue is also = somewhat complicated in SAML too by it having both audience and = recipient that are similar but not the same. I've tried to account for = all of this in the SAML doc but it's admittedly somewhat awkward and = complex and not as simple as saying the value has to be X and must be = validated in exactly such a way. >>=20 >> JWT doesn't have the same history and baggage of SAML but is subject = to many of the same real world deployment variations. >>=20 >> I'm definitely open to improvements with respect to the handling of=20= >> audience values but I believe anything that is done needs to reflect=20= >> the realities of current implementations and deployments as well as=20= >> related specifications., >>=20 >>=20 >>=20 >> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley = wrote: >> Yes in assertions it needs to be general. It is the JWT and SAML = profiles that need to nail down what the format of the audience is. = They should probably both be the URI of the token endpoint. In both = SAML and JWT there can be multiple audiences for the token. >>=20 >> John >> On 2013-01-11, at 11:37 AM, "Richer, Justin P." = wrote: >>=20 >>> It's my understanding that the general assertions claim is more of a = conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. >=20 >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Since we thought we were done with it, I put this document on the=20= >>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>> like its a real one that needs an answer. >>>>=20 >>>> I'd appreciate it if the WG could figure out if there's any change=20= >>>> needed and either make that change in the next week, or else tell=20= >>>> me to take the draft off the telechat agenda for now. >>>>=20 >>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>> time and we can sort out if any changes are needed later. >>>>=20 >>>> The reason why now+1-week matters, is that that's when IESG members=20= >>>> tend to do their reviews and having 'em all review a moving target=20= >>>> isn't a good plan. >>>>=20 >>>> Thanks, >>>> S. >>>>=20 >>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>> Hi guys, >>>>>=20 >>>>> Thanks for updating the assertion document and for incorporating = the comments received on the mailing list. >>>>>=20 >>>>> There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>> " >>>>> Audience A value that identifies the parties intended to process = the >>>>> assertion. An audience value MAY be the URL of the Token = Endpoint >>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>> " >>>>>=20 >>>>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there. >>>>>=20 >>>>> Without having a clear description of what identifier is contained = in this field and how the comparison works it is either possible that a = legitimate client is rejected by the authorization server (which is = annoying) or an assertion with an incorrect assertion is accepted (which = is a security problem). >>>>>=20 >>>>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents. >>>>>=20 >>>>> Note that there are two documents that provide input to this = problem space, namely: >>>>> http://tools.ietf.org/html/rfc6125 >>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>=20 >>>>> So, I would suggest to decide what type of identifier goes into = this field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Sun Jan 13 02:09:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5E21F8635 for ; Sun, 13 Jan 2013 02:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDNARoxIx0KL for ; Sun, 13 Jan 2013 02:09:13 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCF21F85D2 for ; Sun, 13 Jan 2013 02:09:13 -0800 (PST) Received: from BY2FFO11FD015.protection.gbl (10.1.15.200) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sun, 13 Jan 2013 10:09:10 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sun, 13 Jan 2013 10:09:10 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Sun, 13 Jan 2013 10:09:09 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RTcHXvPlTOOEyaLkX1rm6jbZhD/pUAgAA0JQCAABW0gIAAIGKAgAGzmACAAA5L0IAA3e+AgAACUkA= Date: Sun, 13 Jan 2013 10:09:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> In-Reply-To: <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(479174001)(377424002)(13464002)(164054002)(52604002)(51704002)(24454001)(52544001)(550184003)(50986001)(74662001)(44976002)(46102001)(51856001)(54316002)(50466001)(49866001)(5343655001)(54356001)(55846006)(53806001)(15202345001)(47976001)(4396001)(47446002)(47736001)(16406001)(46406002)(33656001)(59766001)(23726001)(31966008)(74502001)(77982001)(79102001)(56776001)(76482001)(5343635001)(47776002)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC105.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0725D9E8D0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 10:09:19 -0000 We already know of use cases where the audience is an abstract identifier a= nd use cases where the audience is the URL of the token endpoint. Both are= legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may requir= e a profile further specifying the behaviors appropriate to that use case. = This is not a bug - it is a feature, as it increases the applicability of = the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate ba= lance by providing guidance on likely audience values for many use cases, b= ut not precluding other values where necessary for those use cases. Best wishes, -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike,=20 I understand your reasoning: you want to keep all options open in the frame= work specification and you want to be more specific in draft-ietf-oauth-jwt= -bearer and in draft-ietf-oauth-saml2-bearer.=20 The RFC 2119 language does not add anything but it does not hurt either. It= just says that there could essentially be anything in there, including the= URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific doc= uments. For example, draft-ietf-oauth-jwt-bearer at the moment does not all= ow an interoperable deployment since it just repeats the abstract framework= text by saying "The token endpoint URL of the authorization server MAY be = used as an acceptable value for an "aud" element."=20 Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: > Hi Hannes, >=20 > For the reasons that Justin and Brian state, I believe that the MAY is ap= propriate. In some use cases, a good representation of an appropriate audi= ence value is URL of the Token Endpoint. That's there in the Assertions sp= ecification as guidance to writers token-type specific specs using the Asse= rtions spec, as I believe it should be. That being the case, as Brian desc= ribes, sometimes audience values are more abstract identifiers or identifie= rs for groups of services, and we don't want to inadvertently preclude thos= e actual use cases. >=20 > Thus, I believe that the language is appropriate as-is. Thus, I believe = that we should proceed with the currently scheduled telechat discussion of = the spec. >=20 > Thanks all= , > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Hannes Tschofenig > Sent: Saturday, January 12, 2013 11:50 AM > To: Brian Campbell > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Brian, >=20 > I understand that this is challenging. >=20 > Nevertheless it would make sense to describe the desired behavior in draf= t-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way = that two versions developed by different groups would interoperate without = causing security problems or failures.=20 >=20 > To move forward with draft-ietf-oauth-assertions I suggest to follow the = recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg105= 07.html and to address the details in draft-ietf-oauth-jwt-bearer and in d= raft-ietf-oauth-saml2-bearer as soon as possible to get these documents mov= ing forward and completed soon.=20 >=20 > Ciao > Hannes >=20 > On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >=20 >> That text around audience in the framework spec changed from a SHOULD to= a MAY in -09 so that it would be more consistent with the the SAML and JWT= versions, which were already using a MAY in that context. >>=20 >> Your concern is valid Hannes and your point is taken. But reality is rat= her messy and I don't believe it can addressed as easily as you suggest. =20 >>=20 >> In SAML, for example, an entity identifier is often used as a value for = the audience (per spec and in practice). But an AS may not necessarily ide= ntify itself with a full blown SAML entity, in which case the token endpoin= t URI is more appropriate. The whole issue is also somewhat complicated in = SAML too by it having both audience and recipient that are similar but not = the same. I've tried to account for all of this in the SAML doc but it's ad= mittedly somewhat awkward and complex and not as simple as saying the value= has to be X and must be validated in exactly such a way. >>=20 >> JWT doesn't have the same history and baggage of SAML but is subject to = many of the same real world deployment variations. >>=20 >> I'm definitely open to improvements with respect to the handling of=20 >> audience values but I believe anything that is done needs to reflect=20 >> the realities of current implementations and deployments as well as=20 >> related specifications., >>=20 >>=20 >>=20 >> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrote: >> Yes in assertions it needs to be general. It is the JWT and SAML profil= es that need to nail down what the format of the audience is. They shoul= d probably both be the URI of the token endpoint. In both SAML and JWT th= ere can be multiple audiences for the token. >>=20 >> John >> On 2013-01-11, at 11:37 AM, "Richer, Justin P." wrot= e: >>=20 >>> It's my understanding that the general assertions claim is more of a co= nceptual mapping than it is a concrete encoding, so anything more specific = here would be out of place. I would like the authors to either confirm or c= orrect my assumptions, though. >=20 >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Since we thought we were done with it, I put this document on the=20 >>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>> like its a real one that needs an answer. >>>>=20 >>>> I'd appreciate it if the WG could figure out if there's any change=20 >>>> needed and either make that change in the next week, or else tell=20 >>>> me to take the draft off the telechat agenda for now. >>>>=20 >>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>> time and we can sort out if any changes are needed later. >>>>=20 >>>> The reason why now+1-week matters, is that that's when IESG members=20 >>>> tend to do their reviews and having 'em all review a moving target=20 >>>> isn't a good plan. >>>>=20 >>>> Thanks, >>>> S. >>>>=20 >>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>> Hi guys, >>>>>=20 >>>>> Thanks for updating the assertion document and for incorporating the = comments received on the mailing list. >>>>>=20 >>>>> There is only one issue that caught my attention. You changed the des= cription of the audience element to the following text (in version -09 of h= ttp://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>> " >>>>> Audience A value that identifies the parties intended to process the >>>>> assertion. An audience value MAY be the URL of the Token Endpoint >>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>> " >>>>>=20 >>>>> Since the value in the audience field is used to by the authorization= server in a comparison operation (see Section 5.2) I believe the current t= ext will lead to interoperability problems. Not only is the comparision ope= ration unspecified but even the value that is contained in the field is lef= t open. The RFC 2119 MAY does not really give a lot of hints of what should= be put in there. >>>>>=20 >>>>> Without having a clear description of what identifier is contained in= this field and how the comparison works it is either possible that a legit= imate client is rejected by the authorization server (which is annoying) or= an assertion with an incorrect assertion is accepted (which is a security = problem). >>>>>=20 >>>>> Btw, the same issue can also be seen in http://tools.ietf.org/html/dr= aft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-s= aml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of= http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim= ). From the description in the JWT document I was not quite sure whether th= e ability to carry an array of case sensitive strings for that field is als= o allowed in any of the assertion documents. >>>>>=20 >>>>> Note that there are two documents that provide input to this problem = space, namely: >>>>> http://tools.ietf.org/html/rfc6125 >>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>=20 >>>>> So, I would suggest to decide what type of identifier goes into this = field and then to point to a document that illustrates how the comparison o= peration would look like. Possible identifiers are domain names, IP address= es, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard = match (like "*.example.com") or only an equality match? Would "www.example.= com" be the same as "example.com" if they resolve to the same IP address(es= )? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun Jan 13 02:48:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9626E21F869A for ; Sun, 13 Jan 2013 02:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdQs38J8xpQh for ; Sun, 13 Jan 2013 02:48:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 504A421F8698 for ; Sun, 13 Jan 2013 02:48:48 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MPKAQ-1TpvH50XdQ-004S3X for ; Sun, 13 Jan 2013 11:48:47 +0100 Received: (qmail invoked by alias); 13 Jan 2013 10:48:46 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 13 Jan 2013 11:48:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/g4OVkxf7g2LmN7zgriOM6qLTj+OPovMz6S+ujvc INdArIvNBuK6rt Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 13 Jan 2013 12:48:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 10:48:49 -0000 Hi Mike,=20 it is fine to support different identifiers and to even allow the set of = supported identifiers to get extended over time.=20 Just omitting a description is, however, not an option. We are in the = lucky position where others have done the work for us already (as = mentioned in the two cited references). For the IAB document there is = even the chance to provide feedback (see = https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-compa= rison-for-security-purposes/) in case you believe the author is = misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: > We already know of use cases where the audience is an abstract = identifier and use cases where the audience is the URL of the token = endpoint. Both are legitimate. We should foreclose neither. >=20 > Like many things OAuth, interoperability can be achieved, but it may = require a profile further specifying the behaviors appropriate to that = use case. This is not a bug - it is a feature, as it increases the = applicability of the OAuth specifications. >=20 > The Assertion, JWT Profile, and SAML Profile are striking an = appropriate balance by providing guidance on likely audience values for = many use cases, but not precluding other values where necessary for = those use cases. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Sunday, January 13, 2013 1:56 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org = WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike,=20 >=20 > I understand your reasoning: you want to keep all options open in the = framework specification and you want to be more specific in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >=20 > The RFC 2119 language does not add anything but it does not hurt = either. It just says that there could essentially be anything in there, = including the URL of the Token Endpoint. >=20 > You can of course post-pone dealing with the issue to the more = specific documents. For example, draft-ietf-oauth-jwt-bearer at the = moment does not allow an interoperable deployment since it just repeats = the abstract framework text by saying "The token endpoint URL of the = authorization server MAY be used as an acceptable value for an "aud" = element."=20 >=20 > Ciao > Hannes >=20 > On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >=20 >> Hi Hannes, >>=20 >> For the reasons that Justin and Brian state, I believe that the MAY = is appropriate. In some use cases, a good representation of an = appropriate audience value is URL of the Token Endpoint. That's there = in the Assertions specification as guidance to writers token-type = specific specs using the Assertions spec, as I believe it should be. = That being the case, as Brian describes, sometimes audience values are = more abstract identifiers or identifiers for groups of services, and we = don't want to inadvertently preclude those actual use cases. >>=20 >> Thus, I believe that the language is appropriate as-is. Thus, I = believe that we should proceed with the currently scheduled telechat = discussion of the spec. >>=20 >> Thanks = all, >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf=20 >> Of Hannes Tschofenig >> Sent: Saturday, January 12, 2013 11:50 AM >> To: Brian Campbell >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Brian, >>=20 >> I understand that this is challenging. >>=20 >> Nevertheless it would make sense to describe the desired behavior in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such = a way that two versions developed by different groups would interoperate = without causing security problems or failures.=20 >>=20 >> To move forward with draft-ietf-oauth-assertions I suggest to follow = the recommendation in = http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to = address the details in draft-ietf-oauth-jwt-bearer and in = draft-ietf-oauth-saml2-bearer as soon as possible to get these documents = moving forward and completed soon.=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>=20 >>> That text around audience in the framework spec changed from a = SHOULD to a MAY in -09 so that it would be more consistent with the the = SAML and JWT versions, which were already using a MAY in that context. >>>=20 >>> Your concern is valid Hannes and your point is taken. But reality is = rather messy and I don't believe it can addressed as easily as you = suggest. =20 >>>=20 >>> In SAML, for example, an entity identifier is often used as a value = for the audience (per spec and in practice). But an AS may not = necessarily identify itself with a full blown SAML entity, in which case = the token endpoint URI is more appropriate. The whole issue is also = somewhat complicated in SAML too by it having both audience and = recipient that are similar but not the same. I've tried to account for = all of this in the SAML doc but it's admittedly somewhat awkward and = complex and not as simple as saying the value has to be X and must be = validated in exactly such a way. >>>=20 >>> JWT doesn't have the same history and baggage of SAML but is subject = to many of the same real world deployment variations. >>>=20 >>> I'm definitely open to improvements with respect to the handling of=20= >>> audience values but I believe anything that is done needs to reflect=20= >>> the realities of current implementations and deployments as well as=20= >>> related specifications., >>>=20 >>>=20 >>>=20 >>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley = wrote: >>> Yes in assertions it needs to be general. It is the JWT and SAML = profiles that need to nail down what the format of the audience is. = They should probably both be the URI of the token endpoint. In both = SAML and JWT there can be multiple audiences for the token. >>>=20 >>> John >>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." = wrote: >>>=20 >>>> It's my understanding that the general assertions claim is more of = a conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. >=20 >>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>=20 >>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Since we thought we were done with it, I put this document on the=20= >>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>>> like its a real one that needs an answer. >>>>>=20 >>>>> I'd appreciate it if the WG could figure out if there's any change=20= >>>>> needed and either make that change in the next week, or else tell=20= >>>>> me to take the draft off the telechat agenda for now. >>>>>=20 >>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>>> time and we can sort out if any changes are needed later. >>>>>=20 >>>>> The reason why now+1-week matters, is that that's when IESG = members=20 >>>>> tend to do their reviews and having 'em all review a moving target=20= >>>>> isn't a good plan. >>>>>=20 >>>>> Thanks, >>>>> S. >>>>>=20 >>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>> Hi guys, >>>>>>=20 >>>>>> Thanks for updating the assertion document and for incorporating = the comments received on the mailing list. >>>>>>=20 >>>>>> There is only one issue that caught my attention. You changed the = description of the audience element to the following text (in version = -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>> " >>>>>> Audience A value that identifies the parties intended to process = the >>>>>> assertion. An audience value MAY be the URL of the Token = Endpoint >>>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>> " >>>>>>=20 >>>>>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there. >>>>>>=20 >>>>>> Without having a clear description of what identifier is = contained in this field and how the comparison works it is either = possible that a legitimate client is rejected by the authorization = server (which is annoying) or an assertion with an incorrect assertion = is accepted (which is a security problem). >>>>>>=20 >>>>>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents. >>>>>>=20 >>>>>> Note that there are two documents that provide input to this = problem space, namely: >>>>>> http://tools.ietf.org/html/rfc6125 >>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>=20 >>>>>> So, I would suggest to decide what type of identifier goes into = this field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? >>>>>>=20 >>>>>> Ciao >>>>>> Hannes >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From torsten@lodderstedt.net Sun Jan 13 09:28:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1721F8831 for ; Sun, 13 Jan 2013 09:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jJ6TqfRK1tQ for ; Sun, 13 Jan 2013 09:28:39 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69821F8824 for ; Sun, 13 Jan 2013 09:28:38 -0800 (PST) Received: from [91.2.72.109] (helo=[192.168.71.56]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TuRMK-000466-Ga; Sun, 13 Jan 2013 18:28:36 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-81816973-F430-4076-850A-D581F11E34A8 Content-Transfer-Encoding: 7bit Message-Id: <5FEB27AF-72A4-469A-9687-6218F5475F56@lodderstedt.net> X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Sun, 13 Jan 2013 18:28:36 +0100 To: "Boone, Keith W (GE Healthcare)" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:28:40 -0000 --Apple-Mail-81816973-F430-4076-850A-D581F11E34A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Keith, comment see below. Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" : > > =20 > Imagine the case where I purchase an application and download it to my iPh= one and to my iPad. Then I connect that application to a data holder/author= izer combination it hasn't seen before. Through dynamic client registration= , I could register that application for my iPhone, but the instance of that s= ame application running on my iPad would know nothing about the first regist= ration. So it would attempt to do it all over again. What happens here? Is this a problem? The user should be able the data she desires from both ap= p, independent of the client id. What do your want to achieve? I don't understand why different instances of a= n app need to be aware of each other. I would assume a user wants to access t= he same data from all those instances. But this is merely controlled by the u= ser identity with the app. I see two possible scenarios: a) the app does not have an user management but relies on the user to setup t= he connection to a particular resource server. The user would do this on eve= ry device, i.e. every app instance would carry out the OAuth dance with the p= articular authorizer. b) the app has their own user management. So the user would 1) register for a= n account and 2) connect this account to the resources managed by the author= izer. Assumption: the app has an backend and stores user data there. On the s= econd device, the user has only to login using her app account and is done. Regards, Torsten. > =20 > Keith > _________________________________ > Keith W. Boone > Standards Architect > GE Healthcare >=20 > M +1 617 640 7007 > keith.boone@ge.com > www.gehealthcare.com >=20 > 116 Huntington Ave > Boston, MA 02116 > USA > GE imagination at work > =20 > From: Richer, Justin P. [mailto:jricher@mitre.org]=20 > Sent: Thursday, January 10, 2013 4:39 PM > To: Boone, Keith W (GE Healthcare) > Cc: oauth@ietf.org WG > Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg > =20 > Interesting use case, and not dissimilar to some others I've heard. How wo= uld you go about tracking this? Why would the instances need to know about e= ach other? > =20 > One possible approach would be to use a common initializing Request Access= Token that is used to call client_register on all instances of a given clie= nt. They wouldn't know about each other, per se, but the Authorization Serve= r would at least know enough to be able to tie them together. > =20 > There's also the OAuth2 Instance Information extension that I had tried to= push a few years ago that comes up every now and again, that might be of us= e here with some modifications: > =20 > http://tools.ietf.org/html/draft-richer-oauth-instance-00 > =20 > I think I'd like to know more about your concerns and the parameters of yo= ur use case first.=20 > =20 > I am CC'ing the IETF OAuth Working Group email list, where this draft is b= eing discussed and worked on. > =20 > -- Justin > =20 > On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" wrote: >=20 >=20 > I would like to be able to use this protocol to dynamically register clien= ts, but am challenged by the fact that there could be multiple instances of a= public client, each unaware of what others have done. The current protocol= doesn't seem to address this. >=20 > Keith > _________________________________ > Keith W. Boone > Standards Architect > GE Healthcare >=20 > M +1 617 640 7007 > keith.boone@ge.com > www.gehealthcare.com >=20 > 116 Huntington Ave > Boston, MA 02116 > USA > GE imagination at work > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-81816973-F430-4076-850A-D581F11E34A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Keith,

com= ment see below.

Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE He= althcare)" <keith.boone@ge.com&= gt;:

=

<snip>

 

Imagine the case where I purc= hase an application and download it to my iPhone and to my iPad.  Then I= connect that application to a data holder/authorizer combination it hasn't seen before.  Through dynamic client registration, I could r= egister that application for my iPhone, but the instance of that same applic= ation running on my iPad would know nothing about the first registration.&nb= sp; So it would attempt to do it all over again.  What happens here?


Is this a problem? The user should be able the data she desires from both a= pp, independent of the client id.

What do your want t= o achieve? I don't understand why different instances of an app need to be a= ware of each other. I would assume a user wants to access the same data from= all those instances. But this is merely controlled by the user identity wit= h the app.

I see two possible scenarios:
=
a) the app does not have an user management but relies on the= user to setup the connection to a particular resource server. The user woul= d do this on every device, i.e. every app instance would carry out the OAuth= dance with the particular authorizer.

b) the app h= as their own user management. So the user would 1) register for an account a= nd 2) connect this account to the resources managed by the authorizer. Assum= ption: the app has an backend and stores user data there. On the second devi= ce, the user has only to login using her app account and is done.
=
Regards,
Torsten.

 

     = ;       Keith

_________________________________
Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.com<= /span>

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

 

From: Richer, Jus= tin P. [mailto:jricher@mitre.org]
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: oauth@ietf.org WG
Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg

 

Interesting use case, and not dissimilar to some othe= rs I've heard. How would you go about tracking this? Why would the instances= need to know about each other?

 

One possible approach would be to use a common initia= lizing Request Access Token that is used to call client_register on all inst= ances of a given client. They wouldn't know about each other, per se, but th= e Authorization Server would at least know enough to be able to tie them together.

 

There's also the OAuth2 Instance Information extensio= n that I had tried to push a few years ago that comes up every now and again= , that might be of use here with some modifications:

 

 

I think I'd like to know more about your concerns and= the parameters of your use case first. 

 

I am CC'ing the IETF OAuth Working Group email list, w= here this draft is being discussed and worked on.

 

 -- Justin

 



I would like to be able to use this protoco= l to dynamically register clients, but am challenged by the fact that there c= ould be multiple instances of a public client, each unaware of what others have done.  The current protocol doesn't seem t= o address this.


            Keith

_________________________________
= Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

 

 

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth
= --Apple-Mail-81816973-F430-4076-850A-D581F11E34A8-- From keith.boone@ge.com Sun Jan 13 18:44:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4786521F8658 for ; Sun, 13 Jan 2013 18:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgLUhTaOoOA8 for ; Sun, 13 Jan 2013 18:44:20 -0800 (PST) Received: from exprod5og101.obsmtp.com (exprod5og101.obsmtp.com [64.18.0.141]) by ietfa.amsl.com (Postfix) with ESMTP id 70E4421F8574 for ; Sun, 13 Jan 2013 18:44:19 -0800 (PST) Received: from cinmlip10.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob101.postini.com ([64.18.4.12]) with SMTP ID DSNKUPNxAvkvUloMC1f9/JHMe7TFnVTz2ahS@postini.com; Sun, 13 Jan 2013 18:44:19 PST Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip10.e2k.ad.ge.com with ESMTP; 13 Jan 2013 21:44:16 -0500 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Jan 2013 21:44:15 -0500 Received: from CINURCNA01.e2k.ad.ge.com (3.159.212.102) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 13 Jan 2013 21:44:15 -0500 Received: from CINURCNA03.e2k.ad.ge.com ([169.254.3.149]) by CINURCNA01.e2k.ad.ge.com ([169.254.1.231]) with mapi id 14.02.0309.002; Sun, 13 Jan 2013 21:44:15 -0500 From: "Boone, Keith W (GE Healthcare)" To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMAAApcswAAg8XaAAAF/0zA Date: Mon, 14 Jan 2013 02:44:14 +0000 Message-ID: References: <5FEB27AF-72A4-469A-9687-6218F5475F56@lodderstedt.net> In-Reply-To: <5FEB27AF-72A4-469A-9687-6218F5475F56@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.188] Content-Type: multipart/alternative; boundary="_000_C41EE4B7616F774CBF466291DC59746F0BD925CINURCNA03e2kadge_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2013 02:44:15.0556 (UTC) FILETIME=[0AE94040:01CDF201] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 02:44:22 -0000 --_000_C41EE4B7616F774CBF466291DC59746F0BD925CINURCNA03e2kadge_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW9yZSB3YWxscyBvZiB0ZXh0IGFzIG15IHVuZGVyc3RhbmRpbmcgZ3Jvd3M6DQoNCkkndmUgcmV2 aXNlZCBteSB1bmRlcnN0YW5kaW5nIGEgYml0IHNpbmNlIG15IGZpcnN0IHBvc3RpbmcuICBMZXQg bWUgc2VlIGlmIEkgY2FuIGV4cGxhaW4gYSBsaXR0bGUgbW9yZSBjbGVhcmx5Og0KDQoNCjEuICAg ICBXZSdkIGxpa2UgdG8gaGF2ZSBzb21lIHdheSBmb3IgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMg dG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGJhc2VkIG9uIHBvbGljaWVzIGFib3V0 IGFuIGFwcGxpY2F0aW9uLg0KVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZWVtZWQgZXNzZW50 aWFsIGZvciB0aGVzZSBhcHBsaWNhdGlvbnMgc2luY2UgdGhleSB3aWxsIGJlIGFjY2Vzc2luZyBw cm90ZWN0ZWQgaGVhbHRoIGluZm9ybWF0aW9uIGZyb20gZW50aXRpZXMgY292ZXJlZCB1bmRlciBv ciBhc3NvY2lhdGVkIHdpdGggZW50aXRpZXMgY292ZXJlZCB1bmRlciBISVBBQS4NCkluIG15IGlu aXRpYWwgdGhpbmtpbmcsIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgd291bGQgaWRlbnRpZnkgdGhl IGFwcGxpY2F0aW9uIHNvIHRoYXQgcG9saWN5IGNoZWNraW5nIHdvdWxkIGJlIGVuYWJsZWQgYnkg dGhlIGRhdGEgaG9sZGVyLiAgQnV0IHRoZSBjbGllbnRfbmFtZSBhbmQvb3IgY2xpZW50X3VybCBj b3VsZCBhbHNvIGJlIHVzZWQgYnkgdGhlIGF1dGhvcml6ZXIuDQpQb2xpY2llcyBtaWdodCBzYXkg c29tZXRoaW5nIGxpa2U6IEFwcGxpY2F0aW9uIFhZWiBoYXMgYmVlbiBjZXJ0aWZpZWQgYnkgb3Jn YW5pemF0aW9uIEFCQyB0byBiZSBjb21wbGlhbnQgd2l0aCBwb2xpY3kgMTIzLCBhbmQgc2hvdWxk IGJlIGdyYW50ZWQgYWNjZXNzLiAgT3IsIEFwcGxpY2F0aW9uIFhZWiBpcyBrbm93biB0byBiZSBh IFRyb2phbiBhbmQgc2hvdWxkIG5vdCBiZSBncmFudGVkIGFjY2Vzcy4gIE9yIEFwcGxpY2F0aW9u IFhZWiBpcyBrbm93biB0byBiZSBzdXNjZXB0aWJsZSB0byB2aXJ1cyBRUlMgYW5kIHNob3VsZCBu byBsb25nZXIgYmUgZ3JhbnRlZCBhY2Nlc3MuIEhvdyB0aGVzZSBwb2xpY2llcyBhcmUgZGlzdHJp YnV0ZWQgdG8gYXV0aG9yaXplcnMgaXNuJ3QgcGFydCBvZiB0aGlzIGRpc2N1c3Npb24uICBBY2Nl c3MgdG9rZW5zIGlzc3VlZCBieSBhdXRob3JpemVycyBjb3VsZCBiZSBzdWZmaWNpZW50bHkgc2hv cnQtbGl2ZWQgdGhhdCByb3V0aW5lIHJlZnJlc2hlcyB3b3VsZCBiZSBuZWNlc3NhcnksIGFsbG93 aW5nIHBvbGljeSBjaGVja3MgdG8gYmUgcGVyZm9ybWVkIGFzIGZyZXF1ZW50bHkgYXMgbmVjZXNz YXJ5Lg0KDQoNCjIuICAgICBXZSdkIGxpa2UgdG8gZmFjaWxpdGF0ZSBhbiBhdXRvbWF0ZWQgcHJv Y2VzcyB3aGVyZWJ5IGFwcGxpY2F0aW9uIGNhbiBiZSBkeW5hbWljYWxseSByZWdpc3RlcmVkIHdp dGhvdXQgcmVxdWlyaW5nIGEgbG90IG9mIGluZnJhc3RydWN0dXJlLg0KDQpJIHRoaW5rIHRoZXJl IGFyZSB0aHJlZSBhY3RvcnMgaW4gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgSSdsbCBjYWxs IHRoZW0gdGhlIHJlZ2lzdHJhciwgdGhlIGFwcGxpY2F0aW9uIGluc3RhbmNlLCBhbmQgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQuICBUaGUgcmVnaXN0cmFyIGlzIGEgY29uZmlkZW50aWFsIGNs aWVudC4gIEl0IHNlcnZlcyB0aHJlZSBmdW5jdGlvbnM6DQoNCg0KMS4gICAgIEl0ICJyZWdpc3Rl cnMiIGFwcGxpY2F0aW9uIGluc3RhbmNlcyAob3RoZXJzIGhhdmUgcmVmZXJyZWQgdG8gdGhpcyBh cyB0aGUgYXBwbGljYXRpb24pIHdpdGggaXRzZWxmLCBhbmQgY29uZmlndXJlcyB0aG9zZSBhcHBs aWNhdGlvbiBpbnN0YW5jZXMgc28gdGhhdCB0aGV5IGNhbiBjb21tdW5pY2F0ZSB3aXRoIGl0IHNl Y3VyZWx5IGluIHRoZSBmdXR1cmUuDQoNCjIuICAgICBJdCByZWdpc3RlcnMgYW4gYXBwbGljYXRp b24gKG90aGVycyBoYXZlIGNhbGxlZCB0aGlzIGFuIGFwcGxpY2F0aW9uIGNsYXNzKSB3aXRoIGFu IGF1dGhvcml6ZXIuDQoNCjMuICAgICBJdCBmYWNpbGl0YXRlcyBjb21tdW5pY2F0aW9uIGJldHdl ZW4gYW4gYXBwbGljYXRpb24gaW5zdGFuY2UgYW5kIHRoZSBhdXRob3JpemVyIGJ5IG9idGFpbmlu ZyBhdXRob3JpemF0aW9uIHRva2VucyB3aGljaCBhcmUgdGhlbiBjb21tdW5pY2F0ZWQgdG8gdGhl IGFwcGxpY2F0aW9uIGluc3RhbmNlIHRvIHJlZ2lzdGVyIGl0c2VsZiB3aXRoIHRoZSBhdXRob3Jp emVyLg0KDQpUaGUgcmVnaXN0cmFyICJyZWdpc3RlcnMiIHRoZSBhcHBsaWNhdGlvbiAoY2xhc3Mp IGR1cmluZyB0aGUgZmlyc3QgcmVnaXN0cmF0aW9uICh0aHVzLCBub3QgbmVlZGluZyBhbiBhY2Nl c3NfdG9rZW4pLCBhbmQgc2luY2UgaXQgaXMgYSBjb25maWRlbnRpYWwgY2xpZW50LCBjYW4gc2Vj dXJlIGl0cyBjbGllbnRfaWQgYW5kIGNsaWVudF9zZWNyZXQuICBUaGlzIHJlZ2lzdHJhdGlvbiBp cyBzY29wZWQgdG8gb25seSBzdXBwb3J0IGZhY2lsaXRhdGluZyB0aGUgaW5pdGlhbCBhdXRob3Jp emF0aW9uIG9mIGFuIGFwcGxpY2F0aW9uIGluc3RhbmNlICh1c2luZyB0aGUgc2NvcGUgcGFyYW1l dGVyKS4NCg0KQW4gYXBwbGljYXRpb24gaW5zdGFuY2UgbXVzdCBjb25maWd1cmUgaXRzZWxmIChw b3N0IGRlcGxveW1lbnQpIGJ5IGNvbW11bmljYXRpbmcgd2l0aCB0aGUgcmVnaXN0cmFyLiAgVGhp cyB3aWxsIGFsbG93IHRoZSBhcHBsaWNhdGlvbiBpbnN0YW5jZSBhbmQgdGhlIHJlZ2lzdHJhciB0 byBzZWN1cmUgdGhlaXIgY29tbXVuaWNhdGlvbnMgaW4gZnV0dXJlIGNvbnZlcnNhdGlvbnMuICBI b3cgdGhleSBkbyB0aGF0IGlzIG91dCBvZiBzY29wZS4gIEFuIGFwcGxpY2F0aW9uIHdpbGwgYmUg Y29uZmlndXJlZCAocHJlLWRlcGxveW1lbnQpIHRvIGNvbW11bmljYXRlIHdpdGggYSBzcGVjaWZp YyByZWdpc3RyYXIuDQoNCldoZW4gYW4gYXBwbGljYXRpb24gaW5zdGFuY2Ugd2lzaGVzIHRvIGJl IHJlZ2lzdGVyZWQgd2l0aCBhbiBhdXRob3JpemVyIHRoYXQgaXQgaGFzbid0IHNlZW4gYmVmb3Jl IGl0IHBlcmZvcm1zIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQoNCjEuICAgICBJdCByZXF1ZXN0cyBh biBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgcmVnaXN0cmFyIGZvciB0aGUgYXV0aG9yaXplci4gIFRo ZSByZWdpc3RyYXIgd2lsbCwgaWYgaXQgaGFzbid0IGFscmVhZHksIHJlZ2lzdGVyIHRoZSBhcHBs aWNhdGlvbiB3aXRoIHRoZSBhdXRob3JpemVyLiAgSXQgd2lsbCB0aGVuIHVzZSBpdHMgY2xpZW50 X2lkIGFuZCBjbGllbnRfc2VjcmV0IHdpdGggdGhlIGF1dGhvcml6ZXIgdG8gb2J0YWluIGFuIGFj Y2VzcyB0b2tlbiBmb3IgdGhlIGluc3RhbmNlIG5lZWRpbmcgcmVnaXN0cmF0aW9uLiAgVGhlc2Ug d2lsbCBiZSByZXR1cm5lZCB0byB0aGUgYXBwbGljYXRpb24gaW5zdGFuY2UuDQoNCjIuICAgICBJ dCB1c2VzIHRoYXQgYWNjZXNzIHRva2VuIHdpdGggdGhlIGF1dGhvcml6ZXIgdG8gcmVnaXN0ZXIg aXRzZWxmLg0KDQpXaGF0IEkndmUgZG9uZSBoZXJlIGlzIGVzc2VudGlhbCBzcGxpdCB0aGUgY2xp ZW50IGludG8gdHdvIGNvbXBvbmVudHM6ICBBIGNvbmZpZGVudGlhbCByZWdpc3RyYXIgY29tcG9u ZW50LCBhbmQgYSAocG9zc2libHkgcHVibGljKSBhcHBsaWNhdGlvbiBpbnN0YW5jZSBjb21wb25l bnQuICBUaGUgcmVnaXN0cmFyIG9ubHkgY29tbXVuaWNhdGVzIHdpdGggYXV0aG9yaXplcnMgYW5k IGFwcGxpY2F0aW9uIGluc3RhbmNlcy4gIEl0IG5ldmVyIGFjdHVhbGx5IGRvZXMgYW55IHdvcmsg d2l0aCBkYXRhIGhvbGRlcnMuDQoNClRoaXMgc2VlbXMgbGlrZSBpdCB3b3VsZCB3b3JrIGZvciBt eSB1c2UgY2FzZSwgYnV0IHN0aWxsIGZlZWxzIG92ZXJseSBjdW1iZXJzb21lLiBJbiBvcmRlciB0 byBhY2Nlc3MgZGF0YSwgYW4gYXBwbGljYXRpb24gaW5zdGFuY2U6DQoNCjEuICAgICBIYXMgdG8g YmUgcHJlLWNvbmZpZ3VyZWQgd2l0aCBhIHJlZ2lzdHJhci4NCg0KMi4gICAgIEhhcyB0byBiZSBw b3N0LWNvbmZpZ3VyZWQgYnkgdGhhdCByZWdpc3RyYXIuDQoNCjMuICAgICBUaGUgcmVnaXN0cmFy IGhhcyB0byByZWdpc3RlciB0aGUgYXBwbGljYXRpb24gd2l0aCBhbiBhdXRob3JpemF0aW9uIGVu ZHBvaW50Lg0KDQo0LiAgICAgVGhlIHJlZ2lzdHJhciBoYXMgdG8gb2J0YWluIGFuIGFjY2VzcyB0 b2tlbiBmcm9tIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb24gYmVoYWxmIG9mIGFuIGFwcGxp Y2F0aW9uIGluc3RhbmNlDQoNCjUuICAgICBUaGUgcmVnaXN0cmFyIGhhcyB0byBjb21tdW5pY2F0 ZSB0aGF0IGFjY2VzcyB0b2tlbiB0byB0aGUgYXBwbGljYXRpb24gaW5zdGFuY2UuDQoNCjYuICAg ICBUaGUgYXBwbGljYXRpb24gaW5zdGFuY2UgaGFzIHRvIHJlZ2lzdGVyIGl0c2VsZiB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50Lg0KDQo3LiAgICAgVGhlIGRhdGEgaG9sZGVyIGhhcyB0 byBhdXRob3JpemUgdGhlIGVuZCB1c2VyIGFuZCB0aGUgYXBwbGljYXRpb24gaW5zdGFuY2UgdG8g YWNjZXNzIHRoZSBkYXRhLg0KDQpUbyBtYWtlIG15c2VsZiBmZWVsIGJldHRlciwgSSBsb29rZWQg YXQgZWFjaCBvZiB0aGVzZSBzdGVwczoNCg0KMS4gICAgIFRoaXMgcHJlLWNvbmZpZ3VyYXRpb24g aXMgbm90IGhhcmQuDQoNCjIuICAgICBSZWdpc3RlcmluZyBhbiBpbnN0YWxsZWQgYXBwbGljYXRp b24gd2l0aCB0aGUgZGV2ZWxvcGVyIG9mIHRoYXQgYXBwbGljYXRpb24gaXMgYSBwcmV0dHkgY29t bW9uIGZlYXR1cmUgKGluIHRoZSBQQyB3b3JsZCwgbm90IGFzIG11Y2ggaW4gdGhlIG1vYmlsZSBh cHAgd29ybGQpLiAgVGhhdCBjYW4gYmUgY29tYmluZWQgd2l0aCB0aGUgcG9zdC1jb25maWd1cmF0 aW9uIHN0ZXAgdGhhdCBlbmFibGVzIHNlY3VyZSBjb21tdW5pY2F0aW9uIHdpdGggdGhlIHJlZ2lz dHJhci4gIFRoaXMgY291bGQgZXZlbiBiZSBzaW1pbGFyIHRvIHRoZSBkeW5hbWljIHJlZ2lzdHJh dGlvbiB3b3JrZmxvdywgc2F2ZSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBpbnN0YW5jZSBpcyBkeW5h bWljYWxseSByZWdpc3RlcmluZyBpdHNlbGYgd2l0aCB0aGUgcmVnaXN0cmFyLg0KDQozLiAgICAg VGhpcyBpcyB2ZXJ5IHNpbWlsYXIgdG8gc3RlcCA2LCBhbmQgbWlnaHQgb2Z0ZW4gYmUgY29kZWQg YnkgdGhlIHNhbWUgZGV2ZWxvcGVycywgb3IgdXNlIHRoZSBzYW1lIGxpYnJhcmllcy4NCg0KNC4g ICAgIFRoaXMgaXMgc3RhbmRhcmQgT0F1dGggc3R1ZmYuDQoNCjUuICAgICBUaGlzIGNvdWxkIGJl IGRvbmUgdXNpbmcgc3RhbmRhcmQgT0F1dGggc3R1ZmYuICBJbiBmYWN0LCBzdGVwIDIgY291bGQg aW4gZmFjdCBiZSBhbiBPQXV0aCB3b3JrZmxvdywgd2hlcmUgYW4gYXBwbGljYXRpb24gaW5zdGFu Y2UgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHJlZ2lzdHJhciwgd2hpY2ggdGhl biByZXJvdXRlcyB0aGF0IHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIHVz aW5nIGl0cyBvd24gY3JlZGVudGlhbHMuDQoNCjYuICAgICBUaGlzIGlzIHRoZSBiYXNpYyBkeW5h bWljIHJlZ2lzdHJhdGlvbi4NCg0KVGhlIHJlZ2lzdHJhciBzZWVtcyB0byBiZSBhIHNpbXBsZSBl bm91Z2ggd2ViIHNlcnZpY2UgdGhhdCB3b3VsZG4ndCB0YWtlIGEgbG90IG9mIGluZnJhc3RydWN0 dXJlIHRvIGRldmVsb3Agb3IgbWFpbnRhaW4uICBBdCBhIGJhcmUgbWluaW11bSwgaXQgbmVlZHMg dG8gc3RvcmUgaXRzIGNsaWVudCBjcmVkZW50aWFscyBmb3IgcmVnaXN0cmF0aW9ucyB3aXRoIGRp ZmZlcmVudCBhdXRob3JpemVycywgYW5kIGV4ZWN1dGUgdHdvIGRpZmZlcmVudCBPQXV0aCB3b3Jr Zmxvd3M6ICBSZWdpc3RlcmluZyBhbiBhcHBsaWNhdGlvbiAoY2xhc3MpIHdpdGggYW4gYXV0aG9y aXplciwgYW5kIG9idGFpbmluZyBhbiBhdXRob3JpemF0aW9uIHRva2VuIGZyb20gYW4gYXV0aG9y aXphdGlvbiBhbmQgY29tbXVuaWNhdGluZyB0aGF0IHRva2VuIHRvIGFuIGFwcGxpY2F0aW9uIGlu c3RhbmNlLiAgQSBzaW5nbGUgcmVnaXN0cmFyIHNlcnZpY2UgY291bGQgYmUgcHJvdmlkZWQgdGhh dCBzdXBwb3J0cyBtdWx0aXBsZSBhcHBsaWNhdGlvbnMsIHBlcmhhcHMgY29tYmluaW5nIHdpdGgg b3RoZXIgc2VydmljZXMgKHN1Y2ggYXMgYW4gYXBwIHN0b3JlKS4gIElmIHVzaW5nIG90aGVyIE9B dXRoIHdvcmtmbG93cy4NCg0KSSB0aG91Z2h0IGFib3V0IGhhdmluZyB0aGUgcmVnaXN0cmFyIGRv IGEgY291cGxlIG9mIG90aGVyIHRoaW5ncyB0byBzaW1wbGlmeSwgYnV0IHRoZXkganVzdCBkaWRu J3Qgc2VlbSB0byB3b3JrOg0KDQoxLiAgICAgSXQgY291bGQganVzdCBjb25maWd1cmUgdGhlIGFw cGxpY2F0aW9uIHdpdGggdGhlIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCB0aGF0IHdlcmUg aXNzdWVkIGR1cmluZyB0aGUgImZpcnN0IiByZWdpc3RyYXRpb24uICBFdmVuIHRob3VnaCB0aGVz ZSBjb3VsZCBiZSBzZWN1cmVkIGR1cmluZyB0aGF0IHBvc3QtaW5zdGFsbGF0aW9uIHJlZ2lzdHJh dGlvbiBzdGVwLCBoYXZpbmcgZWFjaCBjbGllbnQgaW5zdGFuY2Ugc2hhcmUgYW4gaWQgYW5kIHNl Y3JldCBkaWRuJ3QgZmVlbCBzZWN1cmUuICBTb21lb25lIHdpbGwgbWVzcyBpdCB1cCBhbmQgdGhh dCBpZCBhbmQgc2VjcmV0IGNvdWxkIHRoZW4gYmUgdXNlZCBhcyBhbiBhdHRhY2sgdmVjdG9yLg0K DQoyLiAgICAgVGhlIHJlZ2lzdHJhciBjb3VsZCBwZXJmb3JtIHRoZSByZWdpc3RyYXRpb24gZm9y IHRoZSBjbGllbnQsIGFuZCByZXR1cm4gdGhlIGNsaWVudF9pZCBhbmQgc2VjcmV0IGl0IG9idGFp bmVkIG9uIGJlaGFsZiBvZiB0aGUgY2xpZW50LCBidXQgdGhlIHJlZ2lzdHJhciBhbmQgdGhlIGFw cGxpY2F0aW9uIG5lZWQgbm90IGJlIGNyZWF0ZWQgYnkgdGhlIHNhbWUgb3JnYW5pemF0aW9ucywg YW5kIHRoZSByZWdpc3RyYXIgd291bGQgdGhlbiBoYXZlIGFjY2VzcyB0byBhbiBpZCBhbmQgc2Vj cmV0IHRoYXQgaXQgZGlkbid0IG5lZWQgdG8gaGF2ZSBhY2Nlc3MgdG8uDQoNCkFtIEkgb3ZlcnRo aW5raW5nIHRoaXMsIG9yIGlzIHRoaXMgcmlnaHQ/DQoNCiAgICAgICAgICAgIEtlaXRoDQoNCkZy b206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0N ClNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxMjoyOSBQTQ0KVG86IEJvb25lLCBLZWl0 aCBXIChHRSBIZWFsdGhjYXJlKQ0KQ2M6IFJpY2hlciwgSnVzdGluIFAuOyBvYXV0aEBpZXRmLm9y ZyBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1v YXV0aC1keW4tcmVnDQoNCkhpIEtlaXRoLA0KDQpjb21tZW50IHNlZSBiZWxvdy4NCg0KQW0gMTAu MDEuMjAxMyB1bSAyMjo1NCBzY2hyaWViICJCb29uZSwgS2VpdGggVyAoR0UgSGVhbHRoY2FyZSki IDxrZWl0aC5ib29uZUBnZS5jb208bWFpbHRvOmtlaXRoLmJvb25lQGdlLmNvbT4+Og0KPHNuaXA+ DQoNCkltYWdpbmUgdGhlIGNhc2Ugd2hlcmUgSSBwdXJjaGFzZSBhbiBhcHBsaWNhdGlvbiBhbmQg ZG93bmxvYWQgaXQgdG8gbXkgaVBob25lIGFuZCB0byBteSBpUGFkLiAgVGhlbiBJIGNvbm5lY3Qg dGhhdCBhcHBsaWNhdGlvbiB0byBhIGRhdGEgaG9sZGVyL2F1dGhvcml6ZXIgY29tYmluYXRpb24g aXQgaGFzbid0IHNlZW4gYmVmb3JlLiAgVGhyb3VnaCBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRp b24sIEkgY291bGQgcmVnaXN0ZXIgdGhhdCBhcHBsaWNhdGlvbiBmb3IgbXkgaVBob25lLCBidXQg dGhlIGluc3RhbmNlIG9mIHRoYXQgc2FtZSBhcHBsaWNhdGlvbiBydW5uaW5nIG9uIG15IGlQYWQg d291bGQga25vdyBub3RoaW5nIGFib3V0IHRoZSBmaXJzdCByZWdpc3RyYXRpb24uICBTbyBpdCB3 b3VsZCBhdHRlbXB0IHRvIGRvIGl0IGFsbCBvdmVyIGFnYWluLiAgV2hhdCBoYXBwZW5zIGhlcmU/ DQoNCklzIHRoaXMgYSBwcm9ibGVtPyBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0aGUgZGF0YSBz aGUgZGVzaXJlcyBmcm9tIGJvdGggYXBwLCBpbmRlcGVuZGVudCBvZiB0aGUgY2xpZW50IGlkLg0K DQpXaGF0IGRvIHlvdXIgd2FudCB0byBhY2hpZXZlPyBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IGRp ZmZlcmVudCBpbnN0YW5jZXMgb2YgYW4gYXBwIG5lZWQgdG8gYmUgYXdhcmUgb2YgZWFjaCBvdGhl ci4gSSB3b3VsZCBhc3N1bWUgYSB1c2VyIHdhbnRzIHRvIGFjY2VzcyB0aGUgc2FtZSBkYXRhIGZy b20gYWxsIHRob3NlIGluc3RhbmNlcy4gQnV0IHRoaXMgaXMgbWVyZWx5IGNvbnRyb2xsZWQgYnkg dGhlIHVzZXIgaWRlbnRpdHkgd2l0aCB0aGUgYXBwLg0KDQpJIHNlZSB0d28gcG9zc2libGUgc2Nl bmFyaW9zOg0KDQphKSB0aGUgYXBwIGRvZXMgbm90IGhhdmUgYW4gdXNlciBtYW5hZ2VtZW50IGJ1 dCByZWxpZXMgb24gdGhlIHVzZXIgdG8gc2V0dXAgdGhlIGNvbm5lY3Rpb24gdG8gYSBwYXJ0aWN1 bGFyIHJlc291cmNlIHNlcnZlci4gVGhlIHVzZXIgd291bGQgZG8gdGhpcyBvbiBldmVyeSBkZXZp Y2UsIGkuZS4gZXZlcnkgYXBwIGluc3RhbmNlIHdvdWxkIGNhcnJ5IG91dCB0aGUgT0F1dGggZGFu Y2Ugd2l0aCB0aGUgcGFydGljdWxhciBhdXRob3JpemVyLg0KDQpiKSB0aGUgYXBwIGhhcyB0aGVp ciBvd24gdXNlciBtYW5hZ2VtZW50LiBTbyB0aGUgdXNlciB3b3VsZCAxKSByZWdpc3RlciBmb3Ig YW4gYWNjb3VudCBhbmQgMikgY29ubmVjdCB0aGlzIGFjY291bnQgdG8gdGhlIHJlc291cmNlcyBt YW5hZ2VkIGJ5IHRoZSBhdXRob3JpemVyLiBBc3N1bXB0aW9uOiB0aGUgYXBwIGhhcyBhbiBiYWNr ZW5kIGFuZCBzdG9yZXMgdXNlciBkYXRhIHRoZXJlLiBPbiB0aGUgc2Vjb25kIGRldmljZSwgdGhl IHVzZXIgaGFzIG9ubHkgdG8gbG9naW4gdXNpbmcgaGVyIGFwcCBhY2NvdW50IGFuZCBpcyBkb25l Lg0KDQpSZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQoNCiAgICAgICAgICAgIEtlaXRoDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCktlaXRoIFcuIEJvb25lDQpTdGFuZGFyZHMgQXJj aGl0ZWN0DQpHRSBIZWFsdGhjYXJlDQoNCk0gKzEgNjE3IDY0MCA3MDA3DQprZWl0aC5ib29uZUBn ZS5jb208bWFpbHRvOmtlaXRoLmJvb25lQGdlLmNvbT4NCnd3dy5nZWhlYWx0aGNhcmUuY29tPGh0 dHA6Ly93d3cuZ2VoZWFsdGhjYXJlLmNvbS8+DQoNCjExNiBIdW50aW5ndG9uIEF2ZQ0KQm9zdG9u LCBNQSAwMjExNg0KVVNBDQpHRSBpbWFnaW5hdGlvbiBhdCB3b3JrDQoNCkZyb206IFJpY2hlciwg SnVzdGluIFAuIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmddDQpTZW50OiBUaHVyc2RheSwgSmFu dWFyeSAxMCwgMjAxMyA0OjM5IFBNDQpUbzogQm9vbmUsIEtlaXRoIFcgKEdFIEhlYWx0aGNhcmUp DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRw0KU3ViamVjdDog UmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZw0KDQpJbnRlcmVzdGlu ZyB1c2UgY2FzZSwgYW5kIG5vdCBkaXNzaW1pbGFyIHRvIHNvbWUgb3RoZXJzIEkndmUgaGVhcmQu IEhvdyB3b3VsZCB5b3UgZ28gYWJvdXQgdHJhY2tpbmcgdGhpcz8gV2h5IHdvdWxkIHRoZSBpbnN0 YW5jZXMgbmVlZCB0byBrbm93IGFib3V0IGVhY2ggb3RoZXI/DQoNCk9uZSBwb3NzaWJsZSBhcHBy b2FjaCB3b3VsZCBiZSB0byB1c2UgYSBjb21tb24gaW5pdGlhbGl6aW5nIFJlcXVlc3QgQWNjZXNz IFRva2VuIHRoYXQgaXMgdXNlZCB0byBjYWxsIGNsaWVudF9yZWdpc3RlciBvbiBhbGwgaW5zdGFu Y2VzIG9mIGEgZ2l2ZW4gY2xpZW50LiBUaGV5IHdvdWxkbid0IGtub3cgYWJvdXQgZWFjaCBvdGhl ciwgcGVyIHNlLCBidXQgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHdvdWxkIGF0IGxlYXN0IGtu b3cgZW5vdWdoIHRvIGJlIGFibGUgdG8gdGllIHRoZW0gdG9nZXRoZXIuDQoNClRoZXJlJ3MgYWxz byB0aGUgT0F1dGgyIEluc3RhbmNlIEluZm9ybWF0aW9uIGV4dGVuc2lvbiB0aGF0IEkgaGFkIHRy aWVkIHRvIHB1c2ggYSBmZXcgeWVhcnMgYWdvIHRoYXQgY29tZXMgdXAgZXZlcnkgbm93IGFuZCBh Z2FpbiwgdGhhdCBtaWdodCBiZSBvZiB1c2UgaGVyZSB3aXRoIHNvbWUgbW9kaWZpY2F0aW9uczoN Cg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWluc3RhbmNl LTAwDQoNCkkgdGhpbmsgSSdkIGxpa2UgdG8ga25vdyBtb3JlIGFib3V0IHlvdXIgY29uY2VybnMg YW5kIHRoZSBwYXJhbWV0ZXJzIG9mIHlvdXIgdXNlIGNhc2UgZmlyc3QuDQoNCkkgYW0gQ0MnaW5n IHRoZSBJRVRGIE9BdXRoIFdvcmtpbmcgR3JvdXAgZW1haWwgbGlzdCwgd2hlcmUgdGhpcyBkcmFm dCBpcyBiZWluZyBkaXNjdXNzZWQgYW5kIHdvcmtlZCBvbi4NCg0KIC0tIEp1c3Rpbg0KDQpPbiBK YW4gMTAsIDIwMTMsIGF0IDQ6MjQgUE0sICJCb29uZSwgS2VpdGggVyAoR0UgSGVhbHRoY2FyZSki IDxrZWl0aC5ib29uZUBnZS5jb208bWFpbHRvOmtlaXRoLmJvb25lQGdlLmNvbT4+IHdyb3RlOg0K DQoNCg0KSSB3b3VsZCBsaWtlIHRvIGJlIGFibGUgdG8gdXNlIHRoaXMgcHJvdG9jb2wgdG8gZHlu YW1pY2FsbHkgcmVnaXN0ZXIgY2xpZW50cywgYnV0IGFtIGNoYWxsZW5nZWQgYnkgdGhlIGZhY3Qg dGhhdCB0aGVyZSBjb3VsZCBiZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgYSBwdWJsaWMgY2xpZW50 LCBlYWNoIHVuYXdhcmUgb2Ygd2hhdCBvdGhlcnMgaGF2ZSBkb25lLiAgVGhlIGN1cnJlbnQgcHJv dG9jb2wgZG9lc24ndCBzZWVtIHRvIGFkZHJlc3MgdGhpcy4NCg0KICAgICAgICAgICAgS2VpdGgN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KS2VpdGggVy4gQm9vbmUNClN0YW5k YXJkcyBBcmNoaXRlY3QNCkdFIEhlYWx0aGNhcmUNCg0KTSArMSA2MTcgNjQwIDcwMDcNCmtlaXRo LmJvb25lQGdlLmNvbTxtYWlsdG86a2VpdGguYm9vbmVAZ2UuY29tPg0Kd3d3LmdlaGVhbHRoY2Fy ZS5jb208aHR0cDovL3d3dy5nZWhlYWx0aGNhcmUuY29tLz4NCg0KMTE2IEh1bnRpbmd0b24gQXZl DQpCb3N0b24sIE1BIDAyMTE2DQpVU0ENCkdFIGltYWdpbmF0aW9uIGF0IHdvcmsNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_C41EE4B7616F774CBF466291DC59746F0BD925CINURCNA03e2kadge_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjI4MjYxODU3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo3NjA2NTkwODAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MjEyODEwNTQ2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMzA0Njg3ODM0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjQwMjQ1NzkyMDsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTY3NTc4MTkzMCA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28t bGlzdC1pZDo3MDk1NzQyMjc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xNTkxMjAyODM4IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwz OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjkzOTY4MDMzNzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MTQ5MDIwNzggNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0Omxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNDpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTIy MDY3NDYxMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTMyNDg5OTU2IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGw1OmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGw2DQoJe21zby1saXN0LWlkOjE1OTI1NDYzMjk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0OTg1NDY1MjYgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDY6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDY6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw2Omxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDcNCgl7bXNvLWxpc3QtaWQ6MTc3ODEzOTIyNzsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk5MzA4NDYzOCA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsNzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNzpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw3OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGw3OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsOA0KCXttc28t bGlzdC1pZDoxOTg0Nzc1OTgwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo3MjYyODYxNjggNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDg6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDg6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw4OmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw4OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw4 OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsODpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsODpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsODpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9yZSB3YWxscyBvZiB0ZXh0 IGFzIG15IHVuZGVyc3RhbmRpbmcgZ3Jvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkndmUgcmV2aXNlZCBteSB1bmRlcnN0 YW5kaW5nIGEgYml0IHNpbmNlIG15IGZpcnN0IHBvc3RpbmcuJm5ic3A7IExldCBtZSBzZWUgaWYg SSBjYW4gZXhwbGFpbiBhIGxpdHRsZSBtb3JlIGNsZWFybHk6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNyBsZXZlbDEgbGZv MyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSdkIGxpa2UgdG8gaGF2ZSBzb21lIHdheSBmb3IgYXV0aG9y aXphdGlvbiBlbmRwb2ludHMgdG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGJhc2Vk IG9uIHBvbGljaWVzIGFib3V0IGFuIGFwcGxpY2F0aW9uLiZuYnNwOw0KPGJyPg0KVGhpcyBpcyBz b21ldGhpbmcgdGhhdCBpcyBkZWVtZWQgZXNzZW50aWFsIGZvciB0aGVzZSBhcHBsaWNhdGlvbnMg c2luY2UgdGhleSB3aWxsIGJlIGFjY2Vzc2luZyBwcm90ZWN0ZWQgaGVhbHRoIGluZm9ybWF0aW9u IGZyb20gZW50aXRpZXMgY292ZXJlZCB1bmRlciBvciBhc3NvY2lhdGVkIHdpdGggZW50aXRpZXMg Y292ZXJlZCB1bmRlciBISVBBQS48YnI+DQpJbiBteSBpbml0aWFsIHRoaW5raW5nLCB0aGUgY2xp ZW50IGNyZWRlbnRpYWxzIHdvdWxkIGlkZW50aWZ5IHRoZSBhcHBsaWNhdGlvbiBzbyB0aGF0IHBv bGljeSBjaGVja2luZyB3b3VsZCBiZSBlbmFibGVkIGJ5IHRoZSBkYXRhIGhvbGRlci4mbmJzcDsg QnV0IHRoZSBjbGllbnRfbmFtZSBhbmQvb3IgY2xpZW50X3VybCBjb3VsZCBhbHNvIGJlIHVzZWQg YnkgdGhlIGF1dGhvcml6ZXIuPGJyPg0KUG9saWNpZXMgbWlnaHQgc2F5IHNvbWV0aGluZyBsaWtl OiBBcHBsaWNhdGlvbiBYWVogaGFzIGJlZW4gY2VydGlmaWVkIGJ5IG9yZ2FuaXphdGlvbiBBQkMg dG8gYmUgY29tcGxpYW50IHdpdGggcG9saWN5IDEyMywgYW5kIHNob3VsZCBiZSBncmFudGVkIGFj Y2Vzcy4mbmJzcDsgT3IsIEFwcGxpY2F0aW9uIFhZWiBpcyBrbm93biB0byBiZSBhIFRyb2phbiBh bmQgc2hvdWxkIG5vdCBiZSBncmFudGVkIGFjY2Vzcy4mbmJzcDsgT3IgQXBwbGljYXRpb24gWFla IGlzIGtub3duDQogdG8gYmUgc3VzY2VwdGlibGUgdG8gdmlydXMgUVJTIGFuZCBzaG91bGQgbm8g bG9uZ2VyIGJlIGdyYW50ZWQgYWNjZXNzLiBIb3cgdGhlc2UgcG9saWNpZXMgYXJlIGRpc3RyaWJ1 dGVkIHRvIGF1dGhvcml6ZXJzIGlzbid0IHBhcnQgb2YgdGhpcyBkaXNjdXNzaW9uLiZuYnNwOyBB Y2Nlc3MgdG9rZW5zIGlzc3VlZCBieSBhdXRob3JpemVycyBjb3VsZCBiZSBzdWZmaWNpZW50bHkg c2hvcnQtbGl2ZWQgdGhhdCByb3V0aW5lIHJlZnJlc2hlcyB3b3VsZCBiZSBuZWNlc3NhcnksDQog YWxsb3dpbmcgcG9saWN5IGNoZWNrcyB0byBiZSBwZXJmb3JtZWQgYXMgZnJlcXVlbnRseSBhcyBu ZWNlc3NhcnkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDcgbGV2 ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UnZCBsaWtlIHRvIGZhY2lsaXRhdGUgYW4gYXV0 b21hdGVkIHByb2Nlc3Mgd2hlcmVieSBhcHBsaWNhdGlvbiBjYW4gYmUgZHluYW1pY2FsbHkgcmVn aXN0ZXJlZCB3aXRob3V0IHJlcXVpcmluZyBhIGxvdCBvZiBpbmZyYXN0cnVjdHVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayB0aGVyZSBhcmUgdGhyZWUgYWN0b3JzIGluIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vz cy4mbmJzcDsgSSdsbCBjYWxsIHRoZW0gdGhlIHJlZ2lzdHJhciwgdGhlIGFwcGxpY2F0aW9uIGlu c3RhbmNlLCBhbmQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuJm5ic3A7IFRoZSByZWdpc3Ry YXINCiBpcyBhIGNvbmZpZGVudGlhbCBjbGllbnQuJm5ic3A7IEl0IHNlcnZlcyB0aHJlZSBmdW5j dGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCAmcXVvdDty ZWdpc3RlcnMmcXVvdDsgYXBwbGljYXRpb24gaW5zdGFuY2VzIChvdGhlcnMgaGF2ZSByZWZlcnJl ZCB0byB0aGlzIGFzIHRoZSBhcHBsaWNhdGlvbikgd2l0aCBpdHNlbGYsIGFuZCBjb25maWd1cmVz IHRob3NlIGFwcGxpY2F0aW9uIGluc3RhbmNlcyBzbyB0aGF0DQogdGhleSBjYW4gY29tbXVuaWNh dGUgd2l0aCBpdCBzZWN1cmVseSBpbiB0aGUgZnV0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHJlZ2lzdGVycyBhbiBh cHBsaWNhdGlvbiAob3RoZXJzIGhhdmUgY2FsbGVkIHRoaXMgYW4gYXBwbGljYXRpb24gY2xhc3Mp IHdpdGggYW4gYXV0aG9yaXplci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBmYWNpbGl0YXRlcyBjb21tdW5pY2F0aW9uIGJl dHdlZW4gYW4gYXBwbGljYXRpb24gaW5zdGFuY2UgYW5kIHRoZSBhdXRob3JpemVyIGJ5IG9idGFp bmluZyBhdXRob3JpemF0aW9uIHRva2VucyB3aGljaCBhcmUgdGhlbiBjb21tdW5pY2F0ZWQgdG8g dGhlDQogYXBwbGljYXRpb24gaW5zdGFuY2UgdG8gcmVnaXN0ZXIgaXRzZWxmIHdpdGggdGhlIGF1 dGhvcml6ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSByZWdpc3RyYXIgJnF1b3Q7cmVnaXN0ZXJzJnF1b3Q7IHRoZSBh cHBsaWNhdGlvbiAoY2xhc3MpIGR1cmluZyB0aGUgZmlyc3QgcmVnaXN0cmF0aW9uICh0aHVzLCBu b3QgbmVlZGluZyBhbiBhY2Nlc3NfdG9rZW4pLCBhbmQgc2luY2UgaXQgaXMgYSBjb25maWRlbnRp YWwgY2xpZW50LCBjYW4NCiBzZWN1cmUgaXRzIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldC4m bmJzcDsgVGhpcyByZWdpc3RyYXRpb24gaXMgc2NvcGVkIHRvIG9ubHkgc3VwcG9ydCBmYWNpbGl0 YXRpbmcgdGhlIGluaXRpYWwgYXV0aG9yaXphdGlvbiBvZiBhbiBhcHBsaWNhdGlvbiBpbnN0YW5j ZSAodXNpbmcgdGhlIHNjb3BlIHBhcmFtZXRlcikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuIGFwcGxpY2F0aW9uIGluc3Rh bmNlIG11c3QgY29uZmlndXJlIGl0c2VsZiAocG9zdCBkZXBsb3ltZW50KSBieSBjb21tdW5pY2F0 aW5nIHdpdGggdGhlIHJlZ2lzdHJhci4mbmJzcDsgVGhpcyB3aWxsIGFsbG93IHRoZSBhcHBsaWNh dGlvbiBpbnN0YW5jZSBhbmQgdGhlIHJlZ2lzdHJhcg0KIHRvIHNlY3VyZSB0aGVpciBjb21tdW5p Y2F0aW9ucyBpbiBmdXR1cmUgY29udmVyc2F0aW9ucy4mbmJzcDsgSG93IHRoZXkgZG8gdGhhdCBp cyBvdXQgb2Ygc2NvcGUuJm5ic3A7IEFuIGFwcGxpY2F0aW9uIHdpbGwgYmUgY29uZmlndXJlZCAo cHJlLWRlcGxveW1lbnQpIHRvIGNvbW11bmljYXRlIHdpdGggYSBzcGVjaWZpYyByZWdpc3RyYXIu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2hlbiBhbiBhcHBsaWNhdGlvbiBpbnN0YW5jZSB3aXNoZXMgdG8gYmUgcmVnaXN0 ZXJlZCB3aXRoIGFuIGF1dGhvcml6ZXIgdGhhdCBpdCBoYXNuJ3Qgc2VlbiBiZWZvcmUgaXQgcGVy Zm9ybXMgdGhlIGZvbGxvd2luZyBzdGVwczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps NiBsZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9r ZW4gZnJvbSB0aGUgcmVnaXN0cmFyIGZvciB0aGUgYXV0aG9yaXplci4mbmJzcDsgVGhlIHJlZ2lz dHJhciB3aWxsLCBpZiBpdCBoYXNuJ3QgYWxyZWFkeSwgcmVnaXN0ZXIgdGhlIGFwcGxpY2F0aW9u IHdpdGggdGhlIGF1dGhvcml6ZXIuJm5ic3A7DQogSXQgd2lsbCB0aGVuIHVzZSBpdHMgY2xpZW50 X2lkIGFuZCBjbGllbnRfc2VjcmV0IHdpdGggdGhlIGF1dGhvcml6ZXIgdG8gb2J0YWluIGFuIGFj Y2VzcyB0b2tlbiBmb3IgdGhlIGluc3RhbmNlIG5lZWRpbmcgcmVnaXN0cmF0aW9uLiZuYnNwOyBU aGVzZSB3aWxsIGJlIHJldHVybmVkIHRvIHRoZSBhcHBsaWNhdGlvbiBpbnN0YW5jZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNiBsZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J dCB1c2VzIHRoYXQgYWNjZXNzIHRva2VuIHdpdGggdGhlIGF1dGhvcml6ZXIgdG8gcmVnaXN0ZXIg aXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5XaGF0IEkndmUgZG9uZSBoZXJlIGlzIGVzc2VudGlhbCBzcGxpdCB0aGUg Y2xpZW50IGludG8gdHdvIGNvbXBvbmVudHM6Jm5ic3A7IEEgY29uZmlkZW50aWFsIHJlZ2lzdHJh ciBjb21wb25lbnQsIGFuZCBhIChwb3NzaWJseSBwdWJsaWMpIGFwcGxpY2F0aW9uIGluc3RhbmNl IGNvbXBvbmVudC4mbmJzcDsNCiBUaGUgcmVnaXN0cmFyIG9ubHkgY29tbXVuaWNhdGVzIHdpdGgg YXV0aG9yaXplcnMgYW5kIGFwcGxpY2F0aW9uIGluc3RhbmNlcy4mbmJzcDsgSXQgbmV2ZXIgYWN0 dWFsbHkgZG9lcyBhbnkgd29yayB3aXRoIGRhdGEgaG9sZGVycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBzZWVtcyBs aWtlIGl0IHdvdWxkIHdvcmsgZm9yIG15IHVzZSBjYXNlLCBidXQgc3RpbGwgZmVlbHMgb3Zlcmx5 IGN1bWJlcnNvbWUuIEluIG9yZGVyIHRvIGFjY2VzcyBkYXRhLCBhbiBhcHBsaWNhdGlvbiBpbnN0 YW5jZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNyI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IYXMgdG8gYmUgcHJlLWNvbmZpZ3VyZWQgd2l0aCBhIHJlZ2lzdHJhci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNyI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IYXMgdG8gYmUgcG9zdC1jb25maWd1cmVkIGJ5IHRoYXQgcmVnaXN0cmFyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0Omw0IGxldmVsMSBsZm83Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBy ZWdpc3RyYXIgaGFzIHRvIHJlZ2lzdGVyIHRoZSBhcHBsaWNhdGlvbiB3aXRoIGFuIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxm bzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlZ2lzdHJhciBoYXMgdG8gb2J0YWluIGFuIGFjY2Vz cyB0b2tlbiBmcm9tIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb24gYmVoYWxmIG9mIGFuIGFw cGxpY2F0aW9uIGluc3RhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlZ2lzdHJhciBoYXMgdG8gY29tbXVuaWNhdGUg dGhhdCBhY2Nlc3MgdG9rZW4gdG8gdGhlIGFwcGxpY2F0aW9uIGluc3RhbmNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0Omw0IGxldmVsMSBsZm83Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjYuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBh cHBsaWNhdGlvbiBpbnN0YW5jZSBoYXMgdG8gcmVnaXN0ZXIgaXRzZWxmIHdpdGggdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ny48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGRhdGEgaG9sZGVyIGhhcyB0byBhdXRob3JpemUg dGhlIGVuZCB1c2VyIGFuZCB0aGUgYXBwbGljYXRpb24gaW5zdGFuY2UgdG8gYWNjZXNzIHRoZSBk YXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UbyBtYWtlIG15c2VsZiBmZWVsIGJldHRlciwgSSBsb29rZWQgYXQgZWFjaCBv ZiB0aGVzZSBzdGVwczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZv OSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHByZS1jb25maWd1cmF0aW9uIGlzIG5vdCBoYXJkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm85Ij48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlZ2lzdGVyaW5nIGFuIGluc3RhbGxlZCBhcHBsaWNhdGlvbiB3aXRoIHRoZSBkZXZlbG9w ZXIgb2YgdGhhdCBhcHBsaWNhdGlvbiBpcyBhIHByZXR0eSBjb21tb24gZmVhdHVyZSAoaW4gdGhl IFBDIHdvcmxkLCBub3QgYXMgbXVjaCBpbiB0aGUgbW9iaWxlIGFwcA0KIHdvcmxkKS4mbmJzcDsg VGhhdCBjYW4gYmUgY29tYmluZWQgd2l0aCB0aGUgcG9zdC1jb25maWd1cmF0aW9uIHN0ZXAgdGhh dCBlbmFibGVzIHNlY3VyZSBjb21tdW5pY2F0aW9uIHdpdGggdGhlIHJlZ2lzdHJhci4mbmJzcDsg VGhpcyBjb3VsZCBldmVuIGJlIHNpbWlsYXIgdG8gdGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHdv cmtmbG93LCBzYXZlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGluc3RhbmNlIGlzIGR5bmFtaWNhbGx5 IHJlZ2lzdGVyaW5nIGl0c2VsZiB3aXRoDQogdGhlIHJlZ2lzdHJhci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvOSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHZl cnkgc2ltaWxhciB0byBzdGVwIDYsIGFuZCBtaWdodCBvZnRlbiBiZSBjb2RlZCBieSB0aGUgc2Ft ZSBkZXZlbG9wZXJzLCBvciB1c2UgdGhlIHNhbWUgbGlicmFyaWVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwyIGxldmVsMSBsZm85Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgc3Rh bmRhcmQgT0F1dGggc3R1ZmYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzkiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBjb3VsZCBiZSBkb25lIHVzaW5nIHN0YW5kYXJk IE9BdXRoIHN0dWZmLiZuYnNwOyBJbiBmYWN0LCBzdGVwIDIgY291bGQgaW4gZmFjdCBiZSBhbiBP QXV0aCB3b3JrZmxvdywgd2hlcmUgYW4gYXBwbGljYXRpb24gaW5zdGFuY2UgcmVxdWVzdHMgYW4g YWNjZXNzDQogdG9rZW4gZnJvbSB0aGUgcmVnaXN0cmFyLCB3aGljaCB0aGVuIHJlcm91dGVzIHRo YXQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgdXNpbmcgaXRzIG93biBj cmVkZW50aWFscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvOSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj42LjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHRoZSBiYXNpYyBkeW5hbWljIHJlZ2lzdHJhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIHJlZ2lzdHJhciBzZWVtcyB0byBiZSBhIHNpbXBsZSBlbm91Z2ggd2ViIHNlcnZp Y2UgdGhhdCB3b3VsZG4ndCB0YWtlIGEgbG90IG9mIGluZnJhc3RydWN0dXJlIHRvIGRldmVsb3Ag b3IgbWFpbnRhaW4uJm5ic3A7IEF0IGEgYmFyZSBtaW5pbXVtLCBpdCBuZWVkcyB0byBzdG9yZQ0K IGl0cyBjbGllbnQgY3JlZGVudGlhbHMgZm9yIHJlZ2lzdHJhdGlvbnMgd2l0aCBkaWZmZXJlbnQg YXV0aG9yaXplcnMsIGFuZCBleGVjdXRlIHR3byBkaWZmZXJlbnQgT0F1dGggd29ya2Zsb3dzOiZu YnNwOyBSZWdpc3RlcmluZyBhbiBhcHBsaWNhdGlvbiAoY2xhc3MpIHdpdGggYW4gYXV0aG9yaXpl ciwgYW5kIG9idGFpbmluZyBhbiBhdXRob3JpemF0aW9uIHRva2VuIGZyb20gYW4gYXV0aG9yaXph dGlvbiBhbmQgY29tbXVuaWNhdGluZyB0aGF0IHRva2VuDQogdG8gYW4gYXBwbGljYXRpb24gaW5z dGFuY2UuJm5ic3A7IEEgc2luZ2xlIHJlZ2lzdHJhciBzZXJ2aWNlIGNvdWxkIGJlIHByb3ZpZGVk IHRoYXQgc3VwcG9ydHMgbXVsdGlwbGUgYXBwbGljYXRpb25zLCBwZXJoYXBzIGNvbWJpbmluZyB3 aXRoIG90aGVyIHNlcnZpY2VzIChzdWNoIGFzIGFuIGFwcCBzdG9yZSkuJm5ic3A7IElmIHVzaW5n IG90aGVyIE9BdXRoIHdvcmtmbG93cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aG91Z2h0IGFib3V0IGhhdmluZyB0aGUg cmVnaXN0cmFyIGRvIGEgY291cGxlIG9mIG90aGVyIHRoaW5ncyB0byBzaW1wbGlmeSwgYnV0IHRo ZXkganVzdCBkaWRuJ3Qgc2VlbSB0byB3b3JrOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwzIGxldmVsMSBsZm82Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGNvdWxkIGp1c3QgY29uZmlndXJl IHRoZSBhcHBsaWNhdGlvbiB3aXRoIHRoZSBjbGllbnRfaWQgYW5kIGNsaWVudF9zZWNyZXQgdGhh dCB3ZXJlIGlzc3VlZCBkdXJpbmcgdGhlICZxdW90O2ZpcnN0JnF1b3Q7IHJlZ2lzdHJhdGlvbi4m bmJzcDsgRXZlbiB0aG91Z2ggdGhlc2UgY291bGQNCiBiZSBzZWN1cmVkIGR1cmluZyB0aGF0IHBv c3QtaW5zdGFsbGF0aW9uIHJlZ2lzdHJhdGlvbiBzdGVwLCBoYXZpbmcgZWFjaCBjbGllbnQgaW5z dGFuY2Ugc2hhcmUgYW4gaWQgYW5kIHNlY3JldCBkaWRuJ3QgZmVlbCBzZWN1cmUuJm5ic3A7IFNv bWVvbmUgd2lsbCBtZXNzIGl0IHVwIGFuZCB0aGF0IGlkIGFuZCBzZWNyZXQgY291bGQgdGhlbiBi ZSB1c2VkIGFzIGFuIGF0dGFjayB2ZWN0b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzYiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlZ2lzdHJhciBjb3VsZCBwZXJm b3JtIHRoZSByZWdpc3RyYXRpb24gZm9yIHRoZSBjbGllbnQsIGFuZCByZXR1cm4gdGhlIGNsaWVu dF9pZCBhbmQgc2VjcmV0IGl0IG9idGFpbmVkIG9uIGJlaGFsZiBvZiB0aGUgY2xpZW50LCBidXQg dGhlIHJlZ2lzdHJhcg0KIGFuZCB0aGUgYXBwbGljYXRpb24gbmVlZCBub3QgYmUgY3JlYXRlZCBi eSB0aGUgc2FtZSBvcmdhbml6YXRpb25zLCBhbmQgdGhlIHJlZ2lzdHJhciB3b3VsZCB0aGVuIGhh dmUgYWNjZXNzIHRvIGFuIGlkIGFuZCBzZWNyZXQgdGhhdCBpdCBkaWRuJ3QgbmVlZCB0byBoYXZl IGFjY2VzcyB0by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QW0gSSBvdmVydGhpbmtpbmcgdGhpcywgb3IgaXMgdGhpcyByaWdo dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRvcnN0ZW4gTG9kZGVy c3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9i PiBTdW5kYXksIEphbnVhcnkgMTMsIDIwMTMgMTI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IEJvb25l LCBLZWl0aCBXIChHRSBIZWFsdGhjYXJlKTxicj4NCjxiPkNjOjwvYj4gUmljaGVyLCBKdXN0aW4g UC47IG9hdXRoQGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZWl0aCw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5jb21tZW50IHNlZSBiZWxvdy48YnI+DQo8YnI+DQpBbSAxMC4wMS4y MDEzIHVtIDIyOjU0IHNjaHJpZWIgJnF1b3Q7Qm9vbmUsIEtlaXRoIFcgKEdFIEhlYWx0aGNhcmUp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguYm9vbmVAZ2UuY29tIj5rZWl0aC5ib29u ZUBnZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtzbmlw Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbWFnaW5lIHRoZSBjYXNlIHdoZXJlIEkgcHVyY2hhc2UgYW4gYXBwbGljYXRp b24gYW5kIGRvd25sb2FkIGl0IHRvIG15IGlQaG9uZSBhbmQgdG8gbXkgaVBhZC4mbmJzcDsgVGhl biBJIGNvbm5lY3QgdGhhdCBhcHBsaWNhdGlvbiB0byBhIGRhdGEgaG9sZGVyL2F1dGhvcml6ZXIg Y29tYmluYXRpb24NCiBpdCBoYXNuJ3Qgc2VlbiBiZWZvcmUuJm5ic3A7IFRocm91Z2ggZHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uLCBJIGNvdWxkIHJlZ2lzdGVyIHRoYXQgYXBwbGljYXRpb24g Zm9yIG15IGlQaG9uZSwgYnV0IHRoZSBpbnN0YW5jZSBvZiB0aGF0IHNhbWUgYXBwbGljYXRpb24g cnVubmluZyBvbiBteSBpUGFkIHdvdWxkIGtub3cgbm90aGluZyBhYm91dCB0aGUgZmlyc3QgcmVn aXN0cmF0aW9uLiZuYnNwOyBTbyBpdCB3b3VsZCBhdHRlbXB0IHRvIGRvIGl0IGFsbCBvdmVyDQog YWdhaW4uJm5ic3A7IFdoYXQgaGFwcGVucyBoZXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBhIHByb2JsZW0/IFRo ZSB1c2VyIHNob3VsZCBiZSBhYmxlIHRoZSBkYXRhIHNoZSBkZXNpcmVzIGZyb20gYm90aCBhcHAs IGluZGVwZW5kZW50IG9mIHRoZSBjbGllbnQgaWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvIHlvdXIgd2FudCB0byBhY2hpZXZlPyBJIGRvbid0 IHVuZGVyc3RhbmQgd2h5IGRpZmZlcmVudCBpbnN0YW5jZXMgb2YgYW4gYXBwIG5lZWQgdG8gYmUg YXdhcmUgb2YgZWFjaCBvdGhlci4gSSB3b3VsZCBhc3N1bWUgYSB1c2VyIHdhbnRzIHRvIGFjY2Vz cyB0aGUgc2FtZSBkYXRhIGZyb20gYWxsIHRob3NlIGluc3RhbmNlcy4gQnV0IHRoaXMgaXMgbWVy ZWx5IGNvbnRyb2xsZWQgYnkgdGhlIHVzZXIgaWRlbnRpdHkNCiB3aXRoIHRoZSBhcHAuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIHR3 byBwb3NzaWJsZSBzY2VuYXJpb3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmEpIHRoZSBhcHAgZG9lcyBub3QgaGF2ZSBhbiB1c2VyIG1hbmFn ZW1lbnQgYnV0IHJlbGllcyBvbiB0aGUgdXNlciB0byBzZXR1cCB0aGUgY29ubmVjdGlvbiB0byBh IHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyLiBUaGUgdXNlciB3b3VsZCBkbyB0aGlzIG9uIGV2 ZXJ5IGRldmljZSwgaS5lLiBldmVyeSBhcHAgaW5zdGFuY2Ugd291bGQgY2Fycnkgb3V0IHRoZSBP QXV0aCBkYW5jZSB3aXRoIHRoZSBwYXJ0aWN1bGFyDQogYXV0aG9yaXplci48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgdGhlIGFwcCBoYXMg dGhlaXIgb3duIHVzZXIgbWFuYWdlbWVudC4gU28gdGhlIHVzZXIgd291bGQgMSkgcmVnaXN0ZXIg Zm9yIGFuIGFjY291bnQgYW5kIDIpIGNvbm5lY3QgdGhpcyBhY2NvdW50IHRvIHRoZSByZXNvdXJj ZXMgbWFuYWdlZCBieSB0aGUgYXV0aG9yaXplci4gQXNzdW1wdGlvbjogdGhlIGFwcCBoYXMgYW4g YmFja2VuZCBhbmQgc3RvcmVzIHVzZXIgZGF0YSB0aGVyZS4gT24gdGhlIHNlY29uZA0KIGRldmlj ZSwgdGhlIHVzZXIgaGFzIG9ubHkgdG8gbG9naW4gdXNpbmcgaGVyIGFwcCBhY2NvdW50IGFuZCBp cyBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VG9yc3Rlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtlaXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQo8L3NwYW4+PC91PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPktlaXRoIFcuIEJvb25lPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxicj4NClN0YW5kYXJkcyZuYnNwO0FyY2hpdGVjdDxicj4NCkdFIEhlYWx0 aGNhcmU8YnI+DQo8YnI+DQpNICYjNDM7MSA2MTcgNjQwIDcwMDc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmJvb25lQGdlLmNvbSIgdGl0bGU9Im1h aWx0bzprZWl0aC5ib29uZUBnZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQt ZGVjb3JhdGlvbjpub25lIj5rZWl0aC5ib29uZUBnZS5jb208L3NwYW4+PC9hPjxicj4NCjxhIGhy ZWY9Imh0dHA6Ly93d3cuZ2VoZWFsdGhjYXJlLmNvbS8iIHRpdGxlPSJodHRwOi8vd3d3LmdlaGVh bHRoY2FyZS5jb20vIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+d3d3LmdlaGVhbHRoY2FyZS5jb208L3NwYW4+PC9hPjxicj4NCjxicj4NCjExNiBIdW50 aW5ndG9uIEF2ZTxicj4NCkJvc3RvbiwgTUEgMDIxMTY8YnI+DQpVU0E8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPkdFIGltYWdpbmF0aW9uIGF0IHdvcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBSaWNoZXIsIEp1c3RpbiBQLiBbPGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIj5t YWlsdG86anJpY2hlckBtaXRyZS5vcmc8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKYW51YXJ5IDEwLCAyMDEzIDQ6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IEJvb25lLCBLZWl0aCBX IChHRSBIZWFsdGhjYXJlKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1h aWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkludGVyZXN0aW5nIHVzZSBjYXNlLCBhbmQgbm90 IGRpc3NpbWlsYXIgdG8gc29tZSBvdGhlcnMgSSd2ZSBoZWFyZC4gSG93IHdvdWxkIHlvdSBnbyBh Ym91dCB0cmFja2luZyB0aGlzPyBXaHkgd291bGQgdGhlIGluc3RhbmNlcyBuZWVkIHRvIGtub3cg YWJvdXQgZWFjaCBvdGhlcj8NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T25lIHBvc3NpYmxlIGFwcHJvYWNoIHdvdWxkIGJlIHRvIHVzZSBhIGNvbW1vbiBp bml0aWFsaXppbmcgUmVxdWVzdCBBY2Nlc3MgVG9rZW4gdGhhdCBpcyB1c2VkIHRvIGNhbGwgY2xp ZW50X3JlZ2lzdGVyIG9uIGFsbCBpbnN0YW5jZXMgb2YgYSBnaXZlbiBjbGllbnQuIFRoZXkgd291 bGRuJ3Qga25vdyBhYm91dCBlYWNoIG90aGVyLCBwZXIgc2UsIGJ1dCB0aGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgd291bGQgYXQNCiBsZWFzdCBrbm93IGVub3VnaCB0byBiZSBhYmxlIHRvIHRpZSB0 aGVtIHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGVyZSdzIGFsc28gdGhlIE9BdXRoMiBJbnN0YW5jZSBJbmZvcm1hdGlvbiBl eHRlbnNpb24gdGhhdCBJIGhhZCB0cmllZCB0byBwdXNoIGEgZmV3IHllYXJzIGFnbyB0aGF0IGNv bWVzIHVwIGV2ZXJ5IG5vdyBhbmQgYWdhaW4sIHRoYXQgbWlnaHQgYmUgb2YgdXNlIGhlcmUgd2l0 aCBzb21lIG1vZGlmaWNhdGlvbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXJpY2hlci1vYXV0aC1pbnN0YW5jZS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcmljaGVyLW9hdXRoLWluc3RhbmNlLTAwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEknZCBsaWtlIHRvIGtub3cg bW9yZSBhYm91dCB5b3VyIGNvbmNlcm5zIGFuZCB0aGUgcGFyYW1ldGVycyBvZiB5b3VyIHVzZSBj YXNlIGZpcnN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIENDJ2luZyB0aGUgSUVURiBPQXV0aCBXb3JraW5nIEdyb3VwIGVt YWlsIGxpc3QsIHdoZXJlIHRoaXMgZHJhZnQgaXMgYmVpbmcgZGlzY3Vzc2VkIGFuZCB3b3JrZWQg b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEphbiAxMCwgMjAxMywgYXQgNDoyNCBQTSwgJnF1b3Q7Qm9vbmUsIEtl aXRoIFcgKEdFIEhlYWx0aGNhcmUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguYm9v bmVAZ2UuY29tIj5rZWl0aC5ib29uZUBnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgd291bGQgbGlrZSB0byBiZSBhYmxlIHRvIHVzZSB0aGlzIHByb3Rv Y29sIHRvIGR5bmFtaWNhbGx5IHJlZ2lzdGVyIGNsaWVudHMsIGJ1dCBhbSBjaGFsbGVuZ2VkIGJ5 IHRoZSBmYWN0IHRoYXQgdGhlcmUgY291bGQgYmUgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGEgcHVi bGljIGNsaWVudCwgZWFjaA0KIHVuYXdhcmUgb2Ygd2hhdCBvdGhlcnMgaGF2ZSBkb25lLiZuYnNw OyBUaGUgY3VycmVudCBwcm90b2NvbCBkb2Vzbid0IHNlZW0gdG8gYWRkcmVzcyB0aGlzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBLZWl0aDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCjwvc3Bhbj48L3U+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPktlaXRo IFcuIEJvb25lPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpTdGFu ZGFyZHMmbmJzcDtBcmNoaXRlY3Q8YnI+DQpHRSBIZWFsdGhjYXJlPGJyPg0KPGJyPg0KTSAmIzQz OzEgNjE3IDY0MCA3MDA3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFp bHRvOmtlaXRoLmJvb25lQGdlLmNvbSIgdGl0bGU9Im1haWx0bzprZWl0aC5ib29uZUBnZS5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmtlaXRoLmJv b25lQGdlLmNvbTwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5nZWhlYWx0aGNh cmUuY29tLyIgdGl0bGU9Imh0dHA6Ly93d3cuZ2VoZWFsdGhjYXJlLmNvbS8iPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3dy5nZWhlYWx0aGNhcmUuY29t PC9zcGFuPjwvYT48YnI+DQo8YnI+DQoxMTYgSHVudGluZ3RvbiBBdmU8YnI+DQpCb3N0b24sIE1B IDAyMTE2PGJyPg0KVVNBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5H RSBpbWFnaW5hdGlvbiBhdCB3b3JrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C41EE4B7616F774CBF466291DC59746F0BD925CINURCNA03e2kadge_-- From Michael.Jones@microsoft.com Sun Jan 13 23:02:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5660E21F8611 for ; Sun, 13 Jan 2013 23:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br+s4xuao-Y6 for ; Sun, 13 Jan 2013 23:02:44 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7AACB21F85B2 for ; Sun, 13 Jan 2013 23:02:43 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.202) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.0.596.13; Mon, 14 Jan 2013 07:02:41 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Mon, 14 Jan 2013 07:02:40 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Mon, 14 Jan 2013 07:02:37 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RTcHXvPlTOOEyaLkX1rm6jbZhD/pUAgAA0JQCAABW0gIAAIGKAgAGzmACAAA5L0IAA3e+AgAACUkCAAAx9gIABUfFA Date: Mon, 14 Jan 2013 07:02:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> In-Reply-To: <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(51704002)(377454001)(377424002)(13464002)(164054002)(52604002)(479174001)(52544001)(44976002)(5343635001)(31966008)(4396001)(5343655001)(51856001)(79102001)(76482001)(47976001)(33656001)(47776002)(16406001)(54356001)(54316002)(50986001)(74662001)(550184003)(47446002)(56776001)(50466001)(46406002)(56816002)(23726001)(53806001)(15202345001)(47736001)(46102001)(49866001)(55846006)(77982001)(59766001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB037; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0726B2D7A6 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 07:02:46 -0000 I'm thinking it would be useful for us to talk on the phone or Skype tomorr= ow, Hannes, because I'm pretty sure I don't know what specific changes you'= re asking for in which specs. Are you, for instance, asking for language s= aying that audience values are to be compared for equality as case-sensitiv= e strings in the SAML bearer and JWT bearer specs? (They're not just URIs,= as they can be OAuth Client IDs.) Or maybe you can propose specific langu= age changes, so it's clear what you're asking for. Thanks, -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike,=20 it is fine to support different identifiers and to even allow the set of su= pported identifiers to get extended over time.=20 Just omitting a description is, however, not an option. We are in the lucky= position where others have done the work for us already (as mentioned in t= he two cited references). For the IAB document there is even the chance to = provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issue= s-in-identifier-comparison-for-security-purposes/) in case you believe the = author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: > We already know of use cases where the audience is an abstract identifier= and use cases where the audience is the URL of the token endpoint. Both a= re legitimate. We should foreclose neither. >=20 > Like many things OAuth, interoperability can be achieved, but it may requ= ire a profile further specifying the behaviors appropriate to that use case= . This is not a bug - it is a feature, as it increases the applicability o= f the OAuth specifications. >=20 > The Assertion, JWT Profile, and SAML Profile are striking an appropriate = balance by providing guidance on likely audience values for many use cases,= but not precluding other values where necessary for those use cases. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, January 13, 2013 1:56 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org=20 > WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike, >=20 > I understand your reasoning: you want to keep all options open in the fra= mework specification and you want to be more specific in draft-ietf-oauth-j= wt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >=20 > The RFC 2119 language does not add anything but it does not hurt either. = It just says that there could essentially be anything in there, including t= he URL of the Token Endpoint. >=20 > You can of course post-pone dealing with the issue to the more specific d= ocuments. For example, draft-ietf-oauth-jwt-bearer at the moment does not a= llow an interoperable deployment since it just repeats the abstract framewo= rk text by saying "The token endpoint URL of the authorization server MAY b= e used as an acceptable value for an "aud" element."=20 >=20 > Ciao > Hannes >=20 > On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >=20 >> Hi Hannes, >>=20 >> For the reasons that Justin and Brian state, I believe that the MAY is a= ppropriate. In some use cases, a good representation of an appropriate aud= ience value is URL of the Token Endpoint. That's there in the Assertions s= pecification as guidance to writers token-type specific specs using the Ass= ertions spec, as I believe it should be. That being the case, as Brian des= cribes, sometimes audience values are more abstract identifiers or identifi= ers for groups of services, and we don't want to inadvertently preclude tho= se actual use cases. >>=20 >> Thus, I believe that the language is appropriate as-is. Thus, I believe= that we should proceed with the currently scheduled telechat discussion of= the spec. >>=20 >> Thanks all= , >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Hannes Tschofenig >> Sent: Saturday, January 12, 2013 11:50 AM >> To: Brian Campbell >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Brian, >>=20 >> I understand that this is challenging. >>=20 >> Nevertheless it would make sense to describe the desired behavior in dra= ft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way= that two versions developed by different groups would interoperate without= causing security problems or failures.=20 >>=20 >> To move forward with draft-ietf-oauth-assertions I suggest to follow the= recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10= 507.html and to address the details in draft-ietf-oauth-jwt-bearer and in = draft-ietf-oauth-saml2-bearer as soon as possible to get these documents mo= ving forward and completed soon.=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>=20 >>> That text around audience in the framework spec changed from a SHOULD t= o a MAY in -09 so that it would be more consistent with the the SAML and JW= T versions, which were already using a MAY in that context. >>>=20 >>> Your concern is valid Hannes and your point is taken. But reality is ra= ther messy and I don't believe it can addressed as easily as you suggest. = =20 >>>=20 >>> In SAML, for example, an entity identifier is often used as a value for= the audience (per spec and in practice). But an AS may not necessarily id= entify itself with a full blown SAML entity, in which case the token endpoi= nt URI is more appropriate. The whole issue is also somewhat complicated in= SAML too by it having both audience and recipient that are similar but not= the same. I've tried to account for all of this in the SAML doc but it's a= dmittedly somewhat awkward and complex and not as simple as saying the valu= e has to be X and must be validated in exactly such a way. >>>=20 >>> JWT doesn't have the same history and baggage of SAML but is subject to= many of the same real world deployment variations. >>>=20 >>> I'm definitely open to improvements with respect to the handling of=20 >>> audience values but I believe anything that is done needs to reflect=20 >>> the realities of current implementations and deployments as well as=20 >>> related specifications., >>>=20 >>>=20 >>>=20 >>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrote= : >>> Yes in assertions it needs to be general. It is the JWT and SAML profi= les that need to nail down what the format of the audience is. They shou= ld probably both be the URI of the token endpoint. In both SAML and JWT t= here can be multiple audiences for the token. >>>=20 >>> John >>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." wro= te: >>>=20 >>>> It's my understanding that the general assertions claim is more of a c= onceptual mapping than it is a concrete encoding, so anything more specific= here would be out of place. I would like the authors to either confirm or = correct my assumptions, though. >=20 >>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>=20 >>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Since we thought we were done with it, I put this document on the=20 >>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>>> like its a real one that needs an answer. >>>>>=20 >>>>> I'd appreciate it if the WG could figure out if there's any change=20 >>>>> needed and either make that change in the next week, or else tell=20 >>>>> me to take the draft off the telechat agenda for now. >>>>>=20 >>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>>> time and we can sort out if any changes are needed later. >>>>>=20 >>>>> The reason why now+1-week matters, is that that's when IESG=20 >>>>> members tend to do their reviews and having 'em all review a=20 >>>>> moving target isn't a good plan. >>>>>=20 >>>>> Thanks, >>>>> S. >>>>>=20 >>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>> Hi guys, >>>>>>=20 >>>>>> Thanks for updating the assertion document and for incorporating the= comments received on the mailing list. >>>>>>=20 >>>>>> There is only one issue that caught my attention. You changed the de= scription of the audience element to the following text (in version -09 of = http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>> " >>>>>> Audience A value that identifies the parties intended to process th= e >>>>>> assertion. An audience value MAY be the URL of the Token Endpoint >>>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>> " >>>>>>=20 >>>>>> Since the value in the audience field is used to by the authorizatio= n server in a comparison operation (see Section 5.2) I believe the current = text will lead to interoperability problems. Not only is the comparision op= eration unspecified but even the value that is contained in the field is le= ft open. The RFC 2119 MAY does not really give a lot of hints of what shoul= d be put in there. >>>>>>=20 >>>>>> Without having a clear description of what identifier is contained i= n this field and how the comparison works it is either possible that a legi= timate client is rejected by the authorization server (which is annoying) o= r an assertion with an incorrect assertion is accepted (which is a security= problem). >>>>>>=20 >>>>>> Btw, the same issue can also be seen in http://tools.ietf.org/html/d= raft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-= saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 o= f http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" clai= m). From the description in the JWT document I was not quite sure whether t= he ability to carry an array of case sensitive strings for that field is al= so allowed in any of the assertion documents. >>>>>>=20 >>>>>> Note that there are two documents that provide input to this problem= space, namely: >>>>>> http://tools.ietf.org/html/rfc6125 >>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>=20 >>>>>> So, I would suggest to decide what type of identifier goes into this= field and then to point to a document that illustrates how the comparison = operation would look like. Possible identifiers are domain names, IP addres= ses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard= match (like "*.example.com") or only an equality match? Would "www.example= .com" be the same as "example.com" if they resolve to the same IP address(e= s)? >>>>>>=20 >>>>>> Ciao >>>>>> Hannes >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Mon Jan 14 09:37:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71A321F873B for ; Mon, 14 Jan 2013 09:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niNP8MzoHJ9X for ; Mon, 14 Jan 2013 09:37:17 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB221F873C for ; Mon, 14 Jan 2013 09:37:16 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 39B861F3061; Mon, 14 Jan 2013 12:37:16 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E7ED71F308E; Mon, 14 Jan 2013 12:37:15 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 14 Jan 2013 12:37:15 -0500 Message-ID: <50F44242.8070005@mitre.org> Date: Mon, 14 Jan 2013 12:37:06 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Boone, Keith W (GE Healthcare)" References: <5FEB27AF-72A4-469A-9687-6218F5475F56@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090302000302060308000200" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:37:20 -0000 --------------090302000302060308000200 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Keith, I think that splitting the application like this is definitely complicating things, and it fails to address one key problem: how do the "instances" authenticate with the "registrar" portion? You mention it could be an OAuth2 flow, but which one? Do these potentially public instances need to ask the user? How can you tell a good one from a bad one? With this in mind, it seems to me that you haven't actually solved the problem, just moved it one step down the line while introducing another place for sensitive materials like access tokens to leak from. In other words, what do you buy by having the registrar request tokens on behalf of someone else instead of them just getting their own tokens? Basing things on client_name or client_url are not going to work, since those fields are self-asserted. What's to stop me from registering a client with the same display name as "Good Client" that actually goes and does bad things? After reading through your writeup below, I still suggest (as per my previous email [1]) that you make use of a "client class" type approach with a centralized place to register the client classes. It would have many of the hallmarks that you're after and fits completely in the existing infrastructure. Faced with this use case, this is how I would personally go about building it: 1) Create a centralized "application registration" database for the network. 2) People go here to register their application once and get a deployment key, which is a signed JWT OAuth2 access token. 3) All downstream authorization servers know how to validate these deployment keys by checking the signature of the tokens or (better) doing an introspection call back to the centralized server. 4) Instances of an application get copies of the deployment key baked in and protected at runtime. This part could potentially leak out, so it shouldn't be trusted without verification and user involvement. 5) An instance does Dynamic Registration on the downstream AS, using the deployment key as authentication. 6) The downstream AS verifies this deployment key as in (3) 7) The downstream AS generates a new client_id and client_secret for the instance, tying it to the deployment key presented in (5) 6) Normal OAuth happens here, with the option to warn the user that the client was dynamically registered and/or is public -- this is best practice, not baked into the protocol itself. Now let's say that something goes wrong with the deployment key and it needs to be revoked so a new one can be issued. You either push the news out to the downstream AS through some kind of configuration management or you wait for it to call the token introspection again and see that something's up. Now the AS can decide if it wants to nuke all existing instances associated with that deployment key, including their secrets and their tokens. It's arguable that this doesn't buy you all that much over just baking a client_id into all of your instances and doing public clients, and that may be right. However, at least the token endpoint calls within a particular instance can't be coopted and traded by another instance of the same client, since their id and secret will be different. Is that worth the extra overhead? I'm not sure, but maybe so. -- Justin [1] http://www.ietf.org/mail-archive/web/oauth/current/msg10510.html On 01/13/2013 09:44 PM, Boone, Keith W (GE Healthcare) wrote: > > More walls of text as my understanding grows: > > I've revised my understanding a bit since my first posting. Let me > see if I can explain a little more clearly: > > 1.We'd like to have some way for authorization endpoints to make an > authorization decision based on policies about an application. > This is something that is deemed essential for these applications > since they will be accessing protected health information from > entities covered under or associated with entities covered under HIPAA. > In my initial thinking, the client credentials would identify the > application so that policy checking would be enabled by the data > holder. But the client_name and/or client_url could also be used by > the authorizer. > Policies might say something like: Application XYZ has been certified > by organization ABC to be compliant with policy 123, and should be > granted access. Or, Application XYZ is known to be a Trojan and > should not be granted access. Or Application XYZ is known to be > susceptible to virus QRS and should no longer be granted access. How > these policies are distributed to authorizers isn't part of this > discussion. Access tokens issued by authorizers could be sufficiently > short-lived that routine refreshes would be necessary, allowing policy > checks to be performed as frequently as necessary. > > 2.We'd like to facilitate an automated process whereby application can > be dynamically registered without requiring a lot of infrastructure. > > I think there are three actors in the registration process. I'll call > them the registrar, the application instance, and the authorization > endpoint. The registrar is a confidential client. It serves three > functions: > > 1.It "registers" application instances (others have referred to this > as the application) with itself, and configures those application > instances so that they can communicate with it securely in the future. > > 2.It registers an application (others have called this an application > class) with an authorizer. > > 3.It facilitates communication between an application instance and the > authorizer by obtaining authorization tokens which are then > communicated to the application instance to register itself with the > authorizer. > > The registrar "registers" the application (class) during the first > registration (thus, not needing an access_token), and since it is a > confidential client, can secure its client_id and client_secret. This > registration is scoped to only support facilitating the initial > authorization of an application instance (using the scope parameter). > > An application instance must configure itself (post deployment) by > communicating with the registrar. This will allow the application > instance and the registrar to secure their communications in future > conversations. How they do that is out of scope. An application will > be configured (pre-deployment) to communicate with a specific registrar. > > When an application instance wishes to be registered with an > authorizer that it hasn't seen before it performs the following steps: > > 1.It requests an access token from the registrar for the authorizer. > The registrar will, if it hasn't already, register the application > with the authorizer. It will then use its client_id and client_secret > with the authorizer to obtain an access token for the instance needing > registration. These will be returned to the application instance. > > 2.It uses that access token with the authorizer to register itself. > > What I've done here is essential split the client into two > components: A confidential registrar component, and a (possibly > public) application instance component. The registrar only > communicates with authorizers and application instances. It never > actually does any work with data holders. > > This seems like it would work for my use case, but still feels overly > cumbersome. In order to access data, an application instance: > > 1.Has to be pre-configured with a registrar. > > 2.Has to be post-configured by that registrar. > > 3.The registrar has to register the application with an authorization > endpoint. > > 4.The registrar has to obtain an access token from an authorization > endpoint on behalf of an application instance > > 5.The registrar has to communicate that access token to the > application instance. > > 6.The application instance has to register itself with the > authorization endpoint. > > 7.The data holder has to authorize the end user and the application > instance to access the data. > > To make myself feel better, I looked at each of these steps: > > 1.This pre-configuration is not hard. > > 2.Registering an installed application with the developer of that > application is a pretty common feature (in the PC world, not as much > in the mobile app world). That can be combined with the > post-configuration step that enables secure communication with the > registrar. This could even be similar to the dynamic registration > workflow, save that the application instance is dynamically > registering itself with the registrar. > > 3.This is very similar to step 6, and might often be coded by the same > developers, or use the same libraries. > > 4.This is standard OAuth stuff. > > 5.This could be done using standard OAuth stuff. In fact, step 2 > could in fact be an OAuth workflow, where an application instance > requests an access token from the registrar, which then reroutes that > request to the authorization endpoint, using its own credentials. > > 6.This is the basic dynamic registration. > > The registrar seems to be a simple enough web service that wouldn't > take a lot of infrastructure to develop or maintain. At a bare > minimum, it needs to store its client credentials for registrations > with different authorizers, and execute two different OAuth > workflows: Registering an application (class) with an authorizer, and > obtaining an authorization token from an authorization and > communicating that token to an application instance. A single > registrar service could be provided that supports multiple > applications, perhaps combining with other services (such as an app > store). If using other OAuth workflows. > > I thought about having the registrar do a couple of other things to > simplify, but they just didn't seem to work: > > 1.It could just configure the application with the client_id and > client_secret that were issued during the "first" registration. Even > though these could be secured during that post-installation > registration step, having each client instance share an id and secret > didn't feel secure. Someone will mess it up and that id and secret > could then be used as an attack vector. > > 2.The registrar could perform the registration for the client, and > return the client_id and secret it obtained on behalf of the client, > but the registrar and the application need not be created by the same > organizations, and the registrar would then have access to an id and > secret that it didn't need to have access to. > > Am I overthinking this, or is this right? > > Keith > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, January 13, 2013 12:29 PM > *To:* Boone, Keith W (GE Healthcare) > *Cc:* Richer, Justin P.; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg > > Hi Keith, > > comment see below. > > Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" > >: > > > > Imagine the case where I purchase an application and download it > to my iPhone and to my iPad. Then I connect that application to a > data holder/authorizer combination it hasn't seen before. Through > dynamic client registration, I could register that application for > my iPhone, but the instance of that same application running on my > iPad would know nothing about the first registration. So it would > attempt to do it all over again. What happens here? > > Is this a problem? The user should be able the data she desires from > both app, independent of the client id. > > What do your want to achieve? I don't understand why different > instances of an app need to be aware of each other. I would assume a > user wants to access the same data from all those instances. But this > is merely controlled by the user identity with the app. > > I see two possible scenarios: > > a) the app does not have an user management but relies on the user to > setup the connection to a particular resource server. The user would > do this on every device, i.e. every app instance would carry out the > OAuth dance with the particular authorizer. > > b) the app has their own user management. So the user would 1) > register for an account and 2) connect this account to the resources > managed by the authorizer. Assumption: the app has an backend and > stores user data there. On the second device, the user has only to > login using her app account and is done. > > Regards, > > Torsten. > > > > Keith > > *__________________________________ > _**Keith W. Boone* > Standards Architect > GE Healthcare > > M +1 617 640 7007 > > keith.boone@ge.com > www.gehealthcare.com > > 116 Huntington Ave > Boston, MA 02116 > USA > > GE imagination at work > > *From:*Richer, Justin P. [mailto:jricher@mitre.org] > *Sent:* Thursday, January 10, 2013 4:39 PM > *To:* Boone, Keith W (GE Healthcare) > *Cc:* oauth@ietf.org WG > *Subject:* Re: Mail regarding draft-ietf-oauth-dyn-reg > > Interesting use case, and not dissimilar to some others I've heard. > How would you go about tracking this? Why would the instances need to > know about each other? > > One possible approach would be to use a common initializing Request > Access Token that is used to call client_register on all instances of > a given client. They wouldn't know about each other, per se, but the > Authorization Server would at least know enough to be able to tie them > together. > > There's also the OAuth2 Instance Information extension that I had > tried to push a few years ago that comes up every now and again, that > might be of use here with some modifications: > > http://tools.ietf.org/html/draft-richer-oauth-instance-00 > > I think I'd like to know more about your concerns and the parameters > of your use case first. > > I am CC'ing the IETF OAuth Working Group email list, where this draft > is being discussed and worked on. > > -- Justin > > On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" > > wrote: > > > > > I would like to be able to use this protocol to dynamically register > clients, but am challenged by the fact that there could be multiple > instances of a public client, each unaware of what others have done. > The current protocol doesn't seem to address this. > > > Keith > > *__________________________________ > _**Keith W. Boone* > Standards Architect > GE Healthcare > > M +1 617 640 7007 > > keith.boone@ge.com > www.gehealthcare.com > > 116 Huntington Ave > Boston, MA 02116 > USA > > GE imagination at work > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090302000302060308000200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Keith,

I think that splitting the application like this is definitely complicating things, and it fails to address one key problem: how do the "instances" authenticate with the "registrar" portion? You mention it could be an OAuth2 flow, but which one? Do these potentially public instances need to ask the user? How can you tell a good one from a bad one? With this in mind, it seems to me that you haven't actually solved the problem, just moved it one step down the line while introducing another place for sensitive materials like access tokens to leak from. In other words, what do you buy by having the registrar request tokens on behalf of someone else instead of them just getting their own tokens? Basing things on client_name or client_url are not going to work, since those fields are self-asserted. What's to stop me from registering a client with the same display name as "Good Client" that actually goes and does bad things?

After reading through your writeup below, I still suggest (as per my previous email [1]) that you make use of a "client class" type approach with a centralized place to register the client classes. It would have many of the hallmarks that you're after and fits completely in the existing infrastructure. Faced with this use case, this is how I would personally go about building it:

1) Create a centralized "application registration" database for the network.
2) People go here to register their application once and get a deployment key, which is a signed JWT OAuth2 access token.
3) All downstream authorization servers know how to validate these deployment keys by checking the signature of the tokens or (better) doing an introspection call back to the centralized server.
4) Instances of an application get copies of the deployment key baked in and protected at runtime. This part could potentially leak out, so it shouldn't be trusted without verification and user involvement.
5) An instance does Dynamic Registration on the downstream AS, using the deployment key as authentication.
6) The downstream AS verifies this deployment key as in (3)
7) The downstream AS generates a new client_id and client_secret for the instance, tying it to the deployment key presented in (5)
6) Normal OAuth happens here, with the option to warn the user that the client was dynamically registered and/or is public -- this is best practice, not baked into the protocol itself.

Now let's say that something goes wrong with the deployment key and it needs to be revoked so a new one can be issued. You either push the news out to the downstream AS through some kind of configuration management or you wait for it to call the token introspection again and see that something's up. Now the AS can decide if it wants to nuke all existing instances associated with that deployment key, including their secrets and their tokens.

It's arguable that this doesn't buy you all that much over just baking a client_id into all of your instances and doing public clients, and that may be right. However, at least the token endpoint calls within a particular instance can't be coopted and traded by another instance of the same client, since their id and secret will be different. Is that worth the extra overhead? I'm not sure, but maybe so.

-- Justin

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg10510.html



On 01/13/2013 09:44 PM, Boone, Keith W (GE Healthcare) wrote:

More walls of text as my understanding grows:

I've revised my understanding a bit since my first posting. Let me see if I can explain a little more clearly:

1. We'd like to have some way for authorization endpoints to make an authorization decision based on policies about an application.
This is something that is deemed essential for these applications since they will be accessing protected health information from entities covered under or associated with entities covered under HIPAA.
In my initial thinking, the client credentials would identify the application so that policy checking would be enabled by the data holder. But the client_name and/or client_url could also be used by the authorizer.
Policies might say something like: Application XYZ has been certified by organization ABC to be compliant with policy 123, and should be granted access. Or, Application XYZ is known to be a Trojan and should not be granted access. Or Application XYZ is known to be susceptible to virus QRS and should no longer be granted access. How these policies are distributed to authorizers isn't part of this discussion. Access tokens issued by authorizers could be sufficiently short-lived that routine refreshes would be necessary, allowing policy checks to be performed as frequently as necessary.

2. We'd like to facilitate an automated process whereby application can be dynamically registered without requiring a lot of infrastructure.

I think there are three actors in the registration process. I'll call them the registrar, the application instance, and the authorization endpoint. The registrar is a confidential client. It serves three functions:

1. It "registers" application instances (others have referred to this as the application) with itself, and configures those application instances so that they can communicate with it securely in the future.

2. It registers an application (others have called this an application class) with an authorizer.

3. It facilitates communication between an application instance and the authorizer by obtaining authorization tokens which are then communicated to the application instance to register itself with the authorizer.

The registrar "registers" the application (class) during the first registration (thus, not needing an access_token), and since it is a confidential client, can secure its client_id and client_secret. This registration is scoped to only support facilitating the initial authorization of an application instance (using the scope parameter).

An application instance must configure itself (post deployment) by communicating with the registrar. This will allow the application instance and the registrar to secure their communications in future conversations. How they do that is out of scope. An application will be configured (pre-deployment) to communicate with a specific registrar.

When an application instance wishes to be registered with an authorizer that it hasn't seen before it performs the following steps:

1. It requests an access token from the registrar for the authorizer. The registrar will, if it hasn't already, register the application with the authorizer. It will then use its client_id and client_secret with the authorizer to obtain an access token for the instance needing registration. These will be returned to the application instance.

2. It uses that access token with the authorizer to register itself.

What I've done here is essential split the client into two components: A confidential registrar component, and a (possibly public) application instance component. The registrar only communicates with authorizers and application instances. It never actually does any work with data holders.

This seems like it would work for my use case, but still feels overly cumbersome. In order to access data, an application instance:

1. Has to be pre-configured with a registrar.

2. Has to be post-configured by that registrar.

3. The registrar has to register the application with an authorization endpoint.

4. The registrar has to obtain an access token from an authorization endpoint on behalf of an application instance

5. The registrar has to communicate that access token to the application instance.

6. The application instance has to register itself with the authorization endpoint.

7. The data holder has to authorize the end user and the application instance to access the data.

To make myself feel better, I looked at each of these steps:

1. This pre-configuration is not hard.

2. Registering an installed application with the developer of that application is a pretty common feature (in the PC world, not as much in the mobile app world). That can be combined with the post-configuration step that enables secure communication with the registrar. This could even be similar to the dynamic registration workflow, save that the application instance is dynamically registering itself with the registrar.

3. This is very similar to step 6, and might often be coded by the same developers, or use the same libraries.

4. This is standard OAuth stuff.

5. This could be done using standard OAuth stuff. In fact, step 2 could in fact be an OAuth workflow, where an application instance requests an access token from the registrar, which then reroutes that request to the authorization endpoint, using its own credentials.

6. This is the basic dynamic registration.

The registrar seems to be a simple enough web service that wouldn't take a lot of infrastructure to develop or maintain. At a bare minimum, it needs to store its client credentials for registrations with different authorizers, and execute two different OAuth workflows: Registering an application (class) with an authorizer, and obtaining an authorization token from an authorization and communicating that token to an application instance. A single registrar service could be provided that supports multiple applications, perhaps combining with other services (such as an app store). If using other OAuth workflows.

I thought about having the registrar do a couple of other things to simplify, but they just didn't seem to work:

1. It could just configure the application with the client_id and client_secret that were issued during the "first" registration. Even though these could be secured during that post-installation registration step, having each client instance share an id and secret didn't feel secure. Someone will mess it up and that id and secret could then be used as an attack vector.

2. The registrar could perform the registration for the client, and return the client_id and secret it obtained on behalf of the client, but the registrar and the application need not be created by the same organizations, and the registrar would then have access to an id and secret that it didn't need to have access to.

Am I overthinking this, or is this right?

Keith

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, January 13, 2013 12:29 PM
To: Boone, Keith W (GE Healthcare)
Cc: Richer, Justin P.; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg

Hi Keith,

comment see below.

Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>:

<snip>

Imagine the case where I purchase an application and download it to my iPhone and to my iPad. Then I connect that application to a data holder/authorizer combination it hasn't seen before. Through dynamic client registration, I could register that application for my iPhone, but the instance of that same application running on my iPad would know nothing about the first registration. So it would attempt to do it all over again. What happens here?

Is this a problem? The user should be able the data she desires from both app, independent of the client id.

What do your want to achieve? I don't understand why different instances of an app need to be aware of each other. I would assume a user wants to access the same data from all those instances. But this is merely controlled by the user identity with the app.

I see two possible scenarios:

a) the app does not have an user management but relies on the user to setup the connection to a particular resource server. The user would do this on every device, i.e. every app instance would carry out the OAuth dance with the particular authorizer.

b) the app has their own user management. So the user would 1) register for an account and 2) connect this account to the resources managed by the authorizer. Assumption: the app has an backend and stores user data there. On the second device, the user has only to login using her app account and is done.

Regards,

Torsten.



Keith

_________________________________
Keith W. Boone
StandardsArchitect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: oauth@ietf.org WG
Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg

Interesting use case, and not dissimilar to some others I've heard. How would you go about tracking this? Why would the instances need to know about each other?

One possible approach would be to use a common initializing Request Access Token that is used to call client_register on all instances of a given client. They wouldn't know about each other, per se, but the Authorization Server would at least know enough to be able to tie them together.

There's also the OAuth2 Instance Information extension that I had tried to push a few years ago that comes up every now and again, that might be of use here with some modifications:

I think I'd like to know more about your concerns and the parameters of your use case first.

I am CC'ing the IETF OAuth Working Group email list, where this draft is being discussed and worked on.

-- Justin

On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com> wrote:




I would like to be able to use this protocol to dynamically register clients, but am challenged by the fact that there could be multiple instances of a public client, each unaware of what others have done. The current protocol doesn't seem to address this.


Keith

_________________________________
Keith W. Boone
StandardsArchitect
GE Healthcare

M +1 617 640 7007

keith.boone@ge.com
www.gehealthcare.com

116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

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


--------------090302000302060308000200-- From Michael.Jones@microsoft.com Tue Jan 15 09:21:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6ED21F873C for ; Tue, 15 Jan 2013 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMOu6nidkFFS for ; Tue, 15 Jan 2013 09:21:37 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8B21F872C for ; Tue, 15 Jan 2013 09:21:36 -0800 (PST) Received: from BY2FFO11FD002.protection.gbl (10.1.15.201) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.596.13; Tue, 15 Jan 2013 17:21:32 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Tue, 15 Jan 2013 17:21:32 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 15 Jan 2013 17:20:47 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RTcHXvPlTOOEyaLkX1rm6jbZhD/pUAgAA0JQCAABW0gIAAIGKAgAGzmACAAA5L0IAA3e+AgAACUkCAAAx9gIABUfFAgAI/n+A= Date: Tue, 15 Jan 2013 17:20:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A44A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(164054002)(377424002)(13464002)(51704002)(24454001)(479174001)(52144001)(52604002)(52544001)(59766001)(47776002)(51856001)(54316002)(56776001)(550184003)(33656001)(53806001)(31966008)(49866001)(77982001)(79102001)(47446002)(50466001)(74502001)(76482001)(56816002)(47976001)(15202345001)(5343635001)(50986001)(23726001)(44976002)(47736001)(5343655001)(55846006)(4396001)(46406002)(46102001)(54356001)(16406001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0727122FC6 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:21:38 -0000 Hi Hannes, Can you please either give me a call for us to talk about the changes you h= ave in mind or write down the specific changes you want? I'd like us to re= ach a mutual understanding of what you're trying to achieve in time for Ste= phen to proceed with the telechat on schedule. Thank you, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Sunday, January 13, 2013 11:03 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 I'm thinking it would be useful for us to talk on the phone or Skype tomorr= ow, Hannes, because I'm pretty sure I don't know what specific changes you'= re asking for in which specs. Are you, for instance, asking for language s= aying that audience values are to be compared for equality as case-sensitiv= e strings in the SAML bearer and JWT bearer specs? (They're not just URIs,= as they can be OAuth Client IDs.) Or maybe you can propose specific langu= age changes, so it's clear what you're asking for. Thanks, -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike,=20 it is fine to support different identifiers and to even allow the set of su= pported identifiers to get extended over time.=20 Just omitting a description is, however, not an option. We are in the lucky= position where others have done the work for us already (as mentioned in t= he two cited references). For the IAB document there is even the chance to = provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issue= s-in-identifier-comparison-for-security-purposes/) in case you believe the = author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: > We already know of use cases where the audience is an abstract identifier= and use cases where the audience is the URL of the token endpoint. Both a= re legitimate. We should foreclose neither. >=20 > Like many things OAuth, interoperability can be achieved, but it may requ= ire a profile further specifying the behaviors appropriate to that use case= . This is not a bug - it is a feature, as it increases the applicability o= f the OAuth specifications. >=20 > The Assertion, JWT Profile, and SAML Profile are striking an appropriate = balance by providing guidance on likely audience values for many use cases,= but not precluding other values where necessary for those use cases. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, January 13, 2013 1:56 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org=20 > WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike, >=20 > I understand your reasoning: you want to keep all options open in the fra= mework specification and you want to be more specific in draft-ietf-oauth-j= wt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >=20 > The RFC 2119 language does not add anything but it does not hurt either. = It just says that there could essentially be anything in there, including t= he URL of the Token Endpoint. >=20 > You can of course post-pone dealing with the issue to the more specific d= ocuments. For example, draft-ietf-oauth-jwt-bearer at the moment does not a= llow an interoperable deployment since it just repeats the abstract framewo= rk text by saying "The token endpoint URL of the authorization server MAY b= e used as an acceptable value for an "aud" element."=20 >=20 > Ciao > Hannes >=20 > On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >=20 >> Hi Hannes, >>=20 >> For the reasons that Justin and Brian state, I believe that the MAY is a= ppropriate. In some use cases, a good representation of an appropriate aud= ience value is URL of the Token Endpoint. That's there in the Assertions s= pecification as guidance to writers token-type specific specs using the Ass= ertions spec, as I believe it should be. That being the case, as Brian des= cribes, sometimes audience values are more abstract identifiers or identifi= ers for groups of services, and we don't want to inadvertently preclude tho= se actual use cases. >>=20 >> Thus, I believe that the language is appropriate as-is. Thus, I believe= that we should proceed with the currently scheduled telechat discussion of= the spec. >>=20 >> Thanks all= , >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Hannes Tschofenig >> Sent: Saturday, January 12, 2013 11:50 AM >> To: Brian Campbell >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Brian, >>=20 >> I understand that this is challenging. >>=20 >> Nevertheless it would make sense to describe the desired behavior in dra= ft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way= that two versions developed by different groups would interoperate without= causing security problems or failures.=20 >>=20 >> To move forward with draft-ietf-oauth-assertions I suggest to follow the= recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10= 507.html and to address the details in draft-ietf-oauth-jwt-bearer and in = draft-ietf-oauth-saml2-bearer as soon as possible to get these documents mo= ving forward and completed soon.=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>=20 >>> That text around audience in the framework spec changed from a SHOULD t= o a MAY in -09 so that it would be more consistent with the the SAML and JW= T versions, which were already using a MAY in that context. >>>=20 >>> Your concern is valid Hannes and your point is taken. But reality is ra= ther messy and I don't believe it can addressed as easily as you suggest. = =20 >>>=20 >>> In SAML, for example, an entity identifier is often used as a value for= the audience (per spec and in practice). But an AS may not necessarily id= entify itself with a full blown SAML entity, in which case the token endpoi= nt URI is more appropriate. The whole issue is also somewhat complicated in= SAML too by it having both audience and recipient that are similar but not= the same. I've tried to account for all of this in the SAML doc but it's a= dmittedly somewhat awkward and complex and not as simple as saying the valu= e has to be X and must be validated in exactly such a way. >>>=20 >>> JWT doesn't have the same history and baggage of SAML but is subject to= many of the same real world deployment variations. >>>=20 >>> I'm definitely open to improvements with respect to the handling of=20 >>> audience values but I believe anything that is done needs to reflect=20 >>> the realities of current implementations and deployments as well as=20 >>> related specifications., >>>=20 >>>=20 >>>=20 >>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrote= : >>> Yes in assertions it needs to be general. It is the JWT and SAML profi= les that need to nail down what the format of the audience is. They shou= ld probably both be the URI of the token endpoint. In both SAML and JWT t= here can be multiple audiences for the token. >>>=20 >>> John >>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." wro= te: >>>=20 >>>> It's my understanding that the general assertions claim is more of a c= onceptual mapping than it is a concrete encoding, so anything more specific= here would be out of place. I would like the authors to either confirm or = correct my assumptions, though. >=20 >>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>=20 >>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Since we thought we were done with it, I put this document on the=20 >>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>>> like its a real one that needs an answer. >>>>>=20 >>>>> I'd appreciate it if the WG could figure out if there's any change=20 >>>>> needed and either make that change in the next week, or else tell=20 >>>>> me to take the draft off the telechat agenda for now. >>>>>=20 >>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>>> time and we can sort out if any changes are needed later. >>>>>=20 >>>>> The reason why now+1-week matters, is that that's when IESG=20 >>>>> members tend to do their reviews and having 'em all review a=20 >>>>> moving target isn't a good plan. >>>>>=20 >>>>> Thanks, >>>>> S. >>>>>=20 >>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>> Hi guys, >>>>>>=20 >>>>>> Thanks for updating the assertion document and for incorporating the= comments received on the mailing list. >>>>>>=20 >>>>>> There is only one issue that caught my attention. You changed the de= scription of the audience element to the following text (in version -09 of = http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>> " >>>>>> Audience A value that identifies the parties intended to process th= e >>>>>> assertion. An audience value MAY be the URL of the Token Endpoint >>>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>> " >>>>>>=20 >>>>>> Since the value in the audience field is used to by the authorizatio= n server in a comparison operation (see Section 5.2) I believe the current = text will lead to interoperability problems. Not only is the comparision op= eration unspecified but even the value that is contained in the field is le= ft open. The RFC 2119 MAY does not really give a lot of hints of what shoul= d be put in there. >>>>>>=20 >>>>>> Without having a clear description of what identifier is contained i= n this field and how the comparison works it is either possible that a legi= timate client is rejected by the authorization server (which is annoying) o= r an assertion with an incorrect assertion is accepted (which is a security= problem). >>>>>>=20 >>>>>> Btw, the same issue can also be seen in http://tools.ietf.org/html/d= raft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-= saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 o= f http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" clai= m). From the description in the JWT document I was not quite sure whether t= he ability to carry an array of case sensitive strings for that field is al= so allowed in any of the assertion documents. >>>>>>=20 >>>>>> Note that there are two documents that provide input to this problem= space, namely: >>>>>> http://tools.ietf.org/html/rfc6125 >>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>=20 >>>>>> So, I would suggest to decide what type of identifier goes into this= field and then to point to a document that illustrates how the comparison = operation would look like. Possible identifiers are domain names, IP addres= ses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard= match (like "*.example.com") or only an equality match? Would "www.example= .com" be the same as "example.com" if they resolve to the same IP address(e= s)? >>>>>>=20 >>>>>> Ciao >>>>>> Hannes >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> 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 >>=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 hannes.tschofenig@gmx.net Tue Jan 15 10:33:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327B211E80E1 for ; Tue, 15 Jan 2013 10:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.17 X-Spam-Level: X-Spam-Status: No, score=-101.17 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aieZ-XAEL+Ip for ; Tue, 15 Jan 2013 10:33:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C497811E80E0 for ; Tue, 15 Jan 2013 10:33:47 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MGDc1-1Th97F3LKZ-00F8z3 for ; Tue, 15 Jan 2013 19:33:46 +0100 Received: (qmail invoked by alias); 15 Jan 2013 18:33:46 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp001) with SMTP; 15 Jan 2013 19:33:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/UPC928VvU6FHL6Dth7QmrDAhKeGslqv+pSn67BM /YV9z31wKeAzM6 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A44A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 15 Jan 2013 20:33:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <240132C1-2D4C-463A-88CB-AEA776C1E84F@gmx.net> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A44A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:33:49 -0000 Hi Mike,=20 I am sure the rest of the working group is interested to see how = difficult it is to arrange a conference call when one person is in = Espoo/Finland and the other person in the West Coast. In any case, I am online and ready to chat.=20 In any case I will let the group know what conclusions we reached.=20 Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: > Hi Hannes, >=20 > Can you please either give me a call for us to talk about the changes = you have in mind or write down the specific changes you want? I'd like = us to reach a mutual understanding of what you're trying to achieve in = time for Stephen to proceed with the telechat on schedule. >=20 > Thank you, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Sunday, January 13, 2013 11:03 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > I'm thinking it would be useful for us to talk on the phone or Skype = tomorrow, Hannes, because I'm pretty sure I don't know what specific = changes you're asking for in which specs. Are you, for instance, asking = for language saying that audience values are to be compared for equality = as case-sensitive strings in the SAML bearer and JWT bearer specs? = (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you = can propose specific language changes, so it's clear what you're asking = for. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, January 13, 2013 2:49 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org = WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike,=20 >=20 > it is fine to support different identifiers and to even allow the set = of supported identifiers to get extended over time.=20 >=20 > Just omitting a description is, however, not an option. We are in the = lucky position where others have done the work for us already (as = mentioned in the two cited references). For the IAB document there is = even the chance to provide feedback (see = https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-compa= rison-for-security-purposes/) in case you believe the author is = misguided. We just need to make use of them. >=20 > Ciao > Hannes >=20 > On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: >=20 >> We already know of use cases where the audience is an abstract = identifier and use cases where the audience is the URL of the token = endpoint. Both are legitimate. We should foreclose neither. >>=20 >> Like many things OAuth, interoperability can be achieved, but it may = require a profile further specifying the behaviors appropriate to that = use case. This is not a bug - it is a feature, as it increases the = applicability of the OAuth specifications. >>=20 >> The Assertion, JWT Profile, and SAML Profile are striking an = appropriate balance by providing guidance on likely audience values for = many use cases, but not precluding other values where necessary for = those use cases. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Sunday, January 13, 2013 1:56 AM >> To: Mike Jones >> Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; = oauth@ietf.org=20 >> WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Mike, >>=20 >> I understand your reasoning: you want to keep all options open in the = framework specification and you want to be more specific in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >>=20 >> The RFC 2119 language does not add anything but it does not hurt = either. It just says that there could essentially be anything in there, = including the URL of the Token Endpoint. >>=20 >> You can of course post-pone dealing with the issue to the more = specific documents. For example, draft-ietf-oauth-jwt-bearer at the = moment does not allow an interoperable deployment since it just repeats = the abstract framework text by saying "The token endpoint URL of the = authorization server MAY be used as an acceptable value for an "aud" = element."=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >>=20 >>> Hi Hannes, >>>=20 >>> For the reasons that Justin and Brian state, I believe that the MAY = is appropriate. In some use cases, a good representation of an = appropriate audience value is URL of the Token Endpoint. That's there = in the Assertions specification as guidance to writers token-type = specific specs using the Assertions spec, as I believe it should be. = That being the case, as Brian describes, sometimes audience values are = more abstract identifiers or identifiers for groups of services, and we = don't want to inadvertently preclude those actual use cases. >>>=20 >>> Thus, I believe that the language is appropriate as-is. Thus, I = believe that we should proceed with the currently scheduled telechat = discussion of the spec. >>>=20 >>> Thanks = all, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >>> Behalf Of Hannes Tschofenig >>> Sent: Saturday, January 12, 2013 11:50 AM >>> To: Brian Campbell >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>>=20 >>> Hi Brian, >>>=20 >>> I understand that this is challenging. >>>=20 >>> Nevertheless it would make sense to describe the desired behavior in = draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such = a way that two versions developed by different groups would interoperate = without causing security problems or failures.=20 >>>=20 >>> To move forward with draft-ietf-oauth-assertions I suggest to follow = the recommendation in = http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to = address the details in draft-ietf-oauth-jwt-bearer and in = draft-ietf-oauth-saml2-bearer as soon as possible to get these documents = moving forward and completed soon.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>>=20 >>>> That text around audience in the framework spec changed from a = SHOULD to a MAY in -09 so that it would be more consistent with the the = SAML and JWT versions, which were already using a MAY in that context. >>>>=20 >>>> Your concern is valid Hannes and your point is taken. But reality = is rather messy and I don't believe it can addressed as easily as you = suggest. =20 >>>>=20 >>>> In SAML, for example, an entity identifier is often used as a value = for the audience (per spec and in practice). But an AS may not = necessarily identify itself with a full blown SAML entity, in which case = the token endpoint URI is more appropriate. The whole issue is also = somewhat complicated in SAML too by it having both audience and = recipient that are similar but not the same. I've tried to account for = all of this in the SAML doc but it's admittedly somewhat awkward and = complex and not as simple as saying the value has to be X and must be = validated in exactly such a way. >>>>=20 >>>> JWT doesn't have the same history and baggage of SAML but is = subject to many of the same real world deployment variations. >>>>=20 >>>> I'm definitely open to improvements with respect to the handling of=20= >>>> audience values but I believe anything that is done needs to = reflect=20 >>>> the realities of current implementations and deployments as well as=20= >>>> related specifications., >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley = wrote: >>>> Yes in assertions it needs to be general. It is the JWT and SAML = profiles that need to nail down what the format of the audience is. = They should probably both be the URI of the token endpoint. In both = SAML and JWT there can be multiple audiences for the token. >>>>=20 >>>> John >>>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." = wrote: >>>>=20 >>>>> It's my understanding that the general assertions claim is more of = a conceptual mapping than it is a concrete encoding, so anything more = specific here would be out of place. I would like the authors to either = confirm or correct my assumptions, though. >>=20 >>>=20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>=20 >>>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Since we thought we were done with it, I put this document on the=20= >>>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20= >>>>>> like its a real one that needs an answer. >>>>>>=20 >>>>>> I'd appreciate it if the WG could figure out if there's any = change=20 >>>>>> needed and either make that change in the next week, or else tell=20= >>>>>> me to take the draft off the telechat agenda for now. >>>>>>=20 >>>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>>> conclusion, then I'll take the draft off the agenda in a week's=20= >>>>>> time and we can sort out if any changes are needed later. >>>>>>=20 >>>>>> The reason why now+1-week matters, is that that's when IESG=20 >>>>>> members tend to do their reviews and having 'em all review a=20 >>>>>> moving target isn't a good plan. >>>>>>=20 >>>>>> Thanks, >>>>>> S. >>>>>>=20 >>>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>>> Hi guys, >>>>>>>=20 >>>>>>> Thanks for updating the assertion document and for incorporating = the comments received on the mailing list. >>>>>>>=20 >>>>>>> There is only one issue that caught my attention. You changed = the description of the audience element to the following text (in = version -09 of = http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>>> " >>>>>>> Audience A value that identifies the parties intended to = process the >>>>>>> assertion. An audience value MAY be the URL of the Token = Endpoint >>>>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>>> " >>>>>>>=20 >>>>>>> Since the value in the audience field is used to by the = authorization server in a comparison operation (see Section 5.2) I = believe the current text will lead to interoperability problems. Not = only is the comparision operation unspecified but even the value that is = contained in the field is left open. The RFC 2119 MAY does not really = give a lot of hints of what should be put in there. >>>>>>>=20 >>>>>>> Without having a clear description of what identifier is = contained in this field and how the comparison works it is either = possible that a legitimate client is rejected by the authorization = server (which is annoying) or an assertion with an incorrect assertion = is accepted (which is a security problem). >>>>>>>=20 >>>>>>> Btw, the same issue can also be seen in = http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a = more generic form also in the JWT (Section 4.1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" = claim). =46rom the description in the JWT document I was not quite sure = whether the ability to carry an array of case sensitive strings for that = field is also allowed in any of the assertion documents. >>>>>>>=20 >>>>>>> Note that there are two documents that provide input to this = problem space, namely: >>>>>>> http://tools.ietf.org/html/rfc6125 >>>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>>=20 >>>>>>> So, I would suggest to decide what type of identifier goes into = this field and then to point to a document that illustrates how the = comparison operation would look like. Possible identifiers are domain = names, IP addresses, URIs, etc. Just as an example from RFC 6125 would = you allow a wildcard match (like "*.example.com") or only an equality = match? Would "www.example.com" be the same as "example.com" if they = resolve to the same IP address(es)? >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 15 18:27:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98C21F85D0 for ; Tue, 15 Jan 2013 18:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssgWNz1d-K6y for ; Tue, 15 Jan 2013 18:27:31 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 191FE21F8570 for ; Tue, 15 Jan 2013 18:27:31 -0800 (PST) Received: from BL2FFO11FD016.protection.gbl (10.173.161.200) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 16 Jan 2013 02:27:22 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 16 Jan 2013 02:27:21 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 16 Jan 2013 02:26:57 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN79RTcHXvPlTOOEyaLkX1rm6jbZhD/pUAgAA0JQCAABW0gIAAIGKAgAGzmACAAA5L0IAA3e+AgAACUkCAAAx9gIABUfFAgAI/n+CAABUIAIAAg/uQ Date: Wed, 16 Jan 2013 02:26:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A4898B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A44A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> <240132C1-2D4C-463A-88CB-AEA776C1E84F@gmx.net> In-Reply-To: <240132C1-2D4C-463A-88CB-AEA776C1E84F@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52604002)(479174001)(24454001)(377454001)(377424002)(164054002)(13464002)(52544001)(52144001)(51704002)(74662001)(74502001)(47446002)(54356001)(44976002)(46102001)(53806001)(56776001)(77982001)(79102001)(550184003)(59766001)(47736001)(15202345001)(47976001)(31966008)(47776002)(55846006)(51856001)(46406002)(50466001)(33656001)(4396001)(76482001)(16406001)(49866001)(54316002)(50986001)(23726001)(5343655001)(5343635001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB039; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07283408BE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:27:32 -0000 Hannes and I spoke and went through the issues. He was trying to maximize = interoperability of implementations which is obviously a good goal. Howeve= r, after discussing the particulars, we also agreed that, for some features= and use cases, specific profiles of the assertions will be needed to achie= ve complete interoperability (just like profiles of OAuth are required to a= chieve interoperability). Therefore, we propose to add an explanatory paragraph to the assertions doc= ument explaining that profiling will be required to achieve interoperabilit= y in some cases. This would be in exactly the same spirit as http://tools.= ietf.org/html/rfc6749#section-1.8, which supplies the same kinds of caveats= to implementer's of OAuth Core. I'll work on proposed specific wording shortly. I'll note that adding this= text will not change the meaning of the document in any way - it will simp= ly provide additional guidance to implementers on how to think about using = the assertion framework. Best wishes, -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Tuesday, January 15, 2013 10:34 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike,=20 I am sure the rest of the working group is interested to see how difficult = it is to arrange a conference call when one person is in Espoo/Finland and = the other person in the West Coast. In any case, I am online and ready to chat.=20 In any case I will let the group know what conclusions we reached.=20 Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: > Hi Hannes, >=20 > Can you please either give me a call for us to talk about the changes you= have in mind or write down the specific changes you want? I'd like us to = reach a mutual understanding of what you're trying to achieve in time for S= tephen to proceed with the telechat on schedule. >=20 > Thank you, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Mike Jones > Sent: Sunday, January 13, 2013 11:03 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > I'm thinking it would be useful for us to talk on the phone or Skype tomo= rrow, Hannes, because I'm pretty sure I don't know what specific changes yo= u're asking for in which specs. Are you, for instance, asking for language= saying that audience values are to be compared for equality as case-sensit= ive strings in the SAML bearer and JWT bearer specs? (They're not just URI= s, as they can be OAuth Client IDs.) Or maybe you can propose specific lan= guage changes, so it's clear what you're asking for. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, January 13, 2013 2:49 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org=20 > WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike, >=20 > it is fine to support different identifiers and to even allow the set of = supported identifiers to get extended over time.=20 >=20 > Just omitting a description is, however, not an option. We are in the luc= ky position where others have done the work for us already (as mentioned in= the two cited references). For the IAB document there is even the chance t= o provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-iss= ues-in-identifier-comparison-for-security-purposes/) in case you believe th= e author is misguided. We just need to make use of them. >=20 > Ciao > Hannes >=20 > On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: >=20 >> We already know of use cases where the audience is an abstract identifie= r and use cases where the audience is the URL of the token endpoint. Both = are legitimate. We should foreclose neither. >>=20 >> Like many things OAuth, interoperability can be achieved, but it may req= uire a profile further specifying the behaviors appropriate to that use cas= e. This is not a bug - it is a feature, as it increases the applicability = of the OAuth specifications. >>=20 >> The Assertion, JWT Profile, and SAML Profile are striking an appropriate= balance by providing guidance on likely audience values for many use cases= , but not precluding other values where necessary for those use cases. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Sunday, January 13, 2013 1:56 AM >> To: Mike Jones >> Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell;=20 >> oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Mike, >>=20 >> I understand your reasoning: you want to keep all options open in the fr= amework specification and you want to be more specific in draft-ietf-oauth-= jwt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >>=20 >> The RFC 2119 language does not add anything but it does not hurt either.= It just says that there could essentially be anything in there, including = the URL of the Token Endpoint. >>=20 >> You can of course post-pone dealing with the issue to the more specific = documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not = allow an interoperable deployment since it just repeats the abstract framew= ork text by saying "The token endpoint URL of the authorization server MAY = be used as an acceptable value for an "aud" element."=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >>=20 >>> Hi Hannes, >>>=20 >>> For the reasons that Justin and Brian state, I believe that the MAY is = appropriate. In some use cases, a good representation of an appropriate au= dience value is URL of the Token Endpoint. That's there in the Assertions = specification as guidance to writers token-type specific specs using the As= sertions spec, as I believe it should be. That being the case, as Brian de= scribes, sometimes audience values are more abstract identifiers or identif= iers for groups of services, and we don't want to inadvertently preclude th= ose actual use cases. >>>=20 >>> Thus, I believe that the language is appropriate as-is. Thus, I believ= e that we should proceed with the currently scheduled telechat discussion o= f the spec. >>>=20 >>> Thanks all= , >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >>> Behalf Of Hannes Tschofenig >>> Sent: Saturday, January 12, 2013 11:50 AM >>> To: Brian Campbell >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>>=20 >>> Hi Brian, >>>=20 >>> I understand that this is challenging. >>>=20 >>> Nevertheless it would make sense to describe the desired behavior in dr= aft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a wa= y that two versions developed by different groups would interoperate withou= t causing security problems or failures.=20 >>>=20 >>> To move forward with draft-ietf-oauth-assertions I suggest to follow th= e recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg1= 0507.html and to address the details in draft-ietf-oauth-jwt-bearer and in= draft-ietf-oauth-saml2-bearer as soon as possible to get these documents m= oving forward and completed soon.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>>=20 >>>> That text around audience in the framework spec changed from a SHOULD = to a MAY in -09 so that it would be more consistent with the the SAML and J= WT versions, which were already using a MAY in that context. >>>>=20 >>>> Your concern is valid Hannes and your point is taken. But reality is r= ather messy and I don't believe it can addressed as easily as you suggest. = =20 >>>>=20 >>>> In SAML, for example, an entity identifier is often used as a value fo= r the audience (per spec and in practice). But an AS may not necessarily i= dentify itself with a full blown SAML entity, in which case the token endpo= int URI is more appropriate. The whole issue is also somewhat complicated i= n SAML too by it having both audience and recipient that are similar but no= t the same. I've tried to account for all of this in the SAML doc but it's = admittedly somewhat awkward and complex and not as simple as saying the val= ue has to be X and must be validated in exactly such a way. >>>>=20 >>>> JWT doesn't have the same history and baggage of SAML but is subject t= o many of the same real world deployment variations. >>>>=20 >>>> I'm definitely open to improvements with respect to the handling of=20 >>>> audience values but I believe anything that is done needs to=20 >>>> reflect the realities of current implementations and deployments as=20 >>>> well as related specifications., >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrot= e: >>>> Yes in assertions it needs to be general. It is the JWT and SAML prof= iles that need to nail down what the format of the audience is. They sho= uld probably both be the URI of the token endpoint. In both SAML and JWT = there can be multiple audiences for the token. >>>>=20 >>>> John >>>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." wr= ote: >>>>=20 >>>>> It's my understanding that the general assertions claim is more of a = conceptual mapping than it is a concrete encoding, so anything more specifi= c here would be out of place. I would like the authors to either confirm or= correct my assumptions, though. >>=20 >>>=20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>=20 >>>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Since we thought we were done with it, I put this document on the=20 >>>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>>>> like its a real one that needs an answer. >>>>>>=20 >>>>>> I'd appreciate it if the WG could figure out if there's any=20 >>>>>> change needed and either make that change in the next week, or=20 >>>>>> else tell me to take the draft off the telechat agenda for now. >>>>>>=20 >>>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>>>> time and we can sort out if any changes are needed later. >>>>>>=20 >>>>>> The reason why now+1-week matters, is that that's when IESG=20 >>>>>> members tend to do their reviews and having 'em all review a=20 >>>>>> moving target isn't a good plan. >>>>>>=20 >>>>>> Thanks, >>>>>> S. >>>>>>=20 >>>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>>> Hi guys, >>>>>>>=20 >>>>>>> Thanks for updating the assertion document and for incorporating th= e comments received on the mailing list. >>>>>>>=20 >>>>>>> There is only one issue that caught my attention. You changed the d= escription of the audience element to the following text (in version -09 of= http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>>> " >>>>>>> Audience A value that identifies the parties intended to=20 >>>>>>> process the assertion. An audience value MAY be the URL of the=20 >>>>>>> Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>>> " >>>>>>>=20 >>>>>>> Since the value in the audience field is used to by the authorizati= on server in a comparison operation (see Section 5.2) I believe the current= text will lead to interoperability problems. Not only is the comparision o= peration unspecified but even the value that is contained in the field is l= eft open. The RFC 2119 MAY does not really give a lot of hints of what shou= ld be put in there. >>>>>>>=20 >>>>>>> Without having a clear description of what identifier is contained = in this field and how the comparison works it is either possible that a leg= itimate client is rejected by the authorization server (which is annoying) = or an assertion with an incorrect assertion is accepted (which is a securit= y problem). >>>>>>>=20 >>>>>>> Btw, the same issue can also be seen in http://tools.ietf.org/html/= draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth= -saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 = of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" cla= im). From the description in the JWT document I was not quite sure whether = the ability to carry an array of case sensitive strings for that field is a= lso allowed in any of the assertion documents. >>>>>>>=20 >>>>>>> Note that there are two documents that provide input to this proble= m space, namely: >>>>>>> http://tools.ietf.org/html/rfc6125 >>>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>>=20 >>>>>>> So, I would suggest to decide what type of identifier goes into thi= s field and then to point to a document that illustrates how the comparison= operation would look like. Possible identifiers are domain names, IP addre= sses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcar= d match (like "*.example.com") or only an equality match? Would "www.exampl= e.com" be the same as "example.com" if they resolve to the same IP address(= es)? >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Tue Jan 15 20:35:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82D21F857C for ; Tue, 15 Jan 2013 20:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, MANGLED_EMAIL=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63XAA5YZf2Y3 for ; Tue, 15 Jan 2013 20:35:57 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7812121F857A for ; Tue, 15 Jan 2013 20:35:57 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0G4Zrq0017126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jan 2013 04:35:54 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0G4ZrpX016900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2013 04:35:53 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0G4ZqP2023058; Tue, 15 Jan 2013 22:35:53 -0600 Received: from [172.17.195.162] (/173.13.156.125) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jan 2013 20:35:52 -0800 References: <50EFF7F0.90300@cs.tcd.ie> <99183391-A44E-4680-9CC1-FB34BD6181B2@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3B4B7@TK5EX14MBXC284.redmond.corp.microsoft.com> <3E33804D-EDDA-4B04-A1C1-76515AC88907@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A3EF7C@TK5EX14MBXC284.redmond.corp.microsoft.com> <228E67DD-3AE6-46B6-A0CE-07C41B2DCC37@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A40560@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A44A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> <240132C1-2D4C-463A-88CB-AEA776C1E84F@gmx.net> <4E1F6AAD24975D4BA5B168042967394366A4898B@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A4898B@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <77E2D180-B7A5-41B7-B208-FDA1EBA2A6E5@oracle.com> X-Mailer: iPhone Mail (10A523) From: Phil Hunt Date: Tue, 15 Jan 2013 20:35:49 -0800 To: Mike Jones X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 04:35:58 -0000 +1. This makes good sense.=20 Phil Sent from my phone. On 2013-01-15, at 18:26, Mike Jones wrote: > Hannes and I spoke and went through the issues. He was trying to maximize= interoperability of implementations which is obviously a good goal. Howeve= r, after discussing the particulars, we also agreed that, for some features a= nd use cases, specific profiles of the assertions will be needed to achieve c= omplete interoperability (just like profiles of OAuth are required to achiev= e interoperability). >=20 > Therefore, we propose to add an explanatory paragraph to the assertions do= cument explaining that profiling will be required to achieve interoperabilit= y in some cases. This would be in exactly the same spirit as http://tools.i= etf.org/html/rfc6749#section-1.8, which supplies the same kinds of caveats t= o implementer's of OAuth Core. >=20 > I'll work on proposed specific wording shortly. I'll note that adding thi= s text will not change the meaning of the document in any way - it will simp= ly provide additional guidance to implementers on how to think about using t= he assertion framework. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Tuesday, January 15, 2013 10:34 AM > To: Mike Jones > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >=20 > Hi Mike,=20 >=20 > I am sure the rest of the working group is interested to see how difficult= it is to arrange a conference call when one person is in Espoo/Finland and t= he other person in the West Coast. > In any case, I am online and ready to chat.=20 >=20 > In any case I will let the group know what conclusions we reached.=20 >=20 > Ciao > Hannes >=20 > PS: For some reason your SMS arrived one day later... >=20 > On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: >=20 >> Hi Hannes, >>=20 >> Can you please either give me a call for us to talk about the changes you= have in mind or write down the specific changes you want? I'd like us to r= each a mutual understanding of what you're trying to achieve in time for Ste= phen to proceed with the telechat on schedule. >>=20 >> Thank you, >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20= >> Of Mike Jones >> Sent: Sunday, January 13, 2013 11:03 PM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> I'm thinking it would be useful for us to talk on the phone or Skype tomo= rrow, Hannes, because I'm pretty sure I don't know what specific changes you= 're asking for in which specs. Are you, for instance, asking for language s= aying that audience values are to be compared for equality as case-sensitive= strings in the SAML bearer and JWT bearer specs? (They're not just URIs, a= s they can be OAuth Client IDs.) Or maybe you can propose specific language= changes, so it's clear what you're asking for. >>=20 >> Thanks, >> -- Mike >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Sunday, January 13, 2013 2:49 AM >> To: Mike Jones >> Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org=20= >> WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>=20 >> Hi Mike, >>=20 >> it is fine to support different identifiers and to even allow the set of s= upported identifiers to get extended over time.=20 >>=20 >> Just omitting a description is, however, not an option. We are in the luc= ky position where others have done the work for us already (as mentioned in t= he two cited references). For the IAB document there is even the chance to p= rovide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-= in-identifier-comparison-for-security-purposes/) in case you believe the aut= hor is misguided. We just need to make use of them. >>=20 >> Ciao >> Hannes >>=20 >> On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: >>=20 >>> We already know of use cases where the audience is an abstract identifie= r and use cases where the audience is the URL of the token endpoint. Both a= re legitimate. We should foreclose neither. >>>=20 >>> Like many things OAuth, interoperability can be achieved, but it may req= uire a profile further specifying the behaviors appropriate to that use case= . This is not a bug - it is a feature, as it increases the applicability of= the OAuth specifications. >>>=20 >>> The Assertion, JWT Profile, and SAML Profile are striking an appropriate= balance by providing guidance on likely audience values for many use cases,= but not precluding other values where necessary for those use cases. >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >>> Sent: Sunday, January 13, 2013 1:56 AM >>> To: Mike Jones >>> Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell;=20 >>> oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>>=20 >>> Hi Mike, >>>=20 >>> I understand your reasoning: you want to keep all options open in the fr= amework specification and you want to be more specific in draft-ietf-oauth-j= wt-bearer and in draft-ietf-oauth-saml2-bearer.=20 >>>=20 >>> The RFC 2119 language does not add anything but it does not hurt either.= It just says that there could essentially be anything in there, including t= he URL of the Token Endpoint. >>>=20 >>> You can of course post-pone dealing with the issue to the more specific d= ocuments. For example, draft-ietf-oauth-jwt-bearer at the moment does not al= low an interoperable deployment since it just repeats the abstract framework= text by saying "The token endpoint URL of the authorization server MAY be u= sed as an acceptable value for an "aud" element."=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >>>=20 >>>> Hi Hannes, >>>>=20 >>>> For the reasons that Justin and Brian state, I believe that the MAY is a= ppropriate. In some use cases, a good representation of an appropriate audi= ence value is URL of the Token Endpoint. That's there in the Assertions spe= cification as guidance to writers token-type specific specs using the Assert= ions spec, as I believe it should be. That being the case, as Brian describ= es, sometimes audience values are more abstract identifiers or identifiers f= or groups of services, and we don't want to inadvertently preclude those act= ual use cases. >>>>=20 >>>> Thus, I believe that the language is appropriate as-is. Thus, I believ= e that we should proceed with the currently scheduled telechat discussion of= the spec. >>>>=20 >>>> Thanks all,= >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >>>> Behalf Of Hannes Tschofenig >>>> Sent: Saturday, January 12, 2013 11:50 AM >>>> To: Brian Campbell >>>> Cc: oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>>>=20 >>>> Hi Brian, >>>>=20 >>>> I understand that this is challenging. >>>>=20 >>>> Nevertheless it would make sense to describe the desired behavior in dr= aft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way= that two versions developed by different groups would interoperate without c= ausing security problems or failures.=20 >>>>=20 >>>> To move forward with draft-ietf-oauth-assertions I suggest to follow th= e recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10= 507.html and to address the details in draft-ietf-oauth-jwt-bearer and in d= raft-ietf-oauth-saml2-bearer as soon as possible to get these documents movi= ng forward and completed soon.=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>>>=20 >>>>> That text around audience in the framework spec changed from a SHOULD t= o a MAY in -09 so that it would be more consistent with the the SAML and JWT= versions, which were already using a MAY in that context. >>>>>=20 >>>>> Your concern is valid Hannes and your point is taken. But reality is r= ather messy and I don't believe it can addressed as easily as you suggest. =20= >>>>>=20 >>>>> In SAML, for example, an entity identifier is often used as a value fo= r the audience (per spec and in practice). But an AS may not necessarily id= entify itself with a full blown SAML entity, in which case the token endpoin= t URI is more appropriate. The whole issue is also somewhat complicated in S= AML too by it having both audience and recipient that are similar but not th= e same. I've tried to account for all of this in the SAML doc but it's admit= tedly somewhat awkward and complex and not as simple as saying the value has= to be X and must be validated in exactly such a way. >>>>>=20 >>>>> JWT doesn't have the same history and baggage of SAML but is subject t= o many of the same real world deployment variations. >>>>>=20 >>>>> I'm definitely open to improvements with respect to the handling of=20= >>>>> audience values but I believe anything that is done needs to=20 >>>>> reflect the realities of current implementations and deployments as=20= >>>>> well as related specifications., >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley wrot= e: >>>>> Yes in assertions it needs to be general. It is the JWT and SAML prof= iles that need to nail down what the format of the audience is. They shou= ld probably both be the URI of the token endpoint. In both SAML and JWT th= ere can be multiple audiences for the token. >>>>>=20 >>>>> John >>>>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." wr= ote: >>>>>=20 >>>>>> It's my understanding that the general assertions claim is more of a c= onceptual mapping than it is a concrete encoding, so anything more specific h= ere would be out of place. I would like the authors to either confirm or cor= rect my assumptions, though. >>>=20 >>>>=20 >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>>=20 >>>>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell=20 >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Since we thought we were done with it, I put this document on the=20= >>>>>>> IESG telechat agenda for Jan 24. Hannes' question however looks=20 >>>>>>> like its a real one that needs an answer. >>>>>>>=20 >>>>>>> I'd appreciate it if the WG could figure out if there's any=20 >>>>>>> change needed and either make that change in the next week, or=20 >>>>>>> else tell me to take the draft off the telechat agenda for now. >>>>>>>=20 >>>>>>> If discussion doesn't happen, or happens but doesn't reach a=20 >>>>>>> conclusion, then I'll take the draft off the agenda in a week's=20 >>>>>>> time and we can sort out if any changes are needed later. >>>>>>>=20 >>>>>>> The reason why now+1-week matters, is that that's when IESG=20 >>>>>>> members tend to do their reviews and having 'em all review a=20 >>>>>>> moving target isn't a good plan. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> S. >>>>>>>=20 >>>>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>>>> Hi guys, >>>>>>>>=20 >>>>>>>> Thanks for updating the assertion document and for incorporating th= e comments received on the mailing list. >>>>>>>>=20 >>>>>>>> There is only one issue that caught my attention. You changed the d= escription of the audience element to the following text (in version -09 of h= ttp://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>>>> " >>>>>>>> Audience A value that identifies the parties intended to=20 >>>>>>>> process the assertion. An audience value MAY be the URL of the=20= >>>>>>>> Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>>>> " >>>>>>>>=20 >>>>>>>> Since the value in the audience field is used to by the authorizati= on server in a comparison operation (see Section 5.2) I believe the current t= ext will lead to interoperability problems. Not only is the comparision oper= ation unspecified but even the value that is contained in the field is left o= pen. The RFC 2119 MAY does not really give a lot of hints of what should be p= ut in there. >>>>>>>>=20 >>>>>>>> Without having a clear description of what identifier is contained i= n this field and how the comparison works it is either possible that a legit= imate client is rejected by the authorization server (which is annoying) or a= n assertion with an incorrect assertion is accepted (which is a security pro= blem). >>>>>>>>=20 >>>>>>>> Btw, the same issue can also be seen in http://tools.ietf.org/html/= draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-= saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of= http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" claim)= . =46rom the description in the JWT document I was not quite sure whether th= e ability to carry an array of case sensitive strings for that field is also= allowed in any of the assertion documents. >>>>>>>>=20 >>>>>>>> Note that there are two documents that provide input to this proble= m space, namely: >>>>>>>> http://tools.ietf.org/html/rfc6125 >>>>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>>>=20 >>>>>>>> So, I would suggest to decide what type of identifier goes into thi= s field and then to point to a document that illustrates how the comparison o= peration would look like. Possible identifiers are domain names, IP addresse= s, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard ma= tch (like "*.example.com") or only an equality match? Would "www.example.com= " be the same as "example.com" if they resolve to the same IP address(es)? >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=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 >>>>=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 torsten@lodderstedt.net Wed Jan 16 09:11:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB0221F8B34 for ; Wed, 16 Jan 2013 09:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9upIvl+V6uI for ; Wed, 16 Jan 2013 09:11:53 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2AB21F8919 for ; Wed, 16 Jan 2013 09:11:52 -0800 (PST) Received: from [80.187.97.91] (helo=[100.90.25.183]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TvWWW-0001BV-Md; Wed, 16 Jan 2013 18:11:49 +0100 Date: Wed, 16 Jan 2013 18:11:33 +0100 Message-ID: Importance: normal From: Torsten Lodderstedt To: phil.hunt@oracle.com, Michael.Jones@microsoft.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_146709350860570" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Torsten Lodderstedt List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:11:56 -0000 ----_com.android.email_146709350860570 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEKCi0tLS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLQpWb246IFBoaWwg SHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+IApEYXR1bTogIApBbjogTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiAKQ2M6IG9hdXRoQGlldGYub3JnIApCZXRyZWZmOiBS ZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDkgCiAKKzEuIFRoaXMg bWFrZXMgZ29vZCBzZW5zZS4gCgpQaGlsCgpTZW50IGZyb20gbXkgcGhvbmUuCgpPbiAyMDEzLTAx LTE1LCBhdCAxODoyNiwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3 cm90ZToKCj4gSGFubmVzIGFuZCBJIHNwb2tlIGFuZCB3ZW50IHRocm91Z2ggdGhlIGlzc3Vlcy7C oCBIZSB3YXMgdHJ5aW5nIHRvIG1heGltaXplIGludGVyb3BlcmFiaWxpdHkgb2YgaW1wbGVtZW50 YXRpb25zIHdoaWNoIGlzIG9idmlvdXNseSBhIGdvb2QgZ29hbC7CoCBIb3dldmVyLCBhZnRlciBk aXNjdXNzaW5nIHRoZSBwYXJ0aWN1bGFycywgd2UgYWxzbyBhZ3JlZWQgdGhhdCwgZm9yIHNvbWUg ZmVhdHVyZXMgYW5kIHVzZSBjYXNlcywgc3BlY2lmaWMgcHJvZmlsZXMgb2YgdGhlIGFzc2VydGlv bnMgd2lsbCBiZSBuZWVkZWQgdG8gYWNoaWV2ZSBjb21wbGV0ZSBpbnRlcm9wZXJhYmlsaXR5IChq dXN0IGxpa2UgcHJvZmlsZXMgb2YgT0F1dGggYXJlIHJlcXVpcmVkIHRvIGFjaGlldmUgaW50ZXJv cGVyYWJpbGl0eSkuCj4gCj4gVGhlcmVmb3JlLCB3ZSBwcm9wb3NlIHRvIGFkZCBhbiBleHBsYW5h dG9yeSBwYXJhZ3JhcGggdG8gdGhlIGFzc2VydGlvbnMgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGF0 IHByb2ZpbGluZyB3aWxsIGJlIHJlcXVpcmVkIHRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSBp biBzb21lIGNhc2VzLsKgIFRoaXMgd291bGQgYmUgaW4gZXhhY3RseSB0aGUgc2FtZSBzcGlyaXQg YXMgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTEuOCwgd2hpY2gg c3VwcGxpZXMgdGhlIHNhbWUga2luZHMgb2YgY2F2ZWF0cyB0byBpbXBsZW1lbnRlcidzIG9mIE9B dXRoIENvcmUuCj4gCj4gSSdsbCB3b3JrIG9uIHByb3Bvc2VkIHNwZWNpZmljIHdvcmRpbmcgc2hv cnRseS7CoCBJJ2xsIG5vdGUgdGhhdCBhZGRpbmcgdGhpcyB0ZXh0IHdpbGwgbm90IGNoYW5nZSB0 aGUgbWVhbmluZyBvZiB0aGUgZG9jdW1lbnQgaW4gYW55IHdheSAtIGl0IHdpbGwgc2ltcGx5IHBy b3ZpZGUgYWRkaXRpb25hbCBndWlkYW5jZSB0byBpbXBsZW1lbnRlcnMgb24gaG93IHRvIHRoaW5r IGFib3V0IHVzaW5nIHRoZSBhc3NlcnRpb24gZnJhbWV3b3JrLgo+IAo+wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEJlc3Qgd2lzaGVzLAo+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIC0tIE1pa2UKPiAKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEhhbm5l cyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF0gCj4gU2VudDog VHVlc2RheSwgSmFudWFyeSAxNSwgMjAxMyAxMDozNCBBTQo+IFRvOiBNaWtlIEpvbmVzCj4gQ2M6 IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRmLm9yZyBXRwo+IFN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOQo+IAo+IEhpIE1pa2UsIAo+IAo+ IEkgYW0gc3VyZSB0aGUgcmVzdCBvZiB0aGUgd29ya2luZyBncm91cCBpcyBpbnRlcmVzdGVkIHRv IHNlZSBob3cgZGlmZmljdWx0IGl0IGlzIHRvIGFycmFuZ2UgYSBjb25mZXJlbmNlIGNhbGwgd2hl biBvbmUgcGVyc29uIGlzIGluIEVzcG9vL0ZpbmxhbmQgYW5kIHRoZSBvdGhlciBwZXJzb24gaW4g dGhlIFdlc3QgQ29hc3QuCj4gSW4gYW55IGNhc2UsIEkgYW0gb25saW5lIGFuZCByZWFkeSB0byBj aGF0LiAKPiAKPiBJbiBhbnkgY2FzZSBJIHdpbGwgbGV0IHRoZSBncm91cCBrbm93IHdoYXQgY29u Y2x1c2lvbnMgd2UgcmVhY2hlZC4gCj4gCj4gQ2lhbwo+IEhhbm5lcwo+IAo+IFBTOiBGb3Igc29t ZSByZWFzb24geW91ciBTTVMgYXJyaXZlZCBvbmUgZGF5IGxhdGVyLi4uCj4gCj4gT24gSmFuIDE1 LCAyMDEzLCBhdCA3OjIwIFBNLCBNaWtlIEpvbmVzIHdyb3RlOgo+IAo+PiBIaSBIYW5uZXMsCj4+ IAo+PiBDYW4geW91IHBsZWFzZSBlaXRoZXIgZ2l2ZSBtZSBhIGNhbGwgZm9yIHVzIHRvIHRhbGsg YWJvdXQgdGhlIGNoYW5nZXMgeW91IGhhdmUgaW4gbWluZCBvciB3cml0ZSBkb3duIHRoZSBzcGVj aWZpYyBjaGFuZ2VzIHlvdSB3YW50P8KgIEknZCBsaWtlIHVzIHRvIHJlYWNoIGEgbXV0dWFsIHVu ZGVyc3RhbmRpbmcgb2Ygd2hhdCB5b3UncmUgdHJ5aW5nIHRvIGFjaGlldmUgaW4gdGltZSBmb3Ig U3RlcGhlbiB0byBwcm9jZWVkIHdpdGggdGhlIHRlbGVjaGF0IG9uIHNjaGVkdWxlLgo+PiAKPj7C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhhbmsgeW91LAo+PsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAtLSBNaWtlCj4+IAo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+PiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIAo+PiBPZiBNaWtlIEpvbmVzCj4+IFNlbnQ6IFN1bmRheSwgSmFu dWFyeSAxMywgMjAxMyAxMTowMyBQTQo+PiBUbzogSGFubmVzIFRzY2hvZmVuaWcKPj4gQ2M6IG9h dXRoQGlldGYub3JnIFdHCj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWlldGYtb2F1 dGgtYXNzZXJ0aW9ucy0wOQo+PiAKPj4gSSdtIHRoaW5raW5nIGl0IHdvdWxkIGJlIHVzZWZ1bCBm b3IgdXMgdG8gdGFsayBvbiB0aGUgcGhvbmUgb3IgU2t5cGUgdG9tb3Jyb3csIEhhbm5lcywgYmVj YXVzZSBJJ20gcHJldHR5IHN1cmUgSSBkb24ndCBrbm93IHdoYXQgc3BlY2lmaWMgY2hhbmdlcyB5 b3UncmUgYXNraW5nIGZvciBpbiB3aGljaCBzcGVjcy7CoCBBcmUgeW91LCBmb3IgaW5zdGFuY2Us IGFza2luZyBmb3IgbGFuZ3VhZ2Ugc2F5aW5nIHRoYXQgYXVkaWVuY2UgdmFsdWVzIGFyZSB0byBi ZSBjb21wYXJlZCBmb3IgZXF1YWxpdHkgYXMgY2FzZS1zZW5zaXRpdmUgc3RyaW5ncyBpbiB0aGUg U0FNTCBiZWFyZXIgYW5kIEpXVCBiZWFyZXIgc3BlY3M/wqAgKFRoZXkncmUgbm90IGp1c3QgVVJJ cywgYXMgdGhleSBjYW4gYmUgT0F1dGggQ2xpZW50IElEcy4pwqAgT3IgbWF5YmUgeW91IGNhbiBw cm9wb3NlIHNwZWNpZmljIGxhbmd1YWdlIGNoYW5nZXMsIHNvIGl0J3MgY2xlYXIgd2hhdCB5b3Un cmUgYXNraW5nIGZvci4KPj4gCj4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRoYW5r cywKPj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLS0gTWlrZQo+PiAKPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0XQo+PiBTZW50OiBTdW5kYXksIEphbnVhcnkgMTMsIDIw MTMgMjo0OSBBTQo+PiBUbzogTWlrZSBKb25lcwo+PiBDYzogSGFubmVzIFRzY2hvZmVuaWc7IEJy aWFuIENhbXBiZWxsOyBTdGVwaGVuIEZhcnJlbGw7IG9hdXRoQGlldGYub3JnIAo+PiBXRwo+PiBT dWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDkKPj4g Cj4+IEhpIE1pa2UsCj4+IAo+PiBpdCBpcyBmaW5lIHRvIHN1cHBvcnQgZGlmZmVyZW50IGlkZW50 aWZpZXJzIGFuZCB0byBldmVuIGFsbG93IHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGlkZW50aWZpZXJz IHRvIGdldCBleHRlbmRlZCBvdmVyIHRpbWUuIAo+PiAKPj4gSnVzdCBvbWl0dGluZyBhIGRlc2Ny aXB0aW9uIGlzLCBob3dldmVyLCBub3QgYW4gb3B0aW9uLiBXZSBhcmUgaW4gdGhlIGx1Y2t5IHBv c2l0aW9uIHdoZXJlIG90aGVycyBoYXZlIGRvbmUgdGhlIHdvcmsgZm9yIHVzIGFscmVhZHkgKGFz IG1lbnRpb25lZCBpbiB0aGUgdHdvIGNpdGVkIHJlZmVyZW5jZXMpLiBGb3IgdGhlIElBQiBkb2N1 bWVudCB0aGVyZSBpcyBldmVuIHRoZSBjaGFuY2UgdG8gcHJvdmlkZSBmZWVkYmFjayAoc2VlIGh0 dHBzOi8vd3d3LmlhYi5vcmcvMjAxMy8wMS8wOS9jYWxsLWZvci1jb21tZW50LWlzc3Vlcy1pbi1p ZGVudGlmaWVyLWNvbXBhcmlzb24tZm9yLXNlY3VyaXR5LXB1cnBvc2VzLykgaW4gY2FzZSB5b3Ug YmVsaWV2ZSB0aGUgYXV0aG9yIGlzIG1pc2d1aWRlZC4gV2UganVzdCBuZWVkIHRvIG1ha2UgdXNl IG9mIHRoZW0uCj4+IAo+PiBDaWFvCj4+IEhhbm5lcwo+PiAKPj4gT24gSmFuIDEzLCAyMDEzLCBh dCAxMjowOSBQTSwgTWlrZSBKb25lcyB3cm90ZToKPj4gCj4+PiBXZSBhbHJlYWR5IGtub3cgb2Yg dXNlIGNhc2VzIHdoZXJlIHRoZSBhdWRpZW5jZSBpcyBhbiBhYnN0cmFjdCBpZGVudGlmaWVyIGFu ZCB1c2UgY2FzZXMgd2hlcmUgdGhlIGF1ZGllbmNlIGlzIHRoZSBVUkwgb2YgdGhlIHRva2VuIGVu ZHBvaW50LsKgIEJvdGggYXJlIGxlZ2l0aW1hdGUuwqAgV2Ugc2hvdWxkIGZvcmVjbG9zZSBuZWl0 aGVyLgo+Pj4gCj4+PiBMaWtlIG1hbnkgdGhpbmdzIE9BdXRoLCBpbnRlcm9wZXJhYmlsaXR5IGNh biBiZSBhY2hpZXZlZCwgYnV0IGl0IG1heSByZXF1aXJlIGEgcHJvZmlsZSBmdXJ0aGVyIHNwZWNp ZnlpbmcgdGhlIGJlaGF2aW9ycyBhcHByb3ByaWF0ZSB0byB0aGF0IHVzZSBjYXNlLsKgIFRoaXMg aXMgbm90IGEgYnVnIC0gaXQgaXMgYSBmZWF0dXJlLCBhcyBpdCBpbmNyZWFzZXMgdGhlIGFwcGxp Y2FiaWxpdHkgb2YgdGhlIE9BdXRoIHNwZWNpZmljYXRpb25zLgo+Pj4gCj4+PiBUaGUgQXNzZXJ0 aW9uLCBKV1QgUHJvZmlsZSwgYW5kIFNBTUwgUHJvZmlsZSBhcmUgc3RyaWtpbmcgYW4gYXBwcm9w cmlhdGUgYmFsYW5jZSBieSBwcm92aWRpbmcgZ3VpZGFuY2Ugb24gbGlrZWx5IGF1ZGllbmNlIHZh bHVlcyBmb3IgbWFueSB1c2UgY2FzZXMsIGJ1dCBub3QgcHJlY2x1ZGluZyBvdGhlciB2YWx1ZXMg d2hlcmUgbmVjZXNzYXJ5IGZvciB0aG9zZSB1c2UgY2FzZXMuCj4+PiAKPj4+wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIEJlc3Qgd2lzaGVzLAo+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgLS0gTWlrZQo+Pj4gCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4g RnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0 XQo+Pj4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDEzLCAyMDEzIDE6NTYgQU0KPj4+IFRvOiBNaWtl IEpvbmVzCj4+PiBDYzogSGFubmVzIFRzY2hvZmVuaWc7IEJyaWFuIENhbXBiZWxsOyBTdGVwaGVu IEZhcnJlbGw7IAo+Pj4gb2F1dGhAaWV0Zi5vcmcgV0cKPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOQo+Pj4gCj4+PiBIaSBNaWtlLAo+Pj4g Cj4+PiBJIHVuZGVyc3RhbmQgeW91ciByZWFzb25pbmc6IHlvdSB3YW50IHRvIGtlZXAgYWxsIG9w dGlvbnMgb3BlbiBpbiB0aGUgZnJhbWV3b3JrIHNwZWNpZmljYXRpb24gYW5kIHlvdSB3YW50IHRv IGJlIG1vcmUgc3BlY2lmaWMgaW4gZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyIGFuZCBpbiBk cmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci4gCj4+PiAKPj4+IFRoZSBSRkMgMjExOSBsYW5n dWFnZSBkb2VzIG5vdCBhZGQgYW55dGhpbmcgYnV0IGl0IGRvZXMgbm90IGh1cnQgZWl0aGVyLiBJ dCBqdXN0IHNheXMgdGhhdCB0aGVyZSBjb3VsZCBlc3NlbnRpYWxseSBiZSBhbnl0aGluZyBpbiB0 aGVyZSwgaW5jbHVkaW5nIHRoZSBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50Lgo+Pj4gCj4+PiBZ b3UgY2FuIG9mIGNvdXJzZSBwb3N0LXBvbmUgZGVhbGluZyB3aXRoIHRoZSBpc3N1ZSB0byB0aGUg bW9yZSBzcGVjaWZpYyBkb2N1bWVudHMuIEZvciBleGFtcGxlLCBkcmFmdC1pZXRmLW9hdXRoLWp3 dC1iZWFyZXIgYXQgdGhlIG1vbWVudCBkb2VzIG5vdCBhbGxvdyBhbiBpbnRlcm9wZXJhYmxlIGRl cGxveW1lbnQgc2luY2UgaXQganVzdCByZXBlYXRzIHRoZSBhYnN0cmFjdCBmcmFtZXdvcmsgdGV4 dCBieSBzYXlpbmcgIlRoZSB0b2tlbiBlbmRwb2ludCBVUkwgb2YgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIE1BWSBiZSB1c2VkIGFzIGFuIGFjY2VwdGFibGUgdmFsdWUgZm9yIGFuICJhdWQiIGVs ZW1lbnQuIiAKPj4+IAo+Pj4gQ2lhbwo+Pj4gSGFubmVzCj4+PiAKPj4+IE9uIEphbiAxMiwgMjAx MywgYXQgMTA6NDIgUE0sIE1pa2UgSm9uZXMgd3JvdGU6Cj4+PiAKPj4+PiBIaSBIYW5uZXMsCj4+ Pj4gCj4+Pj4gRm9yIHRoZSByZWFzb25zIHRoYXQgSnVzdGluIGFuZCBCcmlhbiBzdGF0ZSwgSSBi ZWxpZXZlIHRoYXQgdGhlIE1BWSBpcyBhcHByb3ByaWF0ZS7CoCBJbiBzb21lIHVzZSBjYXNlcywg YSBnb29kIHJlcHJlc2VudGF0aW9uIG9mIGFuIGFwcHJvcHJpYXRlIGF1ZGllbmNlIHZhbHVlIGlz IFVSTCBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuwqAgVGhhdCdzIHRoZXJlIGluIHRoZSBBc3NlcnRp b25zIHNwZWNpZmljYXRpb24gYXMgZ3VpZGFuY2UgdG8gd3JpdGVycyB0b2tlbi10eXBlIHNwZWNp ZmljIHNwZWNzIHVzaW5nIHRoZSBBc3NlcnRpb25zIHNwZWMsIGFzIEkgYmVsaWV2ZSBpdCBzaG91 bGQgYmUuwqAgVGhhdCBiZWluZyB0aGUgY2FzZSwgYXMgQnJpYW4gZGVzY3JpYmVzLCBzb21ldGlt ZXMgYXVkaWVuY2UgdmFsdWVzIGFyZSBtb3JlIGFic3RyYWN0IGlkZW50aWZpZXJzIG9yIGlkZW50 aWZpZXJzIGZvciBncm91cHMgb2Ygc2VydmljZXMsIGFuZCB3ZSBkb24ndCB3YW50IHRvIGluYWR2 ZXJ0ZW50bHkgcHJlY2x1ZGUgdGhvc2UgYWN0dWFsIHVzZSBjYXNlcy4KPj4+PiAKPj4+PiBUaHVz LCBJIGJlbGlldmUgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMgYXBwcm9wcmlhdGUgYXMtaXMuwqAgVGh1 cywgSSBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIHByb2NlZWQgd2l0aCB0aGUgY3VycmVudGx5IHNj aGVkdWxlZCB0ZWxlY2hhdCBkaXNjdXNzaW9uIG9mIHRoZSBzcGVjLgo+Pj4+IAo+Pj4+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFRoYW5rcyBhbGwsCj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLS0gTWlrZQo+Pj4+IAo+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCj4+Pj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIAo+Pj4+IEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5p Zwo+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEyLCAyMDEzIDExOjUwIEFNCj4+Pj4gVG86 IEJyaWFuIENhbXBiZWxsCj4+Pj4gQ2M6IG9hdXRoQGlldGYub3JnIFdHCj4+Pj4gU3ViamVjdDog UmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5Cj4+Pj4gCj4+Pj4g SGkgQnJpYW4sCj4+Pj4gCj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBjaGFsbGVuZ2lu Zy4KPj4+PiAKPj4+PiBOZXZlcnRoZWxlc3MgaXQgd291bGQgbWFrZSBzZW5zZSB0byBkZXNjcmli ZSB0aGUgZGVzaXJlZCBiZWhhdmlvciBpbiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIgYW5k IGluIGRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyIGluIHN1Y2ggYSB3YXkgdGhhdCB0d28g dmVyc2lvbnMgZGV2ZWxvcGVkIGJ5IGRpZmZlcmVudCBncm91cHMgd291bGQgaW50ZXJvcGVyYXRl IHdpdGhvdXQgY2F1c2luZyBzZWN1cml0eSBwcm9ibGVtcyBvciBmYWlsdXJlcy4gCj4+Pj4gCj4+ Pj4gVG8gbW92ZSBmb3J3YXJkIHdpdGggZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zIEkgc3Vn Z2VzdCB0byBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIGluIGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwNTA3Lmh0bWwgYW5kIHRvIGFkZHJl c3MgdGhlIGRldGFpbHMgaW7CoCBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIgYW5kIGluIGRy YWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyIGFzIHNvb24gYXMgcG9zc2libGUgdG8gZ2V0IHRo ZXNlIGRvY3VtZW50cyBtb3ZpbmcgZm9yd2FyZCBhbmQgY29tcGxldGVkIHNvb24uIAo+Pj4+IAo+ Pj4+IENpYW8KPj4+PiBIYW5uZXMKPj4+PiAKPj4+PiBPbiBKYW4gMTEsIDIwMTMsIGF0IDc6NTEg UE0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOgo+Pj4+IAo+Pj4+PiBUaGF0IHRleHQgYXJvdW5kIGF1 ZGllbmNlIGluIHRoZSBmcmFtZXdvcmsgc3BlYyBjaGFuZ2VkIGZyb20gYSBTSE9VTEQgdG8gYSBN QVkgaW4gLTA5IHNvIHRoYXQgaXQgd291bGQgYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHRo ZSBTQU1MIGFuZCBKV1QgdmVyc2lvbnMsIHdoaWNoIHdlcmUgYWxyZWFkeSB1c2luZyBhIE1BWSBp biB0aGF0IGNvbnRleHQuCj4+Pj4+IAo+Pj4+PiBZb3VyIGNvbmNlcm4gaXMgdmFsaWQgSGFubmVz IGFuZCB5b3VyIHBvaW50IGlzIHRha2VuLiBCdXQgcmVhbGl0eSBpcyByYXRoZXIgbWVzc3kgYW5k IEkgZG9uJ3QgYmVsaWV2ZSBpdCBjYW4gYWRkcmVzc2VkIGFzIGVhc2lseSBhcyB5b3Ugc3VnZ2Vz dC7CoCAKPj4+Pj4gCj4+Pj4+IEluIFNBTUwsIGZvciBleGFtcGxlLCBhbiBlbnRpdHkgaWRlbnRp ZmllciBpcyBvZnRlbiB1c2VkIGFzIGEgdmFsdWUgZm9yIHRoZSBhdWRpZW5jZSAocGVyIHNwZWMg YW5kIGluIHByYWN0aWNlKS7CoCBCdXQgYW4gQVMgbWF5IG5vdCBuZWNlc3NhcmlseSBpZGVudGlm eSBpdHNlbGYgd2l0aCBhIGZ1bGwgYmxvd24gU0FNTCBlbnRpdHksIGluIHdoaWNoIGNhc2UgdGhl IHRva2VuIGVuZHBvaW50IFVSSSBpcyBtb3JlIGFwcHJvcHJpYXRlLiBUaGUgd2hvbGUgaXNzdWUg aXMgYWxzbyBzb21ld2hhdCBjb21wbGljYXRlZCBpbiBTQU1MIHRvbyBieSBpdCBoYXZpbmcgYm90 aCBhdWRpZW5jZSBhbmQgcmVjaXBpZW50IHRoYXQgYXJlIHNpbWlsYXIgYnV0IG5vdCB0aGUgc2Ft ZS4gSSd2ZSB0cmllZCB0byBhY2NvdW50IGZvciBhbGwgb2YgdGhpcyBpbiB0aGUgU0FNTCBkb2Mg YnV0IGl0J3MgYWRtaXR0ZWRseSBzb21ld2hhdCBhd2t3YXJkIGFuZCBjb21wbGV4IGFuZCBub3Qg YXMgc2ltcGxlIGFzIHNheWluZyB0aGUgdmFsdWUgaGFzIHRvIGJlIFggYW5kIG11c3QgYmUgdmFs aWRhdGVkIGluIGV4YWN0bHkgc3VjaCBhIHdheS4KPj4+Pj4gCj4+Pj4+IEpXVCBkb2Vzbid0IGhh dmUgdGhlIHNhbWUgaGlzdG9yeSBhbmQgYmFnZ2FnZSBvZiBTQU1MIGJ1dCBpcyBzdWJqZWN0IHRv IG1hbnkgb2YgdGhlIHNhbWUgcmVhbCB3b3JsZCBkZXBsb3ltZW50IHZhcmlhdGlvbnMuCj4+Pj4+ IAo+Pj4+PiBJJ20gZGVmaW5pdGVseSBvcGVuIHRvIGltcHJvdmVtZW50cyB3aXRoIHJlc3BlY3Qg dG8gdGhlIGhhbmRsaW5nIG9mIAo+Pj4+PiBhdWRpZW5jZSB2YWx1ZXMgYnV0IEkgYmVsaWV2ZSBh bnl0aGluZyB0aGF0IGlzIGRvbmUgbmVlZHMgdG8gCj4+Pj4+IHJlZmxlY3QgdGhlIHJlYWxpdGll cyBvZiBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBhbmQgZGVwbG95bWVudHMgYXMgCj4+Pj4+IHdl bGwgYXMgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucy4sCj4+Pj4+IAo+Pj4+PiAKPj4+Pj4gCj4+Pj4+ IE9uIEZyaSwgSmFuIDExLCAyMDEzIGF0IDg6NTUgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZl N2p0Yi5jb20+IHdyb3RlOgo+Pj4+PiBZZXMgaW4gYXNzZXJ0aW9ucyBpdCBuZWVkcyB0byBiZSBn ZW5lcmFsLsKgIEl0IGlzIHRoZSBKV1QgYW5kIFNBTUwgcHJvZmlsZXMgdGhhdCBuZWVkIHRvIG5h aWwgZG93biB3aGF0IHRoZSBmb3JtYXQgb2YgdGhlIGF1ZGllbmNlIGlzLsKgwqDCoCBUaGV5IHNo b3VsZCBwcm9iYWJseSBib3RoIGJlIHRoZSBVUkkgb2YgdGhlIHRva2VuIGVuZHBvaW50LsKgwqAg SW4gYm90aCBTQU1MIGFuZCBKV1QgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGF1ZGllbmNlcyBmb3Ig dGhlIHRva2VuLgo+Pj4+PiAKPj4+Pj4gSm9obgo+Pj4+PiBPbiAyMDEzLTAxLTExLCBhdCAxMToz NyBBTSwgIlJpY2hlciwgSnVzdGluIFAuIiA8anJpY2hlckBtaXRyZS5vcmc+IHdyb3RlOgo+Pj4+ PiAKPj4+Pj4+IEl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBnZW5lcmFsIGFzc2VydGlv bnMgY2xhaW0gaXMgbW9yZSBvZiBhIGNvbmNlcHR1YWwgbWFwcGluZyB0aGFuIGl0IGlzIGEgY29u Y3JldGUgZW5jb2RpbmcsIHNvIGFueXRoaW5nIG1vcmUgc3BlY2lmaWMgaGVyZSB3b3VsZCBiZSBv dXQgb2YgcGxhY2UuIEkgd291bGQgbGlrZSB0aGUgYXV0aG9ycyB0byBlaXRoZXIgY29uZmlybSBv ciBjb3JyZWN0IG15IGFzc3VtcHRpb25zLCB0aG91Z2guCj4+PiAKPj4+PiAKPj4+Pj4+IAo+Pj4+ Pj4gLS0gSnVzdGluCj4+Pj4+PiAKPj4+Pj4+IAo+Pj4+Pj4gT24gSmFuIDExLCAyMDEzLCBhdCA2 OjMwIEFNLCBTdGVwaGVuIEZhcnJlbGwgCj4+Pj4+PiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4KPj4+Pj4+IHdyb3RlOgo+Pj4+Pj4gCj4+Pj4+Pj4gCj4+Pj4+Pj4gSGksCj4+Pj4+Pj4gCj4+ Pj4+Pj4gU2luY2Ugd2UgdGhvdWdodCB3ZSB3ZXJlIGRvbmUgd2l0aCBpdCwgSSBwdXQgdGhpcyBk b2N1bWVudCBvbiB0aGUgCj4+Pj4+Pj4gSUVTRyB0ZWxlY2hhdCBhZ2VuZGEgZm9yIEphbiAyNC4g SGFubmVzJyBxdWVzdGlvbiBob3dldmVyIGxvb2tzIAo+Pj4+Pj4+IGxpa2UgaXRzIGEgcmVhbCBv bmUgdGhhdCBuZWVkcyBhbiBhbnN3ZXIuCj4+Pj4+Pj4gCj4+Pj4+Pj4gSSdkIGFwcHJlY2lhdGUg aXQgaWYgdGhlIFdHIGNvdWxkIGZpZ3VyZSBvdXQgaWYgdGhlcmUncyBhbnkgCj4+Pj4+Pj4gY2hh bmdlIG5lZWRlZCBhbmQgZWl0aGVyIG1ha2UgdGhhdCBjaGFuZ2UgaW4gdGhlIG5leHQgd2Vlaywg b3IgCj4+Pj4+Pj4gZWxzZSB0ZWxsIG1lIHRvIHRha2UgdGhlIGRyYWZ0IG9mZiB0aGUgdGVsZWNo YXQgYWdlbmRhIGZvciBub3cuCj4+Pj4+Pj4gCj4+Pj4+Pj4gSWYgZGlzY3Vzc2lvbiBkb2Vzbid0 IGhhcHBlbiwgb3IgaGFwcGVucyBidXQgZG9lc24ndCByZWFjaCBhIAo+Pj4+Pj4+IGNvbmNsdXNp b24sIHRoZW4gSSdsbCB0YWtlIHRoZSBkcmFmdCBvZmYgdGhlIGFnZW5kYSBpbiBhIHdlZWsncyAK Pj4+Pj4+PiB0aW1lIGFuZCB3ZSBjYW4gc29ydCBvdXQgaWYgYW55IGNoYW5nZXMgYXJlIG5lZWRl ZCBsYXRlci4KPj4+Pj4+PiAKPj4+Pj4+PiBUaGUgcmVhc29uIHdoeSBub3crMS13ZWVrIG1hdHRl cnMsIGlzIHRoYXQgdGhhdCdzIHdoZW4gSUVTRyAKPj4+Pj4+PiBtZW1iZXJzIHRlbmQgdG8gZG8g dGhlaXIgcmV2aWV3cyBhbmQgaGF2aW5nICdlbSBhbGwgcmV2aWV3IGEgCj4+Pj4+Pj4gbW92aW5n IHRhcmdldCBpc24ndCBhIGdvb2QgcGxhbi4KPj4+Pj4+PiAKPj4+Pj4+PiBUaGFua3MsCj4+Pj4+ Pj4gUy4KPj4+Pj4+PiAKPj4+Pj4+PiBPbiAwMS8xMS8yMDEzIDA4OjE4IEFNLCBIYW5uZXMgVHNj aG9mZW5pZyB3cm90ZToKPj4+Pj4+Pj4gSGkgZ3V5cywKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IFRoYW5r cyBmb3IgdXBkYXRpbmcgdGhlIGFzc2VydGlvbiBkb2N1bWVudCBhbmQgZm9yIGluY29ycG9yYXRp bmcgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoZSBtYWlsaW5nIGxpc3QuCj4+Pj4+Pj4+IAo+ Pj4+Pj4+PiBUaGVyZSBpcyBvbmx5IG9uZSBpc3N1ZSB0aGF0IGNhdWdodCBteSBhdHRlbnRpb24u IFlvdSBjaGFuZ2VkIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgYXVkaWVuY2UgZWxlbWVudCB0byB0 aGUgZm9sbG93aW5nIHRleHQgKGluIHZlcnNpb24gLTA5IG9mIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOSk6Cj4+Pj4+Pj4+ICIKPj4+Pj4+ Pj4gQXVkaWVuY2XCoCBBIHZhbHVlIHRoYXQgaWRlbnRpZmllcyB0aGUgcGFydGllcyBpbnRlbmRl ZCB0byAKPj4+Pj4+Pj4gcHJvY2VzcyB0aGXCoCBhc3NlcnRpb24uwqAgQW4gYXVkaWVuY2UgdmFs dWUgTUFZIGJlIHRoZSBVUkwgb2YgdGhlIAo+Pj4+Pj4+PiBUb2tlbiBFbmRwb2ludMKgIGFzIGRl ZmluZWQgaW4gU2VjdGlvbiAzLjIgb2YgT0F1dGggMi4wIFtSRkM2NzQ5XS4KPj4+Pj4+Pj4gIgo+ Pj4+Pj4+PiAKPj4+Pj4+Pj4gU2luY2UgdGhlIHZhbHVlIGluIHRoZSBhdWRpZW5jZSBmaWVsZCBp cyB1c2VkIHRvIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbiBhIGNvbXBhcmlzb24gb3Bl cmF0aW9uIChzZWUgU2VjdGlvbiA1LjIpIEkgYmVsaWV2ZSB0aGUgY3VycmVudCB0ZXh0IHdpbGwg bGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiBOb3Qgb25seSBpcyB0aGUgY29tcGFy aXNpb24gb3BlcmF0aW9uIHVuc3BlY2lmaWVkIGJ1dCBldmVuIHRoZSB2YWx1ZSB0aGF0IGlzIGNv bnRhaW5lZCBpbiB0aGUgZmllbGQgaXMgbGVmdCBvcGVuLiBUaGUgUkZDIDIxMTkgTUFZIGRvZXMg bm90IHJlYWxseSBnaXZlIGEgbG90IG9mIGhpbnRzIG9mIHdoYXQgc2hvdWxkIGJlIHB1dCBpbiB0 aGVyZS4KPj4+Pj4+Pj4gCj4+Pj4+Pj4+IFdpdGhvdXQgaGF2aW5nIGEgY2xlYXIgZGVzY3JpcHRp b24gb2Ygd2hhdCBpZGVudGlmaWVyIGlzIGNvbnRhaW5lZCBpbiB0aGlzIGZpZWxkIGFuZCBob3cg dGhlIGNvbXBhcmlzb24gd29ya3MgaXQgaXMgZWl0aGVyIHBvc3NpYmxlIHRoYXQgYSBsZWdpdGlt YXRlIGNsaWVudCBpcyByZWplY3RlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHdoaWNo IGlzIGFubm95aW5nKSBvciBhbiBhc3NlcnRpb24gd2l0aCBhbiBpbmNvcnJlY3QgYXNzZXJ0aW9u IGlzIGFjY2VwdGVkICh3aGljaCBpcyBhIHNlY3VyaXR5IHByb2JsZW0pLgo+Pj4+Pj4+PiAKPj4+ Pj4+Pj4gQnR3LCB0aGUgc2FtZSBpc3N1ZSBjYW4gYWxzbyBiZSBzZWVuIGluIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wNCwgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTUgYW5kIGlu IGEgbW9yZSBnZW5lcmljIGZvcm0gYWxzbyBpbiB0aGUgSldUIChTZWN0aW9uIDQuMS4zIG9mIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4t MDY7ICJhdWQiIGNsYWltKS4gRnJvbSB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIEpXVCBkb2N1bWVu dCBJIHdhcyBub3QgcXVpdGUgc3VyZSB3aGV0aGVyIHRoZSBhYmlsaXR5IHRvIGNhcnJ5IGFuIGFy cmF5IG9mIGNhc2Ugc2Vuc2l0aXZlIHN0cmluZ3MgZm9yIHRoYXQgZmllbGQgaXMgYWxzbyBhbGxv d2VkIGluIGFueSBvZiB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50cy4KPj4+Pj4+Pj4gCj4+Pj4+Pj4+ IE5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIGRvY3VtZW50cyB0aGF0IHByb3ZpZGUgaW5wdXQgdG8g dGhpcyBwcm9ibGVtIHNwYWNlLCBuYW1lbHk6Cj4+Pj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzYxMjUKPj4+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWFiLWlkZW50aWZpZXItY29tcGFyaXNvbi0wNwo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gU28sIEkgd291 bGQgc3VnZ2VzdCB0byBkZWNpZGUgd2hhdCB0eXBlIG9mIGlkZW50aWZpZXIgZ29lcyBpbnRvIHRo aXMgZmllbGQgYW5kIHRoZW4gdG8gcG9pbnQgdG8gYSBkb2N1bWVudCB0aGF0IGlsbHVzdHJhdGVz IGhvdyB0aGUgY29tcGFyaXNvbiBvcGVyYXRpb24gd291bGQgbG9vayBsaWtlLiBQb3NzaWJsZSBp ZGVudGlmaWVycyBhcmUgZG9tYWluIG5hbWVzLCBJUCBhZGRyZXNzZXMsIFVSSXMsIGV0Yy4gSnVz dCBhcyBhbiBleGFtcGxlIGZyb20gUkZDIDYxMjUgd291bGQgeW91IGFsbG93IGEgd2lsZGNhcmQg bWF0Y2ggKGxpa2UgIiouZXhhbXBsZS5jb20iKSBvciBvbmx5IGFuIGVxdWFsaXR5IG1hdGNoPyBX b3VsZCAid3d3LmV4YW1wbGUuY29tIiBiZSB0aGUgc2FtZSBhcyAiZXhhbXBsZS5jb20iIGlmIHRo ZXkgcmVzb2x2ZSB0byB0aGUgc2FtZSBJUCBhZGRyZXNzKGVzKT8KPj4+Pj4+Pj4gCj4+Pj4+Pj4+ IENpYW8KPj4+Pj4+Pj4gSGFubmVzCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxp c3QKPj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4g T0F1dGhAaWV0Zi5vcmcKPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoCj4+Pj4+PiAKPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+IE9BdXRoQGll dGYub3JnCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Cj4+Pj4+IAo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+PiAKPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4gT0F1 dGggbWFpbGluZyBsaXN0Cj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+PiAKPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo+PiAKPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+IE9BdXRoQGlldGYub3JnCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPiAKPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9BdXRoIG1haWxpbmcgbGlzdAo+ IE9BdXRoQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0 aCBtYWlsaW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAo= ----_com.android.email_146709350860570 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+KzE8YnI+PGJyPjxicj4tLS0tLS0t LSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS08YnI+Vm9uOiBQaGlsIEh1bnQgJmx0 O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OyA8YnI+RGF0dW06ICA8YnI+QW46IE1pa2UgSm9uZXMg Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDsgPGJyPkNjOiBvYXV0aEBpZXRmLm9y ZyA8YnI+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25z LTA5IDxicj4gPGJyPjxicj4rMS4gVGhpcyBtYWtlcyBnb29kIHNlbnNlLiA8YnI+PGJyPlBoaWw8 YnI+PGJyPlNlbnQgZnJvbSBteSBwaG9uZS48YnI+PGJyPk9uIDIwMTMtMDEtMTUsIGF0IDE4OjI2 LCBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7IHdyb3RlOjxi cj48YnI+Jmd0OyBIYW5uZXMgYW5kIEkgc3Bva2UgYW5kIHdlbnQgdGhyb3VnaCB0aGUgaXNzdWVz LiZuYnNwOyBIZSB3YXMgdHJ5aW5nIHRvIG1heGltaXplIGludGVyb3BlcmFiaWxpdHkgb2YgaW1w bGVtZW50YXRpb25zIHdoaWNoIGlzIG9idmlvdXNseSBhIGdvb2QgZ29hbC4mbmJzcDsgSG93ZXZl ciwgYWZ0ZXIgZGlzY3Vzc2luZyB0aGUgcGFydGljdWxhcnMsIHdlIGFsc28gYWdyZWVkIHRoYXQs IGZvciBzb21lIGZlYXR1cmVzIGFuZCB1c2UgY2FzZXMsIHNwZWNpZmljIHByb2ZpbGVzIG9mIHRo ZSBhc3NlcnRpb25zIHdpbGwgYmUgbmVlZGVkIHRvIGFjaGlldmUgY29tcGxldGUgaW50ZXJvcGVy YWJpbGl0eSAoanVzdCBsaWtlIHByb2ZpbGVzIG9mIE9BdXRoIGFyZSByZXF1aXJlZCB0byBhY2hp ZXZlIGludGVyb3BlcmFiaWxpdHkpLjxicj4mZ3Q7IDxicj4mZ3Q7IFRoZXJlZm9yZSwgd2UgcHJv cG9zZSB0byBhZGQgYW4gZXhwbGFuYXRvcnkgcGFyYWdyYXBoIHRvIHRoZSBhc3NlcnRpb25zIGRv Y3VtZW50IGV4cGxhaW5pbmcgdGhhdCBwcm9maWxpbmcgd2lsbCBiZSByZXF1aXJlZCB0byBhY2hp ZXZlIGludGVyb3BlcmFiaWxpdHkgaW4gc29tZSBjYXNlcy4mbmJzcDsgVGhpcyB3b3VsZCBiZSBp biBleGFjdGx5IHRoZSBzYW1lIHNwaXJpdCBhcyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NzQ5I3NlY3Rpb24tMS44LCB3aGljaCBzdXBwbGllcyB0aGUgc2FtZSBraW5kcyBvZiBjYXZl YXRzIHRvIGltcGxlbWVudGVyJ3Mgb2YgT0F1dGggQ29yZS48YnI+Jmd0OyA8YnI+Jmd0OyBJJ2xs IHdvcmsgb24gcHJvcG9zZWQgc3BlY2lmaWMgd29yZGluZyBzaG9ydGx5LiZuYnNwOyBJJ2xsIG5v dGUgdGhhdCBhZGRpbmcgdGhpcyB0ZXh0IHdpbGwgbm90IGNoYW5nZSB0aGUgbWVhbmluZyBvZiB0 aGUgZG9jdW1lbnQgaW4gYW55IHdheSAtIGl0IHdpbGwgc2ltcGx5IHByb3ZpZGUgYWRkaXRpb25h bCBndWlkYW5jZSB0byBpbXBsZW1lbnRlcnMgb24gaG93IHRvIHRoaW5rIGFib3V0IHVzaW5nIHRo ZSBhc3NlcnRpb24gZnJhbWV3b3JrLjxicj4mZ3Q7IDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4mZ3Q7IEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldF0gPGJyPiZndDsgU2VudDogVHVlc2RheSwgSmFudWFyeSAxNSwgMjAx MyAxMDozNCBBTTxicj4mZ3Q7IFRvOiBNaWtlIEpvbmVzPGJyPiZndDsgQ2M6IEhhbm5lcyBUc2No b2ZlbmlnOyBvYXV0aEBpZXRmLm9yZyBXRzxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOTxicj4mZ3Q7IDxicj4mZ3Q7IEhpIE1pa2Us IDxicj4mZ3Q7IDxicj4mZ3Q7IEkgYW0gc3VyZSB0aGUgcmVzdCBvZiB0aGUgd29ya2luZyBncm91 cCBpcyBpbnRlcmVzdGVkIHRvIHNlZSBob3cgZGlmZmljdWx0IGl0IGlzIHRvIGFycmFuZ2UgYSBj b25mZXJlbmNlIGNhbGwgd2hlbiBvbmUgcGVyc29uIGlzIGluIEVzcG9vL0ZpbmxhbmQgYW5kIHRo ZSBvdGhlciBwZXJzb24gaW4gdGhlIFdlc3QgQ29hc3QuPGJyPiZndDsgSW4gYW55IGNhc2UsIEkg YW0gb25saW5lIGFuZCByZWFkeSB0byBjaGF0LiA8YnI+Jmd0OyA8YnI+Jmd0OyBJbiBhbnkgY2Fz ZSBJIHdpbGwgbGV0IHRoZSBncm91cCBrbm93IHdoYXQgY29uY2x1c2lvbnMgd2UgcmVhY2hlZC4g PGJyPiZndDsgPGJyPiZndDsgQ2lhbzxicj4mZ3Q7IEhhbm5lczxicj4mZ3Q7IDxicj4mZ3Q7IFBT OiBGb3Igc29tZSByZWFzb24geW91ciBTTVMgYXJyaXZlZCBvbmUgZGF5IGxhdGVyLi4uPGJyPiZn dDsgPGJyPiZndDsgT24gSmFuIDE1LCAyMDEzLCBhdCA3OjIwIFBNLCBNaWtlIEpvbmVzIHdyb3Rl Ojxicj4mZ3Q7IDxicj4mZ3Q7Jmd0OyBIaSBIYW5uZXMsPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyBDYW4geW91IHBsZWFzZSBlaXRoZXIgZ2l2ZSBtZSBhIGNhbGwgZm9yIHVzIHRvIHRhbGsgYWJv dXQgdGhlIGNoYW5nZXMgeW91IGhhdmUgaW4gbWluZCBvciB3cml0ZSBkb3duIHRoZSBzcGVjaWZp YyBjaGFuZ2VzIHlvdSB3YW50PyZuYnNwOyBJJ2QgbGlrZSB1cyB0byByZWFjaCBhIG11dHVhbCB1 bmRlcnN0YW5kaW5nIG9mIHdoYXQgeW91J3JlIHRyeWluZyB0byBhY2hpZXZlIGluIHRpbWUgZm9y IFN0ZXBoZW4gdG8gcHJvY2VlZCB3aXRoIHRoZSB0ZWxlY2hhdCBvbiBzY2hlZHVsZS48YnI+Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5r IHlvdSw8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ Jmd0OyZndDsgRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiA8YnI+Jmd0OyZndDsgT2YgTWlrZSBKb25lczxicj4mZ3Q7 Jmd0OyBTZW50OiBTdW5kYXksIEphbnVhcnkgMTMsIDIwMTMgMTE6MDMgUE08YnI+Jmd0OyZndDsg VG86IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPiZndDsmZ3Q7IENjOiBvYXV0aEBpZXRmLm9yZyBXRzxi cj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2Vy dGlvbnMtMDk8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEknbSB0aGlua2luZyBpdCB3b3VsZCBi ZSB1c2VmdWwgZm9yIHVzIHRvIHRhbGsgb24gdGhlIHBob25lIG9yIFNreXBlIHRvbW9ycm93LCBI YW5uZXMsIGJlY2F1c2UgSSdtIHByZXR0eSBzdXJlIEkgZG9uJ3Qga25vdyB3aGF0IHNwZWNpZmlj IGNoYW5nZXMgeW91J3JlIGFza2luZyBmb3IgaW4gd2hpY2ggc3BlY3MuJm5ic3A7IEFyZSB5b3Us IGZvciBpbnN0YW5jZSwgYXNraW5nIGZvciBsYW5ndWFnZSBzYXlpbmcgdGhhdCBhdWRpZW5jZSB2 YWx1ZXMgYXJlIHRvIGJlIGNvbXBhcmVkIGZvciBlcXVhbGl0eSBhcyBjYXNlLXNlbnNpdGl2ZSBz dHJpbmdzIGluIHRoZSBTQU1MIGJlYXJlciBhbmQgSldUIGJlYXJlciBzcGVjcz8mbmJzcDsgKFRo ZXkncmUgbm90IGp1c3QgVVJJcywgYXMgdGhleSBjYW4gYmUgT0F1dGggQ2xpZW50IElEcy4pJm5i c3A7IE9yIG1heWJlIHlvdSBjYW4gcHJvcG9zZSBzcGVjaWZpYyBsYW5ndWFnZSBjaGFuZ2VzLCBz byBpdCdzIGNsZWFyIHdoYXQgeW91J3JlIGFza2luZyBmb3IuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+Jmd0OyZndDsgPGJy PiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsmZ3Q7IEZyb206IEhh bm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF08YnI+Jmd0 OyZndDsgU2VudDogU3VuZGF5LCBKYW51YXJ5IDEzLCAyMDEzIDI6NDkgQU08YnI+Jmd0OyZndDsg VG86IE1pa2UgSm9uZXM8YnI+Jmd0OyZndDsgQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBCcmlhbiBD YW1wYmVsbDsgU3RlcGhlbiBGYXJyZWxsOyBvYXV0aEBpZXRmLm9yZyA8YnI+Jmd0OyZndDsgV0c8 YnI+Jmd0OyZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1hc3Nl cnRpb25zLTA5PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBIaSBNaWtlLDxicj4mZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsgaXQgaXMgZmluZSB0byBzdXBwb3J0IGRpZmZlcmVudCBpZGVudGlmaWVycyBh bmQgdG8gZXZlbiBhbGxvdyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBpZGVudGlmaWVycyB0byBnZXQg ZXh0ZW5kZWQgb3ZlciB0aW1lLiA8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEp1c3Qgb21pdHRp bmcgYSBkZXNjcmlwdGlvbiBpcywgaG93ZXZlciwgbm90IGFuIG9wdGlvbi4gV2UgYXJlIGluIHRo ZSBsdWNreSBwb3NpdGlvbiB3aGVyZSBvdGhlcnMgaGF2ZSBkb25lIHRoZSB3b3JrIGZvciB1cyBh bHJlYWR5IChhcyBtZW50aW9uZWQgaW4gdGhlIHR3byBjaXRlZCByZWZlcmVuY2VzKS4gRm9yIHRo ZSBJQUIgZG9jdW1lbnQgdGhlcmUgaXMgZXZlbiB0aGUgY2hhbmNlIHRvIHByb3ZpZGUgZmVlZGJh Y2sgKHNlZSBodHRwczovL3d3dy5pYWIub3JnLzIwMTMvMDEvMDkvY2FsbC1mb3ItY29tbWVudC1p c3N1ZXMtaW4taWRlbnRpZmllci1jb21wYXJpc29uLWZvci1zZWN1cml0eS1wdXJwb3Nlcy8pIGlu IGNhc2UgeW91IGJlbGlldmUgdGhlIGF1dGhvciBpcyBtaXNndWlkZWQuIFdlIGp1c3QgbmVlZCB0 byBtYWtlIHVzZSBvZiB0aGVtLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgQ2lhbzxicj4mZ3Q7 Jmd0OyBIYW5uZXM8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IE9uIEphbiAxMywgMjAxMywgYXQg MTI6MDkgUE0sIE1pa2UgSm9uZXMgd3JvdGU6PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsg V2UgYWxyZWFkeSBrbm93IG9mIHVzZSBjYXNlcyB3aGVyZSB0aGUgYXVkaWVuY2UgaXMgYW4gYWJz dHJhY3QgaWRlbnRpZmllciBhbmQgdXNlIGNhc2VzIHdoZXJlIHRoZSBhdWRpZW5jZSBpcyB0aGUg VVJMIG9mIHRoZSB0b2tlbiBlbmRwb2ludC4mbmJzcDsgQm90aCBhcmUgbGVnaXRpbWF0ZS4mbmJz cDsgV2Ugc2hvdWxkIGZvcmVjbG9zZSBuZWl0aGVyLjxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsm Z3Q7Jmd0OyBMaWtlIG1hbnkgdGhpbmdzIE9BdXRoLCBpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBh Y2hpZXZlZCwgYnV0IGl0IG1heSByZXF1aXJlIGEgcHJvZmlsZSBmdXJ0aGVyIHNwZWNpZnlpbmcg dGhlIGJlaGF2aW9ycyBhcHByb3ByaWF0ZSB0byB0aGF0IHVzZSBjYXNlLiZuYnNwOyBUaGlzIGlz IG5vdCBhIGJ1ZyAtIGl0IGlzIGEgZmVhdHVyZSwgYXMgaXQgaW5jcmVhc2VzIHRoZSBhcHBsaWNh YmlsaXR5IG9mIHRoZSBPQXV0aCBzcGVjaWZpY2F0aW9ucy48YnI+Jmd0OyZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyZndDsgVGhlIEFzc2VydGlvbiwgSldUIFByb2ZpbGUsIGFuZCBTQU1MIFByb2ZpbGUg YXJlIHN0cmlraW5nIGFuIGFwcHJvcHJpYXRlIGJhbGFuY2UgYnkgcHJvdmlkaW5nIGd1aWRhbmNl IG9uIGxpa2VseSBhdWRpZW5jZSB2YWx1ZXMgZm9yIG1hbnkgdXNlIGNhc2VzLCBidXQgbm90IHBy ZWNsdWRpbmcgb3RoZXIgdmFsdWVzIHdoZXJlIG5lY2Vzc2FyeSBmb3IgdGhvc2UgdXNlIGNhc2Vz Ljxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsmZ3Q7IEZyb206IEhhbm5lcyBU c2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF08YnI+Jmd0OyZndDsm Z3Q7IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxOjU2IEFNPGJyPiZndDsmZ3Q7Jmd0 OyBUbzogTWlrZSBKb25lczxicj4mZ3Q7Jmd0OyZndDsgQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBC cmlhbiBDYW1wYmVsbDsgU3RlcGhlbiBGYXJyZWxsOyA8YnI+Jmd0OyZndDsmZ3Q7IG9hdXRoQGll dGYub3JnIFdHPGJyPiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1p ZXRmLW9hdXRoLWFzc2VydGlvbnMtMDk8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsg SGkgTWlrZSw8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgSSB1bmRlcnN0YW5kIHlv dXIgcmVhc29uaW5nOiB5b3Ugd2FudCB0byBrZWVwIGFsbCBvcHRpb25zIG9wZW4gaW4gdGhlIGZy YW1ld29yayBzcGVjaWZpY2F0aW9uIGFuZCB5b3Ugd2FudCB0byBiZSBtb3JlIHNwZWNpZmljIGlu IGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlciBhbmQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1zYW1s Mi1iZWFyZXIuIDxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBUaGUgUkZDIDIxMTkg bGFuZ3VhZ2UgZG9lcyBub3QgYWRkIGFueXRoaW5nIGJ1dCBpdCBkb2VzIG5vdCBodXJ0IGVpdGhl ci4gSXQganVzdCBzYXlzIHRoYXQgdGhlcmUgY291bGQgZXNzZW50aWFsbHkgYmUgYW55dGhpbmcg aW4gdGhlcmUsIGluY2x1ZGluZyB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC48YnI+Jmd0 OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgWW91IGNhbiBvZiBjb3Vyc2UgcG9zdC1wb25lIGRl YWxpbmcgd2l0aCB0aGUgaXNzdWUgdG8gdGhlIG1vcmUgc3BlY2lmaWMgZG9jdW1lbnRzLiBGb3Ig ZXhhbXBsZSwgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyIGF0IHRoZSBtb21lbnQgZG9lcyBu b3QgYWxsb3cgYW4gaW50ZXJvcGVyYWJsZSBkZXBsb3ltZW50IHNpbmNlIGl0IGp1c3QgcmVwZWF0 cyB0aGUgYWJzdHJhY3QgZnJhbWV3b3JrIHRleHQgYnkgc2F5aW5nICJUaGUgdG9rZW4gZW5kcG9p bnQgVVJMIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYmUgdXNlZCBhcyBhbiBhY2Nl cHRhYmxlIHZhbHVlIGZvciBhbiAiYXVkIiBlbGVtZW50LiIgPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7IENpYW88YnI+Jmd0OyZndDsmZ3Q7IEhhbm5lczxicj4mZ3Q7Jmd0OyZndDsg PGJyPiZndDsmZ3Q7Jmd0OyBPbiBKYW4gMTIsIDIwMTMsIGF0IDEwOjQyIFBNLCBNaWtlIEpvbmVz IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsgSGkgSGFubmVzLDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEZvciB0aGUgcmVhc29ucyB0 aGF0IEp1c3RpbiBhbmQgQnJpYW4gc3RhdGUsIEkgYmVsaWV2ZSB0aGF0IHRoZSBNQVkgaXMgYXBw cm9wcmlhdGUuJm5ic3A7IEluIHNvbWUgdXNlIGNhc2VzLCBhIGdvb2QgcmVwcmVzZW50YXRpb24g b2YgYW4gYXBwcm9wcmlhdGUgYXVkaWVuY2UgdmFsdWUgaXMgVVJMIG9mIHRoZSBUb2tlbiBFbmRw b2ludC4mbmJzcDsgVGhhdCdzIHRoZXJlIGluIHRoZSBBc3NlcnRpb25zIHNwZWNpZmljYXRpb24g YXMgZ3VpZGFuY2UgdG8gd3JpdGVycyB0b2tlbi10eXBlIHNwZWNpZmljIHNwZWNzIHVzaW5nIHRo ZSBBc3NlcnRpb25zIHNwZWMsIGFzIEkgYmVsaWV2ZSBpdCBzaG91bGQgYmUuJm5ic3A7IFRoYXQg YmVpbmcgdGhlIGNhc2UsIGFzIEJyaWFuIGRlc2NyaWJlcywgc29tZXRpbWVzIGF1ZGllbmNlIHZh bHVlcyBhcmUgbW9yZSBhYnN0cmFjdCBpZGVudGlmaWVycyBvciBpZGVudGlmaWVycyBmb3IgZ3Jv dXBzIG9mIHNlcnZpY2VzLCBhbmQgd2UgZG9uJ3Qgd2FudCB0byBpbmFkdmVydGVudGx5IHByZWNs dWRlIHRob3NlIGFjdHVhbCB1c2UgY2FzZXMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsm Z3Q7Jmd0OyZndDsgVGh1cywgSSBiZWxpZXZlIHRoYXQgdGhlIGxhbmd1YWdlIGlzIGFwcHJvcHJp YXRlIGFzLWlzLiZuYnNwOyBUaHVzLCBJIGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgcHJvY2VlZCB3 aXRoIHRoZSBjdXJyZW50bHkgc2NoZWR1bGVkIHRlbGVjaGF0IGRpc2N1c3Npb24gb2YgdGhlIHNw ZWMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhhbmtzIGFsbCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPGJyPiZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gPGJyPiZndDsmZ3Q7 Jmd0OyZndDsgQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJyPiZndDsmZ3Q7Jmd0OyZndDsg U2VudDogU2F0dXJkYXksIEphbnVhcnkgMTIsIDIwMTMgMTE6NTAgQU08YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyBUbzogQnJpYW4gQ2FtcGJlbGw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogb2F1dGhAaWV0 Zi5vcmcgV0c8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFm dC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyBIaSBCcmlhbiw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGNoYWxsZW5naW5nLjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IE5ldmVydGhlbGVzcyBpdCB3b3VsZCBtYWtlIHNl bnNlIHRvIGRlc2NyaWJlIHRoZSBkZXNpcmVkIGJlaGF2aW9yIGluIGRyYWZ0LWlldGYtb2F1dGgt and0LWJlYXJlciBhbmQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXIgaW4gc3VjaCBh IHdheSB0aGF0IHR3byB2ZXJzaW9ucyBkZXZlbG9wZWQgYnkgZGlmZmVyZW50IGdyb3VwcyB3b3Vs ZCBpbnRlcm9wZXJhdGUgd2l0aG91dCBjYXVzaW5nIHNlY3VyaXR5IHByb2JsZW1zIG9yIGZhaWx1 cmVzLiA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBUbyBtb3ZlIGZv cndhcmQgd2l0aCBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMgSSBzdWdnZXN0IHRvIGZvbGxv dyB0aGUgcmVjb21tZW5kYXRpb24gaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMTA1MDcuaHRtbCBhbmQgdG8gYWRkcmVzcyB0aGUgZGV0YWls cyBpbiZuYnNwOyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIgYW5kIGluIGRyYWZ0LWlldGYt b2F1dGgtc2FtbDItYmVhcmVyIGFzIHNvb24gYXMgcG9zc2libGUgdG8gZ2V0IHRoZXNlIGRvY3Vt ZW50cyBtb3ZpbmcgZm9yd2FyZCBhbmQgY29tcGxldGVkIHNvb24uIDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IENpYW88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5uZXM8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKYW4gMTEsIDIwMTMs IGF0IDc6NTEgUE0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGF0IHRleHQgYXJvdW5kIGF1ZGllbmNlIGluIHRoZSBm cmFtZXdvcmsgc3BlYyBjaGFuZ2VkIGZyb20gYSBTSE9VTEQgdG8gYSBNQVkgaW4gLTA5IHNvIHRo YXQgaXQgd291bGQgYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHRoZSBTQU1MIGFuZCBKV1Qg dmVyc2lvbnMsIHdoaWNoIHdlcmUgYWxyZWFkeSB1c2luZyBhIE1BWSBpbiB0aGF0IGNvbnRleHQu PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VyIGNv bmNlcm4gaXMgdmFsaWQgSGFubmVzIGFuZCB5b3VyIHBvaW50IGlzIHRha2VuLiBCdXQgcmVhbGl0 eSBpcyByYXRoZXIgbWVzc3kgYW5kIEkgZG9uJ3QgYmVsaWV2ZSBpdCBjYW4gYWRkcmVzc2VkIGFz IGVhc2lseSBhcyB5b3Ugc3VnZ2VzdC4mbmJzcDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBTQU1MLCBmb3IgZXhhbXBsZSwgYW4gZW50aXR5IGlk ZW50aWZpZXIgaXMgb2Z0ZW4gdXNlZCBhcyBhIHZhbHVlIGZvciB0aGUgYXVkaWVuY2UgKHBlciBz cGVjIGFuZCBpbiBwcmFjdGljZSkuJm5ic3A7IEJ1dCBhbiBBUyBtYXkgbm90IG5lY2Vzc2FyaWx5 IGlkZW50aWZ5IGl0c2VsZiB3aXRoIGEgZnVsbCBibG93biBTQU1MIGVudGl0eSwgaW4gd2hpY2gg Y2FzZSB0aGUgdG9rZW4gZW5kcG9pbnQgVVJJIGlzIG1vcmUgYXBwcm9wcmlhdGUuIFRoZSB3aG9s ZSBpc3N1ZSBpcyBhbHNvIHNvbWV3aGF0IGNvbXBsaWNhdGVkIGluIFNBTUwgdG9vIGJ5IGl0IGhh dmluZyBib3RoIGF1ZGllbmNlIGFuZCByZWNpcGllbnQgdGhhdCBhcmUgc2ltaWxhciBidXQgbm90 IHRoZSBzYW1lLiBJJ3ZlIHRyaWVkIHRvIGFjY291bnQgZm9yIGFsbCBvZiB0aGlzIGluIHRoZSBT QU1MIGRvYyBidXQgaXQncyBhZG1pdHRlZGx5IHNvbWV3aGF0IGF3a3dhcmQgYW5kIGNvbXBsZXgg YW5kIG5vdCBhcyBzaW1wbGUgYXMgc2F5aW5nIHRoZSB2YWx1ZSBoYXMgdG8gYmUgWCBhbmQgbXVz dCBiZSB2YWxpZGF0ZWQgaW4gZXhhY3RseSBzdWNoIGEgd2F5Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSldUIGRvZXNuJ3QgaGF2ZSB0aGUgc2FtZSBo aXN0b3J5IGFuZCBiYWdnYWdlIG9mIFNBTUwgYnV0IGlzIHN1YmplY3QgdG8gbWFueSBvZiB0aGUg c2FtZSByZWFsIHdvcmxkIGRlcGxveW1lbnQgdmFyaWF0aW9ucy48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknbSBkZWZpbml0ZWx5IG9wZW4gdG8gaW1w cm92ZW1lbnRzIHdpdGggcmVzcGVjdCB0byB0aGUgaGFuZGxpbmcgb2YgPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGF1ZGllbmNlIHZhbHVlcyBidXQgSSBiZWxpZXZlIGFueXRoaW5nIHRoYXQgaXMg ZG9uZSBuZWVkcyB0byA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVmbGVjdCB0aGUgcmVhbGl0 aWVzIG9mIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50cyBhcyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgd2VsbCBhcyByZWxhdGVkIHNwZWNpZmljYXRpb25zLiw8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gRnJpLCBKYW4gMTEsIDIwMTMg YXQgODo1NSBBTSwgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDsgd3JvdGU6 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFllcyBpbiBhc3NlcnRpb25zIGl0IG5lZWRzIHRvIGJl IGdlbmVyYWwuJm5ic3A7IEl0IGlzIHRoZSBKV1QgYW5kIFNBTUwgcHJvZmlsZXMgdGhhdCBuZWVk IHRvIG5haWwgZG93biB3aGF0IHRoZSBmb3JtYXQgb2YgdGhlIGF1ZGllbmNlIGlzLiZuYnNwOyZu YnNwOyZuYnNwOyBUaGV5IHNob3VsZCBwcm9iYWJseSBib3RoIGJlIHRoZSBVUkkgb2YgdGhlIHRv a2VuIGVuZHBvaW50LiZuYnNwOyZuYnNwOyBJbiBib3RoIFNBTUwgYW5kIEpXVCB0aGVyZSBjYW4g YmUgbXVsdGlwbGUgYXVkaWVuY2VzIGZvciB0aGUgdG9rZW4uPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKb2huPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIDIwMTMtMDEtMTEsIGF0IDExOjM3IEFNLCAiUmljaGVyLCBKdXN0aW4gUC4iICZsdDtqcmlj aGVyQG1pdHJlLm9yZyZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQncyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGdlbmVy YWwgYXNzZXJ0aW9ucyBjbGFpbSBpcyBtb3JlIG9mIGEgY29uY2VwdHVhbCBtYXBwaW5nIHRoYW4g aXQgaXMgYSBjb25jcmV0ZSBlbmNvZGluZywgc28gYW55dGhpbmcgbW9yZSBzcGVjaWZpYyBoZXJl IHdvdWxkIGJlIG91dCBvZiBwbGFjZS4gSSB3b3VsZCBsaWtlIHRoZSBhdXRob3JzIHRvIGVpdGhl ciBjb25maXJtIG9yIGNvcnJlY3QgbXkgYXNzdW1wdGlvbnMsIHRob3VnaC48YnI+Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLSBKdXN0aW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiBKYW4gMTEsIDIwMTMsIGF0IDY6MzAgQU0sIFN0ZXBoZW4gRmFycmVsbCA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllJmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBIaSw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaW5jZSB3ZSB0aG91Z2h0IHdlIHdlcmUgZG9u ZSB3aXRoIGl0LCBJIHB1dCB0aGlzIGRvY3VtZW50IG9uIHRoZSA8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJRVNHIHRlbGVjaGF0IGFnZW5kYSBmb3IgSmFuIDI0LiBIYW5uZXMnIHF1 ZXN0aW9uIGhvd2V2ZXIgbG9va3MgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlr ZSBpdHMgYSByZWFsIG9uZSB0aGF0IG5lZWRzIGFuIGFuc3dlci48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJJ2QgYXBwcmVj aWF0ZSBpdCBpZiB0aGUgV0cgY291bGQgZmlndXJlIG91dCBpZiB0aGVyZSdzIGFueSA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2UgbmVlZGVkIGFuZCBlaXRoZXIgbWFrZSB0 aGF0IGNoYW5nZSBpbiB0aGUgbmV4dCB3ZWVrLCBvciA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBlbHNlIHRlbGwgbWUgdG8gdGFrZSB0aGUgZHJhZnQgb2ZmIHRoZSB0ZWxlY2hhdCBh Z2VuZGEgZm9yIG5vdy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiBkaXNjdXNzaW9uIGRvZXNuJ3QgaGFwcGVuLCBvciBo YXBwZW5zIGJ1dCBkb2Vzbid0IHJlYWNoIGEgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY29uY2x1c2lvbiwgdGhlbiBJJ2xsIHRha2UgdGhlIGRyYWZ0IG9mZiB0aGUgYWdlbmRhIGlu IGEgd2VlaydzIDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRpbWUgYW5kIHdlIGNh biBzb3J0IG91dCBpZiBhbnkgY2hhbmdlcyBhcmUgbmVlZGVkIGxhdGVyLjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBy ZWFzb24gd2h5IG5vdysxLXdlZWsgbWF0dGVycywgaXMgdGhhdCB0aGF0J3Mgd2hlbiBJRVNHIDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lbWJlcnMgdGVuZCB0byBkbyB0aGVpciBy ZXZpZXdzIGFuZCBoYXZpbmcgJ2VtIGFsbCByZXZpZXcgYSA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBtb3ZpbmcgdGFyZ2V0IGlzbid0IGEgZ29vZCBwbGFuLjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5r cyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzExLzIw MTMgMDg6MTggQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBndXlzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB1cGRh dGluZyB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50IGFuZCBmb3IgaW5jb3Jwb3JhdGluZyB0aGUgY29t bWVudHMgcmVjZWl2ZWQgb24gdGhlIG1haWxpbmcgbGlzdC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJl IGlzIG9ubHkgb25lIGlzc3VlIHRoYXQgY2F1Z2h0IG15IGF0dGVudGlvbi4gWW91IGNoYW5nZWQg dGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhdWRpZW5jZSBlbGVtZW50IHRvIHRoZSBmb2xsb3dpbmcg dGV4dCAoaW4gdmVyc2lvbiAtMDkgb2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5KTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgIjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBdWRpZW5jZSZuYnNw OyBBIHZhbHVlIHRoYXQgaWRlbnRpZmllcyB0aGUgcGFydGllcyBpbnRlbmRlZCB0byA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvY2VzcyB0aGUmbmJzcDsgYXNzZXJ0aW9u LiZuYnNwOyBBbiBhdWRpZW5jZSB2YWx1ZSBNQVkgYmUgdGhlIFVSTCBvZiB0aGUgPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRva2VuIEVuZHBvaW50Jm5ic3A7IGFzIGRlZmlu ZWQgaW4gU2VjdGlvbiAzLjIgb2YgT0F1dGggMi4wIFtSRkM2NzQ5XS48YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgIjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2luY2UgdGhlIHZhbHVlIGlu IHRoZSBhdWRpZW5jZSBmaWVsZCBpcyB1c2VkIHRvIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpbiBhIGNvbXBhcmlzb24gb3BlcmF0aW9uIChzZWUgU2VjdGlvbiA1LjIpIEkgYmVsaWV2ZSB0 aGUgY3VycmVudCB0ZXh0IHdpbGwgbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiBO b3Qgb25seSBpcyB0aGUgY29tcGFyaXNpb24gb3BlcmF0aW9uIHVuc3BlY2lmaWVkIGJ1dCBldmVu IHRoZSB2YWx1ZSB0aGF0IGlzIGNvbnRhaW5lZCBpbiB0aGUgZmllbGQgaXMgbGVmdCBvcGVuLiBU aGUgUkZDIDIxMTkgTUFZIGRvZXMgbm90IHJlYWxseSBnaXZlIGEgbG90IG9mIGhpbnRzIG9mIHdo YXQgc2hvdWxkIGJlIHB1dCBpbiB0aGVyZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdpdGhvdXQgaGF2aW5n IGEgY2xlYXIgZGVzY3JpcHRpb24gb2Ygd2hhdCBpZGVudGlmaWVyIGlzIGNvbnRhaW5lZCBpbiB0 aGlzIGZpZWxkIGFuZCBob3cgdGhlIGNvbXBhcmlzb24gd29ya3MgaXQgaXMgZWl0aGVyIHBvc3Np YmxlIHRoYXQgYSBsZWdpdGltYXRlIGNsaWVudCBpcyByZWplY3RlZCBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgKHdoaWNoIGlzIGFubm95aW5nKSBvciBhbiBhc3NlcnRpb24gd2l0aCBhbiBp bmNvcnJlY3QgYXNzZXJ0aW9uIGlzIGFjY2VwdGVkICh3aGljaCBpcyBhIHNlY3VyaXR5IHByb2Js ZW0pLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnR3LCB0aGUgc2FtZSBpc3N1ZSBjYW4gYWxzbyBiZSBzZWVu IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJl ci0wNCwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1i ZWFyZXItMTUgYW5kIGluIGEgbW9yZSBnZW5lcmljIGZvcm0gYWxzbyBpbiB0aGUgSldUIChTZWN0 aW9uIDQuMS4zIG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItdG9rZW4tMDY7ICJhdWQiIGNsYWltKS4gRnJvbSB0aGUgZGVzY3JpcHRpb24gaW4g dGhlIEpXVCBkb2N1bWVudCBJIHdhcyBub3QgcXVpdGUgc3VyZSB3aGV0aGVyIHRoZSBhYmlsaXR5 IHRvIGNhcnJ5IGFuIGFycmF5IG9mIGNhc2Ugc2Vuc2l0aXZlIHN0cmluZ3MgZm9yIHRoYXQgZmll bGQgaXMgYWxzbyBhbGxvd2VkIGluIGFueSBvZiB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50cy48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIGRvY3VtZW50cyB0aGF0IHByb3Zp ZGUgaW5wdXQgdG8gdGhpcyBwcm9ibGVtIHNwYWNlLCBuYW1lbHk6PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxMjU8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWFiLWlkZW50aWZpZXItY29tcGFyaXNvbi0wNzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU28s IEkgd291bGQgc3VnZ2VzdCB0byBkZWNpZGUgd2hhdCB0eXBlIG9mIGlkZW50aWZpZXIgZ29lcyBp bnRvIHRoaXMgZmllbGQgYW5kIHRoZW4gdG8gcG9pbnQgdG8gYSBkb2N1bWVudCB0aGF0IGlsbHVz dHJhdGVzIGhvdyB0aGUgY29tcGFyaXNvbiBvcGVyYXRpb24gd291bGQgbG9vayBsaWtlLiBQb3Nz aWJsZSBpZGVudGlmaWVycyBhcmUgZG9tYWluIG5hbWVzLCBJUCBhZGRyZXNzZXMsIFVSSXMsIGV0 Yy4gSnVzdCBhcyBhbiBleGFtcGxlIGZyb20gUkZDIDYxMjUgd291bGQgeW91IGFsbG93IGEgd2ls ZGNhcmQgbWF0Y2ggKGxpa2UgIiouZXhhbXBsZS5jb20iKSBvciBvbmx5IGFuIGVxdWFsaXR5IG1h dGNoPyBXb3VsZCAid3d3LmV4YW1wbGUuY29tIiBiZSB0aGUgc2FtZSBhcyAiZXhhbXBsZS5jb20i IGlmIHRoZXkgcmVzb2x2ZSB0byB0aGUgc2FtZSBJUCBhZGRyZXNzKGVzKT88YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IENpYW88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGFubmVzPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRo QGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGgg bWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJy PiZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZn dDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi cj4mZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8YnI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48L2JvZHk+ ----_com.android.email_146709350860570-- From Michael.Jones@microsoft.com Wed Jan 16 11:49:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B650921F8AE6 for ; Wed, 16 Jan 2013 11:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnm+hRNaoD6S for ; Wed, 16 Jan 2013 11:49:15 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7000521F8AE7 for ; Wed, 16 Jan 2013 11:49:15 -0800 (PST) Received: from BY2FFO11FD012.protection.gbl (10.1.15.201) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 16 Jan 2013 19:49:12 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 16 Jan 2013 19:49:12 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 16 Jan 2013 19:48:23 +0000 From: Mike Jones To: Torsten Lodderstedt , "phil.hunt@oracle.com" Thread-Topic: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Thread-Index: AQHN9Aym6AD6RmVsq0CmL2nb/gYQvZhMVjQg Date: Wed, 16 Jan 2013 19:48:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A4AF8D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A4AF8DTK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(52604002)(51704002)(52144001)(52544001)(164054002)(479174001)(13464002)(24454001)(31966008)(33656001)(44976002)(56816002)(59766001)(77982001)(49866001)(79102001)(16406001)(5343645001)(16601075001)(51856001)(74662001)(5343635001)(5343655001)(47446002)(15202345001)(16236675001)(55846006)(512874001)(74502001)(56776001)(54316002)(53806001)(46102001)(16297215001)(4396001)(54356001)(47976001)(50986001)(47736001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB006; H:TK5EX14HUBC103.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07283408BE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:49:17 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A4AF8DTK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcm9wb3NlIHRoYXQgdGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbiBoZWFkaW5nIGFuZCBwYXJh Z3JhcGggYmUgYWRkZWQgdG8gdGhlIEFzc2VydGlvbnMgc3BlY2lmaWNhdGlvbiwgcmlnaHQgYmVm b3JlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gIEZlZWRiYWNrIG9uIHRoZSB3b3JkaW5n IGlzIHdlbGNvbWUhDQoNCjcuICBJbnRlcm9wZXJhYmlsaXR5DQoNClRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIGEgZnJhbWV3b3JrIGZvciB1c2luZyBhc3NlcnRpb25zIHdpdGggT0F1dGggMi4w LiAgSG93ZXZlciwgYXMgYW4gZXh0ZW5zaWJsZSBmcmFtZXdvcmsgaW4gd2hpY2ggdGhlIGRhdGEg Zm9ybWF0cyB1c2VkIGZvciByZXByZXNlbnRpbmcgbWFueSAgdmFsdWVzIGFyZSBub3QgZGVmaW5l ZCwgb24gaXRzIG93biwgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIG5vdCBzdWZmaWNpZW50IHRvIHBy b2R1Y2UgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuDQoNCkV2ZW4gd2hlbiBwcm9maWxl ZCBmb3Igc3BlY2lmaWMgYXNzZXJ0aW9uIHR5cGVzLCBhcyBpcyBkb25lIGZvciBTQU1MIDIuMCBp biBbSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVyXSBhbmQgSlNPTiBXZWIgVG9rZW4gKEpXVCkg aW4gW0ktRC5pZXRmLW9hdXRoLWp3dC1iZWFyZXJdLCBhZGRpdGlvbmFsIHByb2ZpbGluZyBmb3Ig c3BlY2lmaWMgdXNlIGNhc2VzIHdpbGwgYmUgcmVxdWlyZWQgdG8gYWNoaWV2ZSBmdWxsIGludGVy b3BlcmFiaWxpdHkuICBGb3IgaW5zdGFuY2UsIGluIGRpZmZlcmVudCB1c2UgY2FzZXMsIHRoZSB2 YWx1ZXMgdXNlZCBmb3IgSXNzdWVyLCBQcmluY2lwYWwsIGFuZCBBdWRpZW5jZSBpZGVudGlmaWVy cyB3aWxsIGRpZmZlci4gIFRoaXMgZnJhbWV3b3JrIHdhcyBkZXNpZ25lZCB3aXRoIHRoZSBjbGVh ciBleHBlY3RhdGlvbiB0aGF0IGZ1dHVyZSB3b3JrIHdpbGwgZGVmaW5lIHByZXNjcmlwdGl2ZSBw cm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2Fs ZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXRdDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTYsIDIwMTMgOToxMiBBTQ0KVG86IHBo aWwuaHVudEBvcmFjbGUuY29tOyBNaWtlIEpvbmVzDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IEFXOiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDkNCg0K KzENCg0KDQotLS0tLS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0NClZvbjog UGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+Pg0KRGF0dW06DQpBbjogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCkJldHJlZmY6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWll dGYtb2F1dGgtYXNzZXJ0aW9ucy0wOQ0KDQoNCisxLiBUaGlzIG1ha2VzIGdvb2Qgc2Vuc2UuDQoN ClBoaWwNCg0KU2VudCBmcm9tIG15IHBob25lLg0KDQpPbiAyMDEzLTAxLTE1LCBhdCAxODoyNiwg TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPiBIYW5uZXMgYW5kIEkgc3Bva2UgYW5kIHdl bnQgdGhyb3VnaCB0aGUgaXNzdWVzLiAgSGUgd2FzIHRyeWluZyB0byBtYXhpbWl6ZSBpbnRlcm9w ZXJhYmlsaXR5IG9mIGltcGxlbWVudGF0aW9ucyB3aGljaCBpcyBvYnZpb3VzbHkgYSBnb29kIGdv YWwuICBIb3dldmVyLCBhZnRlciBkaXNjdXNzaW5nIHRoZSBwYXJ0aWN1bGFycywgd2UgYWxzbyBh Z3JlZWQgdGhhdCwgZm9yIHNvbWUgZmVhdHVyZXMgYW5kIHVzZSBjYXNlcywgc3BlY2lmaWMgcHJv ZmlsZXMgb2YgdGhlIGFzc2VydGlvbnMgd2lsbCBiZSBuZWVkZWQgdG8gYWNoaWV2ZSBjb21wbGV0 ZSBpbnRlcm9wZXJhYmlsaXR5IChqdXN0IGxpa2UgcHJvZmlsZXMgb2YgT0F1dGggYXJlIHJlcXVp cmVkIHRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSkuDQo+DQo+IFRoZXJlZm9yZSwgd2UgcHJv cG9zZSB0byBhZGQgYW4gZXhwbGFuYXRvcnkgcGFyYWdyYXBoIHRvIHRoZSBhc3NlcnRpb25zIGRv Y3VtZW50IGV4cGxhaW5pbmcgdGhhdCBwcm9maWxpbmcgd2lsbCBiZSByZXF1aXJlZCB0byBhY2hp ZXZlIGludGVyb3BlcmFiaWxpdHkgaW4gc29tZSBjYXNlcy4gIFRoaXMgd291bGQgYmUgaW4gZXhh Y3RseSB0aGUgc2FtZSBzcGlyaXQgYXMgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0 OSNzZWN0aW9uLTEuOCwgd2hpY2ggc3VwcGxpZXMgdGhlIHNhbWUga2luZHMgb2YgY2F2ZWF0cyB0 byBpbXBsZW1lbnRlcidzIG9mIE9BdXRoIENvcmUuDQo+DQo+IEknbGwgd29yayBvbiBwcm9wb3Nl ZCBzcGVjaWZpYyB3b3JkaW5nIHNob3J0bHkuICBJJ2xsIG5vdGUgdGhhdCBhZGRpbmcgdGhpcyB0 ZXh0IHdpbGwgbm90IGNoYW5nZSB0aGUgbWVhbmluZyBvZiB0aGUgZG9jdW1lbnQgaW4gYW55IHdh eSAtIGl0IHdpbGwgc2ltcGx5IHByb3ZpZGUgYWRkaXRpb25hbCBndWlkYW5jZSB0byBpbXBsZW1l bnRlcnMgb24gaG93IHRvIHRoaW5rIGFib3V0IHVzaW5nIHRoZSBhc3NlcnRpb24gZnJhbWV3b3Jr Lg0KPg0KPiAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCj4gICAgICAgICAgICAgICAgLS0g TWlrZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIYW5uZXMgVHNj aG9mZW5pZyBbbWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXRdDQo+IFNlbnQ6IFR1ZXNk YXksIEphbnVhcnkgMTUsIDIwMTMgMTA6MzQgQU0NCj4gVG86IE1pa2UgSm9uZXMNCj4gQ2M6IEhh bm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdH DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0w OQ0KPg0KPiBIaSBNaWtlLA0KPg0KPiBJIGFtIHN1cmUgdGhlIHJlc3Qgb2YgdGhlIHdvcmtpbmcg Z3JvdXAgaXMgaW50ZXJlc3RlZCB0byBzZWUgaG93IGRpZmZpY3VsdCBpdCBpcyB0byBhcnJhbmdl IGEgY29uZmVyZW5jZSBjYWxsIHdoZW4gb25lIHBlcnNvbiBpcyBpbiBFc3Bvby9GaW5sYW5kIGFu ZCB0aGUgb3RoZXIgcGVyc29uIGluIHRoZSBXZXN0IENvYXN0Lg0KPiBJbiBhbnkgY2FzZSwgSSBh bSBvbmxpbmUgYW5kIHJlYWR5IHRvIGNoYXQuDQo+DQo+IEluIGFueSBjYXNlIEkgd2lsbCBsZXQg dGhlIGdyb3VwIGtub3cgd2hhdCBjb25jbHVzaW9ucyB3ZSByZWFjaGVkLg0KPg0KPiBDaWFvDQo+ IEhhbm5lcw0KPg0KPiBQUzogRm9yIHNvbWUgcmVhc29uIHlvdXIgU01TIGFycml2ZWQgb25lIGRh eSBsYXRlci4uLg0KPg0KPiBPbiBKYW4gMTUsIDIwMTMsIGF0IDc6MjAgUE0sIE1pa2UgSm9uZXMg d3JvdGU6DQo+DQo+PiBIaSBIYW5uZXMsDQo+Pg0KPj4gQ2FuIHlvdSBwbGVhc2UgZWl0aGVyIGdp dmUgbWUgYSBjYWxsIGZvciB1cyB0byB0YWxrIGFib3V0IHRoZSBjaGFuZ2VzIHlvdSBoYXZlIGlu IG1pbmQgb3Igd3JpdGUgZG93biB0aGUgc3BlY2lmaWMgY2hhbmdlcyB5b3Ugd2FudD8gIEknZCBs aWtlIHVzIHRvIHJlYWNoIGEgbXV0dWFsIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB5b3UncmUgdHJ5 aW5nIHRvIGFjaGlldmUgaW4gdGltZSBmb3IgU3RlcGhlbiB0byBwcm9jZWVkIHdpdGggdGhlIHRl bGVjaGF0IG9uIHNjaGVkdWxlLg0KPj4NCj4+ICAgICAgICAgICAgICAgIFRoYW5rIHlvdSwNCj4+ ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+IE9m IE1pa2UgSm9uZXMNCj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxMTowMyBQTQ0K Pj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiBDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPiBXRw0KPj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1v YXV0aC1hc3NlcnRpb25zLTA5DQo+Pg0KPj4gSSdtIHRoaW5raW5nIGl0IHdvdWxkIGJlIHVzZWZ1 bCBmb3IgdXMgdG8gdGFsayBvbiB0aGUgcGhvbmUgb3IgU2t5cGUgdG9tb3Jyb3csIEhhbm5lcywg YmVjYXVzZSBJJ20gcHJldHR5IHN1cmUgSSBkb24ndCBrbm93IHdoYXQgc3BlY2lmaWMgY2hhbmdl cyB5b3UncmUgYXNraW5nIGZvciBpbiB3aGljaCBzcGVjcy4gIEFyZSB5b3UsIGZvciBpbnN0YW5j ZSwgYXNraW5nIGZvciBsYW5ndWFnZSBzYXlpbmcgdGhhdCBhdWRpZW5jZSB2YWx1ZXMgYXJlIHRv IGJlIGNvbXBhcmVkIGZvciBlcXVhbGl0eSBhcyBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdzIGluIHRo ZSBTQU1MIGJlYXJlciBhbmQgSldUIGJlYXJlciBzcGVjcz8gIChUaGV5J3JlIG5vdCBqdXN0IFVS SXMsIGFzIHRoZXkgY2FuIGJlIE9BdXRoIENsaWVudCBJRHMuKSAgT3IgbWF5YmUgeW91IGNhbiBw cm9wb3NlIHNwZWNpZmljIGxhbmd1YWdlIGNoYW5nZXMsIHNvIGl0J3MgY2xlYXIgd2hhdCB5b3Un cmUgYXNraW5nIGZvci4NCj4+DQo+PiAgICAgICAgICAgICAgICBUaGFua3MsDQo+PiAgICAgICAg ICAgICAgICAtLSBNaWtlDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF0N Cj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAyOjQ5IEFNDQo+PiBUbzogTWlrZSBK b25lcw0KPj4gQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBCcmlhbiBDYW1wYmVsbDsgU3RlcGhlbiBG YXJyZWxsOyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+PiBXRw0KPj4g U3ViamVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5DQo+ Pg0KPj4gSGkgTWlrZSwNCj4+DQo+PiBpdCBpcyBmaW5lIHRvIHN1cHBvcnQgZGlmZmVyZW50IGlk ZW50aWZpZXJzIGFuZCB0byBldmVuIGFsbG93IHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGlkZW50aWZp ZXJzIHRvIGdldCBleHRlbmRlZCBvdmVyIHRpbWUuDQo+Pg0KPj4gSnVzdCBvbWl0dGluZyBhIGRl c2NyaXB0aW9uIGlzLCBob3dldmVyLCBub3QgYW4gb3B0aW9uLiBXZSBhcmUgaW4gdGhlIGx1Y2t5 IHBvc2l0aW9uIHdoZXJlIG90aGVycyBoYXZlIGRvbmUgdGhlIHdvcmsgZm9yIHVzIGFscmVhZHkg KGFzIG1lbnRpb25lZCBpbiB0aGUgdHdvIGNpdGVkIHJlZmVyZW5jZXMpLiBGb3IgdGhlIElBQiBk b2N1bWVudCB0aGVyZSBpcyBldmVuIHRoZSBjaGFuY2UgdG8gcHJvdmlkZSBmZWVkYmFjayAoc2Vl IGh0dHBzOi8vd3d3LmlhYi5vcmcvMjAxMy8wMS8wOS9jYWxsLWZvci1jb21tZW50LWlzc3Vlcy1p bi1pZGVudGlmaWVyLWNvbXBhcmlzb24tZm9yLXNlY3VyaXR5LXB1cnBvc2VzLykgaW4gY2FzZSB5 b3UgYmVsaWV2ZSB0aGUgYXV0aG9yIGlzIG1pc2d1aWRlZC4gV2UganVzdCBuZWVkIHRvIG1ha2Ug dXNlIG9mIHRoZW0uDQo+Pg0KPj4gQ2lhbw0KPj4gSGFubmVzDQo+Pg0KPj4gT24gSmFuIDEzLCAy MDEzLCBhdCAxMjowOSBQTSwgTWlrZSBKb25lcyB3cm90ZToNCj4+DQo+Pj4gV2UgYWxyZWFkeSBr bm93IG9mIHVzZSBjYXNlcyB3aGVyZSB0aGUgYXVkaWVuY2UgaXMgYW4gYWJzdHJhY3QgaWRlbnRp ZmllciBhbmQgdXNlIGNhc2VzIHdoZXJlIHRoZSBhdWRpZW5jZSBpcyB0aGUgVVJMIG9mIHRoZSB0 b2tlbiBlbmRwb2ludC4gIEJvdGggYXJlIGxlZ2l0aW1hdGUuICBXZSBzaG91bGQgZm9yZWNsb3Nl IG5laXRoZXIuDQo+Pj4NCj4+PiBMaWtlIG1hbnkgdGhpbmdzIE9BdXRoLCBpbnRlcm9wZXJhYmls aXR5IGNhbiBiZSBhY2hpZXZlZCwgYnV0IGl0IG1heSByZXF1aXJlIGEgcHJvZmlsZSBmdXJ0aGVy IHNwZWNpZnlpbmcgdGhlIGJlaGF2aW9ycyBhcHByb3ByaWF0ZSB0byB0aGF0IHVzZSBjYXNlLiAg VGhpcyBpcyBub3QgYSBidWcgLSBpdCBpcyBhIGZlYXR1cmUsIGFzIGl0IGluY3JlYXNlcyB0aGUg YXBwbGljYWJpbGl0eSBvZiB0aGUgT0F1dGggc3BlY2lmaWNhdGlvbnMuDQo+Pj4NCj4+PiBUaGUg QXNzZXJ0aW9uLCBKV1QgUHJvZmlsZSwgYW5kIFNBTUwgUHJvZmlsZSBhcmUgc3RyaWtpbmcgYW4g YXBwcm9wcmlhdGUgYmFsYW5jZSBieSBwcm92aWRpbmcgZ3VpZGFuY2Ugb24gbGlrZWx5IGF1ZGll bmNlIHZhbHVlcyBmb3IgbWFueSB1c2UgY2FzZXMsIGJ1dCBub3QgcHJlY2x1ZGluZyBvdGhlciB2 YWx1ZXMgd2hlcmUgbmVjZXNzYXJ5IGZvciB0aG9zZSB1c2UgY2FzZXMuDQo+Pj4NCj4+PiAgICAg ICAgICAgICAgICBCZXN0IHdpc2hlcywNCj4+PiAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pj4N Cj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IEhhbm5lcyBUc2Nob2Zl bmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF0NCj4+PiBTZW50OiBTdW5kYXks IEphbnVhcnkgMTMsIDIwMTMgMTo1NiBBTQ0KPj4+IFRvOiBNaWtlIEpvbmVzDQo+Pj4gQ2M6IEhh bm5lcyBUc2Nob2ZlbmlnOyBCcmlhbiBDYW1wYmVsbDsgU3RlcGhlbiBGYXJyZWxsOw0KPj4+IG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0cNCj4+PiBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDkNCj4+Pg0KPj4+IEhpIE1p a2UsDQo+Pj4NCj4+PiBJIHVuZGVyc3RhbmQgeW91ciByZWFzb25pbmc6IHlvdSB3YW50IHRvIGtl ZXAgYWxsIG9wdGlvbnMgb3BlbiBpbiB0aGUgZnJhbWV3b3JrIHNwZWNpZmljYXRpb24gYW5kIHlv dSB3YW50IHRvIGJlIG1vcmUgc3BlY2lmaWMgaW4gZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVy IGFuZCBpbiBkcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci4NCj4+Pg0KPj4+IFRoZSBSRkMg MjExOSBsYW5ndWFnZSBkb2VzIG5vdCBhZGQgYW55dGhpbmcgYnV0IGl0IGRvZXMgbm90IGh1cnQg ZWl0aGVyLiBJdCBqdXN0IHNheXMgdGhhdCB0aGVyZSBjb3VsZCBlc3NlbnRpYWxseSBiZSBhbnl0 aGluZyBpbiB0aGVyZSwgaW5jbHVkaW5nIHRoZSBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50Lg0K Pj4+DQo+Pj4gWW91IGNhbiBvZiBjb3Vyc2UgcG9zdC1wb25lIGRlYWxpbmcgd2l0aCB0aGUgaXNz dWUgdG8gdGhlIG1vcmUgc3BlY2lmaWMgZG9jdW1lbnRzLiBGb3IgZXhhbXBsZSwgZHJhZnQtaWV0 Zi1vYXV0aC1qd3QtYmVhcmVyIGF0IHRoZSBtb21lbnQgZG9lcyBub3QgYWxsb3cgYW4gaW50ZXJv cGVyYWJsZSBkZXBsb3ltZW50IHNpbmNlIGl0IGp1c3QgcmVwZWF0cyB0aGUgYWJzdHJhY3QgZnJh bWV3b3JrIHRleHQgYnkgc2F5aW5nICJUaGUgdG9rZW4gZW5kcG9pbnQgVVJMIG9mIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNQVkgYmUgdXNlZCBhcyBhbiBhY2NlcHRhYmxlIHZhbHVlIGZvciBh biAiYXVkIiBlbGVtZW50LiINCj4+Pg0KPj4+IENpYW8NCj4+PiBIYW5uZXMNCj4+Pg0KPj4+IE9u IEphbiAxMiwgMjAxMywgYXQgMTA6NDIgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+Pj4NCj4+Pj4g SGkgSGFubmVzLA0KPj4+Pg0KPj4+PiBGb3IgdGhlIHJlYXNvbnMgdGhhdCBKdXN0aW4gYW5kIEJy aWFuIHN0YXRlLCBJIGJlbGlldmUgdGhhdCB0aGUgTUFZIGlzIGFwcHJvcHJpYXRlLiAgSW4gc29t ZSB1c2UgY2FzZXMsIGEgZ29vZCByZXByZXNlbnRhdGlvbiBvZiBhbiBhcHByb3ByaWF0ZSBhdWRp ZW5jZSB2YWx1ZSBpcyBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50LiAgVGhhdCdzIHRoZXJlIGlu IHRoZSBBc3NlcnRpb25zIHNwZWNpZmljYXRpb24gYXMgZ3VpZGFuY2UgdG8gd3JpdGVycyB0b2tl bi10eXBlIHNwZWNpZmljIHNwZWNzIHVzaW5nIHRoZSBBc3NlcnRpb25zIHNwZWMsIGFzIEkgYmVs aWV2ZSBpdCBzaG91bGQgYmUuICBUaGF0IGJlaW5nIHRoZSBjYXNlLCBhcyBCcmlhbiBkZXNjcmli ZXMsIHNvbWV0aW1lcyBhdWRpZW5jZSB2YWx1ZXMgYXJlIG1vcmUgYWJzdHJhY3QgaWRlbnRpZmll cnMgb3IgaWRlbnRpZmllcnMgZm9yIGdyb3VwcyBvZiBzZXJ2aWNlcywgYW5kIHdlIGRvbid0IHdh bnQgdG8gaW5hZHZlcnRlbnRseSBwcmVjbHVkZSB0aG9zZSBhY3R1YWwgdXNlIGNhc2VzLg0KPj4+ Pg0KPj4+PiBUaHVzLCBJIGJlbGlldmUgdGhhdCB0aGUgbGFuZ3VhZ2UgaXMgYXBwcm9wcmlhdGUg YXMtaXMuICBUaHVzLCBJIGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgcHJvY2VlZCB3aXRoIHRoZSBj dXJyZW50bHkgc2NoZWR1bGVkIHRlbGVjaGF0IGRpc2N1c3Npb24gb2YgdGhlIHNwZWMuDQo+Pj4+ DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRoYW5rcyBhbGwsDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+Pj4NCj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPj4+PiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNCj4+Pj4gU2VudDogU2F0 dXJkYXksIEphbnVhcnkgMTIsIDIwMTMgMTE6NTAgQU0NCj4+Pj4gVG86IEJyaWFuIENhbXBiZWxs DQo+Pj4+IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdHDQo+Pj4+ IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOQ0K Pj4+Pg0KPj4+PiBIaSBCcmlhbiwNCj4+Pj4NCj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBp cyBjaGFsbGVuZ2luZy4NCj4+Pj4NCj4+Pj4gTmV2ZXJ0aGVsZXNzIGl0IHdvdWxkIG1ha2Ugc2Vu c2UgdG8gZGVzY3JpYmUgdGhlIGRlc2lyZWQgYmVoYXZpb3IgaW4gZHJhZnQtaWV0Zi1vYXV0aC1q d3QtYmVhcmVyIGFuZCBpbiBkcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlciBpbiBzdWNoIGEg d2F5IHRoYXQgdHdvIHZlcnNpb25zIGRldmVsb3BlZCBieSBkaWZmZXJlbnQgZ3JvdXBzIHdvdWxk IGludGVyb3BlcmF0ZSB3aXRob3V0IGNhdXNpbmcgc2VjdXJpdHkgcHJvYmxlbXMgb3IgZmFpbHVy ZXMuDQo+Pj4+DQo+Pj4+IFRvIG1vdmUgZm9yd2FyZCB3aXRoIGRyYWZ0LWlldGYtb2F1dGgtYXNz ZXJ0aW9ucyBJIHN1Z2dlc3QgdG8gZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiBpbiBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDUwNy5odG1s IGFuZCB0byBhZGRyZXNzIHRoZSBkZXRhaWxzIGluICBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFy ZXIgYW5kIGluIGRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyIGFzIHNvb24gYXMgcG9zc2li bGUgdG8gZ2V0IHRoZXNlIGRvY3VtZW50cyBtb3ZpbmcgZm9yd2FyZCBhbmQgY29tcGxldGVkIHNv b24uDQo+Pj4+DQo+Pj4+IENpYW8NCj4+Pj4gSGFubmVzDQo+Pj4+DQo+Pj4+IE9uIEphbiAxMSwg MjAxMywgYXQgNzo1MSBQTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+Pj4+DQo+Pj4+PiBUaGF0 IHRleHQgYXJvdW5kIGF1ZGllbmNlIGluIHRoZSBmcmFtZXdvcmsgc3BlYyBjaGFuZ2VkIGZyb20g YSBTSE9VTEQgdG8gYSBNQVkgaW4gLTA5IHNvIHRoYXQgaXQgd291bGQgYmUgbW9yZSBjb25zaXN0 ZW50IHdpdGggdGhlIHRoZSBTQU1MIGFuZCBKV1QgdmVyc2lvbnMsIHdoaWNoIHdlcmUgYWxyZWFk eSB1c2luZyBhIE1BWSBpbiB0aGF0IGNvbnRleHQuDQo+Pj4+Pg0KPj4+Pj4gWW91ciBjb25jZXJu IGlzIHZhbGlkIEhhbm5lcyBhbmQgeW91ciBwb2ludCBpcyB0YWtlbi4gQnV0IHJlYWxpdHkgaXMg cmF0aGVyIG1lc3N5IGFuZCBJIGRvbid0IGJlbGlldmUgaXQgY2FuIGFkZHJlc3NlZCBhcyBlYXNp bHkgYXMgeW91IHN1Z2dlc3QuDQo+Pj4+Pg0KPj4+Pj4gSW4gU0FNTCwgZm9yIGV4YW1wbGUsIGFu IGVudGl0eSBpZGVudGlmaWVyIGlzIG9mdGVuIHVzZWQgYXMgYSB2YWx1ZSBmb3IgdGhlIGF1ZGll bmNlIChwZXIgc3BlYyBhbmQgaW4gcHJhY3RpY2UpLiAgQnV0IGFuIEFTIG1heSBub3QgbmVjZXNz YXJpbHkgaWRlbnRpZnkgaXRzZWxmIHdpdGggYSBmdWxsIGJsb3duIFNBTUwgZW50aXR5LCBpbiB3 aGljaCBjYXNlIHRoZSB0b2tlbiBlbmRwb2ludCBVUkkgaXMgbW9yZSBhcHByb3ByaWF0ZS4gVGhl IHdob2xlIGlzc3VlIGlzIGFsc28gc29tZXdoYXQgY29tcGxpY2F0ZWQgaW4gU0FNTCB0b28gYnkg aXQgaGF2aW5nIGJvdGggYXVkaWVuY2UgYW5kIHJlY2lwaWVudCB0aGF0IGFyZSBzaW1pbGFyIGJ1 dCBub3QgdGhlIHNhbWUuIEkndmUgdHJpZWQgdG8gYWNjb3VudCBmb3IgYWxsIG9mIHRoaXMgaW4g dGhlIFNBTUwgZG9jIGJ1dCBpdCdzIGFkbWl0dGVkbHkgc29tZXdoYXQgYXdrd2FyZCBhbmQgY29t cGxleCBhbmQgbm90IGFzIHNpbXBsZSBhcyBzYXlpbmcgdGhlIHZhbHVlIGhhcyB0byBiZSBYIGFu ZCBtdXN0IGJlIHZhbGlkYXRlZCBpbiBleGFjdGx5IHN1Y2ggYSB3YXkuDQo+Pj4+Pg0KPj4+Pj4g SldUIGRvZXNuJ3QgaGF2ZSB0aGUgc2FtZSBoaXN0b3J5IGFuZCBiYWdnYWdlIG9mIFNBTUwgYnV0 IGlzIHN1YmplY3QgdG8gbWFueSBvZiB0aGUgc2FtZSByZWFsIHdvcmxkIGRlcGxveW1lbnQgdmFy aWF0aW9ucy4NCj4+Pj4+DQo+Pj4+PiBJJ20gZGVmaW5pdGVseSBvcGVuIHRvIGltcHJvdmVtZW50 cyB3aXRoIHJlc3BlY3QgdG8gdGhlIGhhbmRsaW5nIG9mDQo+Pj4+PiBhdWRpZW5jZSB2YWx1ZXMg YnV0IEkgYmVsaWV2ZSBhbnl0aGluZyB0aGF0IGlzIGRvbmUgbmVlZHMgdG8NCj4+Pj4+IHJlZmxl Y3QgdGhlIHJlYWxpdGllcyBvZiBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBhbmQgZGVwbG95bWVu dHMgYXMNCj4+Pj4+IHdlbGwgYXMgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucy4sDQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiBPbiBGcmksIEphbiAxMSwgMjAxMyBhdCA4OjU1IEFNLCBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3Rl Og0KPj4+Pj4gWWVzIGluIGFzc2VydGlvbnMgaXQgbmVlZHMgdG8gYmUgZ2VuZXJhbC4gIEl0IGlz IHRoZSBKV1QgYW5kIFNBTUwgcHJvZmlsZXMgdGhhdCBuZWVkIHRvIG5haWwgZG93biB3aGF0IHRo ZSBmb3JtYXQgb2YgdGhlIGF1ZGllbmNlIGlzLiAgICBUaGV5IHNob3VsZCBwcm9iYWJseSBib3Ro IGJlIHRoZSBVUkkgb2YgdGhlIHRva2VuIGVuZHBvaW50LiAgIEluIGJvdGggU0FNTCBhbmQgSldU IHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBhdWRpZW5jZXMgZm9yIHRoZSB0b2tlbi4NCj4+Pj4+DQo+ Pj4+PiBKb2huDQo+Pj4+PiBPbiAyMDEzLTAxLTExLCBhdCAxMTozNyBBTSwgIlJpY2hlciwgSnVz dGluIFAuIiA8anJpY2hlckBtaXRyZS5vcmc8bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnPj4gd3Jv dGU6DQo+Pj4+Pg0KPj4+Pj4+IEl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBnZW5lcmFs IGFzc2VydGlvbnMgY2xhaW0gaXMgbW9yZSBvZiBhIGNvbmNlcHR1YWwgbWFwcGluZyB0aGFuIGl0 IGlzIGEgY29uY3JldGUgZW5jb2RpbmcsIHNvIGFueXRoaW5nIG1vcmUgc3BlY2lmaWMgaGVyZSB3 b3VsZCBiZSBvdXQgb2YgcGxhY2UuIEkgd291bGQgbGlrZSB0aGUgYXV0aG9ycyB0byBlaXRoZXIg Y29uZmlybSBvciBjb3JyZWN0IG15IGFzc3VtcHRpb25zLCB0aG91Z2guDQo+Pj4NCj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IC0tIEp1c3Rpbg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiBKYW4gMTEs IDIwMTMsIGF0IDY6MzAgQU0sIFN0ZXBoZW4gRmFycmVsbA0KPj4+Pj4+IDxzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NCj4+Pj4+PiB3 cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBIaSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gU2lu Y2Ugd2UgdGhvdWdodCB3ZSB3ZXJlIGRvbmUgd2l0aCBpdCwgSSBwdXQgdGhpcyBkb2N1bWVudCBv biB0aGUNCj4+Pj4+Pj4gSUVTRyB0ZWxlY2hhdCBhZ2VuZGEgZm9yIEphbiAyNC4gSGFubmVzJyBx dWVzdGlvbiBob3dldmVyIGxvb2tzDQo+Pj4+Pj4+IGxpa2UgaXRzIGEgcmVhbCBvbmUgdGhhdCBu ZWVkcyBhbiBhbnN3ZXIuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEknZCBhcHByZWNpYXRlIGl0IGlmIHRo ZSBXRyBjb3VsZCBmaWd1cmUgb3V0IGlmIHRoZXJlJ3MgYW55DQo+Pj4+Pj4+IGNoYW5nZSBuZWVk ZWQgYW5kIGVpdGhlciBtYWtlIHRoYXQgY2hhbmdlIGluIHRoZSBuZXh0IHdlZWssIG9yDQo+Pj4+ Pj4+IGVsc2UgdGVsbCBtZSB0byB0YWtlIHRoZSBkcmFmdCBvZmYgdGhlIHRlbGVjaGF0IGFnZW5k YSBmb3Igbm93Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJZiBkaXNjdXNzaW9uIGRvZXNuJ3QgaGFwcGVu LCBvciBoYXBwZW5zIGJ1dCBkb2Vzbid0IHJlYWNoIGENCj4+Pj4+Pj4gY29uY2x1c2lvbiwgdGhl biBJJ2xsIHRha2UgdGhlIGRyYWZ0IG9mZiB0aGUgYWdlbmRhIGluIGEgd2VlaydzDQo+Pj4+Pj4+ IHRpbWUgYW5kIHdlIGNhbiBzb3J0IG91dCBpZiBhbnkgY2hhbmdlcyBhcmUgbmVlZGVkIGxhdGVy Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgcmVhc29uIHdoeSBub3crMS13ZWVrIG1hdHRlcnMsIGlz IHRoYXQgdGhhdCdzIHdoZW4gSUVTRw0KPj4+Pj4+PiBtZW1iZXJzIHRlbmQgdG8gZG8gdGhlaXIg cmV2aWV3cyBhbmQgaGF2aW5nICdlbSBhbGwgcmV2aWV3IGENCj4+Pj4+Pj4gbW92aW5nIHRhcmdl dCBpc24ndCBhIGdvb2QgcGxhbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBT Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAwMS8xMS8yMDEzIDA4OjE4IEFNLCBIYW5uZXMgVHNjaG9m ZW5pZyB3cm90ZToNCj4+Pj4+Pj4+IEhpIGd1eXMsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmtz IGZvciB1cGRhdGluZyB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50IGFuZCBmb3IgaW5jb3Jwb3JhdGlu ZyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgb24gdGhlIG1haWxpbmcgbGlzdC4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBUaGVyZSBpcyBvbmx5IG9uZSBpc3N1ZSB0aGF0IGNhdWdodCBteSBhdHRlbnRpb24u IFlvdSBjaGFuZ2VkIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgYXVkaWVuY2UgZWxlbWVudCB0byB0 aGUgZm9sbG93aW5nIHRleHQgKGluIHZlcnNpb24gLTA5IG9mIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOSk6DQo+Pj4+Pj4+PiAiDQo+Pj4+ Pj4+PiBBdWRpZW5jZSAgQSB2YWx1ZSB0aGF0IGlkZW50aWZpZXMgdGhlIHBhcnRpZXMgaW50ZW5k ZWQgdG8NCj4+Pj4+Pj4+IHByb2Nlc3MgdGhlICBhc3NlcnRpb24uICBBbiBhdWRpZW5jZSB2YWx1 ZSBNQVkgYmUgdGhlIFVSTCBvZiB0aGUNCj4+Pj4+Pj4+IFRva2VuIEVuZHBvaW50ICBhcyBkZWZp bmVkIGluIFNlY3Rpb24gMy4yIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uDQo+Pj4+Pj4+PiAiDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gU2luY2UgdGhlIHZhbHVlIGluIHRoZSBhdWRpZW5jZSBmaWVsZCBp cyB1c2VkIHRvIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbiBhIGNvbXBhcmlzb24gb3Bl cmF0aW9uIChzZWUgU2VjdGlvbiA1LjIpIEkgYmVsaWV2ZSB0aGUgY3VycmVudCB0ZXh0IHdpbGwg bGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiBOb3Qgb25seSBpcyB0aGUgY29tcGFy aXNpb24gb3BlcmF0aW9uIHVuc3BlY2lmaWVkIGJ1dCBldmVuIHRoZSB2YWx1ZSB0aGF0IGlzIGNv bnRhaW5lZCBpbiB0aGUgZmllbGQgaXMgbGVmdCBvcGVuLiBUaGUgUkZDIDIxMTkgTUFZIGRvZXMg bm90IHJlYWxseSBnaXZlIGEgbG90IG9mIGhpbnRzIG9mIHdoYXQgc2hvdWxkIGJlIHB1dCBpbiB0 aGVyZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBXaXRob3V0IGhhdmluZyBhIGNsZWFyIGRlc2NyaXB0 aW9uIG9mIHdoYXQgaWRlbnRpZmllciBpcyBjb250YWluZWQgaW4gdGhpcyBmaWVsZCBhbmQgaG93 IHRoZSBjb21wYXJpc29uIHdvcmtzIGl0IGlzIGVpdGhlciBwb3NzaWJsZSB0aGF0IGEgbGVnaXRp bWF0ZSBjbGllbnQgaXMgcmVqZWN0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyICh3aGlj aCBpcyBhbm5veWluZykgb3IgYW4gYXNzZXJ0aW9uIHdpdGggYW4gaW5jb3JyZWN0IGFzc2VydGlv biBpcyBhY2NlcHRlZCAod2hpY2ggaXMgYSBzZWN1cml0eSBwcm9ibGVtKS4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBCdHcsIHRoZSBzYW1lIGlzc3VlIGNhbiBhbHNvIGJlIHNlZW4gaW4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA0LCBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xNSBhbmQg aW4gYSBtb3JlIGdlbmVyaWMgZm9ybSBhbHNvIGluIHRoZSBKV1QgKFNlY3Rpb24gNC4xLjMgb2Yg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tl bi0wNjsgImF1ZCIgY2xhaW0pLiBGcm9tIHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgSldUIGRvY3Vt ZW50IEkgd2FzIG5vdCBxdWl0ZSBzdXJlIHdoZXRoZXIgdGhlIGFiaWxpdHkgdG8gY2FycnkgYW4g YXJyYXkgb2YgY2FzZSBzZW5zaXRpdmUgc3RyaW5ncyBmb3IgdGhhdCBmaWVsZCBpcyBhbHNvIGFs bG93ZWQgaW4gYW55IG9mIHRoZSBhc3NlcnRpb24gZG9jdW1lbnRzLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IE5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIGRvY3VtZW50cyB0aGF0IHByb3ZpZGUgaW5wdXQg dG8gdGhpcyBwcm9ibGVtIHNwYWNlLCBuYW1lbHk6DQo+Pj4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2MTI1DQo+Pj4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pYWItaWRlbnRpZmllci1jb21wYXJpc29uLTA3DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gU28s IEkgd291bGQgc3VnZ2VzdCB0byBkZWNpZGUgd2hhdCB0eXBlIG9mIGlkZW50aWZpZXIgZ29lcyBp bnRvIHRoaXMgZmllbGQgYW5kIHRoZW4gdG8gcG9pbnQgdG8gYSBkb2N1bWVudCB0aGF0IGlsbHVz dHJhdGVzIGhvdyB0aGUgY29tcGFyaXNvbiBvcGVyYXRpb24gd291bGQgbG9vayBsaWtlLiBQb3Nz aWJsZSBpZGVudGlmaWVycyBhcmUgZG9tYWluIG5hbWVzLCBJUCBhZGRyZXNzZXMsIFVSSXMsIGV0 Yy4gSnVzdCBhcyBhbiBleGFtcGxlIGZyb20gUkZDIDYxMjUgd291bGQgeW91IGFsbG93IGEgd2ls ZGNhcmQgbWF0Y2ggKGxpa2UgIiouZXhhbXBsZS5jb20iKSBvciBvbmx5IGFuIGVxdWFsaXR5IG1h dGNoPyBXb3VsZCAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+IiBiZSB0 aGUgc2FtZSBhcyAiZXhhbXBsZS5jb20iIGlmIHRoZXkgcmVzb2x2ZSB0byB0aGUgc2FtZSBJUCBh ZGRyZXNzKGVzKT8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDaWFvDQo+Pj4+Pj4+PiBIYW5uZXMNCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+ Pj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4+Pg0KPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gT0F1 dGggbWFpbGluZyBsaXN0DQo+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+ Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0K Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQo= --_000_4E1F6AAD24975D4BA5B168042967394366A4AF8DTK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHByb3Bvc2UgdGhh dCB0aGUgZm9sbG93aW5nIG5ldyBzZWN0aW9uIGhlYWRpbmcgYW5kIHBhcmFncmFwaCBiZSBhZGRl ZCB0byB0aGUgQXNzZXJ0aW9ucyBzcGVjaWZpY2F0aW9uLCByaWdodCBiZWZvcmUgdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zLiZuYnNwOyBGZWVkYmFjaw0KIG9uIHRoZSB3b3JkaW5nIGlzIHdl bGNvbWUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj43LiZuYnNwOyBJbnRlcm9wZXJhYmlsaXR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlz IHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgdXNpbmcgYXNzZXJ0aW9ucyB3 aXRoIE9BdXRoIDIuMC4mbmJzcDsgSG93ZXZlciwgYXMgYW4gZXh0ZW5zaWJsZSBmcmFtZXdvcmsg aW4gd2hpY2ggdGhlIGRhdGEgZm9ybWF0cyB1c2VkIGZvciByZXByZXNlbnRpbmcNCiBtYW55ICZu YnNwO3ZhbHVlcyBhcmUgbm90IGRlZmluZWQsIG9uIGl0cyBvd24sIHRoaXMgc3BlY2lmaWNhdGlv biBpcyBub3Qgc3VmZmljaWVudCB0byBwcm9kdWNlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RXZlbiB3aGVuIHByb2ZpbGVkIGZvciBzcGVjaWZpYyBhc3NlcnRpb24g dHlwZXMsIGFzIGlzIGRvbmUgZm9yIFNBTUwgMi4wIGluIFtJLUQuaWV0Zi1vYXV0aC1zYW1sMi1i ZWFyZXJdIGFuZCBKU09OIFdlYiBUb2tlbiAoSldUKSBpbiBbSS1ELmlldGYtb2F1dGgtand0LWJl YXJlcl0sDQogYWRkaXRpb25hbCBwcm9maWxpbmcgZm9yIHNwZWNpZmljIHVzZSBjYXNlcyB3aWxs IGJlIHJlcXVpcmVkIHRvIGFjaGlldmUgZnVsbCBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBGb3Ig aW5zdGFuY2UsIGluIGRpZmZlcmVudCB1c2UgY2FzZXMsIHRoZSB2YWx1ZXMgdXNlZCBmb3IgSXNz dWVyLCBQcmluY2lwYWwsIGFuZCBBdWRpZW5jZSBpZGVudGlmaWVycyB3aWxsIGRpZmZlci4mbmJz cDsgVGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9u DQogdGhhdCBmdXR1cmUgd29yayB3aWxsIGRlZmluZSBwcmVzY3JpcHRpdmUgcHJvZmlsZXMgYW5k IGV4dGVuc2lvbnMgbmVjZXNzYXJ5IHRvIGFjaGlldmUgZnVsbCB3ZWItc2NhbGUgaW50ZXJvcGVy YWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBC ZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUb3JzdGVu IExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE2LCAyMDEzIDk6MTIgQU08YnI+DQo8Yj5Ubzo8 L2I+IHBoaWwuaHVudEBvcmFjbGUuY29tOyBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBvYXV0 aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBBVzogUmU6IFtPQVVUSC1XR10gZHJhZnQt aWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzsxPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0gVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0IC0tLS0tLS0tPGJyPg0KVm9uOiBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0 OyA8YnI+DQpEYXR1bTogPGJyPg0KQW46IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7DQo8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBp ZXRmLm9yZzwvYT4gPGJyPg0KQmV0cmVmZjogUmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0 aC1hc3NlcnRpb25zLTA5IDxicj4NCjxicj4NCjxicj4NCiYjNDM7MS4gVGhpcyBtYWtlcyBnb29k IHNlbnNlLiA8YnI+DQo8YnI+DQpQaGlsPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IHBob25lLjxi cj4NCjxicj4NCk9uIDIwMTMtMDEtMTUsIGF0IDE4OjI2LCBNaWtlIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEhhbm5lcyBhbmQgSSBzcG9r ZSBhbmQgd2VudCB0aHJvdWdoIHRoZSBpc3N1ZXMuJm5ic3A7IEhlIHdhcyB0cnlpbmcgdG8gbWF4 aW1pemUgaW50ZXJvcGVyYWJpbGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggaXMgb2J2aW91 c2x5IGEgZ29vZCBnb2FsLiZuYnNwOyBIb3dldmVyLCBhZnRlciBkaXNjdXNzaW5nIHRoZSBwYXJ0 aWN1bGFycywgd2UgYWxzbyBhZ3JlZWQgdGhhdCwgZm9yIHNvbWUgZmVhdHVyZXMgYW5kIHVzZSBj YXNlcywgc3BlY2lmaWMgcHJvZmlsZXMNCiBvZiB0aGUgYXNzZXJ0aW9ucyB3aWxsIGJlIG5lZWRl ZCB0byBhY2hpZXZlIGNvbXBsZXRlIGludGVyb3BlcmFiaWxpdHkgKGp1c3QgbGlrZSBwcm9maWxl cyBvZiBPQXV0aCBhcmUgcmVxdWlyZWQgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5KS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhlcmVmb3JlLCB3ZSBwcm9wb3NlIHRvIGFkZCBhbiBleHBsYW5h dG9yeSBwYXJhZ3JhcGggdG8gdGhlIGFzc2VydGlvbnMgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGF0 IHByb2ZpbGluZyB3aWxsIGJlIHJlcXVpcmVkIHRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSBp biBzb21lIGNhc2VzLiZuYnNwOyBUaGlzIHdvdWxkIGJlIGluIGV4YWN0bHkgdGhlIHNhbWUgc3Bp cml0IGFzDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rp b24tMS44Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMS44PC9h Piwgd2hpY2ggc3VwcGxpZXMgdGhlIHNhbWUga2luZHMgb2YgY2F2ZWF0cyB0byBpbXBsZW1lbnRl cidzIG9mIE9BdXRoIENvcmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEknbGwgd29yayBvbiBwcm9w b3NlZCBzcGVjaWZpYyB3b3JkaW5nIHNob3J0bHkuJm5ic3A7IEknbGwgbm90ZSB0aGF0IGFkZGlu ZyB0aGlzIHRleHQgd2lsbCBub3QgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRoZSBkb2N1bWVudCBp biBhbnkgd2F5IC0gaXQgd2lsbCBzaW1wbHkgcHJvdmlkZSBhZGRpdGlvbmFsIGd1aWRhbmNlIHRv IGltcGxlbWVudGVycyBvbiBob3cgdG8gdGhpbmsgYWJvdXQgdXNpbmcgdGhlIGFzc2VydGlvbiBm cmFtZXdvcmsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEJlc3Qgd2lzaGVzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgWzxhIGhyZWY9Im1haWx0bzpo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5tYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dDwvYT5dDQo8YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTUsIDIwMTMgMTA6MzQg QU08YnI+DQomZ3Q7IFRvOiBNaWtlIEpvbmVzPGJyPg0KJmd0OyBDYzogSGFubmVzIFRzY2hvZmVu aWc7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdH PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2Vy dGlvbnMtMDk8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgTWlrZSwgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEkgYW0gc3VyZSB0aGUgcmVzdCBvZiB0aGUgd29ya2luZyBncm91cCBpcyBpbnRlcmVzdGVk IHRvIHNlZSBob3cgZGlmZmljdWx0IGl0IGlzIHRvIGFycmFuZ2UgYSBjb25mZXJlbmNlIGNhbGwg d2hlbiBvbmUgcGVyc29uIGlzIGluIEVzcG9vL0ZpbmxhbmQgYW5kIHRoZSBvdGhlciBwZXJzb24g aW4gdGhlIFdlc3QgQ29hc3QuPGJyPg0KJmd0OyBJbiBhbnkgY2FzZSwgSSBhbSBvbmxpbmUgYW5k IHJlYWR5IHRvIGNoYXQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiBhbnkgY2FzZSBJIHdpbGwg bGV0IHRoZSBncm91cCBrbm93IHdoYXQgY29uY2x1c2lvbnMgd2UgcmVhY2hlZC4gPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lczxicj4NCiZndDsgPGJyPg0KJmd0OyBQ UzogRm9yIHNvbWUgcmVhc29uIHlvdXIgU01TIGFycml2ZWQgb25lIGRheSBsYXRlci4uLjxicj4N CiZndDsgPGJyPg0KJmd0OyBPbiBKYW4gMTUsIDIwMTMsIGF0IDc6MjAgUE0sIE1pa2UgSm9uZXMg d3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSBIYW5uZXMsPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgQ2FuIHlvdSBwbGVhc2UgZWl0aGVyIGdpdmUgbWUgYSBjYWxsIGZvciB1 cyB0byB0YWxrIGFib3V0IHRoZSBjaGFuZ2VzIHlvdSBoYXZlIGluIG1pbmQgb3Igd3JpdGUgZG93 biB0aGUgc3BlY2lmaWMgY2hhbmdlcyB5b3Ugd2FudD8mbmJzcDsgSSdkIGxpa2UgdXMgdG8gcmVh Y2ggYSBtdXR1YWwgdW5kZXJzdGFuZGluZyBvZiB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gYWNoaWV2 ZSBpbiB0aW1lIGZvciBTdGVwaGVuIHRvIHByb2NlZWQgd2l0aCB0aGUgdGVsZWNoYXQNCiBvbiBz Y2hlZHVsZS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYNCjxicj4NCiZndDsmZ3Q7IE9mIE1pa2UgSm9uZXM8YnI+ DQomZ3Q7Jmd0OyBTZW50OiBTdW5kYXksIEphbnVhcnkgMTMsIDIwMTMgMTE6MDMgUE08YnI+DQom Z3Q7Jmd0OyBUbzogSGFubmVzIFRzY2hvZmVuaWc8YnI+DQomZ3Q7Jmd0OyBDYzogPGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8YnI+DQomZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDk8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJJ20gdGhpbmtpbmcgaXQgd291bGQgYmUgdXNl ZnVsIGZvciB1cyB0byB0YWxrIG9uIHRoZSBwaG9uZSBvciBTa3lwZSB0b21vcnJvdywgSGFubmVz LCBiZWNhdXNlIEknbSBwcmV0dHkgc3VyZSBJIGRvbid0IGtub3cgd2hhdCBzcGVjaWZpYyBjaGFu Z2VzIHlvdSdyZSBhc2tpbmcgZm9yIGluIHdoaWNoIHNwZWNzLiZuYnNwOyBBcmUgeW91LCBmb3Ig aW5zdGFuY2UsIGFza2luZyBmb3IgbGFuZ3VhZ2Ugc2F5aW5nIHRoYXQgYXVkaWVuY2UgdmFsdWVz IGFyZQ0KIHRvIGJlIGNvbXBhcmVkIGZvciBlcXVhbGl0eSBhcyBjYXNlLXNlbnNpdGl2ZSBzdHJp bmdzIGluIHRoZSBTQU1MIGJlYXJlciBhbmQgSldUIGJlYXJlciBzcGVjcz8mbmJzcDsgKFRoZXkn cmUgbm90IGp1c3QgVVJJcywgYXMgdGhleSBjYW4gYmUgT0F1dGggQ2xpZW50IElEcy4pJm5ic3A7 IE9yIG1heWJlIHlvdSBjYW4gcHJvcG9zZSBzcGVjaWZpYyBsYW5ndWFnZSBjaGFuZ2VzLCBzbyBp dCdzIGNsZWFyIHdoYXQgeW91J3JlIGFza2luZyBmb3IuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7 IEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldCI+bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+XTxicj4NCiZn dDsmZ3Q7IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAyOjQ5IEFNPGJyPg0KJmd0OyZn dDsgVG86IE1pa2UgSm9uZXM8YnI+DQomZ3Q7Jmd0OyBDYzogSGFubmVzIFRzY2hvZmVuaWc7IEJy aWFuIENhbXBiZWxsOyBTdGVwaGVuIEZhcnJlbGw7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyI+DQpvYXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyZndDsgV0c8YnI+DQomZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDk8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSBNaWtlLDxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IGl0IGlzIGZpbmUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgaWRlbnRpZmllcnMgYW5k IHRvIGV2ZW4gYWxsb3cgdGhlIHNldCBvZiBzdXBwb3J0ZWQgaWRlbnRpZmllcnMgdG8gZ2V0IGV4 dGVuZGVkIG92ZXIgdGltZS4NCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEp1c3Qgb21p dHRpbmcgYSBkZXNjcmlwdGlvbiBpcywgaG93ZXZlciwgbm90IGFuIG9wdGlvbi4gV2UgYXJlIGlu IHRoZSBsdWNreSBwb3NpdGlvbiB3aGVyZSBvdGhlcnMgaGF2ZSBkb25lIHRoZSB3b3JrIGZvciB1 cyBhbHJlYWR5IChhcyBtZW50aW9uZWQgaW4gdGhlIHR3byBjaXRlZCByZWZlcmVuY2VzKS4gRm9y IHRoZSBJQUIgZG9jdW1lbnQgdGhlcmUgaXMgZXZlbiB0aGUgY2hhbmNlIHRvIHByb3ZpZGUgZmVl ZGJhY2sgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFiLm9yZy8yMDEzLzAxLzA5L2NhbGwt Zm9yLWNvbW1lbnQtaXNzdWVzLWluLWlkZW50aWZpZXItY29tcGFyaXNvbi1mb3Itc2VjdXJpdHkt cHVycG9zZXMvIj4NCmh0dHBzOi8vd3d3LmlhYi5vcmcvMjAxMy8wMS8wOS9jYWxsLWZvci1jb21t ZW50LWlzc3Vlcy1pbi1pZGVudGlmaWVyLWNvbXBhcmlzb24tZm9yLXNlY3VyaXR5LXB1cnBvc2Vz LzwvYT4pIGluIGNhc2UgeW91IGJlbGlldmUgdGhlIGF1dGhvciBpcyBtaXNndWlkZWQuIFdlIGp1 c3QgbmVlZCB0byBtYWtlIHVzZSBvZiB0aGVtLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IENpYW88YnI+DQomZ3Q7Jmd0OyBIYW5uZXM8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBP biBKYW4gMTMsIDIwMTMsIGF0IDEyOjA5IFBNLCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBXZSBhbHJlYWR5IGtub3cgb2YgdXNlIGNhc2VzIHdoZXJl IHRoZSBhdWRpZW5jZSBpcyBhbiBhYnN0cmFjdCBpZGVudGlmaWVyIGFuZCB1c2UgY2FzZXMgd2hl cmUgdGhlIGF1ZGllbmNlIGlzIHRoZSBVUkwgb2YgdGhlIHRva2VuIGVuZHBvaW50LiZuYnNwOyBC b3RoIGFyZSBsZWdpdGltYXRlLiZuYnNwOyBXZSBzaG91bGQgZm9yZWNsb3NlIG5laXRoZXIuPGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBMaWtlIG1hbnkgdGhpbmdzIE9BdXRo LCBpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBhY2hpZXZlZCwgYnV0IGl0IG1heSByZXF1aXJlIGEg cHJvZmlsZSBmdXJ0aGVyIHNwZWNpZnlpbmcgdGhlIGJlaGF2aW9ycyBhcHByb3ByaWF0ZSB0byB0 aGF0IHVzZSBjYXNlLiZuYnNwOyBUaGlzIGlzIG5vdCBhIGJ1ZyAtIGl0IGlzIGEgZmVhdHVyZSwg YXMgaXQgaW5jcmVhc2VzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBPQXV0aCBzcGVjaWZpY2F0 aW9ucy48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBBc3NlcnRpb24s IEpXVCBQcm9maWxlLCBhbmQgU0FNTCBQcm9maWxlIGFyZSBzdHJpa2luZyBhbiBhcHByb3ByaWF0 ZSBiYWxhbmNlIGJ5IHByb3ZpZGluZyBndWlkYW5jZSBvbiBsaWtlbHkgYXVkaWVuY2UgdmFsdWVz IGZvciBtYW55IHVzZSBjYXNlcywgYnV0IG5vdCBwcmVjbHVkaW5nIG90aGVyIHZhbHVlcyB3aGVy ZSBuZWNlc3NhcnkgZm9yIHRob3NlIHVzZSBjYXNlcy48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVz LDxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbPGEg aHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPm1haWx0bzpoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0PC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsgU2VudDogU3VuZGF5LCBKYW51 YXJ5IDEzLCAyMDEzIDE6NTYgQU08YnI+DQomZ3Q7Jmd0OyZndDsgVG86IE1pa2UgSm9uZXM8YnI+ DQomZ3Q7Jmd0OyZndDsgQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBCcmlhbiBDYW1wYmVsbDsgU3Rl cGhlbiBGYXJyZWxsOyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDog UmU6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5PGJyPg0KJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBNaWtlLDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsgSSB1bmRlcnN0YW5kIHlvdXIgcmVhc29uaW5nOiB5b3Ugd2FudCB0byBr ZWVwIGFsbCBvcHRpb25zIG9wZW4gaW4gdGhlIGZyYW1ld29yayBzcGVjaWZpY2F0aW9uIGFuZCB5 b3Ugd2FudCB0byBiZSBtb3JlIHNwZWNpZmljIGluIGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJl ciBhbmQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXIuDQo8YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBSRkMgMjExOSBsYW5ndWFnZSBkb2VzIG5vdCBhZGQg YW55dGhpbmcgYnV0IGl0IGRvZXMgbm90IGh1cnQgZWl0aGVyLiBJdCBqdXN0IHNheXMgdGhhdCB0 aGVyZSBjb3VsZCBlc3NlbnRpYWxseSBiZSBhbnl0aGluZyBpbiB0aGVyZSwgaW5jbHVkaW5nIHRo ZSBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgWW91IGNhbiBvZiBjb3Vyc2UgcG9zdC1wb25lIGRlYWxpbmcgd2l0aCB0aGUgaXNz dWUgdG8gdGhlIG1vcmUgc3BlY2lmaWMgZG9jdW1lbnRzLiBGb3IgZXhhbXBsZSwgZHJhZnQtaWV0 Zi1vYXV0aC1qd3QtYmVhcmVyIGF0IHRoZSBtb21lbnQgZG9lcyBub3QgYWxsb3cgYW4gaW50ZXJv cGVyYWJsZSBkZXBsb3ltZW50IHNpbmNlIGl0IGp1c3QgcmVwZWF0cyB0aGUgYWJzdHJhY3QgZnJh bWV3b3JrIHRleHQgYnkgc2F5aW5nICZxdW90O1RoZSB0b2tlbiBlbmRwb2ludA0KIFVSTCBvZiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGJlIHVzZWQgYXMgYW4gYWNjZXB0YWJsZSB2YWx1 ZSBmb3IgYW4gJnF1b3Q7YXVkJnF1b3Q7IGVsZW1lbnQuJnF1b3Q7DQo8YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyZndDsgSGFubmVzPGJyPg0K Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBKYW4gMTIsIDIwMTMsIGF0IDEwOjQy IFBNLCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IEhpIEhhbm5lcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgRm9yIHRoZSByZWFzb25zIHRoYXQgSnVzdGluIGFuZCBCcmlhbiBzdGF0ZSwgSSBiZWxp ZXZlIHRoYXQgdGhlIE1BWSBpcyBhcHByb3ByaWF0ZS4mbmJzcDsgSW4gc29tZSB1c2UgY2FzZXMs IGEgZ29vZCByZXByZXNlbnRhdGlvbiBvZiBhbiBhcHByb3ByaWF0ZSBhdWRpZW5jZSB2YWx1ZSBp cyBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50LiZuYnNwOyBUaGF0J3MgdGhlcmUgaW4gdGhlIEFz c2VydGlvbnMgc3BlY2lmaWNhdGlvbiBhcyBndWlkYW5jZSB0byB3cml0ZXJzDQogdG9rZW4tdHlw ZSBzcGVjaWZpYyBzcGVjcyB1c2luZyB0aGUgQXNzZXJ0aW9ucyBzcGVjLCBhcyBJIGJlbGlldmUg aXQgc2hvdWxkIGJlLiZuYnNwOyBUaGF0IGJlaW5nIHRoZSBjYXNlLCBhcyBCcmlhbiBkZXNjcmli ZXMsIHNvbWV0aW1lcyBhdWRpZW5jZSB2YWx1ZXMgYXJlIG1vcmUgYWJzdHJhY3QgaWRlbnRpZmll cnMgb3IgaWRlbnRpZmllcnMgZm9yIGdyb3VwcyBvZiBzZXJ2aWNlcywgYW5kIHdlIGRvbid0IHdh bnQgdG8gaW5hZHZlcnRlbnRseSBwcmVjbHVkZQ0KIHRob3NlIGFjdHVhbCB1c2UgY2FzZXMuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRodXMsIEkgYmVsaWV2 ZSB0aGF0IHRoZSBsYW5ndWFnZSBpcyBhcHByb3ByaWF0ZSBhcy1pcy4mbmJzcDsgVGh1cywgSSBi ZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIHByb2NlZWQgd2l0aCB0aGUgY3VycmVudGx5IHNjaGVkdWxl ZCB0ZWxlY2hhdCBkaXNjdXNzaW9uIG9mIHRoZSBzcGVjLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWxsLDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbg0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWc8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEyLCAyMDEzIDEx OjUwIEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUbzogQnJpYW4gQ2FtcGJlbGw8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll dGYub3JnPC9hPiBXRzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1X R10gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEJyaWFuLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGNoYWxsZW5naW5n Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBOZXZlcnRoZWxl c3MgaXQgd291bGQgbWFrZSBzZW5zZSB0byBkZXNjcmliZSB0aGUgZGVzaXJlZCBiZWhhdmlvciBp biBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIgYW5kIGluIGRyYWZ0LWlldGYtb2F1dGgtc2Ft bDItYmVhcmVyIGluIHN1Y2ggYSB3YXkgdGhhdCB0d28gdmVyc2lvbnMgZGV2ZWxvcGVkIGJ5IGRp ZmZlcmVudCBncm91cHMgd291bGQgaW50ZXJvcGVyYXRlIHdpdGhvdXQgY2F1c2luZyBzZWN1cml0 eSBwcm9ibGVtcyBvcg0KIGZhaWx1cmVzLiA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgVG8gbW92ZSBmb3J3YXJkIHdpdGggZHJhZnQtaWV0Zi1vYXV0aC1hc3Nl cnRpb25zIEkgc3VnZ2VzdCB0byBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIGluDQo8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cx MDUwNy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxMDUwNy5odG1sPC9hPiBhbmQgdG8gYWRkcmVzcyB0aGUgZGV0YWlscyBpbiZuYnNw OyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIgYW5kIGluIGRyYWZ0LWlldGYtb2F1dGgtc2Ft bDItYmVhcmVyIGFzIHNvb24gYXMgcG9zc2libGUNCiB0byBnZXQgdGhlc2UgZG9jdW1lbnRzIG1v dmluZyBmb3J3YXJkIGFuZCBjb21wbGV0ZWQgc29vbi4gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhhbm5lczxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBKYW4gMTEsIDIw MTMsIGF0IDc6NTEgUE0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhdCB0ZXh0IGFyb3VuZCBhdWRpZW5jZSBp biB0aGUgZnJhbWV3b3JrIHNwZWMgY2hhbmdlZCBmcm9tIGEgU0hPVUxEIHRvIGEgTUFZIGluIC0w OSBzbyB0aGF0IGl0IHdvdWxkIGJlIG1vcmUgY29uc2lzdGVudCB3aXRoIHRoZSB0aGUgU0FNTCBh bmQgSldUIHZlcnNpb25zLCB3aGljaCB3ZXJlIGFscmVhZHkgdXNpbmcgYSBNQVkgaW4gdGhhdCBj b250ZXh0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFlvdXIgY29uY2VybiBpcyB2YWxpZCBIYW5uZXMgYW5kIHlvdXIgcG9pbnQgaXMgdGFrZW4u IEJ1dCByZWFsaXR5IGlzIHJhdGhlciBtZXNzeSBhbmQgSSBkb24ndCBiZWxpZXZlIGl0IGNhbiBh ZGRyZXNzZWQgYXMgZWFzaWx5IGFzIHlvdSBzdWdnZXN0LiZuYnNwOw0KPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gU0FNTCwgZm9yIGV4YW1w bGUsIGFuIGVudGl0eSBpZGVudGlmaWVyIGlzIG9mdGVuIHVzZWQgYXMgYSB2YWx1ZSBmb3IgdGhl IGF1ZGllbmNlIChwZXIgc3BlYyBhbmQgaW4gcHJhY3RpY2UpLiZuYnNwOyBCdXQgYW4gQVMgbWF5 IG5vdCBuZWNlc3NhcmlseSBpZGVudGlmeSBpdHNlbGYgd2l0aCBhIGZ1bGwgYmxvd24gU0FNTCBl bnRpdHksIGluIHdoaWNoIGNhc2UgdGhlIHRva2VuIGVuZHBvaW50IFVSSSBpcyBtb3JlIGFwcHJv cHJpYXRlLiBUaGUNCiB3aG9sZSBpc3N1ZSBpcyBhbHNvIHNvbWV3aGF0IGNvbXBsaWNhdGVkIGlu IFNBTUwgdG9vIGJ5IGl0IGhhdmluZyBib3RoIGF1ZGllbmNlIGFuZCByZWNpcGllbnQgdGhhdCBh cmUgc2ltaWxhciBidXQgbm90IHRoZSBzYW1lLiBJJ3ZlIHRyaWVkIHRvIGFjY291bnQgZm9yIGFs bCBvZiB0aGlzIGluIHRoZSBTQU1MIGRvYyBidXQgaXQncyBhZG1pdHRlZGx5IHNvbWV3aGF0IGF3 a3dhcmQgYW5kIGNvbXBsZXggYW5kIG5vdCBhcyBzaW1wbGUgYXMgc2F5aW5nDQogdGhlIHZhbHVl IGhhcyB0byBiZSBYIGFuZCBtdXN0IGJlIHZhbGlkYXRlZCBpbiBleGFjdGx5IHN1Y2ggYSB3YXku PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSldU IGRvZXNuJ3QgaGF2ZSB0aGUgc2FtZSBoaXN0b3J5IGFuZCBiYWdnYWdlIG9mIFNBTUwgYnV0IGlz IHN1YmplY3QgdG8gbWFueSBvZiB0aGUgc2FtZSByZWFsIHdvcmxkIGRlcGxveW1lbnQgdmFyaWF0 aW9ucy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJJ20gZGVmaW5pdGVseSBvcGVuIHRvIGltcHJvdmVtZW50cyB3aXRoIHJlc3BlY3QgdG8gdGhl IGhhbmRsaW5nIG9mIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF1ZGllbmNlIHZhbHVlcyBi dXQgSSBiZWxpZXZlIGFueXRoaW5nIHRoYXQgaXMgZG9uZSBuZWVkcyB0byA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZWZsZWN0IHRoZSByZWFsaXRpZXMgb2YgY3VycmVudCBpbXBsZW1lbnRh dGlvbnMgYW5kIGRlcGxveW1lbnRzIGFzIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlbGwg YXMgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucy4sPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gRnJpLCBKYW4gMTEsIDIwMTMgYXQgODo1NSBBTSwgSm9o biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2 ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWWVzIGlu IGFzc2VydGlvbnMgaXQgbmVlZHMgdG8gYmUgZ2VuZXJhbC4mbmJzcDsgSXQgaXMgdGhlIEpXVCBh bmQgU0FNTCBwcm9maWxlcyB0aGF0IG5lZWQgdG8gbmFpbCBkb3duIHdoYXQgdGhlIGZvcm1hdCBv ZiB0aGUgYXVkaWVuY2UgaXMuJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXkgc2hvdWxkIHByb2JhYmx5 IGJvdGggYmUgdGhlIFVSSSBvZiB0aGUgdG9rZW4gZW5kcG9pbnQuJm5ic3A7Jm5ic3A7IEluIGJv dGggU0FNTCBhbmQgSldUIHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBhdWRpZW5jZXMNCiBmb3IgdGhl IHRva2VuLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEpvaG48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAyMDEzLTAxLTExLCBhdCAxMToz NyBBTSwgJnF1b3Q7UmljaGVyLCBKdXN0aW4gUC4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdHJlLm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQncyBt eSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGdlbmVyYWwgYXNzZXJ0aW9ucyBjbGFpbSBpcyBtb3Jl IG9mIGEgY29uY2VwdHVhbCBtYXBwaW5nIHRoYW4gaXQgaXMgYSBjb25jcmV0ZSBlbmNvZGluZywg c28gYW55dGhpbmcgbW9yZSBzcGVjaWZpYyBoZXJlIHdvdWxkIGJlIG91dCBvZiBwbGFjZS4gSSB3 b3VsZCBsaWtlIHRoZSBhdXRob3JzIHRvIGVpdGhlciBjb25maXJtIG9yIGNvcnJlY3QgbXkgYXNz dW1wdGlvbnMsIHRob3VnaC48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IC0tIEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEph biAxMSwgMjAxMywgYXQgNjozMCBBTSwgU3RlcGhlbiBGYXJyZWxsIDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEhpLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaW5jZSB3ZSB0aG91Z2h0IHdlIHdlcmUgZG9uZSB3aXRoIGl0 LCBJIHB1dCB0aGlzIGRvY3VtZW50IG9uIHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IElFU0cgdGVsZWNoYXQgYWdlbmRhIGZvciBKYW4gMjQuIEhhbm5lcycgcXVlc3Rpb24g aG93ZXZlciBsb29rcyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpa2UgaXRz IGEgcmVhbCBvbmUgdGhhdCBuZWVkcyBhbiBhbnN3ZXIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknZCBhcHByZWNp YXRlIGl0IGlmIHRoZSBXRyBjb3VsZCBmaWd1cmUgb3V0IGlmIHRoZXJlJ3MgYW55IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhbmdlIG5lZWRlZCBhbmQgZWl0aGVyIG1ha2Ug dGhhdCBjaGFuZ2UgaW4gdGhlIG5leHQgd2Vlaywgb3IgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBlbHNlIHRlbGwgbWUgdG8gdGFrZSB0aGUgZHJhZnQgb2ZmIHRoZSB0ZWxlY2hh dCBhZ2VuZGEgZm9yIG5vdy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgZGlzY3Vzc2lvbiBkb2Vzbid0IGhhcHBl biwgb3IgaGFwcGVucyBidXQgZG9lc24ndCByZWFjaCBhIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgY29uY2x1c2lvbiwgdGhlbiBJJ2xsIHRha2UgdGhlIGRyYWZ0IG9mZiB0aGUg YWdlbmRhIGluIGEgd2VlaydzIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGlt ZSBhbmQgd2UgY2FuIHNvcnQgb3V0IGlmIGFueSBjaGFuZ2VzIGFyZSBuZWVkZWQgbGF0ZXIuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRoZSByZWFzb24gd2h5IG5vdyYjNDM7MS13ZWVrIG1hdHRlcnMsIGlzIHRoYXQg dGhhdCdzIHdoZW4gSUVTRyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lbWJl cnMgdGVuZCB0byBkbyB0aGVpciByZXZpZXdzIGFuZCBoYXZpbmcgJ2VtIGFsbCByZXZpZXcgYSA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vdmluZyB0YXJnZXQgaXNuJ3QgYSBn b29kIHBsYW4uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzExLzIwMTMgMDg6MTggQU0sIEhhbm5lcyBUc2No b2ZlbmlnIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIGd1 eXMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB1cGRhdGluZyB0aGUgYXNzZXJ0aW9u IGRvY3VtZW50IGFuZCBmb3IgaW5jb3Jwb3JhdGluZyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgb24g dGhlIG1haWxpbmcgbGlzdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBpcyBvbmx5IG9uZSBp c3N1ZSB0aGF0IGNhdWdodCBteSBhdHRlbnRpb24uIFlvdSBjaGFuZ2VkIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgYXVkaWVuY2UgZWxlbWVudCB0byB0aGUgZm9sbG93aW5nIHRleHQgKGluIHZlcnNp b24gLTA5IG9mDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWFzc2VydGlvbnMtMDkiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtYXNzZXJ0aW9ucy0wOTwvYT4pOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEF1 ZGllbmNlJm5ic3A7IEEgdmFsdWUgdGhhdCBpZGVudGlmaWVzIHRoZSBwYXJ0aWVzIGludGVuZGVk IHRvIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb2Nlc3MgdGhlJm5i c3A7IGFzc2VydGlvbi4mbmJzcDsgQW4gYXVkaWVuY2UgdmFsdWUgTUFZIGJlIHRoZSBVUkwgb2Yg dGhlIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRva2VuIEVuZHBvaW50 Jm5ic3A7IGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIgb2YgT0F1dGggMi4wIFtSRkM2NzQ5XS48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTaW5jZSB0aGUgdmFsdWUgaW4gdGhlIGF1ZGllbmNlIGZpZWxkIGlzIHVzZWQgdG8g YnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluIGEgY29tcGFyaXNvbiBvcGVyYXRpb24gKHNl ZSBTZWN0aW9uIDUuMikgSSBiZWxpZXZlIHRoZSBjdXJyZW50IHRleHQgd2lsbCBsZWFkIHRvIGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuIE5vdCBvbmx5IGlzIHRoZSBjb21wYXJpc2lvbiBvcGVy YXRpb24gdW5zcGVjaWZpZWQgYnV0IGV2ZW4gdGhlDQogdmFsdWUgdGhhdCBpcyBjb250YWluZWQg aW4gdGhlIGZpZWxkIGlzIGxlZnQgb3Blbi4gVGhlIFJGQyAyMTE5IE1BWSBkb2VzIG5vdCByZWFs bHkgZ2l2ZSBhIGxvdCBvZiBoaW50cyBvZiB3aGF0IHNob3VsZCBiZSBwdXQgaW4gdGhlcmUuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgV2l0aG91dCBoYXZpbmcgYSBjbGVhciBkZXNjcmlwdGlvbiBvZiB3 aGF0IGlkZW50aWZpZXIgaXMgY29udGFpbmVkIGluIHRoaXMgZmllbGQgYW5kIGhvdyB0aGUgY29t cGFyaXNvbiB3b3JrcyBpdCBpcyBlaXRoZXIgcG9zc2libGUgdGhhdCBhIGxlZ2l0aW1hdGUgY2xp ZW50IGlzIHJlamVjdGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAod2hpY2ggaXMgYW5u b3lpbmcpIG9yIGFuIGFzc2VydGlvbiB3aXRoIGFuIGluY29ycmVjdA0KIGFzc2VydGlvbiBpcyBh Y2NlcHRlZCAod2hpY2ggaXMgYSBzZWN1cml0eSBwcm9ibGVtKS48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBCdHcsIHRoZSBzYW1lIGlzc3VlIGNhbiBhbHNvIGJlIHNlZW4gaW4gPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA0Ij4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wNDwv YT4sIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt c2FtbDItYmVhcmVyLTE1Ij4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtc2FtbDItYmVhcmVyLTE1PC9hPiBhbmQgaW4gYSBtb3JlIGdlbmVyaWMgZm9ybSBhbHNv IGluIHRoZSBKV1QgKFNlY3Rpb24gNC4xLjMgb2YNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDYiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDY8L2E+OyAm cXVvdDthdWQmcXVvdDsgY2xhaW0pLiBGcm9tIHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgSldUIGRv Y3VtZW50IEkgd2FzIG5vdCBxdWl0ZSBzdXJlIHdoZXRoZXIgdGhlIGFiaWxpdHkgdG8gY2Fycnkg YW4gYXJyYXkgb2YgY2FzZQ0KIHNlbnNpdGl2ZSBzdHJpbmdzIGZvciB0aGF0IGZpZWxkIGlzIGFs c28gYWxsb3dlZCBpbiBhbnkgb2YgdGhlIGFzc2VydGlvbiBkb2N1bWVudHMuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gZG9jdW1lbnRzIHRoYXQgcHJvdmlkZSBp bnB1dCB0byB0aGlzIHByb2JsZW0gc3BhY2UsIG5hbWVseTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 MTI1Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTI1PC9hPjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlhYi1pZGVudGlmaWVyLWNvbXBhcmlzb24tMDciPg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWFiLWlkZW50aWZpZXItY29tcGFyaXNvbi0wNzwvYT48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTbywgSSB3b3VsZCBzdWdnZXN0IHRvIGRlY2lkZSB3aGF0IHR5cGUgb2Yg aWRlbnRpZmllciBnb2VzIGludG8gdGhpcyBmaWVsZCBhbmQgdGhlbiB0byBwb2ludCB0byBhIGRv Y3VtZW50IHRoYXQgaWxsdXN0cmF0ZXMgaG93IHRoZSBjb21wYXJpc29uIG9wZXJhdGlvbiB3b3Vs ZCBsb29rIGxpa2UuIFBvc3NpYmxlIGlkZW50aWZpZXJzIGFyZSBkb21haW4gbmFtZXMsIElQIGFk ZHJlc3NlcywgVVJJcywgZXRjLiBKdXN0IGFzIGFuIGV4YW1wbGUNCiBmcm9tIFJGQyA2MTI1IHdv dWxkIHlvdSBhbGxvdyBhIHdpbGRjYXJkIG1hdGNoIChsaWtlICZxdW90OyouZXhhbXBsZS5jb20m cXVvdDspIG9yIG9ubHkgYW4gZXF1YWxpdHkgbWF0Y2g/IFdvdWxkICZxdW90OzxhIGhyZWY9Imh0 dHA6Ly93d3cuZXhhbXBsZS5jb20iPnd3dy5leGFtcGxlLmNvbTwvYT4mcXVvdDsgYmUgdGhlIHNh bWUgYXMgJnF1b3Q7ZXhhbXBsZS5jb20mcXVvdDsgaWYgdGhleSByZXNvbHZlIHRvIHRoZSBzYW1l IElQIGFkZHJlc3MoZXMpPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5uZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgPGJyPg0K Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394366A4AF8DTK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Wed Jan 16 11:52:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8E21F8611 for ; Wed, 16 Jan 2013 11:52:51 -0800 (PST) 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=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljkowoLFBsaE for ; Wed, 16 Jan 2013 11:52:50 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5974B21F860A for ; Wed, 16 Jan 2013 11:52:50 -0800 (PST) Received: from BL2FFO11FD001.protection.gbl (10.173.161.203) by BL2FFO11HUB025.protection.gbl (10.173.161.49) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 16 Jan 2013 19:52:37 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 16 Jan 2013 19:52:37 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 16 Jan 2013 19:51:58 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Principal -> Subject in Assertions spec? Thread-Index: Ac30IvFc/O0zg4CgRnm4qoarZkYplg== Date: Wed, 16 Jan 2013 19:51:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A4AFE4@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5343655001)(47446002)(5343635001)(54316002)(49866001)(46102001)(56776001)(50986001)(16406001)(16236675001)(55846006)(47976001)(47736001)(4396001)(512954001)(77982001)(54356001)(59766001)(53806001)(76482001)(56816002)(15202345001)(33656001)(74662001)(74502001)(44976002)(51856001)(31966008)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB025; H:TK5EX14MLTC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07283408BE Subject: [OAUTH-WG] Principal -> Subject in Assertions spec? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:52:52 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In writing the proposed interoperability text for the Assertions specificat= ion, I noticed that the Assertions spec uses the term "Principal" to refer = to the subject of the assertion, whereas both the SAML and JWT profiles use= the term "Subject" for this same concept. I propose that at the same time= we add the Interoperability statement, we also change the uses of the term= "Principal" to "Subject" in the assertions spec so that it's terminology u= sage is more consistent with the two profile specs using it. Thoughts? -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In writing the proposed interoperability text for th= e Assertions specification, I noticed that the Assertions spec uses the ter= m “Principal” to refer to the subject of the assertion, whereas= both the SAML and JWT profiles use the term “Subject” for this same concept.  I propose that at the same time we add the In= teroperability statement, we also change the uses of the term “Princi= pal” to “Subject” in the assertions spec so that it’= ;s terminology usage is more consistent with the two profile specs using it.

 

Thoughts?

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_-- From jricher@mitre.org Wed Jan 16 12:07:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D256921F8B29 for ; Wed, 16 Jan 2013 12:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AGvzeNwMSsc for ; Wed, 16 Jan 2013 12:07:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A59FE21F8B19 for ; Wed, 16 Jan 2013 12:07:20 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA1E443502B8; Wed, 16 Jan 2013 15:07:19 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 930D21F12F6; Wed, 16 Jan 2013 15:07:19 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 15:07:19 -0500 From: "Richer, Justin P." To: Mike Jones , "oauth@ietf.org" Thread-Topic: Principal -> Subject in Assertions spec? Thread-Index: Ac30IvFc/O0zg4CgRnm4qoarZkYplgAAhCXK Date: Wed, 16 Jan 2013 20:07:18 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366A4AFE4@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A4AFE4@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0687A994IMCMBX01MITREOR_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Principal -> Subject in Assertions spec? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:07:22 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E0687A994IMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1, it's a non-normative terminology change that aligns it with related eff= orts. It should be a simple text replace operation. -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Mike Jon= es [Michael.Jones@microsoft.com] Sent: Wednesday, January 16, 2013 2:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] Principal -> Subject in Assertions spec? In writing the proposed interoperability text for the Assertions specificat= ion, I noticed that the Assertions spec uses the term =93Principal=94 to re= fer to the subject of the assertion, whereas both the SAML and JWT profiles= use the term =93Subject=94 for this same concept. I propose that at the s= ame time we add the Interoperability statement, we also change the uses of = the term =93Principal=94 to =93Subject=94 in the assertions spec so that it= =92s terminology usage is more consistent with the two profile specs using = it. Thoughts? -- Mike --_000_B33BFB58CCC8BE4998958016839DE27E0687A994IMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1, it's a non-normative terminology change that aligns it with = related efforts. It should be a simple text replace operation.

 -- Justin

From: oauth-bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of Mike Jones [Michael.Jones@microsoft.com]
Sent: Wednesday, January 16, 2013 2:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Principal -> Subject in Assertions spec?

In writing the proposed interoperability text for th= e Assertions specification, I noticed that the Assertions spec uses the ter= m =93Principal=94 to refer to the subject of the assertion, whereas both th= e SAML and JWT profiles use the term =93Subject=94 for this same concept.  I propose that at the same time we add the In= teroperability statement, we also change the uses of the term =93Principal= =94 to =93Subject=94 in the assertions spec so that it=92s terminology usag= e is more consistent with the two profile specs using it.

 

Thoughts?

 

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

 

--_000_B33BFB58CCC8BE4998958016839DE27E0687A994IMCMBX01MITREOR_-- From torsten@lodderstedt.net Wed Jan 16 13:40:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32D611E80FD for ; Wed, 16 Jan 2013 13:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8dpW9INp-Jv for ; Wed, 16 Jan 2013 13:40:10 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 902A711E80E6 for ; Wed, 16 Jan 2013 13:40:10 -0800 (PST) Received: from [79.253.28.41] (helo=[192.168.71.56]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TvaiN-0008Sp-OR; Wed, 16 Jan 2013 22:40:07 +0100 References: <4E1F6AAD24975D4BA5B168042967394366A4AFE4@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-DDC8A999-66E2-45E9-9D2F-13D0B8BC2714 Content-Transfer-Encoding: 7bit Message-Id: <73F55F17-6FB0-4BD5-8660-393178C6060F@lodderstedt.net> X-Mailer: iPad Mail (10A523) From: Torsten Lodderstedt Date: Wed, 16 Jan 2013 22:40:08 +0100 To: "Richer, Justin P." X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Principal -> Subject in Assertions spec? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 21:40:13 -0000 --Apple-Mail-DDC8A999-66E2-45E9-9D2F-13D0B8BC2714 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 makes sense Am 16.01.2013 um 21:07 schrieb "Richer, Justin P." : > +1, it's a non-normative terminology change that aligns it with related ef= forts. It should be a simple text replace operation. >=20 > -- Justin >=20 > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Mike Jo= nes [Michael.Jones@microsoft.com] > Sent: Wednesday, January 16, 2013 2:51 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Principal -> Subject in Assertions spec? >=20 > In writing the proposed interoperability text for the Assertions specifica= tion, I noticed that the Assertions spec uses the term =E2=80=9CPrincipal=E2= =80=9D to refer to the subject of the assertion, whereas both the SAML and J= WT profiles use the term =E2=80=9CSubject=E2=80=9D for this same concept. I= propose that at the same time we add the Interoperability statement, we als= o change the uses of the term =E2=80=9CPrincipal=E2=80=9D to =E2=80=9CSubjec= t=E2=80=9D in the assertions spec so that it=E2=80=99s terminology usage is m= ore consistent with the two profile specs using it. > =20 > Thoughts? > =20 > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-DDC8A999-66E2-45E9-9D2F-13D0B8BC2714 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 makes sense

Am 16.01.2013 um= 21:07 schrieb "Richer, Justin P." <= jricher@mitre.org>:

+1, it's a non-normative terminology change that aligns it with relate= d efforts. It should be a simple text replace operation.

 -- Justin

From: oauth-bounces@ietf.org [o= auth-bounces@ietf.org] on behalf of Mike Jones [Michael.Jones@microsoft.com]
Sent: Wednesday, January 16, 2013 2:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Principal -> Subject in Assertions spec?

In writing the proposed interoperability text for the= Assertions specification, I noticed that the Assertions spec uses the term =E2= =80=9CPrincipal=E2=80=9D to refer to the subject of the assertion, whereas b= oth the SAML and JWT profiles use the term =E2=80=9CSubject=E2=80=9D for this same concept.  I propose that at the same time we add the Int= eroperability statement, we also change the uses of the term =E2=80=9CPrinci= pal=E2=80=9D to =E2=80=9CSubject=E2=80=9D in the assertions spec so that it=E2= =80=99s terminology usage is more consistent with the two profile specs using it.

 

Thoughts?

 

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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-DDC8A999-66E2-45E9-9D2F-13D0B8BC2714-- From hannes.tschofenig@gmx.net Thu Jan 17 05:43:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD121F8623 for ; Thu, 17 Jan 2013 05:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIcszTLKMhS4 for ; Thu, 17 Jan 2013 05:43:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 28EFC21F8619 for ; Thu, 17 Jan 2013 05:43:29 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M4lZj-1T03Cv18aD-00ywyY for ; Thu, 17 Jan 2013 14:43:28 +0100 Received: (qmail invoked by alias); 17 Jan 2013 13:43:28 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp001) with SMTP; 17 Jan 2013 14:43:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cUoYZ3ydcBnRm8rCbz5Cv3Ul3eppk7TbJQ9FTCP obqFNv7yBCRofp From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jan 2013 15:43:26 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 13:43:31 -0000 Hi all,=20 We will have our next OAuth conference call on the 21st January 2013, = 1pm EST (for roughly one hour). John & Nat kindly offered their conference bridge. It is the same bridge = we used before. https://www3.gotomeeting.com/join/695548174 We will continue where we stopped last time, namely we stopped our = discussions at the crypto agility requirement=20 (first requirement in = http://tools.ietf.org/html/draft-tschofenig-oauth-security-01#section-5). = =20 Here is the slide set I used last time: http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt (We stopped at slide #2.) We also did not manage to get to discuss the use case Justin raised at = the first conference call. He distributed a writeup on the list: http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html Ciao Hannes & Derek PS: I will try to distribute my meeting minute notes from the previous = call by tomorrow.=20 From lainhart@us.ibm.com Thu Jan 17 10:09:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C26F21F87D4 for ; Thu, 17 Jan 2013 10:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ducXfJWEk3yq for ; Thu, 17 Jan 2013 10:09:23 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id A43EE21F87E3 for ; Thu, 17 Jan 2013 10:09:23 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 17 Jan 2013 13:09:22 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 17 Jan 2013 13:09:21 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 30FC86E8077; Thu, 17 Jan 2013 13:09:19 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0HI9KT5307386; Thu, 17 Jan 2013 13:09:20 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0HI9J4v027468; Thu, 17 Jan 2013 16:09:19 -0200 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0HI9JI3027450; Thu, 17 Jan 2013 16:09:19 -0200 To: oauth@ietf.org Cc: oauth-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 89C2383F:5888D4B7-85257AF6:005D229B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Thu, 17 Jan 2013 13:09:17 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/17/2013 13:09:19, Serialize complete at 01/17/2013 13:09:19 Content-Type: multipart/alternative; boundary="=_alternative 0063BA0385257AF6_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13011718-7182-0000-0000-0000048538CA Subject: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:09:24 -0000 This is a multipart message in MIME format. --=_alternative 0063BA0385257AF6_= Content-Type: text/plain; charset="US-ASCII" We're working on an OAuth 2.0 AS, with extensions defined for session mgmt. We're trying to adopt uniformly the error reporting mechanism in 6749. I'm now realizing that the error_description response in specified to be USASCII. I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale. E.G. consider the client credentials grant. The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language. I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there. I'm also wondering about the USASCII constraint on error_description. I'm a long-time reader of this list, but I'm not recalling the background on this. Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com --=_alternative 0063BA0385257AF6_= Content-Type: text/html; charset="US-ASCII" We're working on an OAuth 2.0 AS, with extensions defined for session mgmt.  We're trying to adopt uniformly the error reporting mechanism in 6749.

I'm now realizing that the error_description response in specified to be USASCII.  I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale.  E.G. consider the client credentials grant.  The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language.

I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there.  I'm also wondering about the USASCII constraint on error_description.  I'm a long-time reader of this list, but I'm not recalling the background on this.



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

--=_alternative 0063BA0385257AF6_=-- From zhou.sujing@zte.com.cn Fri Jan 18 01:24:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB421F85D2; Fri, 18 Jan 2013 01:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.972 X-Spam-Level: X-Spam-Status: No, score=-95.972 tagged_above=-999 required=5 tests=[AWL=2.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPzEfsWUsKuZ; Fri, 18 Jan 2013 01:24:07 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59421F8931; Fri, 18 Jan 2013 01:24:06 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 31023126F6DB; Fri, 18 Jan 2013 17:26:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0I9NEWD033232; Fri, 18 Jan 2013 17:23:14 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 18 Jan 2013 17:22:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-18 17:23:08, Serialize complete at 2013-01-18 17:23:08 Content-Type: multipart/alternative; boundary="=_alternative 003394FF48257AF7_=" X-MAIL: mse01.zte.com.cn r0I9NEWD033232 Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 09:24:09 -0000 This is a multipart message in MIME format. --=_alternative 003394FF48257AF7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGNvbmNlcm5pbmcgdGhlIG9hdXRoLXNlY3VyaXR5IGRvY3Vt ZW50Lg0KMS4gY29sbHVzaW9uIA0KICAgIE9ubHkgY29sbHVzaW9uIGJldHdlZW4gcmVzb3VyY2Ug c2VydmVycyBhcmUgY29uc2lkZXJlZCwgDQogaG93ZXZlciwgY29sbHVzaW9uIGJldHdlZW4gcmVz b3VyY2Ugc2VydmVyIGFuZCBjbGllbnQgY291bGQgaGFwcGVuLg0KMi4gQVMtdG8tUlMgcmVsYXRp b25zaGlwIGFub255bWl0eQ0KICAgaWYgInRoZSBDbGllbnQgbXVzdCBub3QgcHJvdmlkZSBpbmZv cm1hdGlvbiBhYm91dCB0aGUgUmVzb3VyY2UgU2VydmVyIA0KaW4gdGhlIGFjY2VzcyB0b2tlbiBy ZXF1ZXN0LiIgDQogIHRoZW4gaG93IEFTIGNhbiBlbmNyeXB0IGFjY2VzcyB0b2tlbiB1c2luZyB0 aGUga2V5IHNoYXJlZCBiZXR3ZWVuIEFToaENCmFuZCBSUz8NCiAgSSBmZWVsIHRoaXMgcmVxdWly ZW1lbnQgaXMgdW5jbGVhciBhbmQgY29uZmxpY3Qgd2l0aCBzb21lIHNlY3VyaXR5IA0KbWVhc3Vy ZXMgdGhhdCBtaWdodCBiZSB0YWtlbiBpbiBPQXV0aCAyLjAuDQozLiBDb21wcm9taXNlIG9mIGNs aWVudKOsIFJTIGhhdmUgYmVlbiBjb25zaWRlcmVkIChzZXBhcmF0ZWx5KQ0KICAgQnV0IHRoZSBy ZXN1bHQgb2YgdGhlaXIgY29tcHJvbWlzZSBtYXkgbm90IGJlIGxpbWl0ZWQgdG8gImNsaWVudCAN CmFjY2Vzc2luZyBtb3JlIHJlc291cmNlcyAiLA0KaXQgY291bGQgYmUgY29tcHJvbWlzZWQgY2xp ZW50L1JTICByZWRpcmVjdCBSTyB0byBhIG1hbmlwdWxhdGVkIEFTIA0KcGhpc2hpbmcgUk8ncyBj cmVkZW50aWFsLCBmb3IgZXhhbXBsZS4gDQoNCg0KDQogDQoNCg0KDQpvYXV0aC1ib3VuY2VzQGll dGYub3JnINC009ogMjAxMy0wMS0xNyAyMTo0MzoyNjoNCg0KPiBIaSBhbGwsIA0KPiANCj4gV2Ug d2lsbCBoYXZlIG91ciBuZXh0IE9BdXRoIGNvbmZlcmVuY2UgY2FsbCBvbiB0aGUgMjFzdCBKYW51 YXJ5IA0KPiAyMDEzLCAxcG0gRVNUIChmb3Igcm91Z2hseSBvbmUgaG91cikuDQo+IA0KPiBKb2hu ICYgTmF0IGtpbmRseSBvZmZlcmVkIHRoZWlyIGNvbmZlcmVuY2UgYnJpZGdlLiBJdCBpcyB0aGUg c2FtZSANCj4gYnJpZGdlIHdlIHVzZWQgYmVmb3JlLg0KPiBodHRwczovL3d3dzMuZ290b21lZXRp bmcuY29tL2pvaW4vNjk1NTQ4MTc0DQo+IA0KPiBXZSB3aWxsIGNvbnRpbnVlIHdoZXJlIHdlIHN0 b3BwZWQgbGFzdCB0aW1lLCBuYW1lbHkgd2Ugc3RvcHBlZCBvdXIgDQo+IGRpc2N1c3Npb25zIGF0 IHRoZSBjcnlwdG8gYWdpbGl0eSByZXF1aXJlbWVudCANCj4gKGZpcnN0IHJlcXVpcmVtZW50IGlu IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctDQo+IG9hdXRoLXNl Y3VyaXR5LTAxI3NlY3Rpb24tNSkuIA0KPiANCj4gSGVyZSBpcyB0aGUgc2xpZGUgc2V0IEkgdXNl ZCBsYXN0IHRpbWU6DQo+IGh0dHA6Ly93d3cudHNjaG9mZW5pZy5wcml2LmF0L09BdXRoMi1TZWN1 cml0eS0xMUphbjIwMTMucHB0DQo+IChXZSBzdG9wcGVkIGF0IHNsaWRlICMyLikNCj4gDQo+IFdl IGFsc28gZGlkIG5vdCBtYW5hZ2UgdG8gZ2V0IHRvIGRpc2N1c3MgdGhlIHVzZSBjYXNlIEp1c3Rp biByYWlzZWQgDQo+IGF0IHRoZSBmaXJzdCBjb25mZXJlbmNlIGNhbGwuIEhlIGRpc3RyaWJ1dGVk IGEgd3JpdGV1cCBvbiB0aGUgbGlzdDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTA0MDcuaHRtbA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMg JiBEZXJlaw0KPiANCj4gUFM6IEkgd2lsbCB0cnkgdG8gZGlzdHJpYnV0ZSBteSBtZWV0aW5nIG1p bnV0ZSBub3RlcyBmcm9tIHRoZSANCj4gcHJldmlvdXMgY2FsbCBieSB0b21vcnJvdy4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --=_alternative 003394FF48257AF7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBzb21lIHF1ZXN0aW9u cyBjb25jZXJuaW5nIHRoZQ0Kb2F1dGgtc2VjdXJpdHkgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBjb2xsdXNpb24gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IE9ubHkgY29sbHVzaW9u IGJldHdlZW4NCnJlc291cmNlIHNlcnZlcnMgYXJlIGNvbnNpZGVyZWQsIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7aG93ZXZlciwgY29sbHVzaW9uIGJl dHdlZW4gcmVzb3VyY2UNCnNlcnZlciBhbmQgY2xpZW50IGNvdWxkIGhhcHBlbi48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIEFTLXRvLVJTIHJlbGF0aW9uc2hp cCBhbm9ueW1pdHk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtpZiAmcXVvdDt0aGUgQ2xpZW50IG11c3QNCm5vdCBwcm92aWRlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSZXNvdXJjZSBTZXJ2ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0 LiZxdW90Ow0KJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgdGhlbiBob3cgQVMgY2FuIGVuY3J5cHQgYWNjZXNzDQp0b2tlbiB1c2luZyB0aGUg a2V5IHNoYXJlZCBiZXR3ZWVuIEFToaFhbmQgUlM/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSSBmZWVsIHRoaXMgcmVxdWlyZW1lbnQgaXMgdW5jbGVh cg0KYW5kIGNvbmZsaWN0IHdpdGggc29tZSBzZWN1cml0eSBtZWFzdXJlcyB0aGF0IG1pZ2h0IGJl IHRha2VuIGluIE9BdXRoIDIuMC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjMuIENvbXByb21pc2Ugb2YgY2xpZW50o6wgUlMgaGF2ZSBiZWVuDQpjb25zaWRlcmVk IChzZXBhcmF0ZWx5KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO0J1dCB0aGUgcmVzdWx0IG9mIHRoZWlyDQpjb21wcm9taXNlIG1heSBub3Qg YmUgbGltaXRlZCB0byAmcXVvdDtjbGllbnQgYWNjZXNzaW5nIG1vcmUgcmVzb3VyY2VzDQomcXVv dDssPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pdCBjb3VsZCBi ZSBjb21wcm9taXNlZCBjbGllbnQvUlMgJm5ic3A7cmVkaXJlY3QNClJPIHRvIGEgbWFuaXB1bGF0 ZWQgQVMgcGhpc2hpbmcgUk8ncyBjcmVkZW50aWFsLCBmb3IgZXhhbXBsZS4gPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDEtMTcgMjE6NDM6MjY6PGJyPg0KPGJyPg0K Jmd0OyBIaSBhbGwsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBXZSB3aWxsIGhhdmUgb3VyIG5leHQg T0F1dGggY29uZmVyZW5jZSBjYWxsIG9uIHRoZSAyMXN0IEphbnVhcnkgPGJyPg0KJmd0OyAyMDEz LCAxcG0gRVNUIChmb3Igcm91Z2hseSBvbmUgaG91cikuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEpv aG4gJmFtcDsgTmF0IGtpbmRseSBvZmZlcmVkIHRoZWlyIGNvbmZlcmVuY2UgYnJpZGdlLiBJdCBp cyB0aGUgc2FtZQ0KPGJyPg0KJmd0OyBicmlkZ2Ugd2UgdXNlZCBiZWZvcmUuPGJyPg0KJmd0OyBo dHRwczovL3d3dzMuZ290b21lZXRpbmcuY29tL2pvaW4vNjk1NTQ4MTc0PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFdlIHdpbGwgY29udGludWUgd2hlcmUgd2Ugc3RvcHBlZCBsYXN0IHRpbWUsIG5hbWVs eSB3ZSBzdG9wcGVkIG91cg0KPGJyPg0KJmd0OyBkaXNjdXNzaW9ucyBhdCB0aGUgY3J5cHRvIGFn aWxpdHkgcmVxdWlyZW1lbnQgPGJyPg0KJmd0OyAoZmlyc3QgcmVxdWlyZW1lbnQgaW4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy08YnI+DQomZ3Q7IG9hdXRoLXNl Y3VyaXR5LTAxI3NlY3Rpb24tNSkuICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyBIZXJlIGlz IHRoZSBzbGlkZSBzZXQgSSB1c2VkIGxhc3QgdGltZTo8YnI+DQomZ3Q7IGh0dHA6Ly93d3cudHNj aG9mZW5pZy5wcml2LmF0L09BdXRoMi1TZWN1cml0eS0xMUphbjIwMTMucHB0PGJyPg0KJmd0OyAo V2Ugc3RvcHBlZCBhdCBzbGlkZSAjMi4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGFsc28gZGlk IG5vdCBtYW5hZ2UgdG8gZ2V0IHRvIGRpc2N1c3MgdGhlIHVzZSBjYXNlIEp1c3RpbiByYWlzZWQN Cjxicj4NCiZndDsgYXQgdGhlIGZpcnN0IGNvbmZlcmVuY2UgY2FsbC4gSGUgZGlzdHJpYnV0ZWQg YSB3cml0ZXVwIG9uIHRoZSBsaXN0Ojxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTA0MDcuaHRtbDxicj4NCiZndDsgPGJyPg0K Jmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQomZ3Q7IDxicj4NCiZn dDsgUFM6IEkgd2lsbCB0cnkgdG8gZGlzdHJpYnV0ZSBteSBtZWV0aW5nIG1pbnV0ZSBub3RlcyBm cm9tIHRoZSA8YnI+DQomZ3Q7IHByZXZpb3VzIGNhbGwgYnkgdG9tb3Jyb3cuIDxicj4NCiZndDsg PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4N CjwvZm9udD48L3R0Pg0K --=_alternative 003394FF48257AF7_=-- From hannes.tschofenig@gmx.net Fri Jan 18 01:40:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7837C21F8865 for ; Fri, 18 Jan 2013 01:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9nJaX4iXVwb for ; Fri, 18 Jan 2013 01:40:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4436721F883F for ; Fri, 18 Jan 2013 01:40:40 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LjP2f-1TMFSK1E1X-00dZzz for ; Fri, 18 Jan 2013 10:40:39 +0100 Received: (qmail invoked by alias); 18 Jan 2013 09:40:39 -0000 Received: from unknown (EHLO [10.255.132.15]) [194.251.119.201] by mail.gmx.net (mp002) with SMTP; 18 Jan 2013 10:40:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sgnE1om7sVurS8JXMhTVaxCbLcIwjpEa5NMyzcm O2x2ovKXl3Oavp Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 18 Jan 2013 11:40:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <814E753D-E176-40A2-9208-6A575F46DA99@gmx.net> References: To: Todd W Lainhart X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 09:40:41 -0000 Hi Todd,=20 it is important to note that the error_description is not meant to be = shown to the end users. That was the reason for not introducing internationalization support.=20 If you want to provide some additional information about the error = description in other languages I would suggest to use the error_uri to = point the developer to that information.=20 Ciao Hannes On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote: > We're working on an OAuth 2.0 AS, with extensions defined for session = mgmt. We're trying to adopt uniformly the error reporting mechanism in = 6749.=20 >=20 > I'm now realizing that the error_description response in specified to = be USASCII. I was assuming that the error message could be UTF-8 = encoded, such that I could return error messages in the client's locale. = E.G. consider the client credentials grant. The store on the AS = holding the registration is down, so I'd like to return a 500 with an = error message from the store, from a catalog mapped to the client's = language.=20 >=20 > I've wondered about adding an additional response parameter, something = like error_description_locale, but thought that there might be better = practices out there. I'm also wondering about the USASCII constraint on = error_description. I'm a long-time reader of this list, but I'm not = recalling the background on this. >=20 >=20 >=20 >=20 > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Fri Jan 18 04:04:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578E21F88B2 for ; Fri, 18 Jan 2013 04:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN9YkJ7DmB1V for ; Fri, 18 Jan 2013 04:04:39 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF721F84D8 for ; Fri, 18 Jan 2013 04:04:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0IC4Tld000881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Jan 2013 13:04:29 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0IC4TSl030253 for ; Fri, 18 Jan 2013 13:04:29 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 13:04:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jan 2013 14:04:28 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Assertion Draft: Text about Interoperability -- Today Thread-Index: Ac31c/ey/0oPxcEZTU2GjVm1VBYpaA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Jan 2013 12:04:28.0923 (UTC) FILETIME=[F7B104B0:01CDF573] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2894 X-purgate-ID: 151667::1358510669-00003C02-1667706C/0-0/0-0 X-Mailman-Approved-At: Fri, 18 Jan 2013 04:06:16 -0800 Subject: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 12:04:40 -0000 Hi all,=20 As you have seen on the list (see http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had a chat with Mike about how to address my comment for the assertion draft and Mike kindly provided his text proposal (see http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I have used his text as input and extended it a bit. Here is the updated text.=20 ---- Operational Considerations and Interoperability Expectations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that instantiate this framework have been developed, one uses SAML 2.0-based assertions and is described in [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two instantiations provide additional details about the assertion encoding and processing rules for those interested to implement and deploy assertions with OAuth 2.0.=20 However, even with these instance documents an interoperable implementation is not possible since for a specific deployment environment (within a trust framework or circle of trust, as it is sometimes called) agreements about acceptable values for various fields in the specification have to be agreed upon. For example, the audience field needs to be populated by the entity that generates the assertion with a specific value and that value may hold identifiers of different types (for example, a URL, an IP address, an FQDN) and the entity receiving and verifying the assertion must compare the value in the audience field with other information it may obtain from the request and/or with locally available information. Since the abstract framework nor the instance documents provide sufficient information about the syntax, the semantic and the comparison operation of the audience field additional profiling in further specifications is needed for an interoperable implementation. This additional profiling is not only needed for the audience field but also for other fields as well.=20 This framework was designed with the expectation that additional specifications will fill this gap for deployment-specific environments. ---- You have the choice: 1. take this as-is if you want the assertion draft (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no normative text in the writeup; it is rather a clarification. 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the Feb 7 telechat (if the discussion is done by Feb 1) 1 or 2 needs to be chosen today. Ciao Hannes PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.=20 From lainhart@us.ibm.com Fri Jan 18 05:43:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9D21F88EF for ; Fri, 18 Jan 2013 05:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJaYRJFuDA+x for ; Fri, 18 Jan 2013 05:43:41 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0321F8862 for ; Fri, 18 Jan 2013 05:43:41 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 Jan 2013 08:43:31 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 18 Jan 2013 08:43:26 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id CFE886E8040; Fri, 18 Jan 2013 08:43:24 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0IDhPH615073466; Fri, 18 Jan 2013 08:43:25 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0IDhPvJ017029; Fri, 18 Jan 2013 08:43:25 -0500 Received: from d01mc255.pok.ibm.com (d01mc255.pok.ibm.com [9.63.10.213]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0IDhPtH017009; Fri, 18 Jan 2013 08:43:25 -0500 In-Reply-To: <814E753D-E176-40A2-9208-6A575F46DA99@gmx.net> References: <814E753D-E176-40A2-9208-6A575F46DA99@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-KeepSent: 5231E27E:C07CA017-85257AF7:004AE118; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Fri, 18 Jan 2013 08:43:23 -0500 X-MIMETrack: Serialize by Router on D01MC255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/18/2013 08:43:24, Serialize complete at 01/18/2013 08:43:24 Content-Type: multipart/alternative; boundary="=_alternative 004B619685257AF7_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13011813-5806-0000-0000-00001E6BB763 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:43:56 -0000 This is a multipart message in MIME format. --=_alternative 004B619685257AF7_= Content-Type: text/plain; charset="US-ASCII" Hi Hannes - Providing localization support indirectly via the error_uri was the conclusion that we were coming to, so thanks for responding and confirming that. Best wishes -- Todd Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Hannes Tschofenig To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: Hannes Tschofenig , oauth@ietf.org, oauth-bounces@ietf.org Date: 01/18/2013 04:42 AM Subject: Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty? Hi Todd, it is important to note that the error_description is not meant to be shown to the end users. That was the reason for not introducing internationalization support. If you want to provide some additional information about the error description in other languages I would suggest to use the error_uri to point the developer to that information. Ciao Hannes On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote: > We're working on an OAuth 2.0 AS, with extensions defined for session mgmt. We're trying to adopt uniformly the error reporting mechanism in 6749. > > I'm now realizing that the error_description response in specified to be USASCII. I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale. E.G. consider the client credentials grant. The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language. > > I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there. I'm also wondering about the USASCII constraint on error_description. I'm a long-time reader of this list, but I'm not recalling the background on this. > > > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > lainhart@us.ibm.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=_alternative 004B619685257AF7_= Content-Type: text/html; charset="US-ASCII" Hi  Hannes -

Providing localization support indirectly via the error_uri was the conclusion that we were coming to, so thanks for responding and confirming that.

Best wishes -- Todd



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





From:        Hannes Tschofenig <hannes.tschofenig@gmx.net>
To:        Todd W Lainhart/Lexington/IBM@IBMUS,
Cc:        Hannes Tschofenig <hannes.tschofenig@gmx.net>, oauth@ietf.org, oauth-bounces@ietf.org
Date:        01/18/2013 04:42 AM
Subject:        Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty?



Hi Todd,

it is important to note that the error_description is not meant to be shown to the end users.
That was the reason for not introducing internationalization support.

If you want to provide some additional information about the error description in other languages I would suggest to use the error_uri to point the developer to that information.

Ciao
Hannes

On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote:

> We're working on an OAuth 2.0 AS, with extensions defined for session mgmt.  We're trying to adopt uniformly the error reporting mechanism in 6749.
>
> I'm now realizing that the error_description response in specified to be USASCII.  I was assuming that the error message could be UTF-8 encoded, such that I could return error messages in the client's locale.  E.G. consider the client credentials grant.  The store on the AS holding the registration is down, so I'd like to return a 500 with an error message from the store, from a catalog mapped to the client's language.
>
> I've wondered about adding an additional response parameter, something like error_description_locale, but thought that there might be better practices out there.  I'm also wondering about the USASCII constraint on error_description.  I'm a long-time reader of this list, but I'm not recalling the background on this.
>
>
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--=_alternative 004B619685257AF7_=-- From stephen.farrell@cs.tcd.ie Fri Jan 18 09:47:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BDE21F8788 for ; Fri, 18 Jan 2013 09:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBCAhhFdqrkf for ; Fri, 18 Jan 2013 09:47:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B40D921F8783 for ; Fri, 18 Jan 2013 09:47:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0B64BE76; Fri, 18 Jan 2013 17:46:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F6Oovpew+zn; Fri, 18 Jan 2013 17:46:54 +0000 (GMT) Received: from [IPv6:2001:770:10:203:18e6:2b4c:99cd:ace9] (unknown [IPv6:2001:770:10:203:18e6:2b4c:99cd:ace9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 01DDCBE57; Fri, 18 Jan 2013 17:46:53 +0000 (GMT) Message-ID: <50F98A8E.7090701@cs.tcd.ie> Date: Fri, 18 Jan 2013 17:46:54 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:47:22 -0000 Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had > a chat with Mike about how to address my comment for the assertion draft > and Mike kindly provided his text proposal (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > have used his text as input and extended it a bit. Here is the updated > text. > > ---- > > Operational Considerations and Interoperability Expectations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework on its own, this specification is > not sufficient to produce interoperable implementations. Two other > specifications that instantiate this framework have been developed, one > uses SAML 2.0-based assertions and is described in > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > instantiations provide additional details about the assertion encoding > and processing rules for those interested to implement and deploy > assertions with OAuth 2.0. > > However, even with these instance documents an interoperable > implementation is not possible since for a specific deployment > environment (within a trust framework or circle of trust, as it is > sometimes called) agreements about acceptable values for various fields > in the specification have to be agreed upon. For example, the audience > field needs to be populated by the entity that generates the assertion > with a specific value and that value may hold identifiers of different > types (for example, a URL, an IP address, an FQDN) and the entity > receiving and verifying the assertion must compare the value in the > audience field with other information it may obtain from the request > and/or with locally available information. Since the abstract framework > nor the instance documents provide sufficient information about the > syntax, the semantic and the comparison operation of the audience field > additional profiling in further specifications is needed for an > interoperable implementation. This additional profiling is not only > needed for the audience field but also for other fields as well. > > This framework was designed with the expectation that additional > specifications will fill this gap for deployment-specific environments. > > ---- > > You have the choice: > > 1. take this as-is if you want the assertion draft > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no > normative text in the writeup; it is rather a clarification. > > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the > Feb 7 > telechat (if the discussion is done by Feb 1) > > 1 or 2 needs to be chosen today. > > > Ciao > Hannes > > PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer > are not yet on the telechat agenda. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From nazrmed@hotmail.com Fri Jan 18 10:53:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B41F21F86D3; Fri, 18 Jan 2013 10:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9X5VLCtEChG; Fri, 18 Jan 2013 10:53:30 -0800 (PST) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 95D0221F876E; Fri, 18 Jan 2013 10:53:30 -0800 (PST) Received: from BLU156-DS20 ([65.55.111.73]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 10:53:29 -0800 X-EIP: [qVLhjCpKIWUsXhWmUpvTPYwSULkFmgZF] X-Originating-Email: [nazrmed@hotmail.com] Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable From: "naz ahmed " To: "oauth-request@ietf.org " , "oauth@ietf.org " Date: Fri, 18 Jan 2013 18:53:29 +0000 X-OriginalArrivalTime: 18 Jan 2013 18:53:29.0862 (UTC) FILETIME=[1B3B2260:01CDF5AD] Subject: Re: [OAUTH-WG] OAuth Digest, Vol 51, Issue 58 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:53:31 -0000 Sent from BlackBerry=AE on Airtel -----Original Message----- From: oauth-request@ietf.org Date: Fri, 18 Jan 2013 17:47:23=20 To: Subject: OAuth Digest, Vol 51, Issue 58 =0A= If you have received this digest without all the individual message=0A= attachments you will need to update your digest options in your list=0A= subscription.=A0 To do so, go to =0A= =0A= https://www.ietf.org/mailman/listinfo/oauth=0A= =0A= Click the 'Unsubscribe or edit options' button, log in, and set "Get=0A= MIME or Plain Text Digests?" to MIME.=A0 You can set this option=0A= globally for all the list digests you receive at this point.=0A= =0A= =0A= =0A= Send OAuth mailing list submissions to=0A= =A0=A0=A0=A0=A0=A0=A0 oauth@ietf.org=0A= =0A= To subscribe or unsubscribe via the World Wide Web, visit=0A= =A0=A0=A0=A0=A0=A0=A0 https://www.ietf.org/mailman/listinfo/oauth=0A= or, via email, send a message with subject or body 'help' to=0A= =A0=A0=A0=A0=A0=A0=A0 oauth-request@ietf.org=0A= =0A= You can reach the person managing the list at=0A= =A0=A0=A0=A0=A0=A0=A0 oauth-owner@ietf.org=0A= =0A= When replying, please edit your Subject line so it is more specific=0A= than "Re: Contents of OAuth digest..." From Michael.Jones@microsoft.com Fri Jan 18 14:31:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14DE21F870A for ; Fri, 18 Jan 2013 14:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHzn+ZZp2nmF for ; Fri, 18 Jan 2013 14:31:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8E19221F868E for ; Fri, 18 Jan 2013 14:31:22 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.200) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.596.13; Fri, 18 Jan 2013 22:31:20 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Fri, 18 Jan 2013 22:31:19 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 18 Jan 2013 22:30:56 +0000 From: Mike Jones To: Stephen Farrell , "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Thread-Index: Ac31c/ey/0oPxcEZTU2GjVm1VBYpaAAL9XQAAAkriSA= Date: Fri, 18 Jan 2013 22:30:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> In-Reply-To: <50F98A8E.7090701@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(479174001)(377454001)(13464002)(69234002)(24454001)(54316002)(53806001)(56776001)(46102001)(79102001)(16406001)(51856001)(76482001)(56816002)(54356001)(46406002)(47446002)(23726001)(55846006)(74662001)(44976002)(31966008)(47776002)(5343655001)(49866001)(47976001)(77982001)(59766001)(50986001)(33656001)(50466001)(4396001)(47736001)(74502001)(15202345001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC107.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0730093765 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 22:31:24 -0000 I can't agree with proceeding with Hannes' rewrite of the interoperability = text, as editorially, it reads like it is apologizing for a defect in the s= pecification, whereas it is an intentional feature of the specification tha= t the syntax and verification rules of some fields is intentionally left op= en for profiles to specify (even while the semantics of them is defined by = the Assertions spec). I propose that instead, we go with the revised versi= on at the end of this message, which I believe incorporates Hannes' ideas w= hile keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology= change of "Principal" to "Subject", which was proposed in http://www.ietf.= org/mail-archive/web/oauth/current/msg10530.html and supported by Justin an= d Torsten, with no one opposed. This should go into the version being disc= ussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertion= s and SAML Profile specs be discussed on the same telechat, as both are use= ful for understanding the other. Frankly, I think they should go to the IE= TF Editor together as "related specifications", with the goal being consecu= tively numbered RFCs referencing one another. Is there any reason we can't= schedule both for the February 7th telechat? (I don't actually understand= how they failed to proceed in lock-step in the first place. Chairs - any = insights?) =3D=3D=3D=3D Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0.= However, as an abstract framework in which the data formats used for repre= senting many values are not defined, on its own, this specification is not = sufficient to produce interoperable implementations.=20 Two other specifications that profile this framework for specific assertion= have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-ba= sed assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web To= kens (JWTs). These two instantiations of this framework specify additional= details about the assertion encoding and processing rules for using those = kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profil= ing for specific use cases will be required to achieve full interoperabilit= y. Deployments for particular trust frameworks, circles of trust, or other= uses cases will need to agree among the participants on the kinds of value= s to be used for some abstract fields defined by this specification. For e= xample the values of Issuer, Subject, and Audience fields might be URLs, UR= Is, fully qualified domain names, OAuth client IDs, IP addresses, or other = values, depending upon the requirements of the particular use case. The ve= rification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional spec= ifications will define prescriptive profiles and extensions necessary to ac= hieve full web-scale interoperability for particular use cases. =3D=3D=3D=3D Thanks all, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= tephen Farrell Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay Hiya, So I'll take the lack of further discussion about this an meaning that the = wg want this to shoot ahead. I'll put this in as an RFC editor note for the= draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, >=20 > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20 > had a chat with Mike about how to address my comment for the assertion=20 > draft and Mike kindly provided his text proposal (see=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20 > have used his text as input and extended it a bit. Here is the updated=20 > text. >=20 > ---- >=20 > Operational Considerations and Interoperability Expectations >=20 > This specification defines a framework for using assertions with OAuth=20 > 2.0. However, as an abstract framework on its own, this specification=20 > is not sufficient to produce interoperable implementations. Two other=20 > specifications that instantiate this framework have been developed,=20 > one uses SAML 2.0-based assertions and is described in=20 > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two=20 > instantiations provide additional details about the assertion encoding=20 > and processing rules for those interested to implement and deploy=20 > assertions with OAuth 2.0. >=20 > However, even with these instance documents an interoperable=20 > implementation is not possible since for a specific deployment=20 > environment (within a trust framework or circle of trust, as it is=20 > sometimes called) agreements about acceptable values for various=20 > fields in the specification have to be agreed upon. For example, the=20 > audience field needs to be populated by the entity that generates the=20 > assertion with a specific value and that value may hold identifiers of=20 > different types (for example, a URL, an IP address, an FQDN) and the=20 > entity receiving and verifying the assertion must compare the value in=20 > the audience field with other information it may obtain from the=20 > request and/or with locally available information. Since the abstract=20 > framework nor the instance documents provide sufficient information=20 > about the syntax, the semantic and the comparison operation of the=20 > audience field additional profiling in further specifications is=20 > needed for an interoperable implementation. This additional profiling=20 > is not only needed for the audience field but also for other fields as we= ll. >=20 > This framework was designed with the expectation that additional=20 > specifications will fill this gap for deployment-specific environments. >=20 > ---- >=20 > You have the choice: >=20 > 1. take this as-is if you want the assertion draft=20 > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20 > no normative text in the writeup; it is rather a clarification. >=20 > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20 > the Feb 7 > telechat (if the discussion is done by Feb 1) >=20 > 1 or 2 needs to be chosen today. >=20 >=20 > Ciao > Hannes >=20 > PS: FYI - draft-ietf-oauth-saml2-bearer and=20 > draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Jan 18 14:59:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B121F8682 for ; Fri, 18 Jan 2013 14:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBIyZhwYq+XW for ; Fri, 18 Jan 2013 14:59:44 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD821F8436 for ; Fri, 18 Jan 2013 14:59:42 -0800 (PST) Received: from BL2FFO11FD012.protection.gbl (10.173.161.202) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.596.13; Fri, 18 Jan 2013 22:59:34 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Fri, 18 Jan 2013 22:59:34 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 18 Jan 2013 22:59:31 +0000 From: Mike Jones To: Stephen Farrell , "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Thread-Index: Ac31c/ey/0oPxcEZTU2GjVm1VBYpaAAL9XQAAAkriSAAAaBW0A== Date: Fri, 18 Jan 2013 22:59:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/mixed; boundary="_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(15374002)(69234002)(24454001)(243025002)(13464002)(51704002)(252514003)(479174001)(377454001)(168374001)(5343635001)(47736001)(76482001)(50986001)(512954001)(551934001)(47976001)(49866001)(79102001)(51856001)(46102001)(16236675001)(33656001)(56816002)(54356001)(5343655001)(56776001)(55846006)(59766001)(16406001)(5343665001)(77982001)(44976002)(4396001)(54316002)(47446002)(74662001)(31966008)(15202345001)(53806001)(74502001)(403724001)(550254004)(552614002)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14MLTC103.redmond.corp.microsoft.com; LANG:; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0730093765 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 22:59:44 -0000 --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To make the proposed changes concrete, I've made them in a proposed draft 1= 0 (attached). This contains no normative changes from draft 9. People sho= uld look at Section 1.1 (Interoperability Considerations) and review the ne= w text there. The only other change was renaming "Principal" to "Subject" = to align terminology with the SAML and JWT specs, as discussed on the list. I will wait for OK from one of the chairs or Stephen before checking this i= n. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, January 18, 2013 2:31 PM To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay I can't agree with proceeding with Hannes' rewrite of the interoperability = text, as editorially, it reads like it is apologizing for a defect in the s= pecification, whereas it is an intentional feature of the specification tha= t the syntax and verification rules of some fields is intentionally left op= en for profiles to specify (even while the semantics of them is defined by = the Assertions spec). I propose that instead, we go with the revised versi= on at the end of this message, which I believe incorporates Hannes' ideas w= hile keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology= change of "Principal" to "Subject", which was proposed in http://www.ietf.= org/mail-archive/web/oauth/current/msg10530.html and supported by Justin an= d Torsten, with no one opposed. This should go into the version being disc= ussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertion= s and SAML Profile specs be discussed on the same telechat, as both are use= ful for understanding the other. Frankly, I think they should go to the IE= TF Editor together as "related specifications", with the goal being consecu= tively numbered RFCs referencing one another. Is there any reason we can't= schedule both for the February 7th telechat? (I don't actually understand= how they failed to proceed in lock-step in the first place. Chairs - any = insights?) =3D=3D=3D=3D Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0.= However, as an abstract framework in which the data formats used for repre= senting many values are not defined, on its own, this specification is not = sufficient to produce interoperable implementations.=20 Two other specifications that profile this framework for specific assertion= have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-ba= sed assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web To= kens (JWTs). These two instantiations of this framework specify additional= details about the assertion encoding and processing rules for using those = kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profil= ing for specific use cases will be required to achieve full interoperabilit= y. Deployments for particular trust frameworks, circles of trust, or other= uses cases will need to agree among the participants on the kinds of value= s to be used for some abstract fields defined by this specification. For e= xample the values of Issuer, Subject, and Audience fields might be URLs, UR= Is, fully qualified domain names, OAuth client IDs, IP addresses, or other = values, depending upon the requirements of the particular use case. The ve= rification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional spec= ifications will define prescriptive profiles and extensions necessary to ac= hieve full web-scale interoperability for particular use cases. =3D=3D=3D=3D Thanks all, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S= tephen Farrell Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay Hiya, So I'll take the lack of further discussion about this an meaning that the = wg want this to shoot ahead. I'll put this in as an RFC editor note for the= draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, >=20 > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20 > had a chat with Mike about how to address my comment for the assertion=20 > draft and Mike kindly provided his text proposal (see=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20 > have used his text as input and extended it a bit. Here is the updated=20 > text. >=20 > ---- >=20 > Operational Considerations and Interoperability Expectations >=20 > This specification defines a framework for using assertions with OAuth=20 > 2.0. However, as an abstract framework on its own, this specification=20 > is not sufficient to produce interoperable implementations. Two other=20 > specifications that instantiate this framework have been developed,=20 > one uses SAML 2.0-based assertions and is described in=20 > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two=20 > instantiations provide additional details about the assertion encoding=20 > and processing rules for those interested to implement and deploy=20 > assertions with OAuth 2.0. >=20 > However, even with these instance documents an interoperable=20 > implementation is not possible since for a specific deployment=20 > environment (within a trust framework or circle of trust, as it is=20 > sometimes called) agreements about acceptable values for various=20 > fields in the specification have to be agreed upon. For example, the=20 > audience field needs to be populated by the entity that generates the=20 > assertion with a specific value and that value may hold identifiers of=20 > different types (for example, a URL, an IP address, an FQDN) and the=20 > entity receiving and verifying the assertion must compare the value in=20 > the audience field with other information it may obtain from the=20 > request and/or with locally available information. Since the abstract=20 > framework nor the instance documents provide sufficient information=20 > about the syntax, the semantic and the comparison operation of the=20 > audience field additional profiling in further specifications is=20 > needed for an interoperable implementation. This additional profiling=20 > is not only needed for the audience field but also for other fields as we= ll. >=20 > This framework was designed with the expectation that additional=20 > specifications will fill this gap for deployment-specific environments. >=20 > ---- >=20 > You have the choice: >=20 > 1. take this as-is if you want the assertion draft=20 > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20 > no normative text in the writeup; it is rather a clarification. >=20 > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20 > the Feb 7 > telechat (if the discussion is done by Feb 1) >=20 > 1 or 2 needs to be chosen today. >=20 >=20 > Ciao > Hannes >=20 > PS: FYI - draft-ietf-oauth-saml2-bearer and=20 > draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. >=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 --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_ Content-Type: text/xml; name="draft-ietf-oauth-assertions-10.xml" Content-Description: draft-ietf-oauth-assertions-10.xml Content-Disposition: attachment; filename="draft-ietf-oauth-assertions-10.xml"; size=51692; creation-date="Fri, 18 Jan 2013 22:50:04 GMT"; modification-date="Fri, 18 Jan 2013 22:46:32 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPD94bWwtc3R5bGVzaGVl dCB0eXBlPSd0ZXh0L3hzbCcgaHJlZj0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcvYXV0aG9yaW5n L3JmYzI2MjkueHNsdCcgPz4KPCFET0NUWVBFIHJmYyBTWVNURU0gInJmYzI2MjkuZHRkIj4KICA8 P3JmYyBzdHJpY3Q9InllcyIgPz4KCiAgPD9yZmMgdG9jPSJ5ZXMiID8+CgogIDw/cmZjIHRvY2Rl cHRoPSIzIiA/PgoKICA8P3JmYyBzeW1yZWZzPSJ5ZXMiID8+CgogIDw/cmZjIHNvcnRyZWZzPSJ5 ZXMiPz4KCiAgPD9yZmMgY29tcGFjdD0ieWVzIiA/PgoKICA8P3JmYyBzdWJjb21wYWN0PSJubyIg Pz4KCiAgPD9yZmMgaXBybm90aWZpZWQ9InllcyIgPz4KCiAgICA8cmZjIGNhdGVnb3J5PSJzdGQi IGRvY05hbWU9ImRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xMCIgaXByPSJ0cnVzdDIwMDkw MiI+CgogICAgPCEtLSBjYXRlZ29yeSB2YWx1ZXM6IHN0ZCwgYmNwLCBpbmZvLCBleHAsIGFuZCBo aXN0b3JpYwppcHIgdmFsdWVzOiBmdWxsMzY2Nywgbm9Nb2RpZmljYXRpb24zNjY3LCBub0Rlcml2 YXRpdmVzMzY2Nwp5b3UgY2FuIGFkZCB0aGUgYXR0cmlidXRlcyB1cGRhdGVzPSJOTk5OIiBhbmQg b2Jzb2xldGVzPSJOTk5OIgp0aGV5IHdpbGwgYXV0b21hdGljYWxseSBiZSBvdXRwdXQgd2l0aCAi KGlmIGFwcHJvdmVkKSIgLS0+CgogIDxmcm9udD4KICAgIDx0aXRsZT5Bc3NlcnRpb24gRnJhbWV3 b3JrIGZvciBPQXV0aCAyLjA8L3RpdGxlPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9IkJyaWFuIENh bXBiZWxsIiBpbml0aWFscz0iQi4iIHN1cm5hbWU9IkNhbXBiZWxsIj4KICAgICAgPG9yZ2FuaXph dGlvbiBhYmJyZXY9IlBpbmciPlBpbmcgSWRlbnRpdHkgQ29ycC48L29yZ2FuaXphdGlvbj4KCiAg ICAgIDxhZGRyZXNzPgogICAgICAgIDxlbWFpbD5icmlhbi5kLmNhbXBiZWxsQGdtYWlsLmNvbTwv ZW1haWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5h bWU9IkNodWNrIE1vcnRpbW9yZSIgaW5pdGlhbHM9IkMuIiBzdXJuYW1lPSJNb3J0aW1vcmUiPgog ICAgICA8b3JnYW5pemF0aW9uIGFiYnJldj0iU2FsZXNmb3JjZSI+U2FsZXNmb3JjZS5jb208L29y Z2FuaXphdGlvbj4KCiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxlbWFpbD5jbW9ydGltb3JlQHNh bGVzZm9yY2UuY29tPC9lbWFpbD4KICAgICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAg PGF1dGhvciBmdWxsbmFtZT0iTWljaGFlbCBCLiBKb25lcyIgaW5pdGlhbHM9Ik0uQi4iIHN1cm5h bWU9IkpvbmVzIj4KICAgICAgPG9yZ2FuaXphdGlvbiBhYmJyZXY9Ik1pY3Jvc29mdCI+TWljcm9z b2Z0PC9vcmdhbml6YXRpb24+CgogICAgICA8YWRkcmVzcz4KICAgICAgICA8ZW1haWw+bWJqQG1p Y3Jvc29mdC5jb208L2VtYWlsPgogICAgICA8L2FkZHJlc3M+CiAgICA8L2F1dGhvcj4KCiAgICA8 YXV0aG9yIGZ1bGxuYW1lPSJZYXJvbiBZLiBHb2xhbmQiIGluaXRpYWxzPSJZLlkuIiBzdXJuYW1l PSJHb2xhbmQiPgogICAgICA8b3JnYW5pemF0aW9uIGFiYnJldj0iTWljcm9zb2Z0Ij5NaWNyb3Nv ZnQ8L29yZ2FuaXphdGlvbj4KCiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxlbWFpbD55YXJvbmdA bWljcm9zb2Z0LmNvbTwvZW1haWw+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAg IDxkYXRlIGRheT0iMTgiIG1vbnRoPSJKYW51YXJ5IiB5ZWFyPSIyMDEzIiAvPgoKCgkgICAgICAg IDwhLS0gTWV0YS1kYXRhIERlY2xhcmF0aW9ucyAtLT4KCgkgICAgICAgIDxhcmVhPlNlY3VyaXR5 PC9hcmVhPgoKICAgICAgICAgIDx3b3JrZ3JvdXA+T0F1dGggV29ya2luZyBHcm91cDwvd29ya2dy b3VwPgoJICAgICAgICAKCSAgICAgICAgPCEtLSBXRyBuYW1lIGF0IHRoZSB1cHBlcmxlZnQgY29y bmVyIG9mIHRoZSBkb2MsCglJRVRGIGlzIGZpbmUgZm9yIGluZGl2aWR1YWwgc3VibWlzc2lvbnMu CglJZiB0aGlzIGVsZW1lbnQgaXMgbm90IHByZXNlbnQsIHRoZSBkZWZhdWx0IGlzICJOZXR3b3Jr IFdvcmtpbmcgR3JvdXAiLAoJd2hpY2ggaXMgdXNlZCBieSB0aGUgUkZDIEVkaXRvciBhcyBhIG5v ZCB0byB0aGUgaGlzdG9yeSBvZiB0aGUgSUVURi4gLS0+CgoJICAgICAgICA8a2V5d29yZD5PQXV0 aDwva2V5d29yZD4KCSAgICAgICAgPGtleXdvcmQ+U0FNTDwva2V5d29yZD4KICAgICAgICAgIDxr ZXl3b3JkPkpXVDwva2V5d29yZD4KCSAgICAgICAgPGtleXdvcmQ+QXNzZXJ0aW9uPC9rZXl3b3Jk PgoKCgogICAgPGFic3RyYWN0PgogICAgICA8dD5UaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMg YSBmcmFtZXdvcmsgZm9yIHRoZSB1c2Ugb2YKICAgICAgYXNzZXJ0aW9ucyB3aXRoIE9BdXRoIDIu MCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGFu ZCBhIG5ldyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuCgkgICAgTWVjaGFuaXNtcyBhcmUgc3Bl Y2lmaWVkIGZvciB0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcKICAgICAgaW50ZXJhY3Rp b25zIHdpdGggYSB0b2tlbiBlbmRwb2ludCwgYXMgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3Npbmcg cnVsZXMuPC90PgoKCSAgICA8dD5UaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0 byBwcm92aWRlIGEgY29tbW9uIGZyYW1ld29yayBmb3IgT0F1dGggMi4wIHRvIGludGVyd29yayB3 aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucywgYW5kIHRvIHByb3Zp ZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuPC90PgoKICAg ICAgPHQ+Tm90ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMgYWJzdHJhY3Qg bWVzc2FnZSBmbG93cyBhbmQgcHJvY2Vzc2luZwoJICAgICAgcnVsZXMuICBJbiBvcmRlciB0byBi ZSBpbXBsZW1lbnRhYmxlLCBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2FyeSB0 byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5nCgkgICAgICBjb25jcmV0ZSBpbnN0YW50aWF0aW9u cy4KICAgICAgPC90PgogICAgPC9hYnN0cmFjdD4KICA8L2Zyb250PgoKICA8bWlkZGxlPgoKICA8 IS0tICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKiogLS0+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJvdmVydmlldyIg dGl0bGU9IkludHJvZHVjdGlvbiI+CiAgICAgIDx0Pk9BdXRoIDIuMCA8eHJlZiB0YXJnZXQ9IlJG QzY3NDkiLz4gaXMgYW4gYXV0aG9yaXphdGlvbiBmcmFtZXdvcmsgdGhhdCBlbmFibGVzIGEgdGhp cmQtcGFydHkKICAgICAgICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8g YSBwcm90ZWN0ZWQgSFRUUCByZXNvdXJjZS4gSW4gT0F1dGgsIHRob3NlIHRoaXJkLXBhcnR5CiAg ICAgICAgYXBwbGljYXRpb25zIGFyZSBjYWxsZWQgY2xpZW50czsgdGhleSBhY2Nlc3MgcHJvdGVj dGVkIHJlc291cmNlcyBieSBwcmVzZW50aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgSFRUUCBy ZXNvdXJjZS4KICAgICAgICBBY2Nlc3MgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gY2xpZW50cyBieSBh bgogICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggdGhlIChzb21ldGltZXMgaW1wbGlj aXQpIGFwcHJvdmFsIG9mIHRoZQogICAgICAgIHJlc291cmNlIG93bmVyLiBUaGVzZSBhY2Nlc3Mg dG9rZW5zIGFyZSB0eXBpY2FsbHkgb2J0YWluZWQgYnkKICAgICAgICBleGNoYW5naW5nIGFuIGF1 dGhvcml6YXRpb24gZ3JhbnQsIHdoaWNoIHJlcHJlc2VudHMgdGhlIGF1dGhvcml6YXRpb24gZ3Jh bnRlZCBieSB0aGUKICAgICAgICByZXNvdXJjZSBvd25lciAob3IgYnkgYSBwcml2aWxlZ2VkIGFk bWluaXN0cmF0b3IpLiBTZXZlcmFsIGF1dGhvcml6YXRpb24KICAgICAgICBncmFudCB0eXBlcyBh cmUgZGVmaW5lZCB0byBzdXBwb3J0IGEgd2lkZSByYW5nZSBvZiBjbGllbnQgdHlwZXMgYW5kCiAg ICAgICAgdXNlciBleHBlcmllbmNlcy4gT0F1dGggYWxzbyBwcm92aWRlcyBhbiBleHRlbnNpYmls aXR5IG1lY2hhbmlzbSBmb3IgZGVmaW5pbmcgYWRkaXRpb25hbAogICAgICAgIGdyYW50IHR5cGVz LCB3aGljaCBjYW4gc2VydmUgYXMgYSBicmlkZ2UgYmV0d2VlbiBPQXV0aCBhbmQgb3RoZXIgcHJv dG9jb2wgZnJhbWV3b3Jrcy4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBUaGlzIHNwZWNp ZmljYXRpb24gcHJvdmlkZXMgYSBnZW5lcmFsIGZyYW1ld29yayBmb3IgdGhlIHVzZSBvZgogICAg ICAgIGFzc2VydGlvbnMgYXMgYXV0aG9yaXphdGlvbiBncmFudHMgd2l0aCBPQXV0aCAyLjAuIEl0 IGFsc28gcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIGFzc2VydGlvbnMgdG8KICAgICAgICBiZSB1 c2VkIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uCiAgICAgICAgSXQgcHJvdmlkZXMgZ2VuZXJp YyBtZWNoYW5pc21zIGZvciB0cmFuc3BvcnRpbmcKICAgICAgICBhc3NlcnRpb25zIGR1cmluZyBp bnRlcmFjdGlvbnMgd2l0aCBhbiBhdXRob3JpemF0aW9uIHNlcnZlcidzIHRva2VuIGVuZHBvaW50 LCBhcyB3ZWxsIGFzIGdlbmVyYWwKICAgICAgICBydWxlcyBmb3IgdGhlIGNvbnRlbnQgYW5kIHBy b2Nlc3Npbmcgb2YgdGhvc2UgYXNzZXJ0aW9ucy4gVGhlIGludGVudAogICAgICAgIGlzIHRvIHBy b3ZpZGUgYW4gYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAob25l IHRoYXQgZG9lc24ndCBzZW5kIGNsaWVudCBzZWNyZXRzKSwKICAgICAgICBhcyB3ZWxsIGFzIHRv IGZhY2lsaXRhdGUgdGhlIHVzZSBvZiBPQXV0aAogICAgICAgIDIuMCBpbiBjbGllbnQtc2VydmVy IGludGVncmF0aW9uIHNjZW5hcmlvcywgd2hlcmUgdGhlIGVuZC11c2VyIG1heSBub3QgYmUgcHJl c2VudC4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gb25s eSBkZWZpbmVzIGFic3RyYWN0IG1lc3NhZ2UgZmxvd3MgYW5kIHByb2Nlc3NpbmcKCSAgICAgIHJ1 bGVzLiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50YWJsZSwgY29tcGFuaW9uIHNwZWNpZmljYXRp b25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZwoJICAgICAgY29u Y3JldGUgaW5zdGFudGlhdGlvbnMuCiAgICAgIEZvciBpbnN0YW5jZSwKICAgICAgU0FNTCAyLjAg QmVhcmVyIEFzc2VydGlvbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wCiAgICAgIDx4cmVmIHRhcmdl dD0iSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVyIi8+CiAgICAgIGRlZmluZXMgYSBjb25jcmV0 ZSBpbnN0YW50aWF0aW9uIGZvciBTQU1MIDIuMCB0b2tlbnMgYW5kIAogICAgICBKU09OIFdlYiBU b2tlbiAoSldUKSBCZWFyZXIgVG9rZW4gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMAogICAgICA8eHJl ZiB0YXJnZXQ9IkktRC5pZXRmLW9hdXRoLWp3dC1iZWFyZXIiLz4KICAgICAgZGVmaW5lcyBhIGNv bmNyZXRlIGluc3RhbnRpYXRpb24gZm9yIEpXVCB0b2tlbnMuCiAgICAgIDwvdD4KCiAgICAgIDx0 PgogICAgICAgIE5vdGU6IFRoZSB1c2Ugb2YgYXNzZXJ0aW9ucyBmb3IgY2xpZW50CiAgICAgICAg YXV0aGVudGljYXRpb24gaXMgb3J0aG9nb25hbCB0byBhbmQgc2VwYXJhYmxlIGZyb20gdXNpbmcg YXNzZXJ0aW9ucyBhcyBhbgogICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQuICBUaGV5IGNhbiBi ZSB1c2VkIGVpdGhlciBpbiBjb21iaW5hdGlvbiBvciBzZXBhcmF0ZWx5LgogICAgICAgIENsaWVu dCBhc3NlcnRpb24gYXV0aGVudGljYXRpb24gaXMgbm90aGluZyBtb3JlIHRoYW4gYW4gYWx0ZXJu YXRpdmUgd2F5IGZvciBhIGNsaWVudCB0byBhdXRoZW50aWNhdGUKICAgICAgICB0byB0aGUgdG9r ZW4gZW5kcG9pbnQgYW5kIG11c3QgYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHNvbWUgZ3Jh bnQgdHlwZSB0byBmb3JtIGEgY29tcGxldGUgYW5kCiAgICAgICAgbWVhbmluZ2Z1bCBwcm90b2Nv bCByZXF1ZXN0LiBBc3NlcnRpb24gYXV0aG9yaXphdGlvbiBncmFudHMgbWF5IGJlIHVzZWQgd2l0 aCBvciB3aXRob3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbgogICAgICAgIG9yIGlkZW50aWZpY2F0 aW9uLiBXaGV0aGVyIG9yIG5vdCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbmVlZGVkIGluIGNv bmp1bmN0aW9uIHdpdGggYW4gYXNzZXJ0aW9uIGF1dGhvcml6YXRpb24KICAgICAgICBncmFudCwg YXMgd2VsbCBhcyB0aGUgc3VwcG9ydGVkIHR5cGVzIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiwg YXJlIHBvbGljeSBkZWNpc2lvbnMgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLgogICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiBhbmNob3I9IkludGVyb3BlcmFi aWxpdHkiIHRpdGxlPSJJbnRlcm9wZXJhYmlsaXR5IENvbnNpZGVyYXRpb25zIj4KCTx0PgoJICBU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgdXNpbmcgYXNzZXJ0aW9u cwoJICB3aXRoIE9BdXRoIDIuMC4gIEhvd2V2ZXIsIGFzIGFuIGFic3RyYWN0IGZyYW1ld29yayBp biB3aGljaAoJICB0aGUgZGF0YSBmb3JtYXRzIHVzZWQgZm9yIHJlcHJlc2VudGluZyBtYW55IHZh bHVlcyBhcmUgbm90CgkgIGRlZmluZWQsIG9uIGl0cyBvd24sIHRoaXMgc3BlY2lmaWNhdGlvbiBp cyBub3Qgc3VmZmljaWVudCB0bwoJICBwcm9kdWNlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRp b25zLgoJPC90PgoJPHQ+CgkgIFR3byBvdGhlciBzcGVjaWZpY2F0aW9ucyB0aGF0IHByb2ZpbGUg dGhpcyBmcmFtZXdvcmsgZm9yCgkgIHNwZWNpZmljIGFzc2VydGlvbiBoYXZlIGJlZW4gZGV2ZWxv cGVkOgoJICBvbmUgPHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXIiLz4K CSAgdXNlcyBTQU1MIDIuMC1iYXNlZCBhc3NlcnRpb25zIGFuZAoJICB0aGUgb3RoZXIgPHhyZWYg dGFyZ2V0PSJJLUQuaWV0Zi1vYXV0aC1qd3QtYmVhcmVyIi8+CgkgIHVzZXMgSlNPTiBXZWIgVG9r ZW5zIChKV1RzKS4gIFRoZXNlIHR3byBpbnN0YW50aWF0aW9ucyBvZgoJICB0aGlzIGZyYW1ld29y ayBzcGVjaWZ5IGFkZGl0aW9uYWwgZGV0YWlscyBhYm91dCB0aGUKCSAgYXNzZXJ0aW9uIGVuY29k aW5nIGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGZvciB1c2luZyB0aG9zZQoJICBraW5kcyBvZiBhc3Nl cnRpb25zIHdpdGggT0F1dGggMi4wLgoJPC90PgoJPHQ+CgkgIEhvd2V2ZXIsIGV2ZW4gd2hlbiBw cm9maWxlZCBmb3Igc3BlY2lmaWMgYXNzZXJ0aW9uIHR5cGVzLAoJICBhZGRpdGlvbmFsIHByb2Zp bGluZyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpbGwgYmUgcmVxdWlyZWQKCSAgdG8gYWNoaWV2 ZSBmdWxsIGludGVyb3BlcmFiaWxpdHkuICBEZXBsb3ltZW50cyBmb3IKCSAgcGFydGljdWxhciB0 cnVzdCBmcmFtZXdvcmtzLCBjaXJjbGVzIG9mIHRydXN0LCBvciBvdGhlciB1c2VzCgkgIGNhc2Vz IHdpbGwgbmVlZCB0byBhZ3JlZSBhbW9uZyB0aGUgcGFydGljaXBhbnRzIG9uIHRoZSBraW5kcwoJ ICBvZiB2YWx1ZXMgdG8gYmUgdXNlZCBmb3Igc29tZSBhYnN0cmFjdCBmaWVsZHMgZGVmaW5lZCBi eQoJICB0aGlzIHNwZWNpZmljYXRpb24uICBGb3IgZXhhbXBsZSB0aGUgdmFsdWVzIG9mIElzc3Vl ciwKCSAgU3ViamVjdCwgYW5kIEF1ZGllbmNlIGZpZWxkcyBtaWdodCBiZSBVUkxzLCBVUklzLCBm dWxseQoJICBxdWFsaWZpZWQgZG9tYWluIG5hbWVzLCBPQXV0aCBjbGllbnQgSURzLCBJUCBhZGRy ZXNzZXMsIG9yCgkgIG90aGVyIHZhbHVlcywgZGVwZW5kaW5nIHVwb24gdGhlIHJlcXVpcmVtZW50 cyBvZiB0aGUKCSAgcGFydGljdWxhciB1c2UgY2FzZS4gIFRoZSB2ZXJpZmljYXRpb24gcnVsZXMg Zm9yIHNvbWUgdmFsdWVzCgkgIHdpbGwgYWxzbyBiZSB1c2UgY2FzZSBzcGVjaWZpYy4KCTwvdD4K CTx0PgoJICBUaGlzIGZyYW1ld29yayB3YXMgZGVzaWduZWQgd2l0aCB0aGUgY2xlYXIgZXhwZWN0 YXRpb24gdGhhdAoJICBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHdpbGwgZGVmaW5lIHByZXNj cmlwdGl2ZSBwcm9maWxlcwoJICBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBm dWxsIHdlYi1zY2FsZQoJICBpbnRlcm9wZXJhYmlsaXR5IGZvciBwYXJ0aWN1bGFyIHVzZSBjYXNl cy4KCTwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCgkgIDwhLS0gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKiAtLT4KCgkgIDxzZWN0aW9uIGFuY2hvcj0icm5jIiB0aXRsZT0iVGVybWlub2xv Z3kiPgogICAgICA8dD5UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgICAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYKICAgICAgdGFyZ2V0 PSJSRkMyMTE5Ii8+IC48L3Q+CgogICAgICA8dD5UaHJvdWdob3V0IHRoaXMgZG9jdW1lbnQsIHZh bHVlcyBhcmUgcXVvdGVkIHRvIGluZGljYXRlIHRoYXQgdGhleSBhcmUKICAgICAgdG8gYmUgdGFr ZW4gbGl0ZXJhbGx5LiBXaGVuIHVzaW5nIHRoZXNlIHZhbHVlcyBpbiBwcm90b2NvbCBtZXNzYWdl cywgdGhlICAgICAgICAgIAogICAgICBxdW90ZXMgbXVzdCBub3QgYmUgdXNlZCBhcyBwYXJ0IG9m IHRoZSB2YWx1ZS48L3Q+CiAgICA8L3NlY3Rpb24+CgoJPCEtLSAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIC0t PgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iZnJhbWV3b3JrIiB0aXRsZT0iRnJhbWV3b3JrIj4KCiA8 dD4KICAgIEFuIGFzc2VydGlvbiBpcyBhIHBhY2thZ2Ugb2YgaW5mb3JtYXRpb24gdGhhdCBhbGxv d3MKICAgIGlkZW50aXR5IGFuZCBzZWN1cml0eSBpbmZvcm1hdGlvbiB0byBiZSBzaGFyZWQgYWNy b3NzIHNlY3VyaXR5CiAgICBkb21haW5zLiBBbiBhc3NlcnRpb24gdHlwaWNhbGx5IGNvbnRhaW5z IGluZm9ybWF0aW9uIGFib3V0IGEgc3ViamVjdCBvciBwcmluY2lwYWwsCiAgICBpbmZvcm1hdGlv biBhYm91dCB0aGUgcGFydHkgdGhhdCBpc3N1ZWQgdGhlIGFzc2VydGlvbiBhbmQgd2hlbiB3YXMg aXQgaXNzdWVkLCBhcyB3ZWxsIGFzIHRoZSBjb25kaXRpb25zCiAgICB1bmRlciB3aGljaCB0aGUg YXNzZXJ0aW9uIGlzIHRvCiAgICBiZSBjb25zaWRlcmVkIHZhbGlkLCBzdWNoIGFzIHdoZW4gYW5k IHdoZXJlIGl0IGNhbiBiZSB1c2VkLiAKICA8L3Q+CiAgPHQ+CiAgICBUaGUgZW50aXR5IHRoYXQg Y3JlYXRlcyBhbmQgc2lnbnMgdGhlIGFzc2VydGlvbiBpcyB0eXBpY2FsbHkga25vd24gYXMgdGhl ICJJc3N1ZXIiIGFuZCB0aGUgZW50aXR5IHRoYXQKICAgIGNvbnN1bWVzIHRoZSBhc3NlcnRpb24g YW5kIHJlbGllcyBvbiBpdHMgaW5mb3JtYXRpb24gaXMgdHlwaWNhbGx5IGtub3duIGFzIHRoZSAi UmVseWluZyBQYXJ0eSIuICBJbiB0aGUgY29udGV4dCBvZgogICAgdGhpcyBkb2N1bWVudCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFjdHMgYXMgYSByZWx5aW5nIHBhcnR5LgogIDwvdD4KICA8 dD4KICAgIEFzc2VydGlvbnMgdXNlZCBpbiB0aGUgcHJvdG9jb2wgZXhjaGFuZ2VzIGRlZmluZWQg YnkgdGhpcyBzcGVjaWZpY2F0aW9uCiAgICBNVVNUIGFsd2F5cyBiZSBwcm90ZWN0ZWQgYWdhaW5z dCB0YW1wZXJpbmcKICAgIHVzaW5nIGEgZGlnaXRhbCBzaWduYXR1cmUgb3IgYSBrZXllZCBtZXNz YWdlIGRpZ2VzdCBhcHBsaWVkIGJ5IHRoZSBpc3N1ZXIuCiAgICBBbiBhc3NlcnRpb24gTUFZIGFk ZGl0aW9uYWxseSBiZSBlbmNyeXB0ZWQsIHByZXZlbnRpbmcgdW5hdXRob3JpemVkIHBhcnRpZXMK ICAgIGZyb20gaW5zcGVjdGluZyB0aGUgY29udGVudC4KICA8L3Q+CgogIDx0PgogICAgQWx0aG91 Z2ggdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgdGhlIHByb2Nlc3NlcyBieSB3aGljaCB0 aGUgY2xpZW50CiAgICBvYnRhaW5zIHRoZSBhc3NlcnRpb24gKHByaW9yIHRvIHNlbmRpbmcgaXQg dG8gdGhlIGF1dGhvcml6YXRpb24KICAgIHNlcnZlciksIHRoZXJlIGFyZSB0d28gY29tbW9uIHBh dHRlcm5zIGRlc2NyaWJlZCBiZWxvdy4KICA8L3Q+CiAgPHQ+CiAgICBJbiB0aGUgZmlyc3QgcGF0 dGVybiwKICAgIGRlcGljdGVkIGluIDx4cmVmIHRhcmdldD0idGhpcmQtcGFydHktY3JlYXRlZCIv PiwgdGhlIGNsaWVudCBvYnRhaW5zCiAgICBhbiBhc3NlcnRpb24gZnJvbSBhIHRoaXJkIHBhcnR5 IGVudGl0eSBjYXBhYmxlIG9mIGlzc3VpbmcsIHJlbmV3aW5nLCB0cmFuc2Zvcm1pbmcsIGFuZCB2 YWxpZGF0aW5nIHNlY3VyaXR5IHRva2Vucy4KICAgIFR5cGljYWxseSBzdWNoIGFuIGVudGl0eSBp cyBrbm93biBhcyBhICJTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIiAoU1RTKSBvciBqdXN0ICJUb2tl biBTZXJ2aWNlIiBhbmQKICAgIGEgdHJ1c3QgcmVsYXRpb25zaGlwICh1c3VhbGx5IG1hbmlmZXN0 ZWQgaW4gdGhlIGV4Y2hhbmdlIG9mIHNvbWUga2luZCBvZiBrZXkgbWF0ZXJpYWwpCiAgICBleGlz dHMgYmV0d2VlbiB0aGUgdG9rZW4gc2VydmljZSBhbmQgdGhlIHJlbHlpbmcgcGFydHkuCiAgICBU aGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlcjsgaXRzIHJvbGUgaXMgdG8g ZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQgdmFyaW91cyBjcmVk ZW50aWFscywgYW5kCiAgICBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVzdGVkLCBmaWxsIHRoZW0g d2l0aCBhcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4KICAgIDx4cmVmIHRh cmdldD0iT0FTSVMuV1MtVHJ1c3QiPldTLVRydXN0PC94cmVmPiBpcyBvbmUgYXZhaWxhYmxlIHN0 YW5kYXJkIGZvciByZXF1ZXN0aW5nIHNlY3VyaXR5IHRva2VucyAoYXNzZXJ0aW9ucykuCiAgPC90 PgogICAgPHQ+CgkgPGZpZ3VyZSBhbmNob3I9InRoaXJkLXBhcnR5LWNyZWF0ZWQiIHRpdGxlPSJU aGlyZCBQYXJ0eSBDcmVhdGVkIEFzc2VydGlvbiI+CiAgICAgICAgICA8YXJ0d29yaz48IVtDREFU QVsKICBSZWx5aW5nCiAgUGFydHkgICAgICAgICAgICAgICAgICAgICBDbGllbnQgICAgICAgICAg ICAgICAgICAgVG9rZW4gU2VydmljZQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAxKSBSZXF1ZXN0IEFzc2VydGlvbiAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAyKSBBc3NlcnRpb24gICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgfCAgICAzKSBBc3NlcnRpb24g ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICA0KSBPSyBv ciBGYWlsdXJlICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8Cl1dPjwvYXJ0 d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KCQk8L3Q+CgoKICA8dD4KICAgIEluIHRoZSBzZWNvbmQg cGF0dGVybiwgZGVwaWN0ZWQgaW4gIDx4cmVmIHRhcmdldD0ic2VsZi1pc3N1ZWQiLz4sIHRoZSBj bGllbnQgY3JlYXRlcyBhc3NlcnRpb25zCiAgICBsb2NhbGx5LiAgVG8gc2lnbiB0aGUgYXNzZXJ0 aW9ucywgaXQgaGFzIHRvIG9idGFpbiBrZXkgbWF0ZXJpYWw6CiAgICBlaXRoZXIgc3ltbWV0cmlj IGtleXMgb3IgYXN5bW1ldHJpYyBrZXkgcGFpcnMuCiAgICBUaGUgbWVjaGFuaXNtcyBmb3Igb2J0 YWluaW5nIHRoaXMga2V5IG1hdGVyaWFsIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4KICA8L3Q+CiAgPHQ+CiAgICBBbHRob3VnaCBhc3NlcnRpb25zIGFyZSB1c3Vh bGx5IHVzZWQgdG8gY29udmV5IGlkZW50aXR5IGFuZCBzZWN1cml0eSBpbmZvcm1hdGlvbiwKICAg IHNlbGYtaXNzdWVkIGFzc2VydGlvbnMgY2FuIGFsc28gc2VydmUgYSBkaWZmZXJlbnQgcHVycG9z ZS4gVGhleSBjYW4gYmUgdXNlZCB0byBkZW1vbnN0cmF0ZSBrbm93bGVkZ2Ugb2Ygc29tZSBzZWNy ZXQsIHN1Y2ggYXMgYSBjbGllbnQgc2VjcmV0LCB3aXRob3V0IGFjdHVhbGx5CiAgICBjb21tdW5p Y2F0aW5nIHRoZSBzZWNyZXQgZGlyZWN0bHkgaW4gdGhlIHRyYW5zYWN0aW9uLiBJbiB0aGF0IGNh c2UsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4gdGhlCiAgICBhc3NlcnRpb24g YnkgdGhlIGNsaWVudCBpdHNlbGYgd2lsbCBiZSBvZiBsaW1pdGVkIHZhbHVlIHRvIHRoZSByZWx5 aW5nIHBhcnR5CiAgICBhbmQsIGZvciB0aGlzIHJlYXNvbiwgb25seSBhIGJhcmUgbWluaW11bSBv ZiBpbmZvcm1hdGlvbiBpcyB0eXBpY2FsbHkgaW5jbHVkZWQgaW4gc3VjaCBhbiBhc3NlcnRpb24s IHN1Y2ggYXMgaW5mb3JtYXRpb24gYWJvdXQgaXNzdWluZyBhbmQgdXNhZ2UgY29uZGl0aW9ucy48 L3Q+CiAgPHQ+CgkgPGZpZ3VyZSBhbmNob3I9InNlbGYtaXNzdWVkIiB0aXRsZT0iU2VsZi1Jc3N1 ZWQgQXNzZXJ0aW9uIj4KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRBWwogIFJlbHlpbmcKICBQ YXJ0eSAgICAgICAgICAgICAgICAgICAgIENsaWVudAogICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAxKSBDcmVhdGUKICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgQXNzZXJ0aW9uCiAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8IDIp IEFzc2VydGlvbiB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0t LS0rCiAgICB8ICAgIDMpIEFzc2VydGlvbiAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS18CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgIDQp IE9LIG9yIEZhaWx1cmUgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICB8Cl1dPjwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KCQk8L3Q+CgoJPHQ+RGVwbG95 bWVudHMgbmVlZCB0bwogICAgZGV0ZXJtaW5lIHRoZSBhcHByb3ByaWF0ZSB2YXJpYW50IHRvIHVz ZSBiYXNlZCBvbiB0aGUgcmVxdWlyZWQgbGV2ZWwgb2Ygc2VjdXJpdHksIHRoZSB0cnVzdCByZWxh dGlvbnNoaXAgYmV0d2VlbiB0aGUgZW50aXRpZXMsIGFuZCBvdGhlciBmYWN0b3JzLgogIDwvdD4K CiAgPHQ+CiAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB3aGF0IG11c3QgYmUgZG9uZSBieSB0 aGUgZW50aXR5IHByZXNlbnRpbmcgdGhlIGFzc2VydGlvbiwgdGhlcmUgYXJlIHR3byBnZW5lcmFs IHR5cGVzIG9mIGFzc2VydGlvbnM6CiAgICA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICA8dD5C ZWFyZXIgQXNzZXJ0aW9uczogIEFueSBlbnRpdHkgaW4KICAgICAgIHBvc3Nlc3Npb24gb2YgYSBi ZWFyZXIgYXNzZXJ0aW9uIChlLmcuIHRoZSBiZWFyZXIpIGNhbiB1c2UgaXQgdG8gZ2V0IGFjY2Vz cyB0bwogICAgICAgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzICh3aXRob3V0IGRlbW9uc3RyYXRp bmcgcG9zc2Vzc2lvbiBvZiBhCiAgICAgICBjcnlwdG9ncmFwaGljIGtleSkuICBUbyBwcmV2ZW50 IG1pc3VzZSwgYmVhcmVyIGFzc2VydGlvbnMgbmVlZCB0byBiZQogICAgICAgcHJvdGVjdGVkIGZy b20gZGlzY2xvc3VyZSBpbiBzdG9yYWdlIGFuZCBpbiB0cmFuc3BvcnQuIEEgc2VjdXJlIGNvbW11 bmljYXRpb24gY2hhbm5lbCBpcyByZXF1aXJlZAogICAgICAgIGJldHdlZW4gYWxsIGVudGl0aWVz IHRvIGF2b2lkIGxlYWtpbmcgdGhlIGFzc2VydGlvbiB0byB1bmF1dGhvcml6ZWQgcGFydGllcy48 L3Q+CgogICAgPHQ+SG9sZGVyLW9mLUtleSBBc3NlcnRpb25zOgogICAgICBUbyBhY2Nlc3MgdGhl IGFzc29jaWF0ZWQgcmVzb3VyY2VzLCB0aGUgZW50aXR5IHByZXNlbnRpbmcgdGhlIGFzc2VydGlv biBtdXN0IGRlbW9uc3RyYXRlIHBvc3Nlc3Npb24gb2YgYWRkaXRpb25hbCBjcnlwdG9ncmFwaGlj IG1hdGVyaWFsLgogICAgICBUaGUgdG9rZW4gc2VydmljZSB0aGVyZWJ5IGJpbmRzIGEga2V5IGlk ZW50aWZpZXIgdG8gdGhlIGFzc2VydGlvbgogICAgICBhbmQgdGhlIGNsaWVudCBoYXMgdG8gZGVt b25zdHJhdGUgdG8gdGhlIHJlbHlpbmcgcGFydHkgdGhhdCBpdCBrbm93cyB0aGUga2V5IGNvcnJl c3BvbmRpbmcgdG8gdGhhdAogICAgICBpZGVudGlmaWVyIHdoZW4gcHJlc2VudGluZyB0aGUgYXNz ZXJ0aW9uLiBUaGlzIG1lY2hhbmlzbSBwcm92aWRlcyBhZGRpdGlvbmFsIHNlY3VyaXR5IHByb3Bl cnRpZXMuPC90PgogICAgPC9saXN0PgoKICAgIFRoZSBwcm90b2NvbCBwYXJhbWV0ZXJzIGFuZCBw cm9jZXNzaW5nIHJ1bGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgaW50ZW5kZWQgdG8g c3VwcG9ydAogICAgYSBjbGllbnQgcHJlc2VudGluZyBhIGJlYXJlciBhc3NlcnRpb24gdG8gYW4g YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB1c2Ugb2YgaG9sZGVyLW9mLWtleSBhc3NlcnRpb25z IGFyZSBub3QgcHJlY2x1ZGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGJ1dAogICAgYWRkaXRpb25hbCBw cm90b2NvbCBkZXRhaWxzIHdvdWxkIG5lZWQgdG8gYmUgc3BlY2lmaWVkLgogIDwvdD4KCgk8L3Nl Y3Rpb24+CgoJPCEtLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIC0tPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJU cmFuc3BvcnRpbmcgQXNzZXJ0aW9ucyIgYW5jaG9yPSJ0cmFuc3BvcnRpbmciPgogICAgICA8dD4K ICAgICAgICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBIVFRQIHBhcmFtZXRlcnMgZm9yIHRyYW5zcG9y dGluZwogICAgICAgIGFzc2VydGlvbnMgZHVyaW5nIGludGVyYWN0aW9ucyB3aXRoIGEgdG9rZW4g ZW5kcG9pbnQgb2YgYW4gT0F1dGggYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgQmVjYXVz ZSByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgcmVzdWx0IGluIHRoZSB0cmFuc21pc3Np b24gb2YKICAgICAgICBjbGVhci10ZXh0IGNyZWRlbnRpYWxzIChpbiBib3RoIHRoZSBIVFRQIHJl cXVlc3QgYW5kIHJlc3BvbnNlKSwgYWxsIHJlcXVlc3RzIHRvIHRoZQogICAgICAgIHRva2VuIGVu ZHBvaW50IE1VU1QgdXNlIFRMUywgYXMgbWFuZGF0ZWQgaW4gU2VjdGlvbiAzLjIgb2YgPHhyZWYg dGFyZ2V0PSJSRkM2NzQ5Ij5PQXV0aCAyLjA8L3hyZWY+LgoJICA8L3Q+CgoKCgkgICAgICAgIDxz ZWN0aW9uIHRpdGxlPSJVc2luZyBBc3NlcnRpb25zIGFzIEF1dGhvcml6YXRpb24gR3JhbnRzIiBh bmNob3I9ImF1dGhncmFudHMiPgoKICAgICAgICA8dD5UaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUg dXNlIG9mIGFzc2VydGlvbnMgYXMgYXV0aG9yaXphdGlvbiBncmFudHMsCiAgICAgICAgYmFzZWQg b24gdGhlIGRlZmluaXRpb24gcHJvdmlkZWQgaW4gU2VjdGlvbiA0LjUgb2YgPHhyZWYgdGFyZ2V0 PSJSRkM2NzQ5Ij5PQXV0aCAyLjA8L3hyZWY+LgoJCSAgICBXaGVuIHVzaW5nIGFzc2VydGlvbnMg YXMgYXV0aG9yaXphdGlvbiBncmFudHMsIHRoZSBjbGllbnQKICAgICAgICBpbmNsdWRlcyB0aGUg YXNzZXJ0aW9uIGFuZCByZWxhdGVkIGluZm9ybWF0aW9uIHVzaW5nIHRoZSBmb2xsb3dpbmcgSFRU UCByZXF1ZXN0CiAgICAgICAgcGFyYW1ldGVyczo8L3Q+CgogICAgICAgIDx0PjxsaXN0IHN0eWxl PSJoYW5naW5nIj4KCiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJncmFudF90eXBlIj5SRVFVSVJF RC4gVGhlIGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzCiAgICAgICAgICAgIGRlZmluZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZQog ICAgICAgICAgICBVUkkuPC90PgoKICAgICAgICAgICAgPHQgaGFuZ1RleHQ9ImFzc2VydGlvbiI+ UkVRVUlSRUQuIFRoZSBhc3NlcnRpb24gYmVpbmcgdXNlZCBhcyBhbgogICAgICAgICAgICBhdXRo b3JpemF0aW9uIGdyYW50LiBTcGVjaWZpYyBzZXJpYWxpemF0aW9uIG9mIHRoZSBhc3NlcnRpb24g aXMKICAgICAgICAgICAgZGVmaW5lZCBieSBwcm9maWxlIGRvY3VtZW50cy4gVGhlIHNlcmlhbGl6 YXRpb24gTVVTVCBiZSBlbmNvZGVkCiAgICAgICAgICAgIGZvciB0cmFuc3BvcnQgd2l0aGluIEhU VFAgZm9ybXMuIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYmFzZTY0dXJsCiAgICAgICAgICAgIGJl IHVzZWQuPC90PgoKICAgICAgICAgICAgPHQgaGFuZ1RleHQ9InNjb3BlIj5PUFRJT05BTC4gVGhl IHJlcXVlc3RlZCBzY29wZSBhcwogICAgICAgICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMg b2YgPHhyZWYgdGFyZ2V0PSJSRkM2NzQ5Ij5PQXV0aAogICAgICAgICAgICAyLjA8L3hyZWY+LiBX aGVuCiAgICAgICAgICAgIGV4Y2hhbmdpbmcgYXNzZXJ0aW9ucyBmb3IgYWNjZXNzIHRva2Vucywg dGhlIGF1dGhvcml6YXRpb24gZm9yIHRoZQogICAgICAgICAgICB0b2tlbiBoYXMgYmVlbiBwcmV2 aW91c2x5IGdyYW50ZWQgdGhyb3VnaCBzb21lIG91dC1vZi1iYW5kIG1lY2hhbmlzbS4gQXMKICAg ICAgICAgICAgc3VjaCwgdGhlIHJlcXVlc3RlZCBzY29wZSBNVVNUIGJlIGVxdWFsIG9yIGxlc3Nl ciB0aGFuIHRoZSBzY29wZQogICAgICAgICAgICBvcmlnaW5hbGx5IGdyYW50ZWQgdG8gdGhlIGF1 dGhvcml6ZWQgYWNjZXNzb3IuIElmIHRoZSBzY29wZQogICAgICAgICAgICBwYXJhbWV0ZXIgYW5k L29yIHZhbHVlIGFyZSBvbWl0dGVkLCB0aGUgc2NvcGUgTVVTVCBiZSB0cmVhdGVkIGFzCiAgICAg ICAgICAgIGVxdWFsIHRvIHRoZSBzY29wZSBvcmlnaW5hbGx5IGdyYW50ZWQgdG8gdGhlIGF1dGhv cml6ZWQgYWNjZXNzb3IuCiAgICAgICAgICAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNU IGxpbWl0IHRoZSBzY29wZSBvZiB0aGUgaXNzdWVkCiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiB0 byBiZSBlcXVhbCBvciBsZXNzZXIgdGhhbiB0aGUgc2NvcGUgb3JpZ2luYWxseQogICAgICAgICAg ICBncmFudGVkIHRvIHRoZSBhdXRob3JpemVkIGFjY2Vzc29yLjwvdD4KICAgICAgICAgIDwvbGlz dD48L3Q+CgogICAgICAgIDx0PlRoZSBmb2xsb3dpbmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRl bW9uc3RyYXRlcyBhbiBhc3NlcnRpb24gYmVpbmcKICAgICAgICB1c2VkIGFzIGFuIGF1dGhvcml6 YXRpb24gZ3JhbnQKCSh3aXRoIGV4dHJhIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5IHB1cnBvc2Vz IG9ubHkpOjwvdD4KCiAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRB WwogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29u dGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQKCiAgY2xpZW50X2lk PXM2QmhkUmtxdDMmCiAgZ3JhbnRfdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGglM0Fn cmFudC10eXBlJTNBc2FtbDItYmVhcmVyJgogIGFzc2VydGlvbj1QSE5oYld4d09sLi4uW29taXR0 ZWQgZm9yIGJyZXZpdHldLi4uWlQ0Cl1dPjwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KCiAg ICAgICAgPHQ+QW4gYXNzZXJ0aW9uIHVzZWQgaW4gdGhpcyBjb250ZXh0IGlzIGdlbmVyYWxseSBh IHNob3J0IGxpdmVkIHJlcHJlc2VudGF0aW9uCiAgICAgICAgICBvZiB0aGUgYXV0aG9yaXphdGlv biBncmFudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIFNIT1VMRCBOT1QgaXNzdWUgYWNjZXNz IHRva2VucyB3aXRoIGEgbGlmZXRpbWUKICAgICAgICAgIHRoYXQgZXhjZWVkcyB0aGUgdmFsaWRp dHkgcGVyaW9kIG9mIHRoZSBhc3NlcnRpb24gYnkgYSBzaWduaWZpY2FudCBwZXJpb2QuIEluIHBy YWN0aWNlLCB0aGF0IHdpbGwKICAgICAgICAgIHVzdWFsbHkgbWVhbiB0aGF0IHJlZnJlc2ggdG9r ZW5zIGFyZSBub3QgaXNzdWVkIGluIHJlc3BvbnNlIHRvIGFzc2VydGlvbgogICAgICAgICAgZ3Jh bnQgcmVxdWVzdHMgYW5kIGFjY2VzcyB0b2tlbnMgd2lsbCBiZSBpc3N1ZWQgd2l0aCBhIHJlYXNv bmFibHkgc2hvcnQgbGlmZXRpbWUuCiAgICAgICAgICBDbGllbnRzIGNhbiByZWZyZXNoIGFuIGV4 cGlyZWQgYWNjZXNzIHRva2VuIGJ5IHJlcXVlc3RpbmcgYSBuZXcgb25lIHVzaW5nIHRoZSBzYW1l CiAgICAgICAgICBhc3NlcnRpb24sIGlmIGl0IGlzIHN0aWxsIHZhbGlkLCBvciB3aXRoIGEgbmV3 IGFzc2VydGlvbi4KICAgICAgICA8L3Q+CgogICAgICAgIDx0PkFuIElFRlQgVVJOIGZvciB1c2Ug YXMgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Z3JhbnRfdHlwZTwvc3Bhbng+IHZhbHVlIGNhbiBi ZSByZXF1ZXN0ZWQKICAgICAgICAgIHVzaW5nIHRoZSB0ZW1wbGF0ZSBpbiA8eHJlZiB0YXJnZXQ9 IlJGQzY3NTUiPkFuIElFVEYgVVJOIFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoPC94cmVmPi4KICAg ICAgICAgIEEgVVJOIG9mIHRoZSBmb3JtIHVybjppZXRmOnBhcmFtczpvYXV0aDpncmFudF90eXBl OiogaXMgc3VnZ2VzdGVkLgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IkVy cm9yIFJlc3BvbnNlcyI+CiAgICAgICAgICAgIDx0PklmIGFuIGFzc2VydGlvbiBpcyBub3QgdmFs aWQgb3IgaGFzIGV4cGlyZWQsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcgogICAgICAgICAgTVVT VCBjb25zdHJ1Y3QgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVmaW5lZCBpbiA8eHJlZgogICAgICAg ICAgdGFyZ2V0PSJSRkM2NzQ5Ij5PQXV0aCAyLjA8L3hyZWY+LiBUaGUgdmFsdWUgb2YgdGhlIDxz cGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PgogICAgICAgICAgcGFyYW1ldGVyIE1VU1Qg YmUgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+aW52YWxpZF9ncmFudDwvc3Bhbng+IGVycm9yIGNv ZGUuIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBzZXJ2ZXIgTUFZIGluY2x1ZGUgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIHJlYXNvbnMgdGhlCiAgICAgICAgICBhc3Nl cnRpb24gd2FzIGNvbnNpZGVyZWQgaW52YWxpZCB1c2luZyB0aGUgPHNwYW54IHN0eWxlPSd2ZXJi Jz5lcnJvcl9kZXNjcmlwdGlvbjwvc3Bhbng+IG9yCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3Zl cmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcnMuPC90PgoKCiAgICAgIDx0PkZvciBleGFt cGxlOjwvdD4KCiAgICAgIDxmaWd1cmU+CiAgICAgICAgPGFydHdvcms+PCFbQ0RBVEFbCiAgSFRU UC8xLjEgNDAwIEJhZCBSZXF1ZXN0CiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAg Q2FjaGUtQ29udHJvbDogbm8tc3RvcmUKCiAgewogICAgImVycm9yIjoiaW52YWxpZF9ncmFudCIs CiAgICAiZXJyb3JfZGVzY3JpcHRpb24iOiJBdWRpZW5jZSB2YWxpZGF0aW9uIGZhaWxlZCIKICB9 Cl1dPjwvYXJ0d29yaz4KICAgICAgPC9maWd1cmU+CgogICAgICAgICAgICAgPC9zZWN0aW9uPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iVXNpbmcgQXNzZXJ0aW9ucyBm b3IgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIiBhbmNob3I9ImNsaWVudGF1dGgiPgoKCiAgICAgICAg PHQ+VGhlIGZvbGxvd2luZyBzZWN0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiBhc3NlcnRpb25zIGFz IGNsaWVudAogICAgICAgIGNyZWRlbnRpYWxzIGFzIGFuIGV4dGVuc2lvbiBvZiBTZWN0aW9uIDIu MyBvZiA8eHJlZgogICAgICAgIHRhcmdldD0iUkZDNjc0OSI+T0F1dGggMi4wPC94cmVmPi4gV2hl biB1c2luZwogICAgICAgIGFzc2VydGlvbnMgYXMgY2xpZW50IGNyZWRlbnRpYWxzLCB0aGUgY2xp ZW50IGluY2x1ZGVzIHRoZSBhc3NlcnRpb24KICAgICAgICBhbmQgcmVsYXRlZCBpbmZvcm1hdGlv biB1c2luZyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCBwYXJhbWV0ZXJzOjwvdD4KCiAgICAg ICAgPHQ+PGxpc3Qgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iY2xp ZW50X2lkIj5PUFRJT05BTC4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGFzCiAgICAgICAgICAgIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDIuMiBvZiA8eHJlZiB0YXJnZXQ9IlJGQzY3NDkiPk9BdXRoCiAg ICAgICAgICAgIDIuMDwveHJlZj4uIFdoZW4gcHJlc2VudCwgdGhlIDxzcGFueCBzdHlsZT0ndmVy Yic+Y2xpZW50X2lkPC9zcGFueD4gTVVTVCBpZGVudGlmeSB0aGUgY2xpZW50IHRvIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci48L3Q+CgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iY2xpZW50X2Fz c2VydGlvbl90eXBlIj5SRVFVSVJFRC4gVGhlIGZvcm1hdCBvZiB0aGUKICAgICAgICAgICAgYXNz ZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUg TVVTVAogICAgICAgICAgICBiZSBhbiBhYnNvbHV0ZSBVUkkuIDwvdD4KCiAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSJjbGllbnRfYXNzZXJ0aW9uIj5SRVFVSVJFRC4gVGhlIGFzc2VydGlvbiBiZWlu ZyB1c2VkCiAgICAgICAgICAgIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LiBTcGVjaWZpYyBz ZXJpYWxpemF0aW9uIG9mIHRoZQogICAgICAgICAgICBhc3NlcnRpb24gaXMgZGVmaW5lZCBieSBw cm9maWxlIGRvY3VtZW50cy4gVGhlIHNlcmlhbGl6YXRpb24gTVVTVAogICAgICAgICAgICBiZSBl bmNvZGVkIGZvciB0cmFuc3BvcnQgd2l0aGluIEhUVFAgZm9ybXMuIEl0IGlzIFJFQ09NTUVOREVE IHRoYXQKICAgICAgICAgICAgYmFzZTY0dXJsIGJlIHVzZWQuPC90PgogICAgICAgICAgPC9saXN0 PjwvdD4KCiAgICAgICAgPHQ+VGhlIGZvbGxvd2luZyBub24tbm9ybWF0aXZlIGV4YW1wbGUgZGVt b25zdHJhdGVzIGEgY2xpZW50CiAgICAgICAgYXV0aGVudGljYXRpbmcgdXNpbmcgYW4gYXNzZXJ0 aW9uIGR1cmluZyBhbgoJQWNjZXNzIFRva2VuIFJlcXVlc3QsIGFzIGRlZmluZWQgaW4gU2VjdGlv biA0LjEuMyBvZgoJPHhyZWYgdGFyZ2V0PSJSRkM2NzQ5Ij5PQXV0aCAyLjA8L3hyZWY+Cgkod2l0 aCBleHRyYSBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KTo8L3Q+CgogICAg ICAgIDxmaWd1cmU+CiAgICAgICAgICA8YXJ0d29yaz48IVtDREFUQVsKICBQT1NUIC90b2tlbiBI VFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkCgogIGdyYW50X3R5cGU9YXV0aG9yaXphdGlvbl9j b2RlJgogIGNvZGU9aTFXc1JuMXVCMSYKICBjbGllbnRfaWQ9czZCaGRSa3F0MyYKICBjbGllbnRf YXNzZXJ0aW9uX3R5cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoCiAgJTNBY2xpZW50LWFz c2VydGlvbi10eXBlJTNBc2FtbDItYmVhcmVyJgogIGNsaWVudF9hc3NlcnRpb249UEhOaGJXLi4u W29taXR0ZWQgZm9yIGJyZXZpdHldLi4uWlQKXV0+PC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJl PgoKICAgICAgICA8dD5Ub2tlbiBlbmRwb2ludHMgY2FuIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBh c3NlcnRpb24gYmFzZWQKICAgICAgY3JlZGVudGlhbHMgYW5kIG90aGVyIGNsaWVudCBjcmVkZW50 aWFsIHR5cGVzIGJ5IGxvb2tpbmcgZm9yIHRoZQogICAgICBwcmVzZW5jZSBvZiB0aGUgPHNwYW54 IHN0eWxlPSd2ZXJiJz5jbGllbnRfYXNzZXJ0aW9uPC9zcGFueD4gYW5kCiAgICAgIDxzcGFueCBz dHlsZT0ndmVyYic+Y2xpZW50X2Fzc2VydGlvbl90eXBlPC9zcGFueD4gcGFyYW1ldGVycywKICAg ICAgd2hpY2ggd2lsbCBvbmx5IGJlIHByZXNlbnQgd2hlbiB1c2luZyBhc3NlcnRpb25zIGZvciBj bGllbnQKICAgICAgYXV0aGVudGljYXRpb24uPC90PgoKICAgICAgPHQ+QW4gSUVGVCBVUk4gZm9y IHVzZSBhcyB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5jbGllbnRfYXNzZXJ0aW9uX3R5cGU8L3Nw YW54PiB2YWx1ZSBtYXkgYmUgcmVxdWVzdGVkCiAgICAgICAgdXNpbmcgdGhlIHRlbXBsYXRlIGlu IDx4cmVmIHRhcmdldD0iUkZDNjc1NSI+QW4gSUVURiBVUk4gU3ViLU5hbWVzcGFjZSBmb3IgT0F1 dGg8L3hyZWY+LgogICAgICAgIEEgVVJOIG9mIHRoZSBmb3JtIHVybjppZXRmOnBhcmFtczpvYXV0 aDpjbGllbnQtYXNzZXJ0aW9uLXR5cGU6KiBpcyBzdWdnZXN0ZWQuCiAgICAgIDwvdD4KCiAgICAg ICA8c2VjdGlvbiB0aXRsZT0iRXJyb3IgUmVzcG9uc2VzIj4KCiAgICAgIDx0PklmIGFuIGFzc2Vy dGlvbiBpcyBpbnZhbGlkIGZvciBhbnkgcmVhc29uIG9yIGlmIG1vcmUgdGhhbiBvbmUgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgQXV0aG9yaXphdGlvbgogICAg ICBTZXJ2ZXIgTVVTVCBjb25zdHJ1Y3QgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVmaW5lZCBpbiA8 eHJlZgogICAgICB0YXJnZXQ9IlJGQzY3NDkiPk9BdXRoIDIuMDwveHJlZj4uIFRoZSB2YWx1ZSBv ZiB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwvc3Bhbng+CiAgICAgIHBhcmFtZXRlciBN VVNUIGJlIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmludmFsaWRfY2xpZW50PC9zcGFueD4gZXJy b3IgY29kZS4gVGhlCiAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBpbmNsdWRlIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZQogICAgICByZWFzb25zIHRoZSBjbGllbnQg YXNzZXJ0aW9uIHdhcyBjb25zaWRlcmVkIGludmFsaWQgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0n dmVyYic+ZXJyb3JfZGVzY3JpcHRpb248L3NwYW54PgogICAgICBvciA8c3Bhbnggc3R5bGU9J3Zl cmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcnMuPC90PgoKICAgICAgPHQ+Rm9yIGV4YW1w bGU6PC90PgoKICAgICAgPGZpZ3VyZT4KICAgICAgICA8YXJ0d29yaz48IVtDREFUQVsKICBIVFRQ LzEuMSA0MDAgQmFkIFJlcXVlc3QKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KICBD YWNoZS1Db250cm9sOiBuby1zdG9yZQoKICB7CiAgICAiZXJyb3IiOiJpbnZhbGlkX2NsaWVudCIK ICAgICJlcnJvcl9kZXNjcmlwdGlvbiI6ImFzc2VydGlvbiBoYXMgZXhwaXJlZCIKICB9Cl1dPjwv YXJ0d29yaz4KICAgICAgPC9maWd1cmU+CgogICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9u PgoKICAgIDwvc2VjdGlvbj4KCgkgIDwhLS0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiAtLT4KCiAgICA8c2Vj dGlvbiB0aXRsZT0iQXNzZXJ0aW9uIENvbnRlbnQgYW5kIFByb2Nlc3NpbmciIGFuY2hvcj0iY29u dGVudHByb2Nlc3NpbmciPgogICAgICA8dD5UaGlzIHNlY3Rpb24gcHJvdmlkZXMgYSBnZW5lcmFs IGNvbnRlbnQgYW5kIHByb2Nlc3NpbmcgbW9kZWwgZm9yIHRoZQogICAgICB1c2Ugb2YgYXNzZXJ0 aW9ucyBpbiA8eHJlZiB0YXJnZXQ9IlJGQzY3NDkiPk9BdXRoCiAgICAgIDIuMDwveHJlZj4uPC90 PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IkFzc2VydGlvbiBNZXRhbW9kZWwiPgogICAgICAgIDx0 PlRoZSBmb2xsb3dpbmcgYXJlIGVudGl0aWVzIGFuZCBtZXRhZGF0YSBpbnZvbHZlZCBpbiB0aGUg aXNzdWFuY2UsCiAgICAgICAgZXhjaGFuZ2UsIGFuZCBwcm9jZXNzaW5nIG9mIGFzc2VydGlvbnMg aW4gT0F1dGggMi4wLiBUaGVzZSBhcmUgZ2VuZXJhbAogICAgICAgIHRlcm1zLCBhYnN0cmFjdCBm cm9tIGFueSBwYXJ0aWN1bGFyIGFzc2VydGlvbiBmb3JtYXQuIE1hcHBpbmdzIG9mCiAgICAgICAg dGhlc2UgdGVybXMgaW50byBzcGVjaWZpYyByZXByZXNlbnRhdGlvbnMgYXJlIHByb3ZpZGVkIGJ5 IHByb2ZpbGVzIG9mCiAgICAgICAgdGhpcyBzcGVjaWZpY2F0aW9uLjwvdD4KCiAgICAgICAgPHQ+ PGxpc3Qgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iSXNzdWVyIj5U aGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdAogICAgICAgICAgICBpc3N1 ZWQgdGhlIGFzc2VydGlvbi4gR2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRz IHRoZQogICAgICAgICAgICBrZXkgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0 aW9uLgoJICAgIEV4YW1wbGVzIG9mIGlzc3VlcnMgYXJlIE9BdXRoIGNsaWVudHMgKHdoZW4gYXNz ZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpCgkgICAgYW5kIHRoaXJkIHBhcnR5IHNlY3VyaXR5IHRv a2VuIHNlcnZpY2VzLjwvdD4KCiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJTdWJqZWN0Ij5BIHVu aXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgc3ViamVjdCBvZiB0aGUKICAgICAgICAgICAgYXNzZXJ0 aW9uLiBXaGVuIHVzaW5nIGFzc2VydGlvbnMgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiwgdGhl CiAgICAgICAgICAgIFN1YmplY3QgU0hPVUxEIGJlIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmNs aWVudF9pZDwvc3Bhbng+IG9mIHRoZSBPQXV0aCBjbGllbnQuIFdoZW4gdXNpbmcKICAgICAgICAg ICAgYXNzZXJ0aW9ucyBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50LCB0aGUgU3ViamVjdCBNVVNU IGlkZW50aWZ5CiAgICAgICAgICAgIGFuIGF1dGhvcml6ZWQgYWNjZXNzb3IgZm9yIHdoaWNoIHRo ZSBhY2Nlc3MgdG9rZW4gaXMgYmVpbmcKICAgICAgICAgICAgcmVxdWVzdGVkICh0eXBpY2FsbHkg dGhlIHJlc291cmNlIG93bmVyLCBvciBhbiBhdXRob3JpemVkCiAgICAgICAgICAgIGRlbGVnYXRl KS48L3Q+CgogICAgICAgICAgICA8dCBoYW5nVGV4dD0iQXVkaWVuY2UiPkEgdmFsdWUgdGhhdCBp ZGVudGlmaWVzIHRoZSBwYXJ0aWVzIGludGVuZGVkIHRvCgkgICAgcHJvY2VzcyB0aGUgYXNzZXJ0 aW9uLiAgQW4gYXVkaWVuY2UgdmFsdWUgTUFZIGJlIHRoZSBVUkwgb2YKICAgICAgICAgICAgdGhl IFRva2VuIEVuZHBvaW50IGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIgb2YgPHhyZWYKICAgICAg ICAgICAgdGFyZ2V0PSJSRkM2NzQ5Ij5PQXV0aCAyLjA8L3hyZWY+LjwvdD4KCiAgICAgICAgICAg IDx0IGhhbmdUZXh0PSJJc3N1ZWQgQXQgIj5UaGUgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0aW9u IHdhcwogICAgICAgICAgICBpc3N1ZWQuIFdoaWxlIHRoZSBzZXJpYWxpemF0aW9uIG1heSBkaWZm ZXIgYnkgYXNzZXJ0aW9uIGZvcm1hdCwKICAgICAgICAgICAgdGhpcyBpcyBhbHdheXMgZXhwcmVz c2VkIGluIFVUQyB3aXRoIG5vIHRpbWUgem9uZSBjb21wb25lbnQuPC90PgoKICAgICAgICAgICAg PHQgaGFuZ1RleHQ9IkV4cGlyZXMgQXQgIj5UaGUgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0aW9u IGV4cGlyZXMuCiAgICAgICAgICAgIFdoaWxlIHRoZSBzZXJpYWxpemF0aW9uIG1heSBkaWZmZXIg YnkgYXNzZXJ0aW9uIGZvcm1hdCwgdGhpcyBpcwogICAgICAgICAgICBhbHdheXMgZXhwcmVzc2Vk IGluIFVUQyB3aXRoIG5vIHRpbWUgem9uZSBjb21wb25lbnQuPC90PgoKICAgICAgICAgICAgPHQg aGFuZ1RleHQ9IkFzc2VydGlvbiBJRCI+QSBub25jZSBvciB1bmlxdWUgaWRlbnRpZmllciBmb3Ig dGhlCiAgICAgICAgICAgIGFzc2VydGlvbi4gVGhlIEFzc2VydGlvbiBJRCBtYXkgYmUgdXNlZCBi eSBpbXBsZW1lbnRhdGlvbnMKICAgICAgICAgICAgcmVxdWlyaW5nIG1lc3NhZ2UgZGUtZHVwbGlj YXRpb24gZm9yIG9uZS10aW1lIHVzZSBhc3NlcnRpb25zLiBBbnkKICAgICAgICAgICAgZW50aXR5 IHRoYXQgYXNzaWducyBhbiBpZGVudGlmaWVyIE1VU1QgZW5zdXJlIHRoYXQgdGhlcmUgaXMKICAg ICAgICAgICAgbmVnbGlnaWJsZSBwcm9iYWJpbGl0eSB0aGF0IHRoYXQgZW50aXR5IG9yIGFueSBv dGhlciBlbnRpdHkgd2lsbAogICAgICAgICAgICBhY2NpZGVudGFsbHkgYXNzaWduIHRoZSBzYW1l IGlkZW50aWZpZXIgdG8gYSBkaWZmZXJlbnQgZGF0YQogICAgICAgICAgICBvYmplY3QuPC90Pgog ICAgICAgICAgPC9saXN0PjwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0 bGU9IkdlbmVyYWwgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSdWxlcyI+CiAgICAg ICAgPHQ+VGhlIGZvbGxvd2luZyBhcmUgZ2VuZXJhbCBmb3JtYXQgYW5kIHByb2Nlc3NpbmcgcnVs ZXMgZm9yIHRoZSB1c2UKICAgICAgICBvZiBhc3NlcnRpb25zIGluIE9BdXRoOjwvdD4KCiAgICAg ICAgPHQ+PGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgICA8dD5UaGUgYXNzZXJ0aW9u IE1VU1QgY29udGFpbiBhbiBJc3N1ZXIuIFRoZSBJc3N1ZXIgTVVTVCBpZGVudGlmeQogICAgICAg ICAgICB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBi eSB0aGUKICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIElmIGFuIGFzc2VydGlvbiBp cyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlcgogICAgICAgICAgICBTSE9VTEQgYmUgdGhlIDxzcGFu eCBzdHlsZT0ndmVyYic+Y2xpZW50X2lkPC9zcGFueD4uPC90PgoKICAgICAgICAgICAgPHQ+VGhl IGFzc2VydGlvbiBTSE9VTEQgY29udGFpbiBhIFN1YmplY3QuIFRoZSBTdWJqZWN0IE1VU1QKICAg ICAgICAgICAgaWRlbnRpZnkgYW4gYXV0aG9yaXplZCBhY2Nlc3NvciBmb3Igd2hpY2ggdGhlIGFj Y2VzcyB0b2tlbiBpcyBiZWluZwogICAgICAgICAgICByZXF1ZXN0ZWQgKHR5cGljYWxseSB0aGUg cmVzb3VyY2Ugb3duZXIsIG9yIGFuIGF1dGhvcml6ZWQKICAgICAgICAgICAgZGVsZWdhdGUpLiAg V2hlbiB0aGUgY2xpZW50IGlzIGFjdGluZyBvbiBiZWhhbGYgb2YgaXRzZWxmLCB0aGUKICAgICAg ICAgICAgU3ViamVjdCBTSE9VTEQgYmUgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2lk PC9zcGFueD4uPC90PgoKICAgICAgICAgICAgPHQ+VGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4g YW4gQXVkaWVuY2UgdGhhdCBpZGVudGlmaWVzIHRoZQogICAgICAgICAgICBBdXRob3JpemF0aW9u IFNlcnZlciBhcyB0aGUgaW50ZW5kZWQgYXVkaWVuY2UuIFRoZSBBdXRob3JpemF0aW9uCiAgICAg ICAgICAgIFNlcnZlciBNVVNUIHZlcmlmeSB0aGF0IGl0IGlzIGFuIGludGVuZGVkIGF1ZGllbmNl IGZvciB0aGUKICAgICAgICAgICAgYXNzZXJ0aW9uLiBUaGUgQXVkaWVuY2UgU0hPVUxEIGJlIHRo ZSBVUkwgb2YgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgICAgU2VydmVyJ3MgVG9rZW4gRW5k cG9pbnQuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4gYW4g RXhwaXJlcyBBdCBlbnRpdHkgdGhhdCBsaW1pdHMgdGhlCiAgICAgICAgICAgIHRpbWUgd2luZG93 IGR1cmluZyB3aGljaCB0aGUgYXNzZXJ0aW9uIGNhbiBiZSB1c2VkLiBUaGUKICAgICAgICAgICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdCB0aGUgZXhwaXJhdGlvbiB0aW1l IGhhcyBub3QKICAgICAgICAgICAgcGFzc2VkLCBzdWJqZWN0IHRvIGFsbG93YWJsZSBjbG9jayBz a2V3IGJldHdlZW4gc3lzdGVtcy4gVGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVy IFNIT1VMRCByZWplY3QgYXNzZXJ0aW9ucyB3aXRoIGFuIEV4cGlyZXMgQXQKICAgICAgICAgICAg YXR0cmlidXRlIHZhbHVlIHRoYXQgaXMgdW5yZWFzb25hYmx5IGZhciBpbiB0aGUgZnV0dXJlLjwv dD4KCiAgICAgICAgICAgIDx0PlRoZSBhc3NlcnRpb24gTUFZIGNvbnRhaW4gYW4gSXNzdWVkIEF0 IGVudGl0eSBjb250YWluaW5nIHRoZQogICAgICAgICAgICBVVEMgdGltZSBhdCB3aGljaCB0aGUg YXNzZXJ0aW9uIHdhcyBpc3N1ZWQuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIGFzc2VydGlvbiBN QVkgY29udGFpbiBhbiBBc3NlcnRpb24gSUQuIEFuIEF1dGhvcml6YXRpb24KICAgICAgICAgICAg U2VydmVyIE1BWSBkaWN0YXRlIHRoYXQgQXNzZXJ0aW9uIElEIGlzIG1hbmRhdG9yeS48L3Q+Cgog ICAgICAgICAgICA8dD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGUg YXNzZXJ0aW9uJ3Mgc2lnbmF0dXJlCiAgICAgICAgICAgIHRvIHZlcmlmeSB0aGUgSXNzdWVyIG9m IHRoZSBhc3NlcnRpb24uIFRoZSBhbGdvcml0aG0gdXNlZCB0byB2YWxpZGF0ZSB0aGUKICAgICAg ICAgICAgc2lnbmF0dXJlLCBhbmQgdGhlIG1lY2hhbmlzbSBmb3IgZGVzaWduYXRpbmcgdGhlIHNl Y3JldCB1c2VkIHRvCiAgICAgICAgICAgIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24sIGFyZSBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48L3Q+CiAgICAgICAgICA8L2xpc3Q+ PC90PgogICAgICA8L3NlY3Rpb24+CiAgICA8L3NlY3Rpb24+CgoJCSAgPCEtLSAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqIC0tPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJTcGVjaWZpYyBBc3NlcnRpb24gRm9ybWF0 IGFuZCBQcm9jZXNzaW5nIFJ1bGVzIj4KICAgICAgPHQ+VGhlIGZvbGxvd2luZyBjbGFyaWZpZXMg dGhlIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBkZWZpbmVkIGluCiAgICAgIDx4cmVmIHRh cmdldD0idHJhbnNwb3J0aW5nIiAvPiBhbmQgPHhyZWYgdGFyZ2V0PSJjb250ZW50cHJvY2Vzc2lu ZyIgLz4KICAgICAgZm9yIGEgbnVtYmVyIG9mIGNvbW1vbiB1c2UgY2FzZXM6PC90PgoKICAgICAg PHNlY3Rpb24gdGl0bGU9IkNsaWVudCBBdXRoZW50aWNhdGlvbiI+CiAgICAgICAgPHQ+V2hlbiBh IGNsaWVudCB1c2VzIGFuIGFzc2VydGlvbiBmb3IgYXV0aGVudGljYXRpb24sIGl0IFNIT1VMRCBk byBzbyBhY2NvcmRpbmcgdG8gPHhyZWYgdGFyZ2V0PSJjbGllbnRhdXRoIiAvPi4gVGhlIGZvbGxv d2luZyBmb3JtYXQgYW5kCiAgICAgICAgcHJvY2Vzc2luZyBydWxlcyBhcHBseToKCTxsaXN0IHN0 eWxlPSJzeW1ib2xzIj4KCiAgICAgICAgICAgIDx0PlRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmNs aWVudF9hc3NlcnRpb25fdHlwZTwvc3Bhbng+IEhUVFAgcGFyYW1ldGVyIE1VU1QgaWRlbnRpZnkg dGhlCiAgICAgICAgICAgIGFzc2VydGlvbiBmb3JtYXQgYmVpbmcgdXNlZCBmb3IgYXV0aGVudGlj YXRpb24uPC90PgoKICAgICAgICAgICAgPHQ+VGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50 X2Fzc2VydGlvbjwvc3Bhbng+IEhUVFAgcGFyYW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFs aXplZAogICAgICAgICAgICBhc3NlcnRpb24gaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSA8 c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9hc3NlcnRpb25fdHlwZTwvc3Bhbng+CiAgICAgICAg ICAgIHBhcmFtZXRlci48L3Q+CgogICAgICAgICAgICA8dD5UaGUgU3ViamVjdCBTSE9VTEQgYmUg dGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2lkPC9zcGFueD4uPC90PgoKICAgICAgICAg ICAgPHQ+VGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0 eSB0aGF0IGlzc3VlZAogICAgICAgICAgICAgICB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQg YnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgSWYgdGhlCiAgICAgICAgICAgICAgIGFzc2Vy dGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlIDxzcGFueCBzdHls ZT0ndmVyYic+Y2xpZW50X2lkPC9zcGFueD4uPC90PgoKICAgICAgICAgICAgPHQ+VGhlIEF1ZGll bmNlIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAg ICAgICAgICBTZXJ2ZXIgYW5kIFNIT1VMRCBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2lu dC48L3Q+CgogICAgICAgICAgICA8dD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCB2ZXJp ZnkgdGhlIGFzc2VydGlvbidzIHNpZ25hdHVyZSBvciBrZXllZCBtZXNzYWdlIGRpZ2VzdCB0byBk ZXRlcm1pbmUgdGhlIHZhbGlkaXR5IG9mIHRoZSBpc3N1ZXIgYW5kIHRoZSBjb250ZW50IG9mIHRo ZSBhc3NlcnRpb24uPC90PgogICAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgPHQ+VGhlIGZv bGxvd2luZyBub24tbm9ybWF0aXZlIGV4YW1wbGUgZGVtb25zdHJhdGVzIGEKICAgICAgICBjbGll bnQgYXV0aGVudGljYXRpb24gdXNpbmcgYW4gYXNzZXJ0aW9uIGR1cmluZyBhbgogICAgICAgIEFj Y2VzcyBUb2tlbiBSZXF1ZXN0LCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjMgb2YKCTx4cmVm IHRhcmdldD0iUkZDNjc0OSI+T0F1dGggMi4wPC94cmVmPgoJKHdpdGggZXh0cmEgbGluZSBicmVh a3MgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6PC90PgoKICAgICAgICA8ZmlndXJlPgogICAg ICAgICAgPGFydHdvcms+PCFbQ0RBVEFbCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBz ZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0t dXJsZW5jb2RlZAoKICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSYKICBjb2RlPWkxV3NS bjF1QjEmCiAgY2xpZW50X2lkPXM2QmhkUmtxdDMmCiAgY2xpZW50X2Fzc2VydGlvbl90eXBlPXVy biUzQWlldGYlM0FwYXJhbXMlM0FvYXV0aAogICUzQWNsaWVudC1hc3NlcnRpb24tdHlwZSUzQXNh bWwyLWJlYXJlciYKICBjbGllbnRfYXNzZXJ0aW9uPVBITmhiLi4uW29taXR0ZWQgZm9yIGJyZXZp dHldLi4uWlQ0Cl1dPjwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IkNsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIEl0c2Vs ZiI+CiAgICAgICAgPHQ+V2hlbiBhIGNsaWVudCBpcyBhY2Nlc3NpbmcgcmVzb3VyY2VzIG9uIGJl aGFsZiBvZiBpdHNlbGYsIGl0IFNIT1VMRAogICAgICAgIGRvIHNvIGluIGEgbWFubmVyIGFuYWxv Z291cyB0byB0aGUgQ2xpZW50IENyZWRlbnRpYWxzIGZsb3cgZGVmaW5lZCBpbgogICAgICAgIFNl Y3Rpb24gNC40IG9mIDx4cmVmIHRhcmdldD0iUkZDNjc0OSI+T0F1dGggMi4wPC94cmVmPi4gVGhp cwogICAgICAgIGlzIGEgc3BlY2lhbCBjYXNlIHRoYXQgY29tYmluZXMgYm90aCB0aGUgYXV0aGVu dGljYXRpb24gYW5kCiAgICAgICAgYXV0aG9yaXphdGlvbiBncmFudCB1c2FnZSBwYXR0ZXJucy4g SW4gdGhpcyBjYXNlLCB0aGUgaW50ZXJhY3Rpb25zCiAgICAgICAgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgdXNpbmcgYW4gYXNzZXJ0aW9uCiAgICAg ICAgZm9yIENsaWVudCBBdXRoZW50aWNhdGlvbiBhY2NvcmRpbmcgdG8gPHhyZWYgdGFyZ2V0PSJj bGllbnRhdXRoIiAvPiwgd2l0aCB0aGUgYWRkaXRpb24KICAgICAgICBvZiBhIGdyYW50X3R5cGUg cGFyYW1ldGVyLiBUaGUgZm9sbG93aW5nIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcwogICAg ICAgIGFwcGx5OgoJPGxpc3Qgc3R5bGU9InN5bWJvbHMiPgoKICAgICAgICAgICAgPHQ+VGhlIGdy YW50X3R5cGUgSFRUUCByZXF1ZXN0IHBhcmFtZXRlciBNVVNUIGJlCiAgICAgICAgICAgIDxzcGFu eCBzdHlsZT0ndmVyYic+Y2xpZW50X2NyZWRlbnRpYWxzPC9zcGFueD4uPC90PgoKICAgICAgICAg ICAgPHQ+VGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2Fzc2VydGlvbl90eXBlPC9zcGFu eD4gSFRUUCBwYXJhbWV0ZXIgTVVTVCBpZGVudGlmeSB0aGUKICAgICAgICAgICAgYXNzZXJ0aW9u IGZvcm1hdC48L3Q+CgogICAgICAgICAgICA8dD5UaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5jbGll bnRfYXNzZXJ0aW9uPC9zcGFueD4gSFRUUCBwYXJhbWV0ZXIgTVVTVCBjb250YWluIHRoZSBzZXJp YWxpemVkCiAgICAgICAgICAgIGFzc2VydGlvbiBhcyBpbiBhIGZvcm1hdCBpbmRpY2F0ZWQgYnkg dGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2Fzc2VydGlvbl90eXBlPC9zcGFueD4KICAg ICAgICAgICAgcGFyYW1ldGVyLjwvdD4KCiAgICAgICAgICAgIDx0PlRoZSBJc3N1ZXIgb2YgdGhl IGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBlbnRpdHkgdGhhdAogICAgICAgICAgICBpc3N1 ZWQgdGhlIGFzc2VydGlvbiBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZl ci4gSWYKICAgICAgICAgICAgdGhlIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3Vl ciBTSE9VTEQgYmUgdGhlCiAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2lk PC9zcGFueD4uIElmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNlY3VyaXR5IFRva2Vu CiAgICAgICAgICAgIFNlcnZpY2UgKFNUUyksIHRoZSBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRo ZSBTVFMgYXMgcmVjb2duaXplZCBieSB0aGUKICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIFN1YmplY3QgU0hPVUxEIGJlIHRoZSA8c3Bhbngg c3R5bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+LjwvdD4KCiAgICAgICAgICAgIDx0PlRoZSBB dWRpZW5jZSBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIEF1dGhvcml6YXRpb24K ICAgICAgICAgICAgU2VydmVyIGFuZCBTSE9VTEQgYmUgdGhlIFVSTCBvZiB0aGUgVG9rZW4gRW5k cG9pbnQuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1Qg dmFsaWRhdGUgdGhlIGFzc2VydGlvbidzIHNpZ25hdHVyZSB0byB2ZXJpZnkgdGhlIElzc3VlciBv ZiB0aGUgYXNzZXJ0aW9uLjwvdD4KICAgICAgICAgIDwvbGlzdD48L3Q+CgogICAgICAgIDx0PlRo ZSBmb2xsb3dpbmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9uc3RyYXRlcwogICAgICAgIGFu IGFzc2VydGlvbiBiZWluZyB1c2VkIGZvciBhIENsaWVudCBDcmVkZW50aWFscyBBY2Nlc3MgVG9r ZW4KICAgICAgICBSZXF1ZXN0LCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC40LjIgb2YKCTx4cmVm IHRhcmdldD0iUkZDNjc0OSI+T0F1dGggMi4wPC94cmVmPgoJKHdpdGggZXh0cmEgbGluZSBicmVh a3MgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6PC90PgoKICAgICAgICA8ZmlndXJlPgogICAg ICAgICAgPGFydHdvcms+PCFbQ0RBVEFbCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBz ZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0t dXJsZW5jb2RlZAoKICBjbGllbnRfaWQ9czZCaGRSa3F0MyYKICBncmFudF90eXBlPWNsaWVudF9j cmVkZW50aWFscyYKICBjbGllbnRfYXNzZXJ0aW9uX3R5cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUz QW9hdXRoCiAgJTNBY2xpZW50LWFzc2VydGlvbi10eXBlJTNBc2FtbDItYmVhcmVyJgogIGNsaWVu dF9hc3NlcnRpb249UEhOaGJXLi4uW29taXR0ZWQgZm9yIGJyZXZpdHldLi4uWlQKXV0+PC9hcnR3 b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0iQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyIj4KICAgICAgICA8dD5XaGVu IGEgY2xpZW50IGlzIGFjY2Vzc2luZyByZXNvdXJjZXMgb24gYmVoYWxmIG9mIGEgdXNlciwgaXQg U0hPVUxECiAgICAgICAgYmUgdHJlYXRlZCBhcyB1c2luZyBhbiBhc3NlcnRpb24gYXMgYW4gQXV0 aG9yaXphdGlvbiBHcmFudCBhY2NvcmRpbmcKICAgICAgICB0byA8eHJlZiB0YXJnZXQ9ImF1dGhn cmFudHMiIC8+LiBUaGUgZm9sbG93aW5nIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBhcHBs eToKCTxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KCiAgICAgICAgICAgIDx0PlRoZSBncmFudF90eXBl IEhUVFAgcmVxdWVzdCBwYXJhbWV0ZXIgTVVTVCBpbmRpY2F0ZSB0aGUKICAgICAgICAgICAgYXNz ZXJ0aW9uIGZvcm1hdC48L3Q+CgogICAgICAgICAgICA8dD5UaGUgYXNzZXJ0aW9uIEhUVFAgcGFy YW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFsaXplZAogICAgICAgICAgICBhc3NlcnRpb24g YXMgaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSBncmFudF90eXBlCiAgICAgICAgICAgIHBh cmFtZXRlci48L3Q+CgogICAgICAgICAgICA8dD5UaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24g TVVTVCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQKICAgICAgICAgICAgaXNzdWVkIHRoZSBhc3Nl cnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIElmCiAgICAg ICAgICAgIHRoZSBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hPVUxEIGJl IHRoZQogICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+LiBJ ZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgYQoJICAgICAgICAgIFNlY3VyaXR5IFRva2Vu IFNlcnZpY2UgKFNUUyksIHRoZSBJc3N1ZXIgU0hPVUxECiAgICAgICAgICAgIGlkZW50aWZ5IHRo ZSBTVFMgYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuPC90PgoKICAg ICAgICAgICAgPHQ+VGhlIFN1YmplY3QgTVVTVCBpZGVudGlmeSBhbiBhdXRob3JpemVkIGFjY2Vz c29yIGZvciB3aGljaCB0aGUKICAgICAgICAgICAgYWNjZXNzIHRva2VuIGlzIGJlaW5nIHJlcXVl c3RlZCAodHlwaWNhbGx5IHRoZSByZXNvdXJjZSBvd25lciwgb3IKICAgICAgICAgICAgYW4gYXV0 aG9yaXplZCBkZWxlZ2F0ZSkuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIEF1ZGllbmNlIG9mIHRo ZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICAgICAgICBT ZXJ2ZXIgYW5kIE1BWSBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC48L3Q+CgogICAg ICAgICAgICA8dD5UaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGUgYXNz ZXJ0aW9uJ3Mgc2lnbmF0dXJlIHRvIHZlcmlmeSB0aGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24u PC90PgogICAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgICAgPHQ+VGhlIGZvbGxvd2luZyBub24t bm9ybWF0aXZlIGV4YW1wbGUgZGVtb25zdHJhdGVzIGEKICAgICAgICBjbGllbnQgdXNpbmcgYW4g YXNzZXJ0aW9uIGFzIGFuIEF1dGhvcml6YXRpb24gR3JhbnQgZHVyaW5nIGFuCiAgICAgICAgQWNj ZXNzIFRva2VuIFJlcXVlc3QsIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEuMyBvZiA8eHJlZgog ICAgICAgIHRhcmdldD0iUkZDNjc0OSI+T0F1dGggMi4wPC94cmVmPgoJKHdpdGggZXh0cmEgbGlu ZSBicmVha3MgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6PC90PgoKICAgICAgICA8ZmlndXJl PgogICAgICAgICAgPGFydHdvcms+PCFbQ0RBVEFbCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBI b3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3 LWZvcm0tdXJsZW5jb2RlZAoKICBjbGllbnRfaWQ9czZCaGRSa3F0MyYKICBncmFudF90eXBlPXVy biUzQWlldGYlM0FwYXJhbXMlM0FvYXV0aCUzQWdyYW50LXR5cGUlM0FzYW1sMi1iZWFyZXImCiAg YXNzZXJ0aW9uPVBITmhiV3h3T2wuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5aVApdXT48L2Fy dHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9u IHRpdGxlPSJDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhbiBBbm9ueW1vdXMgVXNlciI+CiAg ICAgICAgPHQ+V2hlbiBhIGNsaWVudCBpcyBhY2Nlc3NpbmcgcmVzb3VyY2VzIG9uIGJlaGFsZiBv ZiBhbiBhbm9ueW1vdXMKICAgICAgICB1c2VyLCB0aGUgZm9sbG93aW5nIGZvcm1hdCBhbmQgcHJv Y2Vzc2luZyBydWxlcyBhcHBseToKCTxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KCiAgICAgICAgICAg IDx0PlRoZSBncmFudF90eXBlIEhUVFAgcmVxdWVzdCBwYXJhbWV0ZXIgTVVTVCBpbmRpY2F0ZSB0 aGUKICAgICAgICAgICAgYXNzZXJ0aW9uIGZvcm1hdC48L3Q+CgogICAgICAgICAgICA8dD5UaGUg YXNzZXJ0aW9uIEhUVFAgcGFyYW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFsaXplZAogICAg ICAgICAgICBhc3NlcnRpb24gYXMgaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSBncmFudF90 eXBlCiAgICAgICAgICAgIHBhcmFtZXRlci48L3Q+CgogICAgICAgICAgICA8dD5UaGUgSXNzdWVy IG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQKICAgICAgICAg ICAgaXNzdWVkIHRoZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIuIElmCiAgICAgICAgICAgIHRoZSBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRo ZSBJc3N1ZXIgU0hPVUxEIGJlIHRoZQogICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNs aWVudF9pZDwvc3Bhbng+LiBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgYSBTZWN1cml0 eSBUb2tlbgogICAgICAgICAgICBTZXJ2aWNlIChTVFMpLCB0aGUgSXNzdWVyIFNIT1VMRCBpZGVu dGlmeSB0aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlCiAgICAgICAgICAgIEF1dGhvcml6YXRp b24gU2VydmVyLjwvdD4KCiAgICAgICAgICAgIDx0PlRoZSBTdWJqZWN0IFNIT1VMRCBpbmRpY2F0 ZSB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhhdAogICAgICAgICAgICB0aGUgY2xpZW50 IGlzIGFjdGluZyBvbi1iZWhhbGYgb2YgYW4gYW5vbnltb3VzIHVzZXIgYXMgZGVmaW5lZCBieQog ICAgICAgICAgICB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIEl0IGlzIGltcGxpZWQgdGhhdCBh dXRob3JpemF0aW9uIGlzIGJhc2VkCiAgICAgICAgICAgIHVwb24gYWRkaXRpb25hbCBjcml0ZXJp YSwgc3VjaCBhcyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb3IgY2xhaW1zCiAgICAgICAgICAgIHBy b3ZpZGVkIGluIHRoZSBhc3NlcnRpb24uIEZvciBleGFtcGxlLCBhIGNsaWVudCBtYXkgcHJlc2Vu dCBhbgogICAgICAgICAgICBhc3NlcnRpb24gZnJvbSBhIHRydXN0ZWQgaXNzdWVyIGFzc2VydGlu ZyB0aGF0IHRoZSBiZWFyZXIgaXMgb3ZlcgogICAgICAgICAgICAxOCB2aWEgYW4gaW5jbHVkZWQg Y2xhaW0uIEluIHRoaXMgY2FzZSwgbm8gYWRkaXRpb25hbCBpbmZvcm1hdGlvbgogICAgICAgICAg ICBhYm91dCB0aGUgdXNlcidzIGlkZW50aXR5IGlzIGluY2x1ZGVkIHlldCBhbGwgdGhlIGRhdGEg bmVlZGVkIHRvCiAgICAgICAgICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpcyBwcmVzZW50Ljwv dD4KCiAgICAgICAgICAgIDx0PlRoZSBBdWRpZW5jZSBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRl bnRpZnkgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgICAgU2VydmVyIGFuZCBNQVkgYmUgdGhl IFVSTCBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuPC90PgoKICAgICAgICAgICAgPHQ+VGhlIEF1dGhv cml6YXRpb24gU2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGFzc2VydGlvbidzIHNpZ25hdHVyZSB0 byB2ZXJpZnkgdGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uLjwvdD4KICAgICAgICAgIDwvbGlz dD48L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNo b3I9IlNlY3VyaXR5IiB0aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPgoKICAgICAgPHQ+ VGhpcyBzZWN0aW9uIGRpc2N1c3NlcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFwcGx5 IHdoZW4gdXNpbmcgYXNzZXJ0aW9ucyB3aXRoIE9BdXRoIDIuMCBhcyBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudC4KICAgICAgQXMgZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0iZnJhbWV3b3Jr Ii8+LCB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCB3YXlzIHRvIG9idGFpbiBhc3NlcnRpb25zOiAg ZWl0aGVyIGFzIHNlbGYtaXNzdWVkIG9yCiAgICAgICAgIG9idGFpbmVkIGZyb20gYSB0aGlyZCBw YXJ0eSB0b2tlbiBzZXJ2aWNlLgogICAgICAgIFdoaWxlIHRoZSBhY3R1YWwgaW50ZXJhY3Rpb25z IGZvciBvYnRhaW5pbmcgYW4gYXNzZXJ0aW9uIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LAogICAgICAgIHRoZSBkZXRhaWxzIGFyZSBpbXBvcnRhbnQgZnJvbSBhIHNlY3Vy aXR5IHBlcnNwZWN0aXZlLgogICAgICAgIDx4cmVmIHRhcmdldD0iZnJhbWV3b3JrIi8+IGRpc2N1 c3NlcyB0aGUgaGlnaCBsZXZlbCBhcmNoaXRlY3R1cmFsIGFzcGVjdHMuICBNYW55IG9mIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4gdGhpcyBzZWN0aW9uIGFyZSBhcHBs aWNhYmxlIHRvIGJvdGggdGhlIE9BdXRoIGV4Y2hhbmdlIGFzIHdlbGwgYXMgdGhlIGNsaWVudCBv YnRhaW5pbmcgdGhlIGFzc2VydGlvbi4gPC90PgoKPHQ+VGhlIHJlbWFpbmRlciBvZiB0aGlzIHNl Y3Rpb24gZm9jdXNlcyBvbiB0aGUgZXhjaGFuZ2VzIHRoYXQgY29uY2VybiBwcmVzZW50aW5nIGFu IGFzc2VydGlvbiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBmb3IgdGhlIGF1dGhvcml6 YXRpb24gZ3JhbnQuIDwvdD4KCgo8c2VjdGlvbiB0aXRsZT0iRm9yZ2VkIEFzc2VydGlvbiI+Cgo8 dD4KPGxpc3Qgc3R5bGU9ImhhbmdpbmciPgo8dCBoYW5nVGV4dD0iVGhyZWF0OiI+PHZzcGFjZS8+ CgogICAgICBBbiBhZHZlcnNhcnkgY291bGQgZm9yZ2Ugb3IgYWx0ZXIgYW4gYXNzZXJ0aW9uIGlu IG9yZGVyIHRvCiAgICAgIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4gKGluIGNhc2Ugb2YgdGhlIGF1 dGhvcml6YXRpb24gZ3JhbnQpIG9yIHRvCgkgIGltcGVyc29uYXRlIGEgY2xpZW50IChpbiBjYXNl IG9mIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtKS4KICAgICAgPHZzcGFjZSBi bGFua0xpbmVzPSIxIi8+PC90PgoKPHQgaGFuZ1RleHQ9IkNvdW50ZXJtZWFzdXJlczoiPjx2c3Bh Y2UvPgoKICAgICAgVG8gYXZvaWQgdGhpcyBraW5kIG9mIGF0dGFjaywgdGhlIGVudGl0aWVzIG11 c3QgYXNzdXJlIHRoYXQgcHJvcGVyCiAgICAgIG1lY2hhbmlzbXMgZm9yIHByb3RlY3RpbmcgdGhl IGludGVncml0eSBvZiB0aGUgYXNzZXJ0aW9uIGFyZSBlbXBsb3llZC4gVGhpcyBpbmNsdWRlcwoJ ICB0aGUgaXNzdWVyIGRpZ2l0YWxseSBzaWduaW5nIHRoZSBhc3NlcnRpb24gb3IgY29tcHV0aW5n IGEga2V5ZWQKCSAgbWVzc2FnZSBkaWdlc3Qgb3ZlciB0aGUgYXNzZXJ0aW9uLgo8L3Q+CjwvbGlz dD4KPC90Pgo8L3NlY3Rpb24+Cgo8c2VjdGlvbiB0aXRsZT0iU3RvbGVuIEFzc2VydGlvbiI+Cgo8 dD4KPGxpc3Qgc3R5bGU9ImhhbmdpbmciPgo8dCBoYW5nVGV4dD0iVGhyZWF0OiI+PHZzcGFjZS8+ CgogICAgICBBbiBhZHZlcnNhcnkgbWF5IGJlIGFibGUgb2J0YWluIGFuIGFzc2VydGlvbiAoZS5n LiwgYnkgZWF2ZXNkcm9wcGluZykKCSAgYW5kIHRoZW4gcmV1c2UgaXQgKHJlcGxheSBpdCkgYXQg YSBsYXRlciBwb2ludCBpbiB0aW1lLgogICAgICA8dnNwYWNlIGJsYW5rTGluZXM9IjEiLz48L3Q+ Cgo8dCBoYW5nVGV4dD0iQ291bnRlcm1lYXN1cmVzOiI+PHZzcGFjZS8+CiAgICAgICAgICAgIFRo ZSBwcmltYXJ5IG1pdGlnYXRpb24gZm9yIHRoaXMgdGhyZWF0IGlzIHRoZSB1c2Ugb2YgYSBzZWN1 cmUgY29tbXVuaWNhdGlvbgogICAgICBjaGFubmVsIHdpdGggc2VydmVyIGF1dGhlbnRpY2F0aW9u IGZvciBhbGwgbmV0d29yayBleGNoYW5nZXMuCiAgICAgICAgPHZzcGFjZSBibGFua0xpbmVzPSIx Ii8+CgogICAgICBBbiBhc3NlcnRpb24gbWF5IGFsc28gY29udGFpbiBzZXZlcmFsIGVsZW1lbnRz IHRvIHByZXZlbnQgcmVwbGF5CiAgICAgIGF0dGFja3MuICBUaGVyZSBpcywgaG93ZXZlciwgYSBj bGVhciB0cmFkZW9mZiBiZXR3ZWVuCgkgIHJldXNpbmcgYW4gYXNzZXJ0aW9uIGZvciBtdWx0aXBs ZSBleGNoYW5nZXMgYW5kIG9idGFpbmluZyBhbmQgY3JlYXRpbmcKCSAgbmV3IGZyZXNoIGFzc2Vy dGlvbnMuCgkgIDx2c3BhY2UgYmxhbmtMaW5lcz0iMSIvPgoKCSAgQXV0aG9yaXphdGlvbiBTZXJ2 ZXJzIGFuZCBSZXNvdXJjZSBTZXJ2ZXJzIG1heSB1c2UgYSBjb21iaW5hdGlvbiBvZiB0aGUKICAg QXNzZXJ0aW9uIElEIGFuZCBJc3N1ZWQgQXQvRXhwaXJlcyBBdCBhdHRyaWJ1dGVzIGZvciByZXBs YXkgcHJvdGVjdGlvbi4gIFByZXZpb3VzbHkKICAgcHJvY2Vzc2VkIGFzc2VydGlvbnMgbWF5IGJl IHJlamVjdGVkIGJhc2VkIG9uIHRoZQogICBBc3NlcnRpb24gSUQuICBUaGUgYWRkaXRpb24gb2Yg dGhlIHZhbGlkaXR5IHdpbmRvdyByZWxpZXZlcyB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg ZnJvbSBtYWludGFpbmluZyBhbiBpbmZpbml0ZSBzdGF0ZSB0YWJsZSBvZgogICBwcm9jZXNzZWQg YXNzZXJ0aW9uIElEcy4KCgogICA8L3Q+CjwvbGlzdD4KPC90Pgo8L3NlY3Rpb24+Cgo8c2VjdGlv biB0aXRsZT0iVW5hdXRob3JpemVkIERpc2Nsb3N1cmUgb2YgUGVyc29uYWwgSW5mb3JtYXRpb24i PgoKPHQ+CjxsaXN0IHN0eWxlPSJoYW5naW5nIj4KPHQgaGFuZ1RleHQ9IlRocmVhdDoiPjx2c3Bh Y2UvPgogICAgICBUaGUgYWJpbGl0eSBmb3Igb3RoZXIgZW50aXRpZXMgdG8gb2J0YWluIGluZm9y bWF0aW9uCiAgICAgIGFib3V0IGFuIGluZGl2aWR1YWwsIHN1Y2ggYXMgYXV0aGVudGljYXRpb24g aW5mb3JtYXRpb24sIHJvbGUgaW4gYW4gb3JnYW5pemF0aW9uLCBvciBvdGhlcgogICAgICBhdXRo b3JpemF0aW9uIHJlbGV2YW50IGluZm9ybWF0aW9uLCByYWlzZXMgcHJpdmFjeSBjb25jZXJucy4K ICAgICAgPHZzcGFjZSBibGFua0xpbmVzPSIxIi8+PC90PgoKPHQgaGFuZ1RleHQ9IkNvdW50ZXJt ZWFzdXJlczoiPjx2c3BhY2UvPgogICAgICBUbyBhZGRyZXNzIHRoZSB0aHJlYXRzLCB0d28gY2Fz ZXMgbmVlZCB0byBiZSBkaWZmZXJlbnRpYXRlZDoKCSAgPHZzcGFjZSBibGFua0xpbmVzPSIxIi8+ CgogICAgICBGaXJzdCwgYSB0aGlyZCBwYXJ0eSB0aGF0IGRpZCBub3QgcGFydGljaXBhdGUgaW4g YW55IG9mIHRoZQogICAgICBleGNoYW5nZSBpcyBwcmV2ZW50ZWQgZnJvbSBlYXZlc2Ryb3BwaW5n IG9uIHRoZSBjb250ZW50IG9mIHRoZQogICAgICBhc3NlcnRpb24gYnkgZW1wbG95aW5nIGNvbmZp ZGVudGlhbGl0eSBwcm90ZWN0aW9uIG9mIHRoZQogICAgICBleGNoYW5nZSB1c2luZyBUTFMuICBU aGlzIGVuc3VyZXMKICAgICAgdGhhdCBhbiBlYXZlc2Ryb3BwZXIgb24gdGhlIHdpcmUgaXMgdW5h YmxlIHRvIG9idGFpbiBpbmZvcm1hdGlvbi4KICAgICAgSG93ZXZlciwgdGhpcyBkb2VzIG5vdCBw cmV2ZW50IGxlZ2l0aW1hdGUgcHJvdG9jb2wgZW50aXRpZXMKICAgICAgZnJvbSBvYnRhaW5pbmcg aW5mb3JtYXRpb24gZnJvbSBhbiBhc3NlcnRpb24gdGhleSBtYXkgbm90IGhhdmUgYmVlbgoJICAg IGFsbG93ZWQgdG8gb2J0YWluLiBTb21lIGFzc2VydGlvbiBmb3JtYXRzIGFsbG93IGZvciB0aGUg YXNzZXJ0aW9uCiAgICAgIHRvIGJlIGVuY3J5cHRlZCwgcHJldmVudGluZyB1bmF1dGhvcml6ZWQg cGFydGllcyBmcm9tIGluc3BlY3RpbmcgdGhlIGNvbnRlbnQuCgkgIDx2c3BhY2UgYmxhbmtMaW5l cz0iMSIvPgoKCSAgU2Vjb25kLCBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBtYXkgb2J0YWluIGFu CgkgIGFzc2VydGlvbiB0aGF0IHdhcyBjcmVhdGVkIGJ5IGEgdGhpcmQgcGFydHkgdG9rZW4gc2Vy dmljZSBhbmQgdGhhdAoJICB0b2tlbiBzZXJ2aWNlIG1heSBoYXZlIHBsYWNlZCBhdHRyaWJ1dGVz IGludG8gdGhlIGFzc2VydGlvbi4gVG8KbWl0aWdhdGUgcG90ZW50aWFsIHByaXZhY3kgcHJvYmxl bXMsIHByaW9yIGNvbnNlbnQgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIKaGFzIHRvIGJlIG9idGFp bmVkLiAgT0F1dGggaXRzZWxmIGRvZXMgbm90IGRpcmVjdGx5IHByb3ZpZGUgc3VjaCBjYXBhYmls aXRpZXMsIGJ1dCB0aGlzCmNvbnNlbnQgYXBwcm92YWwgbWF5IGJlIG9idGFpbmVkIHVzaW5nIG90 aGVyIGlkZW50aXR5IG1hbmFnZW1lbnQgcHJvdG9jb2xzLAp1c2VyIGNvbnNlbnQgaW50ZXJhY3Rp b25zLApvciBpbiBhbiBvdXQtb2YtYmFuZCBmYXNoaW9uLgo8dnNwYWNlIGJsYW5rTGluZXM9IjEi Lz4KCiAgICAgIEZvciB0aGUgY2FzZXMgd2hlcmUgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNl IGNyZWF0ZXMgYXNzZXJ0aW9ucwp0byBiZSB1c2VkIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24s IHByaXZhY3kgY29uY2VybnMgYXJlIHR5cGljYWxseSBsb3dlciwKc2luY2UgbWFueSBvZiB0aGVz ZSBjbGllbnRzIGFyZSBXZWIgc2VydmVycyByYXRoZXIgdGhhbiBpbmRpdmlkdWFsIGRldmljZXMK b3BlcmF0ZWQgYnkgaHVtYW5zLiBJZiB0aGUgYXNzZXJ0aW9ucyBhcmUgdXNlZCBmb3IgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIG9mCmRldmljZXMgb3Igc29mdHdhcmUgdGhhdCBjYW4gYmUgY2xvc2Vs eSBsaW5rZWQgdG8gZW5kIHVzZXJzLCB0aGVuIHByaXZhY3kKcHJvdGVjdGlvbiBzYWZlZ3VhcmRz IG5lZWQgdG8gYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLgo8dnNwYWNlIGJsYW5rTGluZXM9 IjEiLz4KCkZ1cnRoZXIgZ3VpZGFuY2Ugb24gcHJpdmFjeSBmcmllbmRseSBwcm90b2NvbCBkZXNp Z24gY2FuIGJlIGZvdW5kIGluIDx4cmVmIHRhcmdldD0iSS1ELmlhYi1wcml2YWN5LWNvbnNpZGVy YXRpb25zIi8+LgogPC90Pgo8L2xpc3Q+CjwvdD4KCgogICAgPC9zZWN0aW9uPgo8L3NlY3Rpb24+ CgoJICAgICAgICA8c2VjdGlvbiB0aXRsZT0nSUFOQSBDb25zaWRlcmF0aW9ucyc+CiAgICAgICAg ICAgIDx0PlRoaXMgaXMgYSByZXF1ZXN0IHRvIGFkZCB0aHJlZSB2YWx1ZXMsIGFzIGxpc3RlZCBp biB0aGUgc3ViLXNlY3Rpb25zIGJlbG93LAogICAgICAgICAgICAgIHRvIHRoZSAiT0F1dGggUGFy YW1ldGVycyIgcmVnaXN0cnkgZXN0YWJsaXNoZWQgYnkgPHhyZWYgdGFyZ2V0PSJSRkM2NzQ5Ij5S RkMgNjc0OS48L3hyZWY+PC90PgoJICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdhc3NlcnRpb24g UGFyYW1ldGVyIFJlZ2lzdHJhdGlvbic+CgkgICAgICAgICAgICA8dD4KCSAgICAgICAgICAgICAg PGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgoJICAgICAgICAgICAgICAgIDx0PlBhcmFtZXRlciBuYW1l OiBhc3NlcnRpb248L3Q+CgkgICAgICAgICAgICAgICAgPHQ+UGFyYW1ldGVyIHVzYWdlIGxvY2F0 aW9uOiB0b2tlbiByZXF1ZXN0CgkgICAgICAgICAgICAgICAgPC90PgoJICAgICAgICAgICAgICAg IDx0PkNoYW5nZSBjb250cm9sbGVyOiBJRVRGPC90PgoJICAgICAgICAgICAgICAgIDx0PlNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbdGhpcyBkb2N1bWVudF1dPC90PgoJICAgICAgICAgICAg ICA8L2xpc3Q+CgkgICAgICAgICAgICA8L3Q+CgkgICAgICAgICAgPC9zZWN0aW9uPgoKCSAgICAg ICAgICA8c2VjdGlvbiB0aXRsZT0nY2xpZW50X2Fzc2VydGlvbiBQYXJhbWV0ZXIgUmVnaXN0cmF0 aW9uJz4KCSAgICAgICAgICAgIDx0PgoJICAgICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9s cyc+CgkgICAgICAgICAgICAgICAgPHQ+UGFyYW1ldGVyIG5hbWU6IGNsaWVudF9hc3NlcnRpb248 L3Q+CgkgICAgICAgICAgICAgICAgPHQ+UGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiBy ZXF1ZXN0CgkgICAgICAgICAgICAgICAgPC90PgoJICAgICAgICAgICAgICAgIDx0PkNoYW5nZSBj b250cm9sbGVyOiBJRVRGPC90PgoJICAgICAgICAgICAgICAgIDx0PlNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbdGhpcyBkb2N1bWVudF1dPC90PgoJICAgICAgICAgICAgICA8L2xpc3Q+Cgkg ICAgICAgICAgICA8L3Q+CgkgICAgICAgICAgPC9zZWN0aW9uPgoKCSAgICAgICAgICA8c2VjdGlv biB0aXRsZT0nY2xpZW50X2Fzc2VydGlvbl90eXBlIFBhcmFtZXRlciBSZWdpc3RyYXRpb24nPgoJ ICAgICAgICAgICAgPHQ+CgkgICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KCSAg ICAgICAgICAgICAgICA8dD5QYXJhbWV0ZXIgbmFtZTogY2xpZW50X2Fzc2VydGlvbl90eXBlPC90 PgoJICAgICAgICAgICAgICAgIDx0PlBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVx dWVzdAoJICAgICAgICAgICAgICAgIDwvdD4KCSAgICAgICAgICAgICAgICA8dD5DaGFuZ2UgY29u dHJvbGxlcjogSUVURjwvdD4KCSAgICAgICAgICAgICAgICA8dD5TcGVjaWZpY2F0aW9uIGRvY3Vt ZW50KHMpOiBbW3RoaXMgZG9jdW1lbnRdXTwvdD4KCSAgICAgICAgICAgICAgPC9saXN0PgoJICAg ICAgICAgICAgPC90PgoJICAgICAgICAgIDwvc2VjdGlvbj4KCgkgICAgICAgIDwvc2VjdGlvbj4K CiAgPC9taWRkbGU+CgogIDxiYWNrPgogICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBS ZWZlcmVuY2VzIj4KICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTE5LnhtbCcgPz4KICAgICAgPD9yZmMg aW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy42NzQ5LnhtbCcgPz4KCiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHJlZmVyZW5jZXMg dGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRw Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjY3NTUu eG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5pYWItcHJpdmFjeS1jb25zaWRlcmF0aW9ucy54 bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVy LTE1LnhtbCcgPz4KICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVh cmVyLTA0LnhtbCcgPz4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJPQVNJUy5XUy1UcnVzdCI+ CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlIGFiYnJldj0nV1MtVHJ1c3QnPldTLVRy dXN0PC90aXRsZT4KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9J0EuJyBzdXJuYW1lPSdOYWRh bGluJyBmdWxsbmFtZT0nQW50aG9ueSBOYWRhbGluJyByb2xlPSdlZGl0b3InLz4KICAgICAgICAg IDxhdXRob3IgaW5pdGlhbHM9J00uJyBzdXJuYW1lPSdHb29kbmVyJyBmdWxsbmFtZT0nTWFyYyBH b29kbmVyJyByb2xlPSdlZGl0b3InLz4KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9J00uJyBz dXJuYW1lPSdHdWRnaW4nIGZ1bGxuYW1lPSdNYXJ0aW4gR3VkZ2luJyByb2xlPSdlZGl0b3InLz4K ICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9J0EuJyBzdXJuYW1lPSdCYXJiaXInIGZ1bGxuYW1l PSdBYmJpZSBCYXJiaXInIHJvbGU9J2VkaXRvcicvPgogICAgICAgICAgPGF1dGhvciBpbml0aWFs cz0nSC4nIHN1cm5hbWU9J0dyYW5xdmlzdCcgZnVsbG5hbWU9J0hhbnMgR3JhbnF2aXN0JyByb2xl PSdlZGl0b3InLz4KICAgICAgICAgIDxkYXRlIHllYXI9IjIwMDkiIG1vbnRoPSJGZWIiLz4KICAg ICAgICA8L2Zyb250PgogICAgICAgIDxmb3JtYXQgdHlwZT0nSFRNTCcgdGFyZ2V0PSdodHRwOi8v ZG9jcy5vYXNpcy1vcGVuLm9yZy93cy1zeC93cy10cnVzdC92MS40L3dzLXRydXN0Lmh0bWwnLz4K ICAgICAgPC9yZWZlcmVuY2U+CgogICAgPC9yZWZlcmVuY2VzPgoKICAgIDxzZWN0aW9uIHRpdGxl PSJBY2tub3dsZWRnZW1lbnRzIj4KICAgICAgPHQ+VGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayB0 aGUgZm9sbG93aW5nIHBlb3BsZSB0aGF0IGhhdmUgaW5mbHVlbmNlZAogICAgICBvciBjb250cmli dXRlZCB0aGlzIHNwZWNpZmljYXRpb246IFBhdWwgTWFkc2VuLCBFcmljIFNhY2hzLCBKaWFuIENh aSwKICAgICAgVG9ueSBOYWRhbGluLCBIYW5uZXMgVHNjaG9mZW5pZywgdGhlIGF1dGhvcnMgb2Yg dGhlIE9BdXRoIFdSQVAgc3BlY2lmaWNhdGlvbiwKICAgICAgYW5kIHRoZSBtZW1iZXJzIG9mIHRo ZSBPQXV0aCB3b3JraW5nIGdyb3VwLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0 aXRsZT0nRG9jdW1lbnQgSGlzdG9yeSc+CiAgICAgIDx0PgoJW1sgdG8gYmUgcmVtb3ZlZCBieSB0 aGUgUkZDIGVkaXRvciBiZWZvcmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1dCiAgICAgIDwvdD4K CiAgICAgIDx0PgogICAgICAgIC0xMAogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAg ICAgICAgIDx0PgoJICAgIENoYW5nZSB0ZXJtICJQcmluY2lwYWwiIHRvICJTdWJqZWN0Ii4KCSAg PC90PgogICAgICAgICAgPHQ+CgkgICAgQWRkZWQgSW50ZXJvcGVyYWJpbGl0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLgoJICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAgICAgIDx0 PgogICAgICAgIC0wOQogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0 PgoJICAgIEFsbG93IGF1ZGllbmNlIHZhbHVlcyB0byBub3QgYmUgVVJJcy4KCSAgPC90PgogICAg ICAgICAgPHQ+CgkgICAgQWRkZWQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB0byBkcmFmdC1pZXRm LW9hdXRoLXNhbWwyLWJlYXJlcgoJICAgIGFuZCBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIu CgkgIDwvdD4KCSAgPHQ+CgkgICAgQ2xhcmlmaWVkIHRoYXQgdGhlIHN0YXRlbWVudHMgYWJvdXQg cG9zc2libGUgaXNzdWVycyBhcmUgbm9uLW5vcm1hdGl2ZQoJICAgIGJ5IHVzaW5nIHRoZSBsYW5n dWFnZSAiRXhhbXBsZXMgb2YgaXNzdWVycyIuCgkgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAg IDwvdD4KICAgICAgPHQ+CiAgICAgICAgLTA4CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMn PgogICAgICAgICAgPHQ+VXBkYXRlIHJlZmVyZW5jZSB0byBSRkMgNjc1NSBmcm9tIGRyYWZ0LWll dGYtb2F1dGgtdXJuLXN1Yi1uczwvdD4KICAgICAgICAgIDx0PlRpZHkgdXAgSUFOQSBjb25zaWRl cmF0aW9uIHNlY3Rpb248L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAgICAgICA8dD4K ICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDcKICAgICAgICA8bGlzdCBzdHls ZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD5SZWZlcmVuY2UgUkZDIDY3NDkuPC90PgogICAgICAg ICAgPHQ+UmVtb3ZlIGV4dHJhbmVvdXMgd29yZCBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAwMjkuaHRtbDwvdD4KICAgICAgICA8L2xp c3Q+CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRp b25zLTA2CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+QWRkIG1v cmUgdGV4dCB0byBpbnRybyBleHBsYWluaW5nIHRoYXQgYW4gYXNzZXJ0aW9uIGdyYW50IHR5cGUg Y2FuIGJlIHVzZWQgd2l0aCBvciB3aXRob3V0IGNsaWVudAogICAgICAgICAgICBhdXRoZW50aWNh dGlvbi9pZGVudGlmaWNhdGlvbiBhbmQgdGhhdCBjbGllbnQgYXNzZXJ0aW9uIGF1dGhlbnRpY2F0 aW9uIGlzIG5vdGhpbmcgbW9yZSB0aGFuIGFuIGFsdGVybmF0aXZlIHdheSBmb3IgYSBjbGllbnQg dG8gYXV0aGVudGljYXRlIHRvIHRoZSB0b2tlbiBlbmRwb2ludDwvdD4gICAgICAgICAgCiAgICAg ICAgPC9saXN0PgogICAgICA8L3Q+CiAgICAgICA8dD4KICAgICAgICBkcmFmdC1pZXRmLW9hdXRo LWFzc2VydGlvbnMtMDUKICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8 dD5Ob24tbm9ybWF0aXZlIGVkaXRvcmlhbCBjbGVhbnVwczwvdD4KICAgICAgICA8L2xpc3Q+CiAg ICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA0 CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+VXBkYXRlZCBkb2N1 bWVudCB0byBpbmNvcnBvcmF0ZSB0aGUgcmV2aWV3IGNvbW1lbnRzIGZyb20gdGhlIHNoZXBoZXJk IC0gdGhyZWFkIGFuZCBhbHRlcm5hdGl2ZSBkcmFmdCBhdCBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwOTQzNy5odG1sPC90PgogICAgICAgICAg PHQ+QWRkZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtb2F1dGgtdXJuLXN1Yi1ucyBhbmQgaW5j bHVkZSBzdWdnZXN0aW9ucyBvbiB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6W2dyYW50LXR5cGV8Y2xp ZW50LWFzc2VydGlvbi10eXBlXToqIFVSTnM8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+ CiAgICAgICA8dD4KICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDMKICAgICAg ICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD51cGRhdGVkIHJlZmVyZW5jZSB0 byBkcmFmdC1pZXRmLW9hdXRoLXYyIGZyb20gLTI1IHRvIC0yNjwvdD4KICAgICAgICA8L2xpc3Q+ CiAgICAgIDwvdD4KICAgICAgPHQ+CglkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDIKCTxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KCSAgPHQ+QWRkZWQgdGV4dCBhYm91dCBsaW1pdGVkIGxpZmV0 aW1lIEFUcyBhbmQgUlRzIHBlciBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cwODI5OC5odG1sLjwvdD4KCSAgPHQ+Q2hhbmdlZCB0aGUgbGluZSBi cmVha3MgaW4gc29tZSBleGFtcGxlcyB0byBhdm9pZCBhd2t3YXJkIHJlbmRlcmluZyB0byB0ZXh0 IGZvcm1hdC4gQWxzbyByZW1vdmVkIGVuY29kZWQgJz0nIHBhZGRpbmcgZnJvbSBhIGZldyBleGFt cGxlcyBiZWNhdXNlIGJvdGgga25vd24gZGVyaXZhdGl2ZSBzcGVjcywgU0FNTCBhbmQgSldULCBv bWl0IHRoZSBwYWRkaW5nIGNoYXIgaW4gc2VyaWFsaXphdGlvbi9lbmNvZGluZy48L3Q+CgkgIDx0 PlJlbW92ZSBzZWN0aW9uIDcgb24gZXJyb3IgcmVzcG9uc2VzIGFuZCBtb3ZlIHRoYXQgKHNvbWV3 aGF0IG1vZGlmaWVkKSBjb250ZW50IGludG8gc3Vic2VjdGlvbnMgb2Ygc2VjdGlvbiA0IGJyb2tl biB1cCBieSBhdXRobi9hdXRoeiBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMDg3MzUuaHRtbC48L3Q+CgkgIDx0PlJld29yayB0aGUgdGV4 dCBhYm91dCAiTVVTVCB2YWxpZGF0ZSAuLi4gaW4gb3JkZXIgdG8gZXN0YWJsaXNoIGEgbWFwcGlu ZyBiZXR3ZWVuIC4uLiIgcGVyIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzA4ODcyLmh0bWwgYW5kIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4NzQ5Lmh0bWwuPC90PgoJICA8dD5DaGFuZ2Ug IlRoZSBQcmluY2lwYWwgTVVTVCBpZGVudGlmeSBhbiBhdXRob3JpemVkIGFjY2Vzc29yLiAgSWYg dGhlCgkgIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIFByaW5jaXBhbCBTSE9VTEQgYmUg dGhlIGNsaWVudF9pZCIgaW4gNi4xIHBlciBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODg3My5odG1sLjwvdD4KCSAgPHQ+VXBkYXRlIHJlZmVy ZW5jZSBpbiA0LjEgdG8gcG9pbnQgdG8gMi4zIChyYXRoZXIgdGhhbiAzLjIpIG9mIG9hdXRoLXYy IChyYXRoZXIgdGhhbiBzZWxmKSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cwODg3NC5odG1sLjwvdD4KCSAgPHQ+TW92ZSB0aGUgIlNlY3Rpb24g MyBvZiIgb3V0IG9mIHRoZSB4cmVmIHRvIGhvcGVmdWxseSBmaXggdGhlIGxpbmsgaW4gNC4xIGFu ZCByZW1vdmUgdGhlIGNsaWVudF9pZCBidWxsZXQgZnJvbSA0LjIgcGVyIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4ODc1Lmh0bWwuPC90PgoJ ICA8dD5BZGQgcmVmIHRvIFNlY3Rpb24gMy4zIG9mIG9hdXRoLXYyIGZvciBzY29wZSBkZWZpbml0 aW9uIGFuZCByZW1vdmUgc29tZSB0aGVuIHJlZHVuZGFudCB0ZXh0IHBlciBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODg5MC5odG1sLjwvdD4K CSAgPHQ+Q2hhbmdlICJUaGUgZm9sbG93aW5nIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBT SE9VTEQgYmUgYXBwbGllZCIgdG8gIlRoZSBmb2xsb3dpbmcgZm9ybWF0IGFuZCBwcm9jZXNzaW5n IHJ1bGVzIGFwcGx5IiBpbiBzZWN0aW9ucyA2LnggdG8gcmVtb3ZlIGNvbmZsaWN0aW5nIG5vcm1h dGl2ZSBxdWFsaWZpY2F0aW9uIG9mIG90aGVyIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIHBlciBodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODg5Mi5o dG1sLjwvdD4KCSAgPHQ+QWRkIHRleHQgdGhlIGNsaWVudF9pZCBtdXN0IGlkIHRoZSBjbGllbnQg dG8gNC4xIGFuZCByZW1vdmUgc2ltaWxhciB0ZXh0IGZyb20gb3RoZXIgcGxhY2VzIHBlciBodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODg5My5o dG1sLjwvdD4KCSAgPHQ+UmVtb3ZlIHRoZSBNVVNUIGZyb20gdGhlIHRleHQgcHJpb3IgdG8gdGhl IEhUVFAgcGFyYW1ldGVyIGRlZmluaXRpb25zIHBlciBodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODkyMC5odG1sLjwvdD4KCSAgPHQ+VXBkYXRl ZCBleGFtcGxlcyB0byB1c2UgZ3JhbnRfdHlwZSBhbmQgY2xpZW50X2Fzc2VydGlvbl90eXBlIHZh bHVlcyBmcm9tIHRoZSBPQXV0aCBTQU1MIEFzc2VydGlvbiBQcm9maWxlcyBzcGVjLjwvdD4KCTwv bGlzdD4KICAgICAgPC90PgoKICAgIDwvc2VjdGlvbj4KICA8L2JhY2s+CjwvcmZjPgo= --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_ Content-Type: text/plain; name="draft-ietf-oauth-assertions-10.txt" Content-Description: draft-ietf-oauth-assertions-10.txt Content-Disposition: attachment; filename="draft-ietf-oauth-assertions-10.txt"; size=49439; creation-date="Fri, 18 Jan 2013 22:50:04 GMT"; modification-date="Fri, 18 Jan 2013 22:49:04 GMT" Content-Transfer-Encoding: base64 CgoKT0F1dGggV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEIuIENhbXBiZWxsCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGluZwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBNb3J0aW1vcmUKRXhwaXJl czogSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT YWxlc2ZvcmNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBKb25lcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZLiBHb2xhbmQKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SmFudWFyeSAxOCwgMjAxMwoKCiAgICAgICAgICAgICAgICAgICBBc3NlcnRpb24gRnJhbWV3b3Jr IGZvciBPQXV0aCAyLjAKICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC1hc3Nl cnRpb25zLTEwCgpBYnN0cmFjdAoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgZnJh bWV3b3JrIGZvciB0aGUgdXNlIG9mIGFzc2VydGlvbnMKICAgd2l0aCBPQXV0aCAyLjAgaW4gdGhl IGZvcm0gb2YgYSBuZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbQogICBhbmQgYSBu ZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlLiAgTWVjaGFuaXNtcyBhcmUgc3BlY2lmaWVkIGZv cgogICB0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0 b2tlbiBlbmRwb2ludCwgYXMKICAgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVsZXMuCgog ICBUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29tbW9u IGZyYW1ld29yayBmb3IKICAgT0F1dGggMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyIGlkZW50 aXR5IHN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucywKICAgYW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRp dmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuCgogICBOb3RlIHRoYXQgdGhpcyBz cGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlIGZsb3dzIGFuZAogICBw cm9jZXNzaW5nIHJ1bGVzLiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50YWJsZSwgY29tcGFuaW9u CiAgIHNwZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9u ZGluZyBjb25jcmV0ZQogICBpbnN0YW50aWF0aW9ucy4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0 aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUg dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55 CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSnVs eSAyMiwgMjAxMy4KCkNvcHlyaWdodCBOb3RpY2UKCgoKQ2FtcGJlbGwsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIEp1bHkgMjIsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAgICAgICAgSmFu dWFyeSAyMDEzCgoKICAgQ29weXJpZ2h0IChjKSAyMDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJz b25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF VEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz CiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0 aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu ZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhv dXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl LgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAxLjEuICBJbnRlcm9w ZXJhYmlsaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAg IDIuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNAogICAzLiAgRnJhbWV3b3JrICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgNC4gIFRyYW5zcG9ydGluZyBBc3NlcnRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgNC4xLiAg VXNpbmcgQXNzZXJ0aW9ucyBhcyBBdXRob3JpemF0aW9uIEdyYW50cyAuIC4gLiAuIC4gLiAuIC4g LiAgOAogICAgICAgNC4xLjEuICBFcnJvciBSZXNwb25zZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA0LjIuICBVc2luZyBBc3NlcnRpb25zIGZvciBDbGll bnQgQXV0aGVudGljYXRpb24gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgICA0LjIuMS4gIEVycm9y IFJlc3BvbnNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICA1 LiAgQXNzZXJ0aW9uIENvbnRlbnQgYW5kIFByb2Nlc3NpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTEKICAgICA1LjEuICBBc3NlcnRpb24gTWV0YW1vZGVsICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgNS4yLiAgR2VuZXJhbCBBc3NlcnRpb24g Rm9ybWF0IGFuZCBQcm9jZXNzaW5nIFJ1bGVzICAuIC4gLiAuIC4gLiAxMgogICA2LiAgU3BlY2lm aWMgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSdWxlcyAuIC4gLiAuIC4gLiAuIC4g MTMKICAgICA2LjEuICBDbGllbnQgQXV0aGVudGljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgNi4yLiAgQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2Yg SXRzZWxmICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgIDYuMy4gIENsaWVudCBBY3Rp bmcgb24gQmVoYWxmIG9mIGEgVXNlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICA2 LjQuICBDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhbiBBbm9ueW1vdXMgVXNlciAuIC4gLiAu IC4gLiAuIDE2CiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgIDcuMS4gIEZvcmdlZCBBc3NlcnRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICA3LjIuICBTdG9s ZW4gQXNzZXJ0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3 CiAgICAgNy4zLiAgVW5hdXRob3JpemVkIERpc2Nsb3N1cmUgb2YgUGVyc29uYWwgSW5mb3JtYXRp b24gIC4gLiAuIC4gLiAxOAogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgICA4LjEuICBhc3NlcnRpb24gUGFy YW1ldGVyIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgOC4y LiAgY2xpZW50X2Fzc2VydGlvbiBQYXJhbWV0ZXIgUmVnaXN0cmF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAxOQogICAgIDguMy4gIGNsaWVudF9hc3NlcnRpb25fdHlwZSBQYXJhbWV0ZXIgUmVnaXN0 cmF0aW9uIC4gLiAuIC4gLiAuIC4gMTkKICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgOS4xLiAgTm9ybWF0 aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQog ICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjAKICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwCiAgIEFwcGVuZGl4IEIuICBEb2N1bWVudCBI aXN0b3J5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMAogICBBdXRob3Jz JyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjMKCgoKCkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEz ICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9u IEZyYW1ld29yayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCjEuICBJbnRyb2R1 Y3Rpb24KCiAgIE9BdXRoIDIuMCBbUkZDNjc0OV0gaXMgYW4gYXV0aG9yaXphdGlvbiBmcmFtZXdv cmsgdGhhdCBlbmFibGVzIGEKICAgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8gb2J0YWluIGxp bWl0ZWQgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIEhUVFAKICAgcmVzb3VyY2UuICBJbiBPQXV0aCwg dGhvc2UgdGhpcmQtcGFydHkgYXBwbGljYXRpb25zIGFyZSBjYWxsZWQKICAgY2xpZW50czsgdGhl eSBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcyBieSBwcmVzZW50aW5nIGFuIGFjY2VzcwogICB0 b2tlbiB0byB0aGUgSFRUUCByZXNvdXJjZS4gIEFjY2VzcyB0b2tlbnMgYXJlIGlzc3VlZCB0byBj bGllbnRzIGJ5CiAgIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggdGhlIChzb21ldGltZXMg aW1wbGljaXQpIGFwcHJvdmFsIG9mIHRoZQogICByZXNvdXJjZSBvd25lci4gIFRoZXNlIGFjY2Vz cyB0b2tlbnMgYXJlIHR5cGljYWxseSBvYnRhaW5lZCBieQogICBleGNoYW5naW5nIGFuIGF1dGhv cml6YXRpb24gZ3JhbnQsIHdoaWNoIHJlcHJlc2VudHMgdGhlIGF1dGhvcml6YXRpb24KICAgZ3Jh bnRlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIgKG9yIGJ5IGEgcHJpdmlsZWdlZCBhZG1pbmlzdHJh dG9yKS4KICAgU2V2ZXJhbCBhdXRob3JpemF0aW9uIGdyYW50IHR5cGVzIGFyZSBkZWZpbmVkIHRv IHN1cHBvcnQgYSB3aWRlIHJhbmdlCiAgIG9mIGNsaWVudCB0eXBlcyBhbmQgdXNlciBleHBlcmll bmNlcy4gIE9BdXRoIGFsc28gcHJvdmlkZXMgYW4KICAgZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20g Zm9yIGRlZmluaW5nIGFkZGl0aW9uYWwgZ3JhbnQgdHlwZXMsIHdoaWNoCiAgIGNhbiBzZXJ2ZSBh cyBhIGJyaWRnZSBiZXR3ZWVuIE9BdXRoIGFuZCBvdGhlciBwcm90b2NvbCBmcmFtZXdvcmtzLgoK ICAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgZ2VuZXJhbCBmcmFtZXdvcmsgZm9yIHRo ZSB1c2Ugb2YKICAgYXNzZXJ0aW9ucyBhcyBhdXRob3JpemF0aW9uIGdyYW50cyB3aXRoIE9BdXRo IDIuMC4gIEl0IGFsc28gcHJvdmlkZXMKICAgYSBmcmFtZXdvcmsgZm9yIGFzc2VydGlvbnMgdG8g YmUgdXNlZCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAgSXQKICAgcHJvdmlkZXMgZ2VuZXJp YyBtZWNoYW5pc21zIGZvciB0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcKICAgaW50ZXJh Y3Rpb25zIHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyB0b2tlbiBlbmRwb2ludCwgYXMg d2VsbAogICBhcyBnZW5lcmFsIHJ1bGVzIGZvciB0aGUgY29udGVudCBhbmQgcHJvY2Vzc2luZyBv ZiB0aG9zZSBhc3NlcnRpb25zLgogICBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgYW4gYWx0ZXJu YXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uCiAgIG1lY2hhbmlzbSAob25lIHRoYXQgZG9lc24n dCBzZW5kIGNsaWVudCBzZWNyZXRzKSwgYXMgd2VsbCBhcyB0bwogICBmYWNpbGl0YXRlIHRoZSB1 c2Ugb2YgT0F1dGggMi4wIGluIGNsaWVudC1zZXJ2ZXIgaW50ZWdyYXRpb24KICAgc2NlbmFyaW9z LCB3aGVyZSB0aGUgZW5kLXVzZXIgbWF5IG5vdCBiZSBwcmVzZW50LgoKICAgVGhpcyBzcGVjaWZp Y2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlIGZsb3dzIGFuZCBwcm9jZXNzaW5n CiAgIHJ1bGVzLiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50YWJsZSwgY29tcGFuaW9uIHNwZWNp ZmljYXRpb25zIGFyZQogICBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZyBj b25jcmV0ZSBpbnN0YW50aWF0aW9ucy4gIEZvcgogICBpbnN0YW5jZSwgU0FNTCAyLjAgQmVhcmVy IEFzc2VydGlvbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wCiAgIFtJLUQuaWV0Zi1vYXV0aC1zYW1s Mi1iZWFyZXJdIGRlZmluZXMgYSBjb25jcmV0ZSBpbnN0YW50aWF0aW9uIGZvcgogICBTQU1MIDIu MCB0b2tlbnMgYW5kIEpTT04gV2ViIFRva2VuIChKV1QpIEJlYXJlciBUb2tlbiBQcm9maWxlcyBm b3IKICAgT0F1dGggMi4wIFtJLUQuaWV0Zi1vYXV0aC1qd3QtYmVhcmVyXSBkZWZpbmVzIGEgY29u Y3JldGUKICAgaW5zdGFudGlhdGlvbiBmb3IgSldUIHRva2Vucy4KCiAgIE5vdGU6IFRoZSB1c2Ug b2YgYXNzZXJ0aW9ucyBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG9ydGhvZ29uYWwKICAg dG8gYW5kIHNlcGFyYWJsZSBmcm9tIHVzaW5nIGFzc2VydGlvbnMgYXMgYW4gYXV0aG9yaXphdGlv biBncmFudC4KICAgVGhleSBjYW4gYmUgdXNlZCBlaXRoZXIgaW4gY29tYmluYXRpb24gb3Igc2Vw YXJhdGVseS4gIENsaWVudAogICBhc3NlcnRpb24gYXV0aGVudGljYXRpb24gaXMgbm90aGluZyBt b3JlIHRoYW4gYW4gYWx0ZXJuYXRpdmUgd2F5IGZvcgogICBhIGNsaWVudCB0byBhdXRoZW50aWNh dGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IGFuZCBtdXN0IGJlIHVzZWQgaW4KICAgY29uanVuY3Rp b24gd2l0aCBzb21lIGdyYW50IHR5cGUgdG8gZm9ybSBhIGNvbXBsZXRlIGFuZCBtZWFuaW5nZnVs CiAgIHByb3RvY29sIHJlcXVlc3QuICBBc3NlcnRpb24gYXV0aG9yaXphdGlvbiBncmFudHMgbWF5 IGJlIHVzZWQgd2l0aCBvcgogICB3aXRob3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpZGVu dGlmaWNhdGlvbi4gIFdoZXRoZXIgb3Igbm90CiAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBu ZWVkZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhbiBhc3NlcnRpb24KICAgYXV0aG9yaXphdGlvbiBn cmFudCwgYXMgd2VsbCBhcyB0aGUgc3VwcG9ydGVkIHR5cGVzIG9mIGNsaWVudAogICBhdXRoZW50 aWNhdGlvbiwgYXJlIHBvbGljeSBkZWNpc2lvbnMgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlCiAg IGF1dGhvcml6YXRpb24gc2VydmVyLgoKCgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGly ZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFm dCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCAgICAgICBKYW51YXJ5IDIw MTMKCgoxLjEuICBJbnRlcm9wZXJhYmlsaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIHNwZWNp ZmljYXRpb24gZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgdXNpbmcgYXNzZXJ0aW9ucyB3aXRoCiAg IE9BdXRoIDIuMC4gIEhvd2V2ZXIsIGFzIGFuIGFic3RyYWN0IGZyYW1ld29yayBpbiB3aGljaCB0 aGUgZGF0YQogICBmb3JtYXRzIHVzZWQgZm9yIHJlcHJlc2VudGluZyBtYW55IHZhbHVlcyBhcmUg bm90IGRlZmluZWQsIG9uIGl0cwogICBvd24sIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBub3Qgc3Vm ZmljaWVudCB0byBwcm9kdWNlIGludGVyb3BlcmFibGUKICAgaW1wbGVtZW50YXRpb25zLgoKICAg VHdvIG90aGVyIHNwZWNpZmljYXRpb25zIHRoYXQgcHJvZmlsZSB0aGlzIGZyYW1ld29yayBmb3Ig c3BlY2lmaWMKICAgYXNzZXJ0aW9uIGhhdmUgYmVlbiBkZXZlbG9wZWQ6IG9uZSBbSS1ELmlldGYt b2F1dGgtc2FtbDItYmVhcmVyXSB1c2VzCiAgIFNBTUwgMi4wLWJhc2VkIGFzc2VydGlvbnMgYW5k IHRoZSBvdGhlciBbSS1ELmlldGYtb2F1dGgtand0LWJlYXJlcl0KICAgdXNlcyBKU09OIFdlYiBU b2tlbnMgKEpXVHMpLiAgVGhlc2UgdHdvIGluc3RhbnRpYXRpb25zIG9mIHRoaXMKICAgZnJhbWV3 b3JrIHNwZWNpZnkgYWRkaXRpb25hbCBkZXRhaWxzIGFib3V0IHRoZSBhc3NlcnRpb24gZW5jb2Rp bmcgYW5kCiAgIHByb2Nlc3NpbmcgcnVsZXMgZm9yIHVzaW5nIHRob3NlIGtpbmRzIG9mIGFzc2Vy dGlvbnMgd2l0aCBPQXV0aCAyLjAuCgogICBIb3dldmVyLCBldmVuIHdoZW4gcHJvZmlsZWQgZm9y IHNwZWNpZmljIGFzc2VydGlvbiB0eXBlcywgYWRkaXRpb25hbAogICBwcm9maWxpbmcgZm9yIHNw ZWNpZmljIHVzZSBjYXNlcyB3aWxsIGJlIHJlcXVpcmVkIHRvIGFjaGlldmUgZnVsbAogICBpbnRl cm9wZXJhYmlsaXR5LiAgRGVwbG95bWVudHMgZm9yIHBhcnRpY3VsYXIgdHJ1c3QgZnJhbWV3b3Jr cywKICAgY2lyY2xlcyBvZiB0cnVzdCwgb3Igb3RoZXIgdXNlcyBjYXNlcyB3aWxsIG5lZWQgdG8g YWdyZWUgYW1vbmcgdGhlCiAgIHBhcnRpY2lwYW50cyBvbiB0aGUga2luZHMgb2YgdmFsdWVzIHRv IGJlIHVzZWQgZm9yIHNvbWUgYWJzdHJhY3QKICAgZmllbGRzIGRlZmluZWQgYnkgdGhpcyBzcGVj aWZpY2F0aW9uLiAgRm9yIGV4YW1wbGUgdGhlIHZhbHVlcyBvZgogICBJc3N1ZXIsIFN1YmplY3Qs IGFuZCBBdWRpZW5jZSBmaWVsZHMgbWlnaHQgYmUgVVJMcywgVVJJcywgZnVsbHkKICAgcXVhbGlm aWVkIGRvbWFpbiBuYW1lcywgT0F1dGggY2xpZW50IElEcywgSVAgYWRkcmVzc2VzLCBvciBvdGhl cgogICB2YWx1ZXMsIGRlcGVuZGluZyB1cG9uIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHBhcnRp Y3VsYXIgdXNlIGNhc2UuCiAgIFRoZSB2ZXJpZmljYXRpb24gcnVsZXMgZm9yIHNvbWUgdmFsdWVz IHdpbGwgYWxzbyBiZSB1c2UgY2FzZQogICBzcGVjaWZpYy4KCiAgIFRoaXMgZnJhbWV3b3JrIHdh cyBkZXNpZ25lZCB3aXRoIHRoZSBjbGVhciBleHBlY3RhdGlvbiB0aGF0CiAgIGFkZGl0aW9uYWwg c3BlY2lmaWNhdGlvbnMgd2lsbCBkZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZAogICBl eHRlbnNpb25zIG5lY2Vzc2FyeSB0byBhY2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFi aWxpdHkgZm9yCiAgIHBhcnRpY3VsYXIgdXNlIGNhc2VzLgoKCjIuICBUZXJtaW5vbG9neQoKICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XSAuCgogICBUaHJvdWdob3V0IHRoaXMgZG9jdW1l bnQsIHZhbHVlcyBhcmUgcXVvdGVkIHRvIGluZGljYXRlIHRoYXQgdGhleSBhcmUKICAgdG8gYmUg dGFrZW4gbGl0ZXJhbGx5LiAgV2hlbiB1c2luZyB0aGVzZSB2YWx1ZXMgaW4gcHJvdG9jb2wgbWVz c2FnZXMsCiAgIHRoZSBxdW90ZXMgbXVzdCBub3QgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSB2YWx1 ZS4KCgozLiAgRnJhbWV3b3JrCgogICBBbiBhc3NlcnRpb24gaXMgYSBwYWNrYWdlIG9mIGluZm9y bWF0aW9uIHRoYXQgYWxsb3dzIGlkZW50aXR5IGFuZAogICBzZWN1cml0eSBpbmZvcm1hdGlvbiB0 byBiZSBzaGFyZWQgYWNyb3NzIHNlY3VyaXR5IGRvbWFpbnMuICBBbgoKCgpDYW1wYmVsbCwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2Ug NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIu MCAgICAgICBKYW51YXJ5IDIwMTMKCgogICBhc3NlcnRpb24gdHlwaWNhbGx5IGNvbnRhaW5zIGlu Zm9ybWF0aW9uIGFib3V0IGEgc3ViamVjdCBvcgogICBwcmluY2lwYWwsIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBwYXJ0eSB0aGF0IGlzc3VlZCB0aGUgYXNzZXJ0aW9uIGFuZAogICB3aGVuIHdhcyBp dCBpc3N1ZWQsIGFzIHdlbGwgYXMgdGhlIGNvbmRpdGlvbnMgdW5kZXIgd2hpY2ggdGhlCiAgIGFz c2VydGlvbiBpcyB0byBiZSBjb25zaWRlcmVkIHZhbGlkLCBzdWNoIGFzIHdoZW4gYW5kIHdoZXJl IGl0IGNhbiBiZQogICB1c2VkLgoKICAgVGhlIGVudGl0eSB0aGF0IGNyZWF0ZXMgYW5kIHNpZ25z IHRoZSBhc3NlcnRpb24gaXMgdHlwaWNhbGx5IGtub3duIGFzCiAgIHRoZSAiSXNzdWVyIiBhbmQg dGhlIGVudGl0eSB0aGF0IGNvbnN1bWVzIHRoZSBhc3NlcnRpb24gYW5kIHJlbGllcyBvbgogICBp dHMgaW5mb3JtYXRpb24gaXMgdHlwaWNhbGx5IGtub3duIGFzIHRoZSAiUmVseWluZyBQYXJ0eSIu ICBJbiB0aGUKICAgY29udGV4dCBvZiB0aGlzIGRvY3VtZW50LCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYWN0cyBhcyBhIHJlbHlpbmcKICAgcGFydHkuCgogICBBc3NlcnRpb25zIHVzZWQgaW4g dGhlIHByb3RvY29sIGV4Y2hhbmdlcyBkZWZpbmVkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbiBN VVNUIGFsd2F5cyBiZSBwcm90ZWN0ZWQgYWdhaW5zdCB0YW1wZXJpbmcgdXNpbmcgYQogICBkaWdp dGFsIHNpZ25hdHVyZSBvciBhIGtleWVkIG1lc3NhZ2UgZGlnZXN0IGFwcGxpZWQgYnkgdGhlIGlz c3Vlci4KICAgQW4gYXNzZXJ0aW9uIE1BWSBhZGRpdGlvbmFsbHkgYmUgZW5jcnlwdGVkLCBwcmV2 ZW50aW5nIHVuYXV0aG9yaXplZAogICBwYXJ0aWVzIGZyb20gaW5zcGVjdGluZyB0aGUgY29udGVu dC4KCiAgIEFsdGhvdWdoIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIHRoZSBwcm9jZXNz ZXMgYnkgd2hpY2ggdGhlCiAgIGNsaWVudCBvYnRhaW5zIHRoZSBhc3NlcnRpb24gKHByaW9yIHRv IHNlbmRpbmcgaXQgdG8gdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyKSwgdGhlcmUgYXJlIHR3 byBjb21tb24gcGF0dGVybnMgZGVzY3JpYmVkIGJlbG93LgoKICAgSW4gdGhlIGZpcnN0IHBhdHRl cm4sIGRlcGljdGVkIGluIEZpZ3VyZSAxLCB0aGUgY2xpZW50IG9idGFpbnMgYW4KICAgYXNzZXJ0 aW9uIGZyb20gYSB0aGlyZCBwYXJ0eSBlbnRpdHkgY2FwYWJsZSBvZiBpc3N1aW5nLCByZW5ld2lu ZywKICAgdHJhbnNmb3JtaW5nLCBhbmQgdmFsaWRhdGluZyBzZWN1cml0eSB0b2tlbnMuICBUeXBp Y2FsbHkgc3VjaCBhbgogICBlbnRpdHkgaXMga25vd24gYXMgYSAiU2VjdXJpdHkgVG9rZW4gU2Vy dmljZSIgKFNUUykgb3IganVzdCAiVG9rZW4KICAgU2VydmljZSIgYW5kIGEgdHJ1c3QgcmVsYXRp b25zaGlwICh1c3VhbGx5IG1hbmlmZXN0ZWQgaW4gdGhlIGV4Y2hhbmdlCiAgIG9mIHNvbWUga2lu ZCBvZiBrZXkgbWF0ZXJpYWwpIGV4aXN0cyBiZXR3ZWVuIHRoZSB0b2tlbiBzZXJ2aWNlIGFuZAog ICB0aGUgcmVseWluZyBwYXJ0eS4gIFRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24g aXNzdWVyOyBpdHMKICAgcm9sZSBpcyB0byBmdWxmaWxsIHJlcXVlc3RzIGZyb20gY2xpZW50cywg d2hpY2ggcHJlc2VudCB2YXJpb3VzCiAgIGNyZWRlbnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25z IGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGgKICAgYXBwcm9wcmlhdGUgaW5mb3JtYXRpb24s IGFuZCBzaWduIHRoZW0uICBXUy1UcnVzdCBbT0FTSVMuV1MtVHJ1c3RdIGlzCiAgIG9uZSBhdmFp bGFibGUgc3RhbmRhcmQgZm9yIHJlcXVlc3Rpbmcgc2VjdXJpdHkgdG9rZW5zIChhc3NlcnRpb25z KS4KCgoKCgoKCgoKCgoKCgoKCgoKQ2FtcGJlbGwsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjIsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAgICAgICAgSmFudWFyeSAyMDEzCgoK ICAgICBSZWx5aW5nCiAgICAgUGFydHkgICAgICAgICAgICAgICAgICAgICBDbGllbnQgICAgICAg ICAgICAgICAgICAgVG9rZW4gU2VydmljZQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAxKSBSZXF1ZXN0IEFzc2VydGlvbiAgIHwKICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAyKSBBc3NlcnRpb24gICAgICAgICAgIHwKICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAog ICAgICAgfCAgICAzKSBBc3NlcnRpb24gICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgfCAgICA0KSBPSyBvciBGYWlsdXJlICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CgogICAgICAgICAgICAgICAgICBGaWd1 cmUgMTogVGhpcmQgUGFydHkgQ3JlYXRlZCBBc3NlcnRpb24KCiAgIEluIHRoZSBzZWNvbmQgcGF0 dGVybiwgZGVwaWN0ZWQgaW4gRmlndXJlIDIsIHRoZSBjbGllbnQgY3JlYXRlcwogICBhc3NlcnRp b25zIGxvY2FsbHkuICBUbyBzaWduIHRoZSBhc3NlcnRpb25zLCBpdCBoYXMgdG8gb2J0YWluIGtl eQogICBtYXRlcmlhbDogZWl0aGVyIHN5bW1ldHJpYyBrZXlzIG9yIGFzeW1tZXRyaWMga2V5IHBh aXJzLiAgVGhlCiAgIG1lY2hhbmlzbXMgZm9yIG9idGFpbmluZyB0aGlzIGtleSBtYXRlcmlhbCBh cmUgYmV5b25kIHRoZSBzY29wZSBvZgogICB0aGlzIHNwZWNpZmljYXRpb24uCgogICBBbHRob3Vn aCBhc3NlcnRpb25zIGFyZSB1c3VhbGx5IHVzZWQgdG8gY29udmV5IGlkZW50aXR5IGFuZCBzZWN1 cml0eQogICBpbmZvcm1hdGlvbiwgc2VsZi1pc3N1ZWQgYXNzZXJ0aW9ucyBjYW4gYWxzbyBzZXJ2 ZSBhIGRpZmZlcmVudAogICBwdXJwb3NlLiAgVGhleSBjYW4gYmUgdXNlZCB0byBkZW1vbnN0cmF0 ZSBrbm93bGVkZ2Ugb2Ygc29tZSBzZWNyZXQsCiAgIHN1Y2ggYXMgYSBjbGllbnQgc2VjcmV0LCB3 aXRob3V0IGFjdHVhbGx5IGNvbW11bmljYXRpbmcgdGhlIHNlY3JldAogICBkaXJlY3RseSBpbiB0 aGUgdHJhbnNhY3Rpb24uICBJbiB0aGF0IGNhc2UsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24KICAg aW5jbHVkZWQgaW4gdGhlIGFzc2VydGlvbiBieSB0aGUgY2xpZW50IGl0c2VsZiB3aWxsIGJlIG9m IGxpbWl0ZWQKICAgdmFsdWUgdG8gdGhlIHJlbHlpbmcgcGFydHkgYW5kLCBmb3IgdGhpcyByZWFz b24sIG9ubHkgYSBiYXJlIG1pbmltdW0KICAgb2YgaW5mb3JtYXRpb24gaXMgdHlwaWNhbGx5IGlu Y2x1ZGVkIGluIHN1Y2ggYW4gYXNzZXJ0aW9uLCBzdWNoIGFzCiAgIGluZm9ybWF0aW9uIGFib3V0 IGlzc3VpbmcgYW5kIHVzYWdlIGNvbmRpdGlvbnMuCgoKCgoKCgoKCgoKCgoKCgoKCkNhbXBiZWxs LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEzICAgICAgICAgICAgICAgICBb UGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1 dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCiAgICAgUmVseWluZwogICAgIFBhcnR5ICAgICAg ICAgICAgICAgICAgICAgQ2xpZW50CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8IDEpIENyZWF0ZQogICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBBc3NlcnRpb24KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLSsKICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgIHwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgMikgQXNzZXJ0aW9uIHwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLS0tLSsKICAgICAgIHwgICAgMykgQXNzZXJ0aW9uICAgICAgICAgIHwKICAgICAg IHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgIHwgICAgNCkgT0sgb3IgRmFpbHVyZSAgICAgIHwKICAgICAgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKCiAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMjogU2VsZi1Jc3N1ZWQgQXNzZXJ0aW9uCgogICBEZXBsb3ltZW50cyBuZWVk IHRvIGRldGVybWluZSB0aGUgYXBwcm9wcmlhdGUgdmFyaWFudCB0byB1c2UgYmFzZWQgb24KICAg dGhlIHJlcXVpcmVkIGxldmVsIG9mIHNlY3VyaXR5LCB0aGUgdHJ1c3QgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlCiAgIGVudGl0aWVzLCBhbmQgb3RoZXIgZmFjdG9ycy4KCiAgIEZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIHdoYXQgbXVzdCBiZSBkb25lIGJ5IHRoZSBlbnRpdHkgcHJlc2VudGluZwog ICB0aGUgYXNzZXJ0aW9uLCB0aGVyZSBhcmUgdHdvIGdlbmVyYWwgdHlwZXMgb2YgYXNzZXJ0aW9u czoKCiAgIDEuICBCZWFyZXIgQXNzZXJ0aW9uczogQW55IGVudGl0eSBpbiBwb3NzZXNzaW9uIG9m IGEgYmVhcmVyIGFzc2VydGlvbgogICAgICAgKGUuZy4gdGhlIGJlYXJlcikgY2FuIHVzZSBpdCB0 byBnZXQgYWNjZXNzIHRvIHRoZSBhc3NvY2lhdGVkCiAgICAgICByZXNvdXJjZXMgKHdpdGhvdXQg ZGVtb25zdHJhdGluZyBwb3NzZXNzaW9uIG9mIGEgY3J5cHRvZ3JhcGhpYwogICAgICAga2V5KS4g IFRvIHByZXZlbnQgbWlzdXNlLCBiZWFyZXIgYXNzZXJ0aW9ucyBuZWVkIHRvIGJlIHByb3RlY3Rl ZAogICAgICAgZnJvbSBkaXNjbG9zdXJlIGluIHN0b3JhZ2UgYW5kIGluIHRyYW5zcG9ydC4gIEEg c2VjdXJlCiAgICAgICBjb21tdW5pY2F0aW9uIGNoYW5uZWwgaXMgcmVxdWlyZWQgYmV0d2VlbiBh bGwgZW50aXRpZXMgdG8gYXZvaWQKICAgICAgIGxlYWtpbmcgdGhlIGFzc2VydGlvbiB0byB1bmF1 dGhvcml6ZWQgcGFydGllcy4KCiAgIDIuICBIb2xkZXItb2YtS2V5IEFzc2VydGlvbnM6IFRvIGFj Y2VzcyB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMsIHRoZQogICAgICAgZW50aXR5IHByZXNlbnRp bmcgdGhlIGFzc2VydGlvbiBtdXN0IGRlbW9uc3RyYXRlIHBvc3Nlc3Npb24gb2YKICAgICAgIGFk ZGl0aW9uYWwgY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbC4gIFRoZSB0b2tlbiBzZXJ2aWNlIHRoZXJl YnkKICAgICAgIGJpbmRzIGEga2V5IGlkZW50aWZpZXIgdG8gdGhlIGFzc2VydGlvbiBhbmQgdGhl IGNsaWVudCBoYXMgdG8KICAgICAgIGRlbW9uc3RyYXRlIHRvIHRoZSByZWx5aW5nIHBhcnR5IHRo YXQgaXQga25vd3MgdGhlIGtleQogICAgICAgY29ycmVzcG9uZGluZyB0byB0aGF0IGlkZW50aWZp ZXIgd2hlbiBwcmVzZW50aW5nIHRoZSBhc3NlcnRpb24uCiAgICAgICBUaGlzIG1lY2hhbmlzbSBw cm92aWRlcyBhZGRpdGlvbmFsIHNlY3VyaXR5IHByb3BlcnRpZXMuCgogICBUaGUgcHJvdG9jb2wg cGFyYW1ldGVycyBhbmQgcHJvY2Vzc2luZyBydWxlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQK ICAgYXJlIGludGVuZGVkIHRvIHN1cHBvcnQgYSBjbGllbnQgcHJlc2VudGluZyBhIGJlYXJlciBh c3NlcnRpb24gdG8gYW4KICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBUaGUgdXNlIG9mIGhvbGRl ci1vZi1rZXkgYXNzZXJ0aW9ucyBhcmUgbm90CiAgIHByZWNsdWRlZCBieSB0aGlzIGRvY3VtZW50 LCBidXQgYWRkaXRpb25hbCBwcm90b2NvbCBkZXRhaWxzIHdvdWxkCiAgIG5lZWQgdG8gYmUgc3Bl Y2lmaWVkLgoKCgoKQ2FtcGJlbGwsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIw MTMgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBc3NlcnRp b24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAgICAgICAgSmFudWFyeSAyMDEzCgoKNC4gIFRyYW5z cG9ydGluZyBBc3NlcnRpb25zCgogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBIVFRQIHBhcmFtZXRl cnMgZm9yIHRyYW5zcG9ydGluZyBhc3NlcnRpb25zCiAgIGR1cmluZyBpbnRlcmFjdGlvbnMgd2l0 aCBhIHRva2VuIGVuZHBvaW50IG9mIGFuIE9BdXRoIGF1dGhvcml6YXRpb24KICAgc2VydmVyLiAg QmVjYXVzZSByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgcmVzdWx0IGluIHRoZQogICB0 cmFuc21pc3Npb24gb2YgY2xlYXItdGV4dCBjcmVkZW50aWFscyAoaW4gYm90aCB0aGUgSFRUUCBy ZXF1ZXN0IGFuZAogICByZXNwb25zZSksIGFsbCByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9p bnQgTVVTVCB1c2UgVExTLCBhcwogICBtYW5kYXRlZCBpbiBTZWN0aW9uIDMuMiBvZiBPQXV0aCAy LjAgW1JGQzY3NDldLgoKNC4xLiAgVXNpbmcgQXNzZXJ0aW9ucyBhcyBBdXRob3JpemF0aW9uIEdy YW50cwoKICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiBhc3NlcnRpb25zIGFzIGF1 dGhvcml6YXRpb24gZ3JhbnRzLAogICBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbiBwcm92aWRlZCBp biBTZWN0aW9uIDQuNSBvZiBPQXV0aCAyLjAKICAgW1JGQzY3NDldLiAgV2hlbiB1c2luZyBhc3Nl cnRpb25zIGFzIGF1dGhvcml6YXRpb24gZ3JhbnRzLCB0aGUgY2xpZW50CiAgIGluY2x1ZGVzIHRo ZSBhc3NlcnRpb24gYW5kIHJlbGF0ZWQgaW5mb3JtYXRpb24gdXNpbmcgdGhlIGZvbGxvd2luZwog ICBIVFRQIHJlcXVlc3QgcGFyYW1ldGVyczoKCiAgIGdyYW50X3R5cGUgIFJFUVVJUkVELiAgVGhl IGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlCiAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyLiAgVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJLgoKICAgYXNz ZXJ0aW9uICBSRVFVSVJFRC4gIFRoZSBhc3NlcnRpb24gYmVpbmcgdXNlZCBhcyBhbiBhdXRob3Jp emF0aW9uCiAgICAgIGdyYW50LiAgU3BlY2lmaWMgc2VyaWFsaXphdGlvbiBvZiB0aGUgYXNzZXJ0 aW9uIGlzIGRlZmluZWQgYnkKICAgICAgcHJvZmlsZSBkb2N1bWVudHMuICBUaGUgc2VyaWFsaXph dGlvbiBNVVNUIGJlIGVuY29kZWQgZm9yCiAgICAgIHRyYW5zcG9ydCB3aXRoaW4gSFRUUCBmb3Jt cy4gIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYmFzZTY0dXJsIGJlCiAgICAgIHVzZWQuCgogICBz Y29wZSAgT1BUSU9OQUwuICBUaGUgcmVxdWVzdGVkIHNjb3BlIGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuMyBvZgogICAgICBPQXV0aCAyLjAgW1JGQzY3NDldLiAgV2hlbiBleGNoYW5naW5nIGFz c2VydGlvbnMgZm9yIGFjY2VzcwogICAgICB0b2tlbnMsIHRoZSBhdXRob3JpemF0aW9uIGZvciB0 aGUgdG9rZW4gaGFzIGJlZW4gcHJldmlvdXNseQogICAgICBncmFudGVkIHRocm91Z2ggc29tZSBv dXQtb2YtYmFuZCBtZWNoYW5pc20uICBBcyBzdWNoLCB0aGUKICAgICAgcmVxdWVzdGVkIHNjb3Bl IE1VU1QgYmUgZXF1YWwgb3IgbGVzc2VyIHRoYW4gdGhlIHNjb3BlIG9yaWdpbmFsbHkKICAgICAg Z3JhbnRlZCB0byB0aGUgYXV0aG9yaXplZCBhY2Nlc3Nvci4gIElmIHRoZSBzY29wZSBwYXJhbWV0 ZXIgYW5kL29yCiAgICAgIHZhbHVlIGFyZSBvbWl0dGVkLCB0aGUgc2NvcGUgTVVTVCBiZSB0cmVh dGVkIGFzIGVxdWFsIHRvIHRoZSBzY29wZQogICAgICBvcmlnaW5hbGx5IGdyYW50ZWQgdG8gdGhl IGF1dGhvcml6ZWQgYWNjZXNzb3IuICBUaGUgQXV0aG9yaXphdGlvbgogICAgICBTZXJ2ZXIgTVVT VCBsaW1pdCB0aGUgc2NvcGUgb2YgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gdG8gYmUgZXF1YWwK ICAgICAgb3IgbGVzc2VyIHRoYW4gdGhlIHNjb3BlIG9yaWdpbmFsbHkgZ3JhbnRlZCB0byB0aGUg YXV0aG9yaXplZAogICAgICBhY2Nlc3Nvci4KCiAgIFRoZSBmb2xsb3dpbmcgbm9uLW5vcm1hdGl2 ZSBleGFtcGxlIGRlbW9uc3RyYXRlcyBhbiBhc3NlcnRpb24gYmVpbmcKICAgdXNlZCBhcyBhbiBh dXRob3JpemF0aW9uIGdyYW50ICh3aXRoIGV4dHJhIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5CiAg IHB1cnBvc2VzIG9ubHkpOgoKICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQogICAgIEhvc3Q6IHNl cnZlci5leGFtcGxlLmNvbQogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9y bS11cmxlbmNvZGVkCgogICAgIGNsaWVudF9pZD1zNkJoZFJrcXQzJgogICAgIGdyYW50X3R5cGU9 dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoJTNBZ3JhbnQtdHlwZSUzQXNhbWwyLWJlYXJlciYK CgoKQ2FtcGJlbGwsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIwMTMgICAgICAg ICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBc3NlcnRpb24gRnJhbWV3 b3JrIGZvciBPQXV0aCAyLjAgICAgICAgSmFudWFyeSAyMDEzCgoKICAgICBhc3NlcnRpb249UEhO aGJXeHdPbC4uLltvbWl0dGVkIGZvciBicmV2aXR5XS4uLlpUNAoKICAgQW4gYXNzZXJ0aW9uIHVz ZWQgaW4gdGhpcyBjb250ZXh0IGlzIGdlbmVyYWxseSBhIHNob3J0IGxpdmVkCiAgIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIGdyYW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZl cnMKICAgU0hPVUxEIE5PVCBpc3N1ZSBhY2Nlc3MgdG9rZW5zIHdpdGggYSBsaWZldGltZSB0aGF0 IGV4Y2VlZHMgdGhlCiAgIHZhbGlkaXR5IHBlcmlvZCBvZiB0aGUgYXNzZXJ0aW9uIGJ5IGEgc2ln bmlmaWNhbnQgcGVyaW9kLiAgSW4KICAgcHJhY3RpY2UsIHRoYXQgd2lsbCB1c3VhbGx5IG1lYW4g dGhhdCByZWZyZXNoIHRva2VucyBhcmUgbm90IGlzc3VlZAogICBpbiByZXNwb25zZSB0byBhc3Nl cnRpb24gZ3JhbnQgcmVxdWVzdHMgYW5kIGFjY2VzcyB0b2tlbnMgd2lsbCBiZQogICBpc3N1ZWQg d2l0aCBhIHJlYXNvbmFibHkgc2hvcnQgbGlmZXRpbWUuICBDbGllbnRzIGNhbiByZWZyZXNoIGFu CiAgIGV4cGlyZWQgYWNjZXNzIHRva2VuIGJ5IHJlcXVlc3RpbmcgYSBuZXcgb25lIHVzaW5nIHRo ZSBzYW1lCiAgIGFzc2VydGlvbiwgaWYgaXQgaXMgc3RpbGwgdmFsaWQsIG9yIHdpdGggYSBuZXcg YXNzZXJ0aW9uLgoKICAgQW4gSUVGVCBVUk4gZm9yIHVzZSBhcyB0aGUgImdyYW50X3R5cGUiIHZh bHVlIGNhbiBiZSByZXF1ZXN0ZWQgdXNpbmcKICAgdGhlIHRlbXBsYXRlIGluIEFuIElFVEYgVVJO IFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoIFtSRkM2NzU1XS4gIEEgVVJOCiAgIG9mIHRoZSBmb3Jt IHVybjppZXRmOnBhcmFtczpvYXV0aDpncmFudF90eXBlOiogaXMgc3VnZ2VzdGVkLgoKNC4xLjEu ICBFcnJvciBSZXNwb25zZXMKCiAgIElmIGFuIGFzc2VydGlvbiBpcyBub3QgdmFsaWQgb3IgaGFz IGV4cGlyZWQsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcgogICBNVVNUIGNvbnN0cnVjdCBhbiBl cnJvciByZXNwb25zZSBhcyBkZWZpbmVkIGluIE9BdXRoIDIuMCBbUkZDNjc0OV0uCiAgIFRoZSB2 YWx1ZSBvZiB0aGUgImVycm9yIiBwYXJhbWV0ZXIgTVVTVCBiZSB0aGUgImludmFsaWRfZ3JhbnQi IGVycm9yCiAgIGNvZGUuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGluY2x1ZGUgYWRk aXRpb25hbCBpbmZvcm1hdGlvbgogICByZWdhcmRpbmcgdGhlIHJlYXNvbnMgdGhlIGFzc2VydGlv biB3YXMgY29uc2lkZXJlZCBpbnZhbGlkIHVzaW5nIHRoZQogICAiZXJyb3JfZGVzY3JpcHRpb24i IG9yICJlcnJvcl91cmkiIHBhcmFtZXRlcnMuCgogICBGb3IgZXhhbXBsZToKCiAgICAgSFRUUC8x LjEgNDAwIEJhZCBSZXF1ZXN0CiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCiAg ICAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKCiAgICAgewogICAgICAgImVycm9yIjoiaW52YWxp ZF9ncmFudCIsCiAgICAgICAiZXJyb3JfZGVzY3JpcHRpb24iOiJBdWRpZW5jZSB2YWxpZGF0aW9u IGZhaWxlZCIKICAgICB9Cgo0LjIuICBVc2luZyBBc3NlcnRpb25zIGZvciBDbGllbnQgQXV0aGVu dGljYXRpb24KCiAgIFRoZSBmb2xsb3dpbmcgc2VjdGlvbiBkZWZpbmVzIHRoZSB1c2Ugb2YgYXNz ZXJ0aW9ucyBhcyBjbGllbnQKICAgY3JlZGVudGlhbHMgYXMgYW4gZXh0ZW5zaW9uIG9mIFNlY3Rp b24gMi4zIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uCiAgIFdoZW4gdXNpbmcgYXNzZXJ0aW9ucyBh cyBjbGllbnQgY3JlZGVudGlhbHMsIHRoZSBjbGllbnQgaW5jbHVkZXMgdGhlCiAgIGFzc2VydGlv biBhbmQgcmVsYXRlZCBpbmZvcm1hdGlvbiB1c2luZyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVz dAogICBwYXJhbWV0ZXJzOgoKCgoKCgoKCkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBKdWx5IDIyLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0 ICAgICAgQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAx MwoKCiAgIGNsaWVudF9pZCAgT1BUSU9OQUwuICBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24KICAgICAgMi4yIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uICBXaGVu IHByZXNlbnQsIHRoZSAiY2xpZW50X2lkIiBNVVNUCiAgICAgIGlkZW50aWZ5IHRoZSBjbGllbnQg dG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKICAgY2xpZW50X2Fzc2VydGlvbl90eXBlICBS RVFVSVJFRC4gIFRoZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcwogICAgICBkZWZpbmVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSB2YWx1ZSBNVVNUIGJlIGFuCiAgICAgIGFi c29sdXRlIFVSSS4KCiAgIGNsaWVudF9hc3NlcnRpb24gIFJFUVVJUkVELiAgVGhlIGFzc2VydGlv biBiZWluZyB1c2VkIHRvIGF1dGhlbnRpY2F0ZQogICAgICB0aGUgY2xpZW50LiAgU3BlY2lmaWMg c2VyaWFsaXphdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIGlzIGRlZmluZWQgYnkKICAgICAgcHJvZmls ZSBkb2N1bWVudHMuICBUaGUgc2VyaWFsaXphdGlvbiBNVVNUIGJlIGVuY29kZWQgZm9yCiAgICAg IHRyYW5zcG9ydCB3aXRoaW4gSFRUUCBmb3Jtcy4gIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYmFz ZTY0dXJsIGJlCiAgICAgIHVzZWQuCgogICBUaGUgZm9sbG93aW5nIG5vbi1ub3JtYXRpdmUgZXhh bXBsZSBkZW1vbnN0cmF0ZXMgYSBjbGllbnQKICAgYXV0aGVudGljYXRpbmcgdXNpbmcgYW4gYXNz ZXJ0aW9uIGR1cmluZyBhbiBBY2Nlc3MgVG9rZW4gUmVxdWVzdCwgYXMKICAgZGVmaW5lZCBpbiBT ZWN0aW9uIDQuMS4zIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0gKHdpdGggZXh0cmEgbGluZQogICBi cmVha3MgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CgogICAgIFBPU1QgL3Rva2VuIEhUVFAv MS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQKCiAgICAgZ3JhbnRfdHlwZT1hdXRob3JpemF0 aW9uX2NvZGUmCiAgICAgY29kZT1pMVdzUm4xdUIxJgogICAgIGNsaWVudF9pZD1zNkJoZFJrcXQz JgogICAgIGNsaWVudF9hc3NlcnRpb25fdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGgK ICAgICAlM0FjbGllbnQtYXNzZXJ0aW9uLXR5cGUlM0FzYW1sMi1iZWFyZXImCiAgICAgY2xpZW50 X2Fzc2VydGlvbj1QSE5oYlcuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5aVAoKICAgVG9rZW4g ZW5kcG9pbnRzIGNhbiBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYXNzZXJ0aW9uIGJhc2VkIGNyZWRl bnRpYWxzCiAgIGFuZCBvdGhlciBjbGllbnQgY3JlZGVudGlhbCB0eXBlcyBieSBsb29raW5nIGZv ciB0aGUgcHJlc2VuY2Ugb2YgdGhlCiAgICJjbGllbnRfYXNzZXJ0aW9uIiBhbmQgImNsaWVudF9h c3NlcnRpb25fdHlwZSIgcGFyYW1ldGVycywgd2hpY2ggd2lsbAogICBvbmx5IGJlIHByZXNlbnQg d2hlbiB1c2luZyBhc3NlcnRpb25zIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uCgogICBBbiBJ RUZUIFVSTiBmb3IgdXNlIGFzIHRoZSAiY2xpZW50X2Fzc2VydGlvbl90eXBlIiB2YWx1ZSBtYXkg YmUKICAgcmVxdWVzdGVkIHVzaW5nIHRoZSB0ZW1wbGF0ZSBpbiBBbiBJRVRGIFVSTiBTdWItTmFt ZXNwYWNlIGZvciBPQXV0aAogICBbUkZDNjc1NV0uICBBIFVSTiBvZiB0aGUgZm9ybQogICB1cm46 aWV0ZjpwYXJhbXM6b2F1dGg6Y2xpZW50LWFzc2VydGlvbi10eXBlOiogaXMgc3VnZ2VzdGVkLgoK NC4yLjEuICBFcnJvciBSZXNwb25zZXMKCiAgIElmIGFuIGFzc2VydGlvbiBpcyBpbnZhbGlkIGZv ciBhbnkgcmVhc29uIG9yIGlmIG1vcmUgdGhhbiBvbmUgY2xpZW50CiAgIGF1dGhlbnRpY2F0aW9u IG1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVAogICBjb25z dHJ1Y3QgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVmaW5lZCBpbiBPQXV0aCAyLjAgW1JGQzY3NDld LiAgVGhlCiAgIHZhbHVlIG9mIHRoZSAiZXJyb3IiIHBhcmFtZXRlciBNVVNUIGJlIHRoZSAiaW52 YWxpZF9jbGllbnQiIGVycm9yCiAgIGNvZGUuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZ IGluY2x1ZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbgogICByZWdhcmRpbmcgdGhlIHJlYXNvbnMg dGhlIGNsaWVudCBhc3NlcnRpb24gd2FzIGNvbnNpZGVyZWQgaW52YWxpZAoKCgpDYW1wYmVsbCwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRo IDIuMCAgICAgICBKYW51YXJ5IDIwMTMKCgogICB1c2luZyB0aGUgImVycm9yX2Rlc2NyaXB0aW9u IiBvciAiZXJyb3JfdXJpIiBwYXJhbWV0ZXJzLgoKICAgRm9yIGV4YW1wbGU6CgogICAgIEhUVFAv MS4xIDQwMCBCYWQgUmVxdWVzdAogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbgog ICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCgogICAgIHsKICAgICAgICJlcnJvciI6ImludmFs aWRfY2xpZW50IgogICAgICAgImVycm9yX2Rlc2NyaXB0aW9uIjoiYXNzZXJ0aW9uIGhhcyBleHBp cmVkIgogICAgIH0KCgo1LiAgQXNzZXJ0aW9uIENvbnRlbnQgYW5kIFByb2Nlc3NpbmcKCiAgIFRo aXMgc2VjdGlvbiBwcm92aWRlcyBhIGdlbmVyYWwgY29udGVudCBhbmQgcHJvY2Vzc2luZyBtb2Rl bCBmb3IgdGhlCiAgIHVzZSBvZiBhc3NlcnRpb25zIGluIE9BdXRoIDIuMCBbUkZDNjc0OV0uCgo1 LjEuICBBc3NlcnRpb24gTWV0YW1vZGVsCgogICBUaGUgZm9sbG93aW5nIGFyZSBlbnRpdGllcyBh bmQgbWV0YWRhdGEgaW52b2x2ZWQgaW4gdGhlIGlzc3VhbmNlLAogICBleGNoYW5nZSwgYW5kIHBy b2Nlc3Npbmcgb2YgYXNzZXJ0aW9ucyBpbiBPQXV0aCAyLjAuICBUaGVzZSBhcmUKICAgZ2VuZXJh bCB0ZXJtcywgYWJzdHJhY3QgZnJvbSBhbnkgcGFydGljdWxhciBhc3NlcnRpb24gZm9ybWF0Lgog ICBNYXBwaW5ncyBvZiB0aGVzZSB0ZXJtcyBpbnRvIHNwZWNpZmljIHJlcHJlc2VudGF0aW9ucyBh cmUgcHJvdmlkZWQgYnkKICAgcHJvZmlsZXMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgoKICAgSXNz dWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhl CiAgICAgIGFzc2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xk cyB0aGUga2V5CiAgICAgIG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4g IEV4YW1wbGVzIG9mIGlzc3VlcnMgYXJlCiAgICAgIE9BdXRoIGNsaWVudHMgKHdoZW4gYXNzZXJ0 aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIGFuZCB0aGlyZCBwYXJ0eQogICAgICBzZWN1cml0eSB0b2tl biBzZXJ2aWNlcy4KCiAgIFN1YmplY3QgIEEgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBzdWJq ZWN0IG9mIHRoZSBhc3NlcnRpb24uICBXaGVuCiAgICAgIHVzaW5nIGFzc2VydGlvbnMgZm9yIGNs aWVudCBhdXRoZW50aWNhdGlvbiwgdGhlIFN1YmplY3QgU0hPVUxEIGJlCiAgICAgIHRoZSAiY2xp ZW50X2lkIiBvZiB0aGUgT0F1dGggY2xpZW50LiAgV2hlbiB1c2luZyBhc3NlcnRpb25zIGFzIGFu CiAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQsIHRoZSBTdWJqZWN0IE1VU1QgaWRlbnRpZnkgYW4g YXV0aG9yaXplZAogICAgICBhY2Nlc3NvciBmb3Igd2hpY2ggdGhlIGFjY2VzcyB0b2tlbiBpcyBi ZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseQogICAgICB0aGUgcmVzb3VyY2Ugb3duZXIsIG9yIGFu IGF1dGhvcml6ZWQgZGVsZWdhdGUpLgoKICAgQXVkaWVuY2UgIEEgdmFsdWUgdGhhdCBpZGVudGlm aWVzIHRoZSBwYXJ0aWVzIGludGVuZGVkIHRvIHByb2Nlc3MgdGhlCiAgICAgIGFzc2VydGlvbi4g IEFuIGF1ZGllbmNlIHZhbHVlIE1BWSBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludAog ICAgICBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4yIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uCgog ICBJc3N1ZWQgQXQgICBUaGUgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQu ICBXaGlsZSB0aGUKICAgICAgc2VyaWFsaXphdGlvbiBtYXkgZGlmZmVyIGJ5IGFzc2VydGlvbiBm b3JtYXQsIHRoaXMgaXMgYWx3YXlzCiAgICAgIGV4cHJlc3NlZCBpbiBVVEMgd2l0aCBubyB0aW1l IHpvbmUgY29tcG9uZW50LgoKCgoKQ2FtcGJlbGwsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAgICAgICAgSmFudWFyeSAyMDEzCgoK ICAgRXhwaXJlcyBBdCAgIFRoZSB0aW1lIGF0IHdoaWNoIHRoZSBhc3NlcnRpb24gZXhwaXJlcy4g IFdoaWxlIHRoZQogICAgICBzZXJpYWxpemF0aW9uIG1heSBkaWZmZXIgYnkgYXNzZXJ0aW9uIGZv cm1hdCwgdGhpcyBpcyBhbHdheXMKICAgICAgZXhwcmVzc2VkIGluIFVUQyB3aXRoIG5vIHRpbWUg em9uZSBjb21wb25lbnQuCgogICBBc3NlcnRpb24gSUQgIEEgbm9uY2Ugb3IgdW5pcXVlIGlkZW50 aWZpZXIgZm9yIHRoZSBhc3NlcnRpb24uICBUaGUKICAgICAgQXNzZXJ0aW9uIElEIG1heSBiZSB1 c2VkIGJ5IGltcGxlbWVudGF0aW9ucyByZXF1aXJpbmcgbWVzc2FnZSBkZS0KICAgICAgZHVwbGlj YXRpb24gZm9yIG9uZS10aW1lIHVzZSBhc3NlcnRpb25zLiAgQW55IGVudGl0eSB0aGF0IGFzc2ln bnMKICAgICAgYW4gaWRlbnRpZmllciBNVVNUIGVuc3VyZSB0aGF0IHRoZXJlIGlzIG5lZ2xpZ2li bGUgcHJvYmFiaWxpdHkKICAgICAgdGhhdCB0aGF0IGVudGl0eSBvciBhbnkgb3RoZXIgZW50aXR5 IHdpbGwgYWNjaWRlbnRhbGx5IGFzc2lnbiB0aGUKICAgICAgc2FtZSBpZGVudGlmaWVyIHRvIGEg ZGlmZmVyZW50IGRhdGEgb2JqZWN0LgoKNS4yLiAgR2VuZXJhbCBBc3NlcnRpb24gRm9ybWF0IGFu ZCBQcm9jZXNzaW5nIFJ1bGVzCgogICBUaGUgZm9sbG93aW5nIGFyZSBnZW5lcmFsIGZvcm1hdCBh bmQgcHJvY2Vzc2luZyBydWxlcyBmb3IgdGhlIHVzZSBvZgogICBhc3NlcnRpb25zIGluIE9BdXRo OgoKICAgbyAgVGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4gYW4gSXNzdWVyLiAgVGhlIElzc3Vl ciBNVVNUIGlkZW50aWZ5CiAgICAgIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlIGFzc2VydGlv biBhcyByZWNvZ25pemVkIGJ5IHRoZQogICAgICBBdXRob3JpemF0aW9uIFNlcnZlci4gIElmIGFu IGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlcgogICAgICBTSE9VTEQgYmUgdGhl ICJjbGllbnRfaWQiLgoKICAgbyAgVGhlIGFzc2VydGlvbiBTSE9VTEQgY29udGFpbiBhIFN1Ympl Y3QuICBUaGUgU3ViamVjdCBNVVNUIGlkZW50aWZ5CiAgICAgIGFuIGF1dGhvcml6ZWQgYWNjZXNz b3IgZm9yIHdoaWNoIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYmVpbmcKICAgICAgcmVxdWVzdGVkICh0 eXBpY2FsbHkgdGhlIHJlc291cmNlIG93bmVyLCBvciBhbiBhdXRob3JpemVkCiAgICAgIGRlbGVn YXRlKS4gIFdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIGl0c2VsZiwgdGhl CiAgICAgIFN1YmplY3QgU0hPVUxEIGJlIHRoZSAiY2xpZW50X2lkIi4KCiAgIG8gIFRoZSBhc3Nl cnRpb24gTVVTVCBjb250YWluIGFuIEF1ZGllbmNlIHRoYXQgaWRlbnRpZmllcyB0aGUKICAgICAg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgYXMgdGhlIGludGVuZGVkIGF1ZGllbmNlLiAgVGhlIEF1dGhv cml6YXRpb24KICAgICAgU2VydmVyIE1VU1QgdmVyaWZ5IHRoYXQgaXQgaXMgYW4gaW50ZW5kZWQg YXVkaWVuY2UgZm9yIHRoZQogICAgICBhc3NlcnRpb24uICBUaGUgQXVkaWVuY2UgU0hPVUxEIGJl IHRoZSBVUkwgb2YgdGhlIEF1dGhvcml6YXRpb24KICAgICAgU2VydmVyJ3MgVG9rZW4gRW5kcG9p bnQuCgogICBvICBUaGUgYXNzZXJ0aW9uIE1VU1QgY29udGFpbiBhbiBFeHBpcmVzIEF0IGVudGl0 eSB0aGF0IGxpbWl0cyB0aGUKICAgICAgdGltZSB3aW5kb3cgZHVyaW5nIHdoaWNoIHRoZSBhc3Nl cnRpb24gY2FuIGJlIHVzZWQuICBUaGUKICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2 ZXJpZnkgdGhhdCB0aGUgZXhwaXJhdGlvbiB0aW1lIGhhcyBub3QKICAgICAgcGFzc2VkLCBzdWJq ZWN0IHRvIGFsbG93YWJsZSBjbG9jayBza2V3IGJldHdlZW4gc3lzdGVtcy4gIFRoZQogICAgICBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVqZWN0IGFzc2VydGlvbnMgd2l0aCBhbiBFeHBp cmVzIEF0CiAgICAgIGF0dHJpYnV0ZSB2YWx1ZSB0aGF0IGlzIHVucmVhc29uYWJseSBmYXIgaW4g dGhlIGZ1dHVyZS4KCiAgIG8gIFRoZSBhc3NlcnRpb24gTUFZIGNvbnRhaW4gYW4gSXNzdWVkIEF0 IGVudGl0eSBjb250YWluaW5nIHRoZSBVVEMKICAgICAgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0 aW9uIHdhcyBpc3N1ZWQuCgogICBvICBUaGUgYXNzZXJ0aW9uIE1BWSBjb250YWluIGFuIEFzc2Vy dGlvbiBJRC4gIEFuIEF1dGhvcml6YXRpb24KICAgICAgU2VydmVyIE1BWSBkaWN0YXRlIHRoYXQg QXNzZXJ0aW9uIElEIGlzIG1hbmRhdG9yeS4KCiAgIG8gIFRoZSBBdXRob3JpemF0aW9uIFNlcnZl ciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24ncyBzaWduYXR1cmUKICAgICAgdG8gdmVyaWZ5 IHRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbi4gIFRoZSBhbGdvcml0aG0gdXNlZCB0bwoKCgpD YW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAg ICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsg Zm9yIE9BdXRoIDIuMCAgICAgICBKYW51YXJ5IDIwMTMKCgogICAgICB2YWxpZGF0ZSB0aGUgc2ln bmF0dXJlLCBhbmQgdGhlIG1lY2hhbmlzbSBmb3IgZGVzaWduYXRpbmcgdGhlCiAgICAgIHNlY3Jl dCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24sIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9m CiAgICAgIHRoaXMgc3BlY2lmaWNhdGlvbi4KCgo2LiAgU3BlY2lmaWMgQXNzZXJ0aW9uIEZvcm1h dCBhbmQgUHJvY2Vzc2luZyBSdWxlcwoKICAgVGhlIGZvbGxvd2luZyBjbGFyaWZpZXMgdGhlIGZv cm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBkZWZpbmVkIGluCiAgIFNlY3Rpb24gNCBhbmQgU2Vj dGlvbiA1IGZvciBhIG51bWJlciBvZiBjb21tb24gdXNlIGNhc2VzOgoKNi4xLiAgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uCgogICBXaGVuIGEgY2xpZW50IHVzZXMgYW4gYXNzZXJ0aW9uIGZvciBhdXRo ZW50aWNhdGlvbiwgaXQgU0hPVUxEIGRvIHNvCiAgIGFjY29yZGluZyB0byBTZWN0aW9uIDQuMi4g IFRoZSBmb2xsb3dpbmcgZm9ybWF0IGFuZCBwcm9jZXNzaW5nIHJ1bGVzCiAgIGFwcGx5OgoKICAg byAgVGhlICJjbGllbnRfYXNzZXJ0aW9uX3R5cGUiIEhUVFAgcGFyYW1ldGVyIE1VU1QgaWRlbnRp ZnkgdGhlCiAgICAgIGFzc2VydGlvbiBmb3JtYXQgYmVpbmcgdXNlZCBmb3IgYXV0aGVudGljYXRp b24uCgogICBvICBUaGUgImNsaWVudF9hc3NlcnRpb24iIEhUVFAgcGFyYW1ldGVyIE1VU1QgY29u dGFpbiB0aGUgc2VyaWFsaXplZAogICAgICBhc3NlcnRpb24gaW4gYSBmb3JtYXQgaW5kaWNhdGVk IGJ5IHRoZSAiY2xpZW50X2Fzc2VydGlvbl90eXBlIgogICAgICBwYXJhbWV0ZXIuCgogICBvICBU aGUgU3ViamVjdCBTSE9VTEQgYmUgdGhlICJjbGllbnRfaWQiLgoKICAgbyAgVGhlIElzc3VlciBv ZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlZAogICAg ICB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVy LiAgSWYgdGhlCiAgICAgIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9V TEQgYmUgdGhlICJjbGllbnRfaWQiLgoKICAgbyAgVGhlIEF1ZGllbmNlIG9mIHRoZSBhc3NlcnRp b24gTVVTVCBpZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICBTZXJ2ZXIgYW5kIFNIT1VM RCBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KCiAgIG8gIFRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciBNVVNUIHZlcmlmeSB0aGUgYXNzZXJ0aW9uJ3Mgc2lnbmF0dXJlIG9yCiAgICAg IGtleWVkIG1lc3NhZ2UgZGlnZXN0IHRvIGRldGVybWluZSB0aGUgdmFsaWRpdHkgb2YgdGhlIGlz c3VlciBhbmQKICAgICAgdGhlIGNvbnRlbnQgb2YgdGhlIGFzc2VydGlvbi4KCiAgIFRoZSBmb2xs b3dpbmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9uc3RyYXRlcyBhIGNsaWVudAogICBhdXRo ZW50aWNhdGlvbiB1c2luZyBhbiBhc3NlcnRpb24gZHVyaW5nIGFuIEFjY2VzcyBUb2tlbiBSZXF1 ZXN0LCBhcwogICBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjMgb2YgT0F1dGggMi4wIFtSRkM2NzQ5 XSAod2l0aCBleHRyYSBsaW5lCiAgIGJyZWFrcyBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToK CgoKCgoKCgoKCgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAx MyAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlv biBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCAgICAgICBKYW51YXJ5IDIwMTMKCgogICAgIFBPU1Qg L3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQKCiAgICAgZ3JhbnRfdHlw ZT1hdXRob3JpemF0aW9uX2NvZGUmCiAgICAgY29kZT1pMVdzUm4xdUIxJgogICAgIGNsaWVudF9p ZD1zNkJoZFJrcXQzJgogICAgIGNsaWVudF9hc3NlcnRpb25fdHlwZT11cm4lM0FpZXRmJTNBcGFy YW1zJTNBb2F1dGgKICAgICAlM0FjbGllbnQtYXNzZXJ0aW9uLXR5cGUlM0FzYW1sMi1iZWFyZXIm CiAgICAgY2xpZW50X2Fzc2VydGlvbj1QSE5oYi4uLltvbWl0dGVkIGZvciBicmV2aXR5XS4uLlpU NAoKNi4yLiAgQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgSXRzZWxmCgogICBXaGVuIGEgY2xp ZW50IGlzIGFjY2Vzc2luZyByZXNvdXJjZXMgb24gYmVoYWxmIG9mIGl0c2VsZiwgaXQgU0hPVUxE CiAgIGRvIHNvIGluIGEgbWFubmVyIGFuYWxvZ291cyB0byB0aGUgQ2xpZW50IENyZWRlbnRpYWxz IGZsb3cgZGVmaW5lZCBpbgogICBTZWN0aW9uIDQuNCBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLiAg VGhpcyBpcyBhIHNwZWNpYWwgY2FzZSB0aGF0CiAgIGNvbWJpbmVzIGJvdGggdGhlIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGdyYW50IHVzYWdlCiAgIHBhdHRlcm5zLiAgSW4gdGhp cyBjYXNlLCB0aGUgaW50ZXJhY3Rpb25zIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgc2VydmVy IFNIT1VMRCBiZSB0cmVhdGVkIGFzIHVzaW5nIGFuIGFzc2VydGlvbiBmb3IgQ2xpZW50CiAgIEF1 dGhlbnRpY2F0aW9uIGFjY29yZGluZyB0byBTZWN0aW9uIDQuMiwgd2l0aCB0aGUgYWRkaXRpb24g b2YgYQogICBncmFudF90eXBlIHBhcmFtZXRlci4gIFRoZSBmb2xsb3dpbmcgZm9ybWF0IGFuZCBw cm9jZXNzaW5nIHJ1bGVzCiAgIGFwcGx5OgoKICAgbyAgVGhlIGdyYW50X3R5cGUgSFRUUCByZXF1 ZXN0IHBhcmFtZXRlciBNVVNUIGJlCiAgICAgICJjbGllbnRfY3JlZGVudGlhbHMiLgoKICAgbyAg VGhlICJjbGllbnRfYXNzZXJ0aW9uX3R5cGUiIEhUVFAgcGFyYW1ldGVyIE1VU1QgaWRlbnRpZnkg dGhlCiAgICAgIGFzc2VydGlvbiBmb3JtYXQuCgogICBvICBUaGUgImNsaWVudF9hc3NlcnRpb24i IEhUVFAgcGFyYW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFsaXplZAogICAgICBhc3NlcnRp b24gYXMgaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSAiY2xpZW50X2Fzc2VydGlvbl90eXBl IgogICAgICBwYXJhbWV0ZXIuCgogICBvICBUaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24gTVVT VCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQgaXNzdWVkCiAgICAgIHRoZSBhc3NlcnRpb24gYXMg cmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuICBJZiB0aGUKICAgICAgYXNz ZXJ0aW9uIGlzIHNlbGYtaXNzdWVkLCB0aGUgSXNzdWVyIFNIT1VMRCBiZSB0aGUgImNsaWVudF9p ZCIuCiAgICAgIElmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNlY3VyaXR5IFRva2Vu IFNlcnZpY2UgKFNUUyksIHRoZQogICAgICBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSBTVFMg YXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbgogICAgICBTZXJ2ZXIuCgogICBvICBU aGUgU3ViamVjdCBTSE9VTEQgYmUgdGhlICJjbGllbnRfaWQiLgoKICAgbyAgVGhlIEF1ZGllbmNl IG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICBT ZXJ2ZXIgYW5kIFNIT1VMRCBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KCiAgIG8g IFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24ncyBz aWduYXR1cmUKICAgICAgdG8gdmVyaWZ5IHRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbi4KCgoK CkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEzICAgICAgICAg ICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9uIEZyYW1ld29y ayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCiAgIFRoZSBmb2xsb3dpbmcgbm9u LW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9uc3RyYXRlcyBhbiBhc3NlcnRpb24gYmVpbmcKICAgdXNl ZCBmb3IgYSBDbGllbnQgQ3JlZGVudGlhbHMgQWNjZXNzIFRva2VuIFJlcXVlc3QsIGFzIGRlZmlu ZWQgaW4KICAgU2VjdGlvbiA0LjQuMiBvZiBPQXV0aCAyLjAgW1JGQzY3NDldICh3aXRoIGV4dHJh IGxpbmUgYnJlYWtzIGZvcgogICBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgoKICAgICBQT1NUIC90 b2tlbiBIVFRQLzEuMQogICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogICAgIENvbnRlbnQt VHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkCgogICAgIGNsaWVudF9pZD1z NkJoZFJrcXQzJgogICAgIGdyYW50X3R5cGU9Y2xpZW50X2NyZWRlbnRpYWxzJgogICAgIGNsaWVu dF9hc3NlcnRpb25fdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGgKICAgICAlM0FjbGll bnQtYXNzZXJ0aW9uLXR5cGUlM0FzYW1sMi1iZWFyZXImCiAgICAgY2xpZW50X2Fzc2VydGlvbj1Q SE5oYlcuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5aVAoKNi4zLiAgQ2xpZW50IEFjdGluZyBv biBCZWhhbGYgb2YgYSBVc2VyCgogICBXaGVuIGEgY2xpZW50IGlzIGFjY2Vzc2luZyByZXNvdXJj ZXMgb24gYmVoYWxmIG9mIGEgdXNlciwgaXQgU0hPVUxECiAgIGJlIHRyZWF0ZWQgYXMgdXNpbmcg YW4gYXNzZXJ0aW9uIGFzIGFuIEF1dGhvcml6YXRpb24gR3JhbnQgYWNjb3JkaW5nCiAgIHRvIFNl Y3Rpb24gNC4xLiAgVGhlIGZvbGxvd2luZyBmb3JtYXQgYW5kIHByb2Nlc3NpbmcgcnVsZXMgYXBw bHk6CgogICBvICBUaGUgZ3JhbnRfdHlwZSBIVFRQIHJlcXVlc3QgcGFyYW1ldGVyIE1VU1QgaW5k aWNhdGUgdGhlIGFzc2VydGlvbgogICAgICBmb3JtYXQuCgogICBvICBUaGUgYXNzZXJ0aW9uIEhU VFAgcGFyYW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFsaXplZCBhc3NlcnRpb24KICAgICAg YXMgaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSBncmFudF90eXBlIHBhcmFtZXRlci4KCiAg IG8gIFRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBlbnRpdHkg dGhhdCBpc3N1ZWQKICAgICAgdGhlIGFzc2VydGlvbiBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlci4gIElmIHRoZQogICAgICBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQs IHRoZSBJc3N1ZXIgU0hPVUxEIGJlIHRoZSAiY2xpZW50X2lkIi4KICAgICAgSWYgdGhlIGFzc2Vy dGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4gU2VydmljZSAoU1RTKSwgdGhlCiAg ICAgIElzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25pemVkIGJ5IHRoZSBB dXRob3JpemF0aW9uCiAgICAgIFNlcnZlci4KCiAgIG8gIFRoZSBTdWJqZWN0IE1VU1QgaWRlbnRp ZnkgYW4gYXV0aG9yaXplZCBhY2Nlc3NvciBmb3Igd2hpY2ggdGhlCiAgICAgIGFjY2VzcyB0b2tl biBpcyBiZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseSB0aGUgcmVzb3VyY2Ugb3duZXIsIG9yCiAg ICAgIGFuIGF1dGhvcml6ZWQgZGVsZWdhdGUpLgoKICAgbyAgVGhlIEF1ZGllbmNlIG9mIHRoZSBh c3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICBTZXJ2ZXIgYW5k IE1BWSBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KCiAgIG8gIFRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24ncyBzaWduYXR1cmUKICAg ICAgdG8gdmVyaWZ5IHRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbi4KCiAgIFRoZSBmb2xsb3dp bmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9uc3RyYXRlcyBhIGNsaWVudCB1c2luZyBhbgog ICBhc3NlcnRpb24gYXMgYW4gQXV0aG9yaXphdGlvbiBHcmFudCBkdXJpbmcgYW4gQWNjZXNzIFRv a2VuIFJlcXVlc3QsCiAgIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEuMyBvZiBPQXV0aCAyLjAg W1JGQzY3NDldICh3aXRoIGV4dHJhIGxpbmUKICAgYnJlYWtzIGZvciBkaXNwbGF5IHB1cnBvc2Vz IG9ubHkpOgoKCgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAx MyAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlv biBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCAgICAgICBKYW51YXJ5IDIwMTMKCgogICAgIFBPU1Qg L3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQKCiAgICAgY2xpZW50X2lk PXM2QmhkUmtxdDMmCiAgICAgZ3JhbnRfdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGgl M0FncmFudC10eXBlJTNBc2FtbDItYmVhcmVyJgogICAgIGFzc2VydGlvbj1QSE5oYld4d09sLi4u W29taXR0ZWQgZm9yIGJyZXZpdHldLi4uWlQKCjYuNC4gIENsaWVudCBBY3Rpbmcgb24gQmVoYWxm IG9mIGFuIEFub255bW91cyBVc2VyCgogICBXaGVuIGEgY2xpZW50IGlzIGFjY2Vzc2luZyByZXNv dXJjZXMgb24gYmVoYWxmIG9mIGFuIGFub255bW91cyB1c2VyLAogICB0aGUgZm9sbG93aW5nIGZv cm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBhcHBseToKCiAgIG8gIFRoZSBncmFudF90eXBlIEhU VFAgcmVxdWVzdCBwYXJhbWV0ZXIgTVVTVCBpbmRpY2F0ZSB0aGUgYXNzZXJ0aW9uCiAgICAgIGZv cm1hdC4KCiAgIG8gIFRoZSBhc3NlcnRpb24gSFRUUCBwYXJhbWV0ZXIgTVVTVCBjb250YWluIHRo ZSBzZXJpYWxpemVkIGFzc2VydGlvbgogICAgICBhcyBpbiBhIGZvcm1hdCBpbmRpY2F0ZWQgYnkg dGhlIGdyYW50X3R5cGUgcGFyYW1ldGVyLgoKICAgbyAgVGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0 aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlZAogICAgICB0aGUgYXNzZXJ0 aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgSWYgdGhlCiAg ICAgIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlICJj bGllbnRfaWQiLgogICAgICBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgYSBTZWN1cml0 eSBUb2tlbiBTZXJ2aWNlIChTVFMpLCB0aGUKICAgICAgSXNzdWVyIFNIT1VMRCBpZGVudGlmeSB0 aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24KICAgICAgU2VydmVyLgoK ICAgbyAgVGhlIFN1YmplY3QgU0hPVUxEIGluZGljYXRlIHRvIHRoZSBBdXRob3JpemF0aW9uIFNl cnZlciB0aGF0IHRoZQogICAgICBjbGllbnQgaXMgYWN0aW5nIG9uLWJlaGFsZiBvZiBhbiBhbm9u eW1vdXMgdXNlciBhcyBkZWZpbmVkIGJ5IHRoZQogICAgICBBdXRob3JpemF0aW9uIFNlcnZlci4g IEl0IGlzIGltcGxpZWQgdGhhdCBhdXRob3JpemF0aW9uIGlzIGJhc2VkCiAgICAgIHVwb24gYWRk aXRpb25hbCBjcml0ZXJpYSwgc3VjaCBhcyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb3IgY2xhaW1z CiAgICAgIHByb3ZpZGVkIGluIHRoZSBhc3NlcnRpb24uICBGb3IgZXhhbXBsZSwgYSBjbGllbnQg bWF5IHByZXNlbnQgYW4KICAgICAgYXNzZXJ0aW9uIGZyb20gYSB0cnVzdGVkIGlzc3VlciBhc3Nl cnRpbmcgdGhhdCB0aGUgYmVhcmVyIGlzIG92ZXIKICAgICAgMTggdmlhIGFuIGluY2x1ZGVkIGNs YWltLiAgSW4gdGhpcyBjYXNlLCBubyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uCiAgICAgIGFib3V0 IHRoZSB1c2VyJ3MgaWRlbnRpdHkgaXMgaW5jbHVkZWQgeWV0IGFsbCB0aGUgZGF0YSBuZWVkZWQg dG8KICAgICAgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGlzIHByZXNlbnQuCgogICBvICBUaGUgQXVk aWVuY2Ugb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBBdXRob3JpemF0aW9uCiAg ICAgIFNlcnZlciBhbmQgTUFZIGJlIHRoZSBVUkwgb2YgdGhlIFRva2VuIEVuZHBvaW50LgoKICAg byAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGFzc2VydGlvbidz IHNpZ25hdHVyZQogICAgICB0byB2ZXJpZnkgdGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uLgoK CjcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IGFwcGx5IHdoZW4gdXNpbmcKICAgYXNzZXJ0aW9u cyB3aXRoIE9BdXRoIDIuMCBhcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIEFzCiAgIGRp c2N1c3NlZCBpbiBTZWN0aW9uIDMsIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IHdheXMgdG8gb2J0 YWluCgoKCkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEzICAg ICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9uIEZy YW1ld29yayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCiAgIGFzc2VydGlvbnM6 IGVpdGhlciBhcyBzZWxmLWlzc3VlZCBvciBvYnRhaW5lZCBmcm9tIGEgdGhpcmQgcGFydHkKICAg dG9rZW4gc2VydmljZS4gIFdoaWxlIHRoZSBhY3R1YWwgaW50ZXJhY3Rpb25zIGZvciBvYnRhaW5p bmcgYW4KICAgYXNzZXJ0aW9uIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 LCB0aGUgZGV0YWlscyBhcmUKICAgaW1wb3J0YW50IGZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2 ZS4gIFNlY3Rpb24gMyBkaXNjdXNzZXMgdGhlIGhpZ2gKICAgbGV2ZWwgYXJjaGl0ZWN0dXJhbCBh c3BlY3RzLiAgTWFueSBvZiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMKICAgZGlzY3Vzc2Vk IGluIHRoaXMgc2VjdGlvbiBhcmUgYXBwbGljYWJsZSB0byBib3RoIHRoZSBPQXV0aCBleGNoYW5n ZQogICBhcyB3ZWxsIGFzIHRoZSBjbGllbnQgb2J0YWluaW5nIHRoZSBhc3NlcnRpb24uCgogICBU aGUgcmVtYWluZGVyIG9mIHRoaXMgc2VjdGlvbiBmb2N1c2VzIG9uIHRoZSBleGNoYW5nZXMgdGhh dCBjb25jZXJuCiAgIHByZXNlbnRpbmcgYW4gYXNzZXJ0aW9uIGZvciBjbGllbnQgYXV0aGVudGlj YXRpb24gYW5kIGZvciB0aGUKICAgYXV0aG9yaXphdGlvbiBncmFudC4KCjcuMS4gIEZvcmdlZCBB c3NlcnRpb24KCiAgIFRocmVhdDoKICAgICAgQW4gYWR2ZXJzYXJ5IGNvdWxkIGZvcmdlIG9yIGFs dGVyIGFuIGFzc2VydGlvbiBpbiBvcmRlciB0byBvYnRhaW4KICAgICAgYW4gYWNjZXNzIHRva2Vu IChpbiBjYXNlIG9mIHRoZSBhdXRob3JpemF0aW9uIGdyYW50KSBvciB0bwogICAgICBpbXBlcnNv bmF0ZSBhIGNsaWVudCAoaW4gY2FzZSBvZiB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uCiAgICAg IG1lY2hhbmlzbSkuCgoKICAgQ291bnRlcm1lYXN1cmVzOgogICAgICBUbyBhdm9pZCB0aGlzIGtp bmQgb2YgYXR0YWNrLCB0aGUgZW50aXRpZXMgbXVzdCBhc3N1cmUgdGhhdCBwcm9wZXIKICAgICAg bWVjaGFuaXNtcyBmb3IgcHJvdGVjdGluZyB0aGUgaW50ZWdyaXR5IG9mIHRoZSBhc3NlcnRpb24g YXJlCiAgICAgIGVtcGxveWVkLiAgVGhpcyBpbmNsdWRlcyB0aGUgaXNzdWVyIGRpZ2l0YWxseSBz aWduaW5nIHRoZQogICAgICBhc3NlcnRpb24gb3IgY29tcHV0aW5nIGEga2V5ZWQgbWVzc2FnZSBk aWdlc3Qgb3ZlciB0aGUgYXNzZXJ0aW9uLgoKNy4yLiAgU3RvbGVuIEFzc2VydGlvbgoKICAgVGhy ZWF0OgogICAgICBBbiBhZHZlcnNhcnkgbWF5IGJlIGFibGUgb2J0YWluIGFuIGFzc2VydGlvbiAo ZS5nLiwgYnkKICAgICAgZWF2ZXNkcm9wcGluZykgYW5kIHRoZW4gcmV1c2UgaXQgKHJlcGxheSBp dCkgYXQgYSBsYXRlciBwb2ludCBpbgogICAgICB0aW1lLgoKCiAgIENvdW50ZXJtZWFzdXJlczoK ICAgICAgVGhlIHByaW1hcnkgbWl0aWdhdGlvbiBmb3IgdGhpcyB0aHJlYXQgaXMgdGhlIHVzZSBv ZiBhIHNlY3VyZQogICAgICBjb21tdW5pY2F0aW9uIGNoYW5uZWwgd2l0aCBzZXJ2ZXIgYXV0aGVu dGljYXRpb24gZm9yIGFsbCBuZXR3b3JrCiAgICAgIGV4Y2hhbmdlcy4KCiAgICAgIEFuIGFzc2Vy dGlvbiBtYXkgYWxzbyBjb250YWluIHNldmVyYWwgZWxlbWVudHMgdG8gcHJldmVudCByZXBsYXkK ICAgICAgYXR0YWNrcy4gIFRoZXJlIGlzLCBob3dldmVyLCBhIGNsZWFyIHRyYWRlb2ZmIGJldHdl ZW4gcmV1c2luZyBhbgogICAgICBhc3NlcnRpb24gZm9yIG11bHRpcGxlIGV4Y2hhbmdlcyBhbmQg b2J0YWluaW5nIGFuZCBjcmVhdGluZyBuZXcKICAgICAgZnJlc2ggYXNzZXJ0aW9ucy4KCiAgICAg IEF1dGhvcml6YXRpb24gU2VydmVycyBhbmQgUmVzb3VyY2UgU2VydmVycyBtYXkgdXNlIGEgY29t YmluYXRpb24KICAgICAgb2YgdGhlIEFzc2VydGlvbiBJRCBhbmQgSXNzdWVkIEF0L0V4cGlyZXMg QXQgYXR0cmlidXRlcyBmb3IgcmVwbGF5CiAgICAgIHByb3RlY3Rpb24uICBQcmV2aW91c2x5IHBy b2Nlc3NlZCBhc3NlcnRpb25zIG1heSBiZSByZWplY3RlZCBiYXNlZAoKCgpDYW1wYmVsbCwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAx N10KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIu MCAgICAgICBKYW51YXJ5IDIwMTMKCgogICAgICBvbiB0aGUgQXNzZXJ0aW9uIElELiAgVGhlIGFk ZGl0aW9uIG9mIHRoZSB2YWxpZGl0eSB3aW5kb3cgcmVsaWV2ZXMKICAgICAgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGZyb20gbWFpbnRhaW5pbmcgYW4gaW5maW5pdGUgc3RhdGUgdGFibGUKICAg ICAgb2YgcHJvY2Vzc2VkIGFzc2VydGlvbiBJRHMuCgo3LjMuICBVbmF1dGhvcml6ZWQgRGlzY2xv c3VyZSBvZiBQZXJzb25hbCBJbmZvcm1hdGlvbgoKICAgVGhyZWF0OgogICAgICBUaGUgYWJpbGl0 eSBmb3Igb3RoZXIgZW50aXRpZXMgdG8gb2J0YWluIGluZm9ybWF0aW9uIGFib3V0IGFuCiAgICAg IGluZGl2aWR1YWwsIHN1Y2ggYXMgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24sIHJvbGUgaW4g YW4KICAgICAgb3JnYW5pemF0aW9uLCBvciBvdGhlciBhdXRob3JpemF0aW9uIHJlbGV2YW50IGlu Zm9ybWF0aW9uLCByYWlzZXMKICAgICAgcHJpdmFjeSBjb25jZXJucy4KCgogICBDb3VudGVybWVh c3VyZXM6CiAgICAgIFRvIGFkZHJlc3MgdGhlIHRocmVhdHMsIHR3byBjYXNlcyBuZWVkIHRvIGJl IGRpZmZlcmVudGlhdGVkOgoKICAgICAgRmlyc3QsIGEgdGhpcmQgcGFydHkgdGhhdCBkaWQgbm90 IHBhcnRpY2lwYXRlIGluIGFueSBvZiB0aGUKICAgICAgZXhjaGFuZ2UgaXMgcHJldmVudGVkIGZy b20gZWF2ZXNkcm9wcGluZyBvbiB0aGUgY29udGVudCBvZiB0aGUKICAgICAgYXNzZXJ0aW9uIGJ5 IGVtcGxveWluZyBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBvZiB0aGUgZXhjaGFuZ2UKICAg ICAgdXNpbmcgVExTLiAgVGhpcyBlbnN1cmVzIHRoYXQgYW4gZWF2ZXNkcm9wcGVyIG9uIHRoZSB3 aXJlIGlzCiAgICAgIHVuYWJsZSB0byBvYnRhaW4gaW5mb3JtYXRpb24uICBIb3dldmVyLCB0aGlz IGRvZXMgbm90IHByZXZlbnQKICAgICAgbGVnaXRpbWF0ZSBwcm90b2NvbCBlbnRpdGllcyBmcm9t IG9idGFpbmluZyBpbmZvcm1hdGlvbiBmcm9tIGFuCiAgICAgIGFzc2VydGlvbiB0aGV5IG1heSBu b3QgaGF2ZSBiZWVuIGFsbG93ZWQgdG8gb2J0YWluLiAgU29tZQogICAgICBhc3NlcnRpb24gZm9y bWF0cyBhbGxvdyBmb3IgdGhlIGFzc2VydGlvbiB0byBiZSBlbmNyeXB0ZWQsCiAgICAgIHByZXZl bnRpbmcgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJvbSBpbnNwZWN0aW5nIHRoZSBjb250ZW50LgoK ICAgICAgU2Vjb25kLCBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBtYXkgb2J0YWluIGFuIGFzc2Vy dGlvbiB0aGF0IHdhcwogICAgICBjcmVhdGVkIGJ5IGEgdGhpcmQgcGFydHkgdG9rZW4gc2Vydmlj ZSBhbmQgdGhhdCB0b2tlbiBzZXJ2aWNlIG1heQogICAgICBoYXZlIHBsYWNlZCBhdHRyaWJ1dGVz IGludG8gdGhlIGFzc2VydGlvbi4gIFRvIG1pdGlnYXRlIHBvdGVudGlhbAogICAgICBwcml2YWN5 IHByb2JsZW1zLCBwcmlvciBjb25zZW50IGZyb20gdGhlIHJlc291cmNlIG93bmVyIGhhcyB0byBi ZQogICAgICBvYnRhaW5lZC4gIE9BdXRoIGl0c2VsZiBkb2VzIG5vdCBkaXJlY3RseSBwcm92aWRl IHN1Y2gKICAgICAgY2FwYWJpbGl0aWVzLCBidXQgdGhpcyBjb25zZW50IGFwcHJvdmFsIG1heSBi ZSBvYnRhaW5lZCB1c2luZwogICAgICBvdGhlciBpZGVudGl0eSBtYW5hZ2VtZW50IHByb3RvY29s cywgdXNlciBjb25zZW50IGludGVyYWN0aW9ucywgb3IKICAgICAgaW4gYW4gb3V0LW9mLWJhbmQg ZmFzaGlvbi4KCiAgICAgIEZvciB0aGUgY2FzZXMgd2hlcmUgYSB0aGlyZCBwYXJ0eSB0b2tlbiBz ZXJ2aWNlIGNyZWF0ZXMgYXNzZXJ0aW9ucwogICAgICB0byBiZSB1c2VkIGZvciBjbGllbnQgYXV0 aGVudGljYXRpb24sIHByaXZhY3kgY29uY2VybnMgYXJlCiAgICAgIHR5cGljYWxseSBsb3dlciwg c2luY2UgbWFueSBvZiB0aGVzZSBjbGllbnRzIGFyZSBXZWIgc2VydmVycwogICAgICByYXRoZXIg dGhhbiBpbmRpdmlkdWFsIGRldmljZXMgb3BlcmF0ZWQgYnkgaHVtYW5zLiAgSWYgdGhlCiAgICAg IGFzc2VydGlvbnMgYXJlIHVzZWQgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvZiBkZXZpY2Vz IG9yCiAgICAgIHNvZnR3YXJlIHRoYXQgY2FuIGJlIGNsb3NlbHkgbGlua2VkIHRvIGVuZCB1c2Vy cywgdGhlbiBwcml2YWN5CiAgICAgIHByb3RlY3Rpb24gc2FmZWd1YXJkcyBuZWVkIHRvIGJlIHRh a2VuIGludG8gY29uc2lkZXJhdGlvbi4KCiAgICAgIEZ1cnRoZXIgZ3VpZGFuY2Ugb24gcHJpdmFj eSBmcmllbmRseSBwcm90b2NvbCBkZXNpZ24gY2FuIGJlIGZvdW5kCiAgICAgIGluIFtJLUQuaWFi LXByaXZhY3ktY29uc2lkZXJhdGlvbnNdLgoKCgoKCgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCAgICAgICBKYW51 YXJ5IDIwMTMKCgo4LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBpcyBhIHJlcXVlc3Qg dG8gYWRkIHRocmVlIHZhbHVlcywgYXMgbGlzdGVkIGluIHRoZSBzdWItc2VjdGlvbnMKICAgYmVs b3csIHRvIHRoZSAiT0F1dGggUGFyYW1ldGVycyIgcmVnaXN0cnkgZXN0YWJsaXNoZWQgYnkgUkZD IDY3NDkuCiAgIFtSRkM2NzQ5XQoKOC4xLiAgYXNzZXJ0aW9uIFBhcmFtZXRlciBSZWdpc3RyYXRp b24KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBhc3NlcnRpb24KCiAgIG8gIFBhcmFtZXRlciB1c2Fn ZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAoKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYK CiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbdGhpcyBkb2N1bWVudF1dCgo4LjIu ICBjbGllbnRfYXNzZXJ0aW9uIFBhcmFtZXRlciBSZWdpc3RyYXRpb24KCiAgIG8gIFBhcmFtZXRl ciBuYW1lOiBjbGllbnRfYXNzZXJ0aW9uCgogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IHRva2VuIHJlcXVlc3QKCiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCgogICBvICBTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbW3RoaXMgZG9jdW1lbnRdXQoKOC4zLiAgY2xpZW50X2Fz c2VydGlvbl90eXBlIFBhcmFtZXRlciBSZWdpc3RyYXRpb24KCiAgIG8gIFBhcmFtZXRlciBuYW1l OiBjbGllbnRfYXNzZXJ0aW9uX3R5cGUKCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjog dG9rZW4gcmVxdWVzdAoKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKCiAgIG8gIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbdGhpcyBkb2N1bWVudF1dCgoKOS4gIFJlZmVyZW5jZXMK CjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVp cmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDNjc0 OV0gIEhhcmR0LCBELiwgIlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiLAog ICAgICAgICAgICAgIFJGQyA2NzQ5LCBPY3RvYmVyIDIwMTIuCgoKCgoKQ2FtcGJlbGwsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMTld CgwKSW50ZXJuZXQtRHJhZnQgICAgICBBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAg ICAgICAgSmFudWFyeSAyMDEzCgoKOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5pYWItcHJpdmFjeS1jb25zaWRlcmF0aW9uc10KICAgICAgICAgICAgICBDb29wZXIsIEEuLCBU c2Nob2ZlbmlnLCBILiwgQWJvYmEsIEIuLCBQZXRlcnNvbiwgSi4sCiAgICAgICAgICAgICAgTW9y cmlzLCBKLiwgSGFuc2VuLCBNLiwgYW5kIFIuIFNtaXRoLCAiUHJpdmFjeQogICAgICAgICAgICAg IENvbnNpZGVyYXRpb25zIGZvciBJbnRlcm5ldCBQcm90b2NvbHMiLAogICAgICAgICAgICAgIGRy YWZ0LWlhYi1wcml2YWN5LWNvbnNpZGVyYXRpb25zLTAzICh3b3JrIGluIHByb2dyZXNzKSwKICAg ICAgICAgICAgICBKdWx5IDIwMTIuCgogICBbSS1ELmlldGYtb2F1dGgtand0LWJlYXJlcl0KICAg ICAgICAgICAgICBKb25lcywgTS4sIENhbXBiZWxsLCBCLiwgYW5kIEMuIE1vcnRpbW9yZSwgIkpT T04gV2ViIFRva2VuCiAgICAgICAgICAgICAgKEpXVCkgQmVhcmVyIFRva2VuIFByb2ZpbGVzIGZv ciBPQXV0aCAyLjAiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0w NCAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMi4KCiAgIFtJ LUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXJdCiAgICAgICAgICAgICAgQ2FtcGJlbGwsIEIuIGFu ZCBDLiBNb3J0aW1vcmUsICJTQU1MIDIuMCBCZWFyZXIgQXNzZXJ0aW9uCiAgICAgICAgICAgICAg UHJvZmlsZXMgZm9yIE9BdXRoIDIuMCIsIGRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTE1 CiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDEyLgoKICAgW09B U0lTLldTLVRydXN0XQogICAgICAgICAgICAgIE5hZGFsaW4sIEEuLCBFZC4sIEdvb2RuZXIsIE0u LCBFZC4sIEd1ZGdpbiwgTS4sIEVkLiwKICAgICAgICAgICAgICBCYXJiaXIsIEEuLCBFZC4sIGFu ZCBILiBHcmFucXZpc3QsIEVkLiwgIldTLVRydXN0IiwKICAgICAgICAgICAgICBGZWIgMjAwOS4K CiAgIFtSRkM2NzU1XSAgQ2FtcGJlbGwsIEIuIGFuZCBILiBUc2Nob2ZlbmlnLCAiQW4gSUVURiBV Uk4gU3ViLU5hbWVzcGFjZQogICAgICAgICAgICAgIGZvciBPQXV0aCIsIFJGQyA2NzU1LCBPY3Rv YmVyIDIwMTIuCgoKQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBhdXRob3Jz IHdpc2ggdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBwZW9wbGUgdGhhdCBoYXZlIGluZmx1ZW5jZWQK ICAgb3IgY29udHJpYnV0ZWQgdGhpcyBzcGVjaWZpY2F0aW9uOiBQYXVsIE1hZHNlbiwgRXJpYyBT YWNocywgSmlhbiBDYWksCiAgIFRvbnkgTmFkYWxpbiwgSGFubmVzIFRzY2hvZmVuaWcsIHRoZSBh dXRob3JzIG9mIHRoZSBPQXV0aCBXUkFQCiAgIHNwZWNpZmljYXRpb24sIGFuZCB0aGUgbWVtYmVy cyBvZiB0aGUgT0F1dGggd29ya2luZyBncm91cC4KCgpBcHBlbmRpeCBCLiAgRG9jdW1lbnQgSGlz dG9yeQoKICAgW1sgdG8gYmUgcmVtb3ZlZCBieSB0aGUgUkZDIGVkaXRvciBiZWZvcmUgcHVibGlj YXRpb24gYXMgYW4gUkZDIF1dCgogICAtMTAKCiAgIG8gIENoYW5nZSB0ZXJtICJQcmluY2lwYWwi IHRvICJTdWJqZWN0Ii4KCiAgIG8gIEFkZGVkIEludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbi4KCiAgIC0wOQoKCgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg SnVseSAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgIEFzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCAgICAgICBKYW51YXJ5IDIwMTMK CgogICBvICBBbGxvdyBhdWRpZW5jZSB2YWx1ZXMgdG8gbm90IGJlIFVSSXMuCgogICBvICBBZGRl ZCBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVy IGFuZAogICAgICBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIuCgogICBvICBDbGFyaWZpZWQg dGhhdCB0aGUgc3RhdGVtZW50cyBhYm91dCBwb3NzaWJsZSBpc3N1ZXJzIGFyZSBub24tCiAgICAg IG5vcm1hdGl2ZSBieSB1c2luZyB0aGUgbGFuZ3VhZ2UgIkV4YW1wbGVzIG9mIGlzc3VlcnMiLgoK ICAgLTA4CgogICBvICBVcGRhdGUgcmVmZXJlbmNlIHRvIFJGQyA2NzU1IGZyb20gZHJhZnQtaWV0 Zi1vYXV0aC11cm4tc3ViLW5zCgogICBvICBUaWR5IHVwIElBTkEgY29uc2lkZXJhdGlvbiBzZWN0 aW9uCgogICBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDcKCiAgIG8gIFJlZmVyZW5jZSBS RkMgNjc0OS4KCiAgIG8gIFJlbW92ZSBleHRyYW5lb3VzIHdvcmQgcGVyCiAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMDI5Lmh0bWwK CiAgIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wNgoKICAgbyAgQWRkIG1vcmUgdGV4dCB0 byBpbnRybyBleHBsYWluaW5nIHRoYXQgYW4gYXNzZXJ0aW9uIGdyYW50IHR5cGUgY2FuCiAgICAg IGJlIHVzZWQgd2l0aCBvciB3aXRob3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbi9pZGVudGlmaWNh dGlvbiBhbmQKICAgICAgdGhhdCBjbGllbnQgYXNzZXJ0aW9uIGF1dGhlbnRpY2F0aW9uIGlzIG5v dGhpbmcgbW9yZSB0aGFuIGFuCiAgICAgIGFsdGVybmF0aXZlIHdheSBmb3IgYSBjbGllbnQgdG8g YXV0aGVudGljYXRlIHRvIHRoZSB0b2tlbiBlbmRwb2ludAoKICAgZHJhZnQtaWV0Zi1vYXV0aC1h c3NlcnRpb25zLTA1CgogICBvICBOb24tbm9ybWF0aXZlIGVkaXRvcmlhbCBjbGVhbnVwcwoKICAg ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA0CgogICBvICBVcGRhdGVkIGRvY3VtZW50IHRv IGluY29ycG9yYXRlIHRoZSByZXZpZXcgY29tbWVudHMgZnJvbSB0aGUKICAgICAgc2hlcGhlcmQg LSB0aHJlYWQgYW5kIGFsdGVybmF0aXZlIGRyYWZ0IGF0CiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA5NDM3Lmh0bWwKCiAgIG8gIEFk ZGVkIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLW9hdXRoLXVybi1zdWItbnMgYW5kIGluY2x1ZGUK ICAgICAgc3VnZ2VzdGlvbnMgb24KICAgICAgdXJuOmlldGY6cGFyYW1zOm9hdXRoOltncmFudC10 eXBlfGNsaWVudC1hc3NlcnRpb24tdHlwZV06KiBVUk5zCgogICBkcmFmdC1pZXRmLW9hdXRoLWFz c2VydGlvbnMtMDMKCiAgIG8gIHVwZGF0ZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtb2F1dGgt djIgZnJvbSAtMjUgdG8gLTI2CgogICBkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDIKCgoK CkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEzICAgICAgICAg ICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9uIEZyYW1ld29y ayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCiAgIG8gIEFkZGVkIHRleHQgYWJv dXQgbGltaXRlZCBsaWZldGltZSBBVHMgYW5kIFJUcyBwZXIKICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDgyOTguaHRtbC4KCiAgIG8g IENoYW5nZWQgdGhlIGxpbmUgYnJlYWtzIGluIHNvbWUgZXhhbXBsZXMgdG8gYXZvaWQgYXdrd2Fy ZAogICAgICByZW5kZXJpbmcgdG8gdGV4dCBmb3JtYXQuICBBbHNvIHJlbW92ZWQgZW5jb2RlZCAn PScgcGFkZGluZyBmcm9tIGEKICAgICAgZmV3IGV4YW1wbGVzIGJlY2F1c2UgYm90aCBrbm93biBk ZXJpdmF0aXZlIHNwZWNzLCBTQU1MIGFuZCBKV1QsCiAgICAgIG9taXQgdGhlIHBhZGRpbmcgY2hh ciBpbiBzZXJpYWxpemF0aW9uL2VuY29kaW5nLgoKICAgbyAgUmVtb3ZlIHNlY3Rpb24gNyBvbiBl cnJvciByZXNwb25zZXMgYW5kIG1vdmUgdGhhdCAoc29tZXdoYXQKICAgICAgbW9kaWZpZWQpIGNv bnRlbnQgaW50byBzdWJzZWN0aW9ucyBvZiBzZWN0aW9uIDQgYnJva2VuIHVwIGJ5CiAgICAgIGF1 dGhuL2F1dGh6IHBlcgogICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cwODczNS5odG1sLgoKICAgbyAgUmV3b3JrIHRoZSB0ZXh0IGFib3V0 ICJNVVNUIHZhbGlkYXRlIC4uLiBpbiBvcmRlciB0byBlc3RhYmxpc2ggYQogICAgICBtYXBwaW5n IGJldHdlZW4gLi4uIiBwZXIKICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4NzIuaHRtbAogICAgICBhbmQKICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg3NDkuaHRtbC4K CiAgIG8gIENoYW5nZSAiVGhlIFByaW5jaXBhbCBNVVNUIGlkZW50aWZ5IGFuIGF1dGhvcml6ZWQg YWNjZXNzb3IuICBJZgogICAgICB0aGUgYXNzZXJ0aW9uIGlzIHNlbGYtaXNzdWVkLCB0aGUgUHJp bmNpcGFsIFNIT1VMRCBiZSB0aGUKICAgICAgY2xpZW50X2lkIiBpbiA2LjEgcGVyCiAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4ODcz Lmh0bWwuCgogICBvICBVcGRhdGUgcmVmZXJlbmNlIGluIDQuMSB0byBwb2ludCB0byAyLjMgKHJh dGhlciB0aGFuIDMuMikgb2YKICAgICAgb2F1dGgtdjIgKHJhdGhlciB0aGFuIHNlbGYpCiAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4 ODc0Lmh0bWwuCgogICBvICBNb3ZlIHRoZSAiU2VjdGlvbiAzIG9mIiBvdXQgb2YgdGhlIHhyZWYg dG8gaG9wZWZ1bGx5IGZpeCB0aGUgbGluawogICAgICBpbiA0LjEgYW5kIHJlbW92ZSB0aGUgY2xp ZW50X2lkIGJ1bGxldCBmcm9tIDQuMiBwZXIKICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4NzUuaHRtbC4KCiAgIG8gIEFkZCByZWYg dG8gU2VjdGlvbiAzLjMgb2Ygb2F1dGgtdjIgZm9yIHNjb3BlIGRlZmluaXRpb24gYW5kIHJlbW92 ZQogICAgICBzb21lIHRoZW4gcmVkdW5kYW50IHRleHQgcGVyCiAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4ODkwLmh0bWwuCgogICBv ICBDaGFuZ2UgIlRoZSBmb2xsb3dpbmcgZm9ybWF0IGFuZCBwcm9jZXNzaW5nIHJ1bGVzIFNIT1VM RCBiZQogICAgICBhcHBsaWVkIiB0byAiVGhlIGZvbGxvd2luZyBmb3JtYXQgYW5kIHByb2Nlc3Np bmcgcnVsZXMgYXBwbHkiIGluCiAgICAgIHNlY3Rpb25zIDYueCB0byByZW1vdmUgY29uZmxpY3Rp bmcgbm9ybWF0aXZlIHF1YWxpZmljYXRpb24gb2YKICAgICAgb3RoZXIgbm9ybWF0aXZlIHN0YXRl bWVudHMgcGVyCiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0 aC9jdXJyZW50L21zZzA4ODkyLmh0bWwuCgogICBvICBBZGQgdGV4dCB0aGUgY2xpZW50X2lkIG11 c3QgaWQgdGhlIGNsaWVudCB0byA0LjEgYW5kIHJlbW92ZQogICAgICBzaW1pbGFyIHRleHQgZnJv bSBvdGhlciBwbGFjZXMgcGVyCiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9vYXV0aC9jdXJyZW50L21zZzA4ODkzLmh0bWwuCgogICBvICBSZW1vdmUgdGhlIE1VU1Qg ZnJvbSB0aGUgdGV4dCBwcmlvciB0byB0aGUgSFRUUCBwYXJhbWV0ZXIKICAgICAgZGVmaW5pdGlv bnMgcGVyCgoKCkNhbXBiZWxsLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDEz ICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXNzZXJ0aW9u IEZyYW1ld29yayBmb3IgT0F1dGggMi4wICAgICAgIEphbnVhcnkgMjAxMwoKCiAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4OTIwLmh0 bWwuCgogICBvICBVcGRhdGVkIGV4YW1wbGVzIHRvIHVzZSBncmFudF90eXBlIGFuZCBjbGllbnRf YXNzZXJ0aW9uX3R5cGUKICAgICAgdmFsdWVzIGZyb20gdGhlIE9BdXRoIFNBTUwgQXNzZXJ0aW9u IFByb2ZpbGVzIHNwZWMuCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBCcmlhbiBDYW1wYmVsbAog ICBQaW5nIElkZW50aXR5IENvcnAuCgogICBFbWFpbDogYnJpYW4uZC5jYW1wYmVsbEBnbWFpbC5j b20KCgogICBDaHVjayBNb3J0aW1vcmUKICAgU2FsZXNmb3JjZS5jb20KCiAgIEVtYWlsOiBjbW9y dGltb3JlQHNhbGVzZm9yY2UuY29tCgoKICAgTWljaGFlbCBCLiBKb25lcwogICBNaWNyb3NvZnQK CiAgIEVtYWlsOiBtYmpAbWljcm9zb2Z0LmNvbQoKCiAgIFlhcm9uIFkuIEdvbGFuZAogICBNaWNy b3NvZnQKCiAgIEVtYWlsOiB5YXJvbmdAbWljcm9zb2Z0LmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoK CgpDYW1wYmVsbCwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAxMyAgICAgICAg ICAgICAgICBbUGFnZSAyM10KDAo= --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_ Content-Type: application/pdf; name="draft-ietf-oauth-assertions-10.pdf" Content-Description: draft-ietf-oauth-assertions-10.pdf Content-Disposition: attachment; filename="draft-ietf-oauth-assertions-10.pdf"; size=171748; creation-date="Fri, 18 Jan 2013 22:50:04 GMT"; modification-date="Fri, 18 Jan 2013 22:49:40 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKMSAwIG9iago8PAovVGl0bGUgKP7/AEEAcwBzAGUAcgB0AGkAbwBuACAARgByAGEA bQBlAHcAbwByAGsAIABmAG8AcgAgAE8AQQB1AHQAaAAgADIALgAwKQovQ3JlYXRvciAo/v8pCi9Q cm9kdWNlciAo/v8AdwBrAGgAdABtAGwAdABvAHAAZABmKQovQ3JlYXRpb25EYXRlIChEOjIwMTMw MTE4MjM0OTI5KzAxJzAwJykKPj4KZW5kb2JqCjMgMCBvYmoKPDwKL1R5cGUgL0V4dEdTdGF0ZQov U0EgdHJ1ZQovU00gMC4wMgovY2EgMS4wCi9DQSAxLjAKL0FJUyBmYWxzZQovU01hc2sgL05vbmU+ PgplbmRvYmoKNCAwIG9iagpbL1BhdHRlcm4gL0RldmljZVJHQl0KZW5kb2JqCjEwIDAgb2JqClsw IC9YWVogNDcuNTE5OTk5OSAgCjY3NS40Mzk5OTkgIDBdCmVuZG9iagoxMSAwIG9iagpbMCAvWFla IDQ3LjUxOTk5OTkgIAo1ODcuMTE5OTk5ICAwXQplbmRvYmoKMTIgMCBvYmoKWzAgL1hZWiA0Ny41 MTk5OTk5ICAKMTE1Ljc1OTk5OSAgMF0KZW5kb2JqCjEzIDAgb2JqClswIC9YWVogNDcuNTE5OTk5 OSAgCjQxNC4zMTk5OTkgIDBdCmVuZG9iagoxNCAwIG9iagpbMCAvWFlaIDQ3LjUxOTk5OTkgIAo4 NS45OTk5OTk5ICAwXQplbmRvYmoKMTUgMCBvYmoKWzAgL1hZWiA0Ny41MTk5OTk5ICAKMjUzLjk5 OTk5OSAgMF0KZW5kb2JqCjE2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgNzgyLjk1OTk5OSAgNTQzLjg0MDAwMCAgNzkwLjYzOTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIz dG9jCj4+CmVuZG9iagoxNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzc4LjIzOTk5OTkgIDQ5LjUxOTk5OTkgIDg4Ljc5OTk5OTkgIDYwLjA3OTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0 NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM292 ZXJ2aWV3Cj4+CmVuZG9iagoxOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzkzLjU5OTk5OTkgIDM3Ljk5OTk5OTkgIDExNC43MTk5OTkgIDQ4LjU1OTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMy M0ludGVyb3BlcmFiaWxpdHkKPj4KZW5kb2JqCjUgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVu dCAyIDAgUgovQ29udGVudHMgMTkgMCBSCi9SZXNvdXJjZXMgMjEgMCBSCi9Bbm5vdHMgMjIgMCBS Ci9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iagoyMSAwIG9iago8PAovQ29sb3JTcGFj ZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4 dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAg UgovRjcgNyAwIFIKL0Y4IDggMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRv YmoKMjIgMCBvYmoKWyAxNiAwIFIgMTcgMCBSIDE4IDAgUiBdCmVuZG9iagoxOSAwIG9iago8PAov TGVuZ3RoIDIwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXVtv47gVfvev 0HOByYjUHSgWSDJJgT4UCBKgD4s+FLOdLRaTRaf70L9fyZJt+nySPvKYku0kyexOwpHIw3O/kf78 l+d/Jr/+kXy+f/5P8nX4+/55k96kRdN/JWn7/ckdsPVNZtPuK6lNdlNW29Gvr5sfyY/N0+ap/X/3 94/NbtZ0+/3H1983n/v1hqe60ddN3ZTt7GlqsvbX7+6vxjZFO3/7czueyl+7h/+9+fufkt9nl9r/ y02eDl+TP7vv/dgYe1Nvx812UvFru19bJd0fYxNTJv/91+Zbu68ll8vTdderkjxfd3urrlclpVl3 e6uuVyVVve72Vl2vSppi3e2tul6VmHatVfe37oJVp89X3uCqC7YbzMuVNzizYJlmjTVFWU/+7C6Y ZcMCecsWTZpvLXJrrLO86CxwmhbduCm7hzpzXJcm72DvFj8et9WN3Y3v5vk+MX9n0L85MDfZ8DX5 8xHMR7DZpncVXsVaud3CCbC54+5edvN8n5hfwhwJzxMwT8EwRZcl8DxO61cx7oPncd6Y4qVjmHfu aAMen4ewlJ2jUXd/TLETlSefF3frm+23u2o/8nz/t9Y1/V9ik7+2//2W/PyP9r1fHAcVX7x72Xx+ LBOTJi/fkn6hT/1fLz2gn7Imefkl+XMHx0/Jy2+bzlEeBux2oDoMZNuB+jCQyyf6OR5ejlz0CbCq CbBaRQpQ1RSqUkLlbKSQT5TyiWo70BwGavlKI1+53Q7kh4E7+cS9nOMLheNB7haWBcBg+48xaJBb hwgmFTg3wCtyJ0aSyUg4TS5x/iifkHQzpRyo5LJVJAYsyt2MNSWr5DcAE6ko58BXYFI5h7mVggBP AMqBRfNYvHLA170Ey1cuTidalcUkGtBIii+yIxVw8yC1BsDB1RmQVU5qHpl4WinRHnBwfMArwJHw CuADIDXBbG6thOM2FpsfOAz0G1WJNgs3MkB7KUyoRemkA9ueLm7NfmfSD7C95i6mdTtqhQkwT2Pz UsIBsiMtiK3kKzCpxDAOAB35HLdy4E4O3Mdi4gPdwK5T9HhQBShLORIENhqLmrQ6JkEE9B3mBIn2 UALAkYAd6hsMKI+AHZvHx85+TvslWEWi/yuxgwzpa6cioCs38dG1nxPNgxQktGs0OkD7Ck8s4xN2 6Crq+OjazwmCxBkBlT91WDysAejph7WtgU/eQv4bzSXMTbalU53YcpxO7W9WBvDG4euejU0+N5LB SM+WJj2MFFJgSukq9tQzDoFrGGnkS7fwCC59B+D19LDgprvP9IrIpnMA4loPMA+A/Cgx4TOvnGWI 8l3wgHaDCncnllQYPOM5FBtAjZEe5BD7C5WhZsqsXeuTreyxSQ2lMaAZ9g55JGBJ5ApgY7kMzork BWBVlMKVEAmXJb2wNmxhyAW4jzi8deCsvusg3RZKxn8+1qf8eQ8dG7bowOKmGNW7ZfIpM3sPZSC/ Oey6kQi30tmCqC2X9vFOvDIkoWCOY9yiNfK0QeNC3iQmG8NA0eUsc3uMgWpmv9m461PJ3QAfO0+U ctJq3IUFFQChL8gP+HVgpGpJGYh0IQXmvPJlnHaQjHGeeJCrwKSPbLeDmZnDGCfDBNuBjcxnQJdz 7DQmlAWcR6yUIdi/XGawdXObAVDppDgHkB+YHbAs5xhs8Bwd6BwIOmxu3LCHSXrW5EeiDuwAkPOt AI5jSBTlZOQoWIWTFiYtpLUdHJ5mhtiKZUA8avlEQxkGtsu1UgReV8jciHrw5f7TmH1r1op9Hour PsAgV2MwhzQ4g6GH8GZGWSIcQDiq1zVsqoDjQuythwVCyGD/ACqsS/0eH16ny6ChV5jxGLwcg6m4 SQY/5+48PMQh5QzCBVU+YWSylzvGYC2iuAZFVrnqckiAOnHQ5YiUws0FWo72O2gMzD43cq4QB9iD q49FHGeFuHCMccC4LgD9CpNy/rkev1hSH5U21cDeGDsxGNk2rB3kh3u0gEGOdKAkiNz1hisebgBM KveCYTZ3A2EV+grqJC7p4eww9DWAYQwSbE45ULjSxUef3xeOCPao3ltwwCinbLg8eexVkQwDIeWp LhiIYQcglpXKFLdPIR3ct9NJnXf57H4NnrLlkX0M9atwiH0TX0F5jI8EdSixOYKoKbmYNLjCTgIZ wE5CGDISmCgI8b7S7deUYFXw+xIerJ6WESxMNg1FDP8VdqJIUvJIVaFBFJlPntihJgdfAa1M+UeT LvEoYL2roFoTRyiSuG/IoKIbrAjVgS4KVwh2y/fyUbF5WcgBjWCA8l2Ic8klnuUivP2xmeHEgdsH xo0n533OYpwbPsKzkw0Qd4zAvEDOibobHnqe44NnjMKLMxaOKnO3J0aeV1NF5i4L6HWehqORFpok CE/BP1cUyRQ+zLXl9k7UyWXmKuUl04ORq7tlemxO7DgCI5isup6kPKCLayRFHZJ60ahvwpOjI7pC igKnvY/C4R4dVacegPCAR5EgQ+WgcL8UxvNNuwrxeh/mUMjNfAwtTiH1yKFccRDtG9+drpSLNJuk G0/icv5R9HFwX+NMNt7kVSDCQFjgFY5BRezGfXPuRis62mDZVdScG1K/raNHRba/AWY4MwZnvSDd CWwB3dZzp5XAlMHhtUe57ERNdq5KUcpXKByDPLseBFychY9UI4wBEr/cuami3DeYL3FuaspRD1Id PNNK9dFwyN4ZmDpvO6ddgI14MilCqgiiMvSQ0Xfl5S1eipkIn0+zT7YojrhOcQ4EBI+GrR5dPgo7 GeUsCTdh3FVdp1svxvGbJXxXj/RKjLgkvNHHyqPOVjYLWIqx4YoIR/h55T9CYmwZ0CG3GKvQUDS7 Ost7MzirxNNR+nEilOCRb2l2Fm1DlKTVEuoihoK9FPZHwMDz5+RXVG/4XmJ0goCnTFtDeHuahfsz eWYj3DMY7uZy1JJkGCSU3C1AakH4lznh1Rxren1J+XSDU5oAqVXUoFfpLPM4MghZcujyAI+Ot2tx J9gjccpbeAAQhX3hviYv7co5MHzjrTMfJnoBEx1+mOZSzOu5vMuFFHueHWnUCKdBPJrguCSvd81D afdHYah0aAoc4f19753To2TyFIYfWJ3n7aQFtrIanqVsALU2B50/Ed7k5HGak/uavN0VIIWMIkzK ral8wgPJSzAuLHsmjYLbj5XsKQvWBvR+lVSMZM8ibHrNfiJkoHnswfsrFrnUgh4U9Ii9MnC/ePOY D2liZMhoph+B98AArw7w6HuVdtUokbOifZBH/RoHgtYbzegnGmksRrlv6uT6kPdB8l5t363N8bpC /OUrHp3pkODhHb/qwvEMD3okfNZJiV2RWVJEF1wHKToWPXqLfa8Am4s/F+m14CUGQBkkPBU1bf6K ok1N0bHJ03kR7oa9MC89gjmp9wHIxfj5/BVu+SYa64KiiRjdKx5NMgqGoRLl0SQU4545Xl7k3fyL HJX0ON5xphsQFCU23kUWLkIZfPbbIveUKDriwk2QR+0v/EQEmPUslsqt5AccfLSpnmJgwhsGNS2V crsYnAPfAukUh3/Cj1xl8CGYvKOUn1cGfRp+bA1fkd1/WSEHIH59s0cPqjw/pgbe9uvcy/QgBx7H 9Rt8iqujJlI5x8Ql1DOlBQsf0ILnF2ASCQh+/Eo2QmRQs8sdI6iqfVuObBTl0Q/KEr9kGyblhTPa CwWOFzQ2LSKg3BoperI8mtbo6W9NiXyRi4ViNJpzc837hRRd4+tc3rXILduKGDMC5S4nA8dbzhb5 PIGVem6qxtXaeI2hwt9bRGvHuli4aqbh5JEO1x705i6sAcQqiNdmX95YIji6YIlc5XRdVjFlqris R3Pvx/UeJ1rkaMPFekVZHcyWGXy0K6gP4I/w/CXyx9Ucv8uAC+k19pqT/YrDIApBVnNyBFuRzdQu LrbWiaHaefokeY+jJoiip5iuqMeR913zghDXDvIVyJt6JNFpvxWP/jWpel5142U4hbuhuIdqkWAu Rhlb0TgGKSd+p4KCk890ueaCnzgRweDk9SQznMneLBNRG1u4uwVfy6OzimdcuHDw4JZ7dAA6/6xF hbII39zFcJBHnMmVQ3hDhuKiE8itL/IhU5rughgX/gJg/OoyehrTgw0BdH5MlvsSC2bPYrQlR7AE 5eTFsx6UDT9n+6Y+Ki/GJYbnSVstcp/6xVgCj05WWhBVXL7pManHfbac2xcxjbwvZJH70hUlMP7p Vh5ofw8CEcE6VPUkGFEq0zxWp5+kghgLl9zsjpkH1d3cq5SEoQIBmxlJKvJU9yopIg8xVOilCL7z pbi5HuowPN2F3K5wQiIkTTLQ02C3F8k7xWhlWaVxJ2IBKoItaPZFiuutWEWpm8a4DP8898V7nGaN ESjxyFvR/Myxzv1RHjmE33H1zo1JDG364X6dx/16u13oTSmuI2kkwzpYaCTBsnE+mXMyoF2cXnfv 0R4/EH2uCR0g46/YA9HTm6IZvpJdF7pBQpVF0jTFTdET4nVTNe7v3zfPDiGPJzzmFFyMcMX0ZFsO KKc+mKpoOaDJjzEAHyOwaF/+FGhdh6cDmpHEgYFKchoQuGcs54TErRwA9XoPGumLfORhnOWdWaFm AcuE9FLO0dK0q/tjbGIghOHrIjGt7u85vGV408LmDFwex9cCSxMsDw7XZQhFh95AIoeLhZHnhLic 7LyONGAScFyHw6WusEnJGfzjfPoJ3I08wYIoQrdjQkAdWCEsAUBAdShQotclAOqWX9vv5EfLfqbc ctTw19dXLSM/JU+b/wNoiMrrZW5kc3RyZWFtCmVuZG9iagoyMCAwIG9iagozNTY0CmVuZG9iagoy NSAwIG9iagpbMSAvWFlaIDQ3LjUxOTk5OTkgIAo0MjguNzE5OTk5ICAwXQplbmRvYmoKMjYgMCBv YmoKWzEgL1hZWiA0Ny41MTk5OTk5ICAKNDY5Ljk5OTk5OSAgMF0KZW5kb2JqCjI3IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgODAzLjEyMDAw MCAgODguNzk5OTk5OSAgODEzLjY3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzcm5jCj4+CmVuZG9iagoyOCAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzc4LjIzOTk5OTkgIDc5MS41OTk5OTkg IDg4Ljc5OTk5OTkgIDgwMi4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM2ZyYW1ld29yawo+PgplbmRvYmoKMjkgMCBvYmoK PDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs3OC4yMzk5OTk5ICA3ODAuMDc5 OTk5ICA4OC43OTk5OTk5ICA3OTAuNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0cmFuc3BvcnRpbmcKPj4KZW5kb2JqCjMw IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAg NzY4LjU1OTk5OSAgMTE0LjcxOTk5OSAgNzc5LjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYXV0aGdyYW50cwo+PgplbmRv YmoKMzEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDguOTU5 OTk5ICA3NTcuMDM5OTk5ICAxNDAuNjM5OTk5ICA3NjcuNTk5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3IxCj4+CmVu ZG9iagozMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5 OTk5OTkgIDc0NS41MTk5OTkgIDExNC43MTk5OTkgIDc1Ni4wNzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM2NsaWVudGF1dGgK Pj4KZW5kb2JqCjMzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTA4Ljk1OTk5OSAgNzM0ICAxNDAuNjM5OTk5ICA3NDQuNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3IyCj4+CmVu ZG9iagozNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzc4LjIz OTk5OTkgIDcyMi40Nzk5OTkgIDg4Ljc5OTk5OTkgIDczMy4wMzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM2NvbnRlbnRwcm9j ZXNzaW5nCj4+CmVuZG9iagozNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzkzLjU5OTk5OTkgIDcxMC45NTk5OTkgIDExNC43MTk5OTkgIDcyMS41MTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMy M2FuY2hvcjMKPj4KZW5kb2JqCjM2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbOTMuNTk5OTk5OSAgNjk5LjQzOTk5OSAgMTE0LjcxOTk5OSAgNzA5Ljk5OTk5OSBd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1s IzIzYW5jaG9yNAo+PgplbmRvYmoKMzcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs3OC4yMzk5OTk5ICA2ODcuOTE5OTk5ICA4OC43OTk5OTk5ICA2OTguNDc5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0 bWwjMjNhbmNob3I1Cj4+CmVuZG9iagozOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDY3Ni4zOTk5OTkgIDExNC43MTk5OTkgIDY4Ni45NTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwu aHRtbCMyM2FuY2hvcjYKPj4KZW5kb2JqCjM5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNjY0Ljg3OTk5OSAgMTE0LjcxOTk5OSAgNjc1LjQz OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRt bC5odG1sIzIzYW5jaG9yNwo+PgplbmRvYmoKNDAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA2NTMuMzU5OTk5ICAxMTQuNzE5OTk5ICA2NjMu OTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5o dG1sLmh0bWwjMjNhbmNob3I4Cj4+CmVuZG9iago0MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDY0MS44Mzk5OTkgIDExNC43MTk5OTkgIDY1 Mi4zOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25z Lmh0bWwuaHRtbCMyM2FuY2hvcjkKPj4KZW5kb2JqCjQyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgNjMwLjMxOTk5OSAgODguNzk5OTk5OSAg NjQwLjg3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlv bnMuaHRtbC5odG1sIzIzU2VjdXJpdHkKPj4KZW5kb2JqCjQzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNjE4Ljc5OTk5OSAgMTE0LjcxOTk5 OSAgNjI5LjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2Vy dGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTAKPj4KZW5kb2JqCjQ0IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNjA3LjI3OTk5OSAgMTE0Ljcx OTk5OSAgNjE3LjgzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFz c2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTEKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTk1Ljc1OTk5OSAgMTE0 LjcxOTk5OSAgNjA2LjMxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTIKPj4KZW5kb2JqCjQ2IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgNTg0LjI0MDAwMCAg ODguNzk5OTk5OSAgNTk0Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTMKPj4KZW5kb2JqCjQ3IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTcyLjcxOTk5 OSAgMTE0LjcxOTk5OSAgNTgzLjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTQKPj4KZW5kb2JqCjQ4IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTYxLjE5 OTk5OSAgMTE0LjcxOTk5OSAgNTcxLjc1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTUKPj4KZW5kb2JqCjQ5IDAg b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTQ5 LjY3OTk5OSAgMTE0LjcxOTk5OSAgNTYwLjIzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAv ZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGll dGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTYKPj4KZW5kb2JqCjUw IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAg NTM4LjE1OTk5OSAgODguNzk5OTk5OSAgNTQ4LjcxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzcmZjLnJlZmVyZW5jZXMxCj4+ CmVuZG9iago1MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkz LjU5OTk5OTkgIDUyNi42Mzk5OTkgIDExNC43MTk5OTkgIDUzNy4xOTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3JmYy5yZWZl cmVuY2VzMQo+PgplbmRvYmoKNTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs5My41OTk5OTk5ICA1MTUuMTIwMDAwICAxMTQuNzE5OTk5ICA1MjUuNjc5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwj MjNyZmMucmVmZXJlbmNlczIKPj4KZW5kb2JqCjUzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgNTAzLjU5OTk5OSAgMTQ3LjM2MDAwMCAgNTE0 LjE1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMu aHRtbC5odG1sIzIzYW5jaG9yMTkKPj4KZW5kb2JqCjU0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgNDkyLjA3OTk5OSAgMTQ3LjM2MDAwMCAg NTAyLjYzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlv bnMuaHRtbC5odG1sIzIzYW5jaG9yMjAKPj4KZW5kb2JqCjU1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgNDgwLjU1OTk5OSAgODMuMDM5OTk5 OSAgNDkxLjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2Vy dGlvbnMuaHRtbC5odG1sIzIzcmZjLmF1dGhvcnMKPj4KZW5kb2JqCjU2IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDI0Ljg3OTk5OSAgNTQz Ljg0MDAwMCAgNDMyLjU1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago1NyAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEyMC40Nzk5OTkgIDM5Mi4yMzk5OTkgIDE3OS4w Mzk5OTkgIDQwMi43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRh c3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3NDkKPj4KZW5kb2JqCjU4IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgMTMwLjE1OTk5OSAgMjI5 LjkxOTk5OSAgMTQwLjcxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzSSMyZEQuaWV0ZiMyZG9hdXRoIzJkc2FtbDIjMmRiZWFy ZXIKPj4KZW5kb2JqCjU5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMzUzLjc1OTk5OSAgMTE4LjYzOTk5OSAgNDk5LjY3OTk5OSAgMTI5LjE5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2 My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzSSMy ZEQuaWV0ZiMyZG9hdXRoIzJkand0IzJkYmVhcmVyCj4+CmVuZG9iagoyMyAwIG9iago8PAovVHlw ZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyA2MCAwIFIKL1Jlc291cmNlcyA2MiAwIFIK L0Fubm90cyA2MyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjYyIDAgb2Jq Cjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2 aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0Zv bnQgPDwKL0Y2IDYgMCBSCi9GOCA4IDAgUgovRjkgOSAwIFIKL0YyNCAyNCAwIFIKPj4KL1hPYmpl Y3QgPDwKPj4KPj4KZW5kb2JqCjYzIDAgb2JqClsgMjcgMCBSIDI4IDAgUiAyOSAwIFIgMzAgMCBS IDMxIDAgUiAzMiAwIFIgMzMgMCBSIDM0IDAgUiAzNSAwIFIgMzYgMCBSIDM3IDAgUiAzOCAwIFIg MzkgMCBSIDQwIDAgUiA0MSAwIFIgNDIgMCBSIDQzIDAgUiA0NCAwIFIgNDUgMCBSIDQ2IDAgUiA0 NyAwIFIgNDggMCBSIDQ5IDAgUiA1MCAwIFIgNTEgMCBSIDUyIDAgUiA1MyAwIFIgNTQgMCBSIDU1 IDAgUiA1NiAwIFIgNTcgMCBSIDU4IDAgUiA1OSAwIFIgXQplbmRvYmoKNjAgMCBvYmoKPDwKL0xl bmd0aCA2MSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1dj9y2FX2fXzHP BbwWKVEfQFFgs7YL5CGAYQN9CPJQ2E2LwA66zUP+fjWSdiTyDOeQFDni7IyNZHfokXR5ee+5n6Te /v3TP/f//mP/9unTf/dfpp9Pn3bFQ6G68c++6P++WQ7I9qGUxeHPvhXlQ90Mo1++7573z7uPu4/9 /593oh4unH70//jyiGL4+8eX33dvx4fvxpFPTz/1v/25l/sf+/9+2//8Sz/4dbrf4Qvfd21X93QU hSj7j9+WH4XseqoOv/fjhfnx8OX/7P7xl/3vB8LkQzsQL0YClx/f9BeqfkaHT2tIfp4v7W9WdlKo urX+vrxxWU70VPtadOrhwOeun3pZqQNZRaH2tSyGufXjPQ9qUT1UPb3SHJfN4eLD+Hyfb5b7H9jz 64Lmrpz+WH/XaF7SJovh/gPNi2fJcmAr0KaPL+ZyvM83y/1NmiPx2UKzjQbbuqTg8+m1/q6PO/H5 tGzYZEmn+QUGOlAKL92qq2ovVNH0aNL/3P/vX/1DPg6qE6CgYvi7pGUcsSjo85kLf/i8e/uh3oti //nX/UjBm/HH55HoN0KJdv/56/6vB5r+tv/82+4AR9OAHAaaeaAcBtp5oDK/Md7j/ed+8iZ3D/QL pL9WPX1SPagBg7/vmm75+dvuk9NynXrYWWadu9kL28qTbFP9h0JW04xFM8y4m1lQzywIxNznMxee pa3n3ZK2aTWUuTyLAWmsqCjM6TwOA/X8jXYYENX8lQ/DyGKgNW/ygzEgKvMS+EY3PqaYR1SYbFWF LlvHz7nKVtm9zPgxO9k60sZlS5hLiqIkzUUH2QJ5FE/jV6RddPA578IkRxmopHJHJXVEpffZSY5a gUpccgByRG0imzABhQtO0ZkDFOoQt1AxPgC0AbEwQHHZgVaYr4Vpg5QEL/coirU7UNgGfPS1Pehr MyO9OMRR80B+CtvqXLIp7IIpKiOVPrDXb5FlQYX+NpSrPUM72EN+CUy3eGcSYtIuBXPPcP7mdCU4 joDIEViGUjRGIEKsMQ1AWUTYaz2sXMIBH+jsTXMPle3s64iqWQ7kh50Hipe8DgfPXOG1XwE/YZIV VWEY4FoPT1EAruCfh/hd3HmzPCaGynaX91REYXgq80B+2tbqXOLKllVKZPJUPBb57qlwt0PW68Fk Sh4u5w9ZIZN2nD817mlcphBCYCHep/OhIgCjEFfqywhh+DLzQH7oOvoyM6/D4TVrX8ZHmG7Zl/FI T4pST2zPn/OT8hFQ5IsRljl5CEN6cqbNIbGdreF2sLEON4HwOIbR5VH5E/WYZAtf4UAARpZrebC7 F8PqVuutrnc4UikjHKnyNZitziUblORqDYdwxGeRrwht5BT0lGcIAXDhNUCkBKAClbqKppBqg/xA beYH6nxte6tziStkhvkBn0XGHDQ3kA5tFaAHEAxfMTJgLwAv2mMvAA+Pb9PtOEs8hDmQ7QBJixah NHoDxfw5PxQbsb45uhXZtd7MtDlAFHRTQeCKQGBKLNb8IOlHM1p3zLpjVgaYtdIDbDfwADvTA+xy 9wCPXLJhZ94hmc8i3ysXJg5kVbmQxeVzKLIwcijzQKYKO3OJK2yGIZvXIuejsOAhJWkxDUne8KQK YgkNWtFnpKQ6XNKYLLJ0dJ1zZSyUxoAfcXl/4bCNS4cfmbm/MHPJAX5yisYm+PFZ5Dv8vCb4QWcn oIXIFtTGwJ9yA/enNN2fMnf3p/Rwf3LaTjPhj88i3/HndeMPz2XhStA9msh4ZWKYQ6kOEje8t3Al eHokqKXSW2jmz/mB1gjt1dFpgsh/6wT1TFtIgpqno2HCdJMKhgWmBEdpmHFIgnJwcdjHktUGP1lv 4GTUppNR5+5kHLlk09esk6I+ixxSLsE9/qAWvNSRW0kphnI1G2QQWjOD0OZrDFudS1y5ckxgeiwy 2EsUT3rEhoNHfwuq1W1gtzrTbnW5263O3W7lmJzzWGQMN9BrAldsoz3WAdZRjn70csc0hPrgv0J5 jx/XA/eg7jrOJkJsjH0PDp420M79aP9uPSxamDcN2FQX1HDihbYe0XQp9Gh6/pwfyg22oCyODsSH jDBsiKZn2hzMkilaaLfLwoSBEymhezAc6FSUPkeuRXIqSmk4FWXGh+a1Opds6pZ1MOyzyPwkl1y6 HE8YTNC1GOe2Oewqi7JlE4sD3N0BviaEnxho43EIXzS0qYzsQJnxMYqtziWONhlmB7wWmfvrEcp7 5fjY+bDXO8jdQS4dyPmcFxkL5JTpUmV84merc8kB5PLL03gt8h3ktAGglFc7XXYB3aEzA+j0Sbo0 RtIl4zNPR2A/HhpaAtc2T7r4HGjKhQ0Seg6JDg5Zrru0YhjhCMdZehvh1jTCGZ9E2epcskl03nkN j0XGNOKFctSl+eoJB8t1Cwq6weGVlXl4ZZX74ZUzl7iC5pgK8FnkbKtMr1aDPZy1ankyodIG8lOd AWCq+WBC7AXBcMIhwHDYzA6iU5keuUN/85Zqq3TWOdQLeKe8gII6f8sOvCvFoSkIq3O8S88lvvM6 hd1HpxbHII46lfs5iNXxrMGsdQp3RGSgUx7HNJ7ofKEnXuB2hRiSjW60AtICshDcboe9MataHAfY yOXnXBXqeJxeuWUGQWqkBIF+ir4ykKQSfEQHyhAMcIR6WgG5U3FqRR/GN7YeRNL2uy6O/PsOIur3 0EFWhtdBnpAVWfcf1GwHWpMNkNvu2ICESwCXlCmRlQkpZvAzcX8xAHvgHk2cgqfUJmEQYrUn1jiy 1nYWrVUHrVW1AZnY8dyZawPtgosZw/vLlInujbngrfmN7vQ93JIGttmKrtGmC4RNr/icT/DEV3zC JSAB79j04ZIQnj6ZA+/NS8y5TFtUmjOkw2OBH/BYPlvQXaAU+DE5fYvngsRACE4ZIkq6lpztnGVw U5N0ZJl508nMLWb7aK4D3DRAUAOmD/IATC7MuZSnAfEcT0FATMKmaBBmuw4eVC10eADCgHQw4LBQ wLF2Gy2Emz7F4NhgPhplowsEGcmA2cNk6dw4008ACjwGKAPIMUXbQcVgsWGAKzLXbMvaelEK37Bs izj3FMpCnH4ErpfvTKelgOYAc0ACZTB/mC5fKZMhaNfhplQewDUCSqeNMl4ak8TPE1DlD7AwIFTA Zb50N2/HCh2Wr9iO+Rxkf95KdR7rxEWMzh44yH04BwNjPtZhnbj7Cetkqlz5PoJiw2wtsr+9Ob0a y5eLjeI8xYiGrz5fBk5HgPBT/1MEeFf+OYFcXEeMmjlPYzioroASwTTUxYulvE1XcmVSzeAheJLX LMkBWZUAZ4JnHc0BFIcA6xGgldv4H1HMiSsmr9OGSnSaNtxYrpcbYCD9g/8lEM5CMphnd2iR4qIW SB4l+x1VBsA1ni3ni+1yEw6GDneNEWnS1ZVUZAJiYocwAGSZRoVIGNwU6icRgq8oWCfbRpPdXPwc zlPbkTbnOAYZIpqYQ9+Rr0tAtus1RQ6X8bd4Gg503z/9xRNA02Nj2I/ywiUYf2/T2WVbGY2UQueH SSluHISV5EVfnhLIJIvwqr1NZCHtLODBBy9ioPHg5QUuYwFJg40SZAGmwdUfuUtyREm2gXQMe6O8 YX17d7WrNcpvy1tFewyBJpfBJGmYgLw/aBzEXaDXvPgG04/Q/wGXuDSiwOLy9CBoFIcPnvwz7wFB NY+ASmjPBkENSP8EBNU3YE1WwvqwwWRGxzQWKUYkZkHpGFattndM+EeZCBdwCWR2UgReIWl+Xm7g 2TIuQFw8qLHgmV+HZeCud0AA6G/mHRJ9lym/JNTSVQUam6yvrNgUlab7KOsBRQ3aBI5pCM5C7gfx xfZPBXIrf6FdIw523+Kwx7ANrX2hAuoCASiVZCcKF0ve2cSTuOZsMSfJ/XVa8+Gxh0uNK0IykPvr Jwjhu2b8w7M0HkiKzCbGSUA6r+gGeM6ukcRKCyM7DUGuzrdeSG4u2VHefbxRswJHZVcgj2G1uhev BiGXR6+glP5OLj6WtiagAMEl/h2IW7kozj7sOaAPyJdyhzRGkzN8A7QSUpk8VZPvdlGLZxxBTxtZ vjyE9wwE7FGGb3Dk50033HfYaKvj9TjovA7EoS5JvjRfJUzhKMcoWIakDYJTQiv90arWMYe7KAGu UrzdX14q5X/J9dcCYligsrViUIzohC5Lkh7efM8zCdnW658vd86QvU5zemtm7Ipx3LVItdLytZ2G dQ7haQQ77xDzxVj9hMWhGAZGWd2NEAiOsbHzIuFJyk13M09DjEWuuJ4mCOKrf03lAg6oScKiAE+Q px4CGgWCaxArzUdNkOx6DC4md3kroyvXY1iLunV+qkOJksstP54hySok2bh43zdAZnuRXaply3B9 q9MY6CVoxTlo+6upw3FR/tkdXj1yOJgnBh2bZnJXInBV6hAM4ayJDlHOp7xkIjeGiWqPbgAte4XY rICKf4zqY0BUEGN7aYyukiQ7p2OcR3c1bmKaPc30mICU6hGjOXSh6gHF14D+641C8ySeJJiGAHed Nm45aENA607mGbWutTL9NWfUripRE7DtjvuFAWbM/9xyxAvu0gIYmnPBoIh7Nf57lrM5SDNgLiCo fOcRLbbizj1L6LXSWDbVeVi6nvAtxGiDt8mTTBHa3h00OwZ+RAubWvHiS120Y+ZCPQFrDy/pdA75 9xWEONvbgCMeqL3N4XExopGQnpnLZDZ5bM59a14IoEFylH0DfG3jIV3c/CnIepJNhifcTwgM+AEN IA+8D9y16z+G+ZBH72Kb42/iNX23qn55yL3pezXy8UYMy/FrPkXSJFv4AzrdUMFiHAnCa6AhkTfP dQJIBWymN9cBXRZ+qk7CLepXnGBfiXRFoUNdilpSmh4rNXrjR9ID3rPj0BnKISag6kWD1ZQWuhE2 mQs6Dhh8bQfM4R48RVQHQnj9mu+H4xwJSUzGiBxek7dwmWNluaWPAeSU0pAT+K6nJBUjgOP1ephc QGzBe2a493DBlru2rd35w8+VCUhbxygccz84YPMSPPYiIJXGq5FFrS22fPJXho3Whb/gJklZQ3a6 esChhpg/HjkmxHGk7Bgmx8j1SmUQgioVYOd43gne+JNLfwswiD+WFxT8zxa9TPNbbpsdV2pdfSgm doXQ6Vh701a7abYJnhCf5W6T49vkFHqar/3I5p0eFsc4gpfbiaMZrwxxwHUBQJWFOYKr+8FcO2AR Jl94l2WKjQDQi4QswcnA6w/5KeHbeCUX4uHdo7icRxE7Nz0AQnl3Bu7OwHbOQADkbmS341W+O9XZ DSpvNwB7yhPxEXYtbNSudj2bR67uVIvIe0VkV2iyfeNd+SEtKwFHAdANW1jXjncu8LqSSoxuAq77 vJ5IO0MCiqMOYEAd5ak4GsPgNJU7iid5dd/1gHaEE/XSvKJGdJ22lLd1aEGalx0mKTGV0lgof+/L oYYd4QTwbI7/gscGHAOSpPM9RkcLf9tDlP2dMXpG30czOG3nLB8xLLTDFgXa/propDLZaPyQkEG6 zM67bC0y30F9DxuIKQjYssAb7P29vhPNfNxoJ9nc6y9kt7WzH3u/AzbKxDuxdb3Bkb2a2PR2o5fE BQTAV4R0FhFbG+EYSxnA0xj9kTd1DFmSvAyaAofAIXhf3cXjlRSBA54V0RhPwbnwKleSUDzJqY30 ZHbrxocY5kO8+OdX9HKyGCbI34i7vLwvQgU3yl6ZkBJuMPqtrJ40jS6HDtt8AnbGcK8edhLyDWox Nktw2Y3xci0aflT8XGDe0eCaZrzGFuJXmHUeFPeotg+qm/6AApv/9unpp12x/3Mv9z/2//22//mX fvDrEgPO3GxAg9qaNTp8UvXRFxglqD6SLrE1yWzfmyRm2b73aHxl6oCDzst5oDRtfXm6uTl0omO2 8NiQDPO0mHj2OFlZnlfrzytOl9hCZ1M32t0l9LFOyLgQUrN3Y7Iui2XszKWv47JEFG1KnghR6reH NlNwJ02pRBaEkWhngVJJWVAXets9eDImCyaLIcAMQ9dgNB7IokrJA1l0Og9KADBT8m1Zqtp+CXwj MlxVstKbqFPjVVXqD4y8KtWwx3++/XUgVtUWSZnSKv32GSKWGstKqVigSmOzwKO56KMvJaQ55Xgz VEklXyld8jfAo/7v/rmfi6gHoqYfX76fCSHHEYvf+XH/cfd/oEcmtmVuZHN0cmVhbQplbmRvYmoK NjEgMCBvYmoKNDYxNAplbmRvYmoKNjUgMCBvYmoKWzIgL1hZWiA0Ny41MTk5OTk5ICAKNzU4ICAw XQplbmRvYmoKNjYgMCBvYmoKWzIgL1hZWiA0Ny41MTk5OTk5ICAKMjg2LjYzOTk5OSAgMF0KZW5k b2JqCjY3IDAgb2JqClsyIC9YWVogNDcuNTE5OTk5OSAgCjQzMS41OTk5OTkgIDBdCmVuZG9iago2 OCAwIG9iagpbMiAvWFlaIDQ3LjUxOTk5OTkgIAo3MjguMjM5OTk5ICAwXQplbmRvYmoKNjkgMCBv YmoKWzIgL1hZWiA0Ny41MTk5OTk5ICAKNDAxLjgzOTk5OSAgMF0KZW5kb2JqCjcwIDAgb2JqClsy IC9YWVogNDcuNTE5OTk5OSAgCjI1Ni44Nzk5OTkgIDBdCmVuZG9iago3MSAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDcyNC4zOTk5OTkgIDU0 My44NDAwMDAgIDczMi4wNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNzIgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNDYuNDAwMDAwICA2MjMuNTk5OTk5ICAzMDgu NjM5OTk5ICA2MzQuMTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk YXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNJIzJkRC5pZXRmIzJkb2F1dGgjMmRzYW1sMiMyZGJlYXJl cgo+PgplbmRvYmoKNzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs5Ny40Mzk5OTk5ICA2MTIuMDc5OTk5ICAyNDMuMzU5OTk5ICA2MjIuNjM5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYz LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNJIzJk RC5pZXRmIzJkb2F1dGgjMmRqd3QjMmRiZWFyZXIKPj4KZW5kb2JqCjc0IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMzk3Ljk5OTk5OSAgNTQz Ljg0MDAwMCAgNDA1LjY3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3NSAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIwMi4wNzk5OTkgIDM0Mi4zMTk5OTkgIDI2MC42 Mzk5OTkgIDM1Mi44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRh c3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzIxMTkKPj4KZW5kb2JqCjc2IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMjUzLjAzOTk5OSAgNTQz Ljg0MDAwMCAgMjYwLjcxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago2NCAwIG9iago8PAovVHlwZSAv UGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyA3NyAwIFIKL1Jlc291cmNlcyA3OSAwIFIKL0Fu bm90cyA4MCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjc5IDAgb2JqCjw8 Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNl R3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQg PDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjggOCAwIFIKL0YyNCAyNCAwIFIKPj4KL1hPYmplY3Qg PDwKPj4KPj4KZW5kb2JqCjgwIDAgb2JqClsgNzEgMCBSIDcyIDAgUiA3MyAwIFIgNzQgMCBSIDc1 IDAgUiA3NiAwIFIgXQplbmRvYmoKNzcgMCBvYmoKPDwKL0xlbmd0aCA3OCAwIFIKL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj9y4Eb73r+hzAI9F6tESEATw+BEghwCGDeSwyCHw ZhMsxotM9pC/H42k6Rb5NfsjS0W1ejxjJB5zu8lisVjvKr7985d/7P/1+/7t+y//2X+b/n7/ZVfc FXU3/uyL/s+b+YBt70pbPP3sW1PeNYdh9Nv33eP+cfd597n//8edaYYvTn/1//F5iWL48/u333Zv x8V348iX93/tf/vf3u7/0v/v1/1Pf+8Hf57me/rA913bNT0cRWHK/p8P83+asmjNXdP/3o8X/j+f Pvzv3d/+sP/tCTB71w7AmxHA+T/f2Lodv1guAvnx9NV+srKzpm7a4O/zictygqfqISvKOztA9n1X VvUTWEVR9+OmuRsh7nHQmOqu6n+3/rg9PH15GD/O8xCY/wk9v8xg7srpJ/i7A/Mctp442meY52tV A1oRNmd8tpfjPA+B+X2YlfAcgDkEQ+hccuD5/Fl/d8ej8HyeNkK0pITnpqnGtTqXnpumHtfqXBi8 8SPMs3keAvOr0XPTNONZdy5t9MMjPgE2Z3y2l+M8D4H5M+E5AHMIhtC55MDz+bP+7o5H4fk8bYRo SQnPXdHYYfrSpeeuONQDOKULgzd+hHk2z0NgfjV67oq2nUSmQxudKYqn3wE2d3y2l+M8D4H5M+E5 AHMIhtC55MDz+bN26DkSz+dpI0RLLszPaloHSkuS7tNU1d4ae+i1vb2p9//9Z7/I50G1EShQZvgz h2UcCShQjxe+eP919/ZTszfF/usv+xGCN+NfX0eg31hTtvuvP+//+ATTn/Zff909qYvTgB0GDqeB chhoTwOV/4lxjo9fp+3nwXRd2xvEdN2UN4fpQ2VuENOHnj7yYFpo5Dxe+OKwn663ws7tp9/Im17r rCZQzHsf2I/DQH0aeOd/4oM/cO9/BTZcDwPVccCMGDBleBnzgU1ijQ/IwR+AdSt6Nv4cpqCTjhTQ +RRQXsCQZZMW/GCywOEvixiDOQD01sOpeefDAYDByXEig2WBgjjosH0BHLAXf/t4g/gccPoAR33i IWJmUJnK4QYCogPQ8b5o4LRjy66DddP6cPj4KD+NnM2kEJmALvnBCM4SDgbmuFegulEEVd0ru1id XVy6QFRo46SwfS4808UrQso3BzilCCoPPh8DcoBlYZUcB5VHu+BKHf8KEAzVpZAFZSFtjZvNuScI vvubkfv1YNScWHAWK8B8YrIygqT4bQCG4ksPFCexcGiIuaaKpzlqvgB+kLIbOsDPGiAVMG2gBjDn ADDYPpdIsBfQE1+NkytoG5KrD1TIbwMl7YizBXKgbocIAweQzJUtgSTg14OfLb23Ai6FCOLbB4xx csiiOggYSizGNKTJoQsd7QvUcS7IvQjN8lPyVybj3nXL3o2pNv1P8HfHaRvxee7STVx0IJzBp36G cGzzFJM5qXrtecKpfDRc+AReCn/AwldaX2+rz9MJ8LfGP8HTHOajPymf497fXOfP0fh7Kc/LHeAJ oPpeYCOTmJm7ifzdIcrgAvuAmGY5QvBgYLuxkF4vwGHaIyjG5wOARYEnBD7BlVmuE2zExylReDjo 3HckUGfgEwAHtWPPRKLA2gGbkwpOU9LNAKiCgA+PZtFzQNP/dhw/AYpZGBMZBWYbPn0F/5sZB0wR Zt0ShQ6WAVL24xeT+LvwCR2Hkz04SC0/+PtH2416eiQqXg6fVMg3pqDwm64OLYLRbwAUCIZ79bhL +5Z5bnokAeHg6gPgMHBPl9GHLSuXQLJY7lzBEAhlfpQ8PUSSdJIj+UNDjkc4O0C/5F/hQlngPkxX H2LOEmalTjjk/cBkIA4Ax6+hggrclitG2a0JU3IOJR5WiRC4GrHrdGYQoW8IvNqcB78am6lnK8hL CFyoSyyYR9ao0ysChVlCS/CJAE9eaBcVjcNQIkQSXDHgDoBkwBhnp5xL0XgmBz3izlG1FzR2DE+p RQqsrUP4OSOQ/c2FAEtS4SPOIQtHgZvcqiG19vLtZ4twe4ULvixpgC9aenDZwHEqCJKmsz6OMX7n VlI3bsieF9teS0Vh4XKDrdyx23HdAqT8WnJvn6BAJCC0NIRF81wGF2F60b0hd0jXUAAOGzBolu3e DA700/YjqCFwksvgKBsPDpVJD4V7tuk+Jc6Cy3uPWWJwYLyUs/Bx2bFZBcGAKfR9uup4oziHEfjU Nsu2xLEAvv1ldNkYly7XzEqybRnEoJ5Ku9Bb3hYupDqTVs6keZhB5ZEpcgcIJtrCH4mpU/Jhw8sO 1A7JFWDygxLHzUSKEvvBIxHEEe4OQPWXsYF8MGXxWPmUyBNUBK59no8tMFi5p4WHIAXVxLBsRlNS gx12Yc0nkE26kPe37qo/ulW4ijUWEaIChID7kydKa1A2jYxJMr74xeYOjnRtCkWSRr26OHK+0Jbo PHaxWbUXMMaFOK3AjCB+jVy1WPV7mXePhy34UcZuX0FElaYM7Q3uT4RfUiA9NpvsKKiaiNXGFrpV 2sY5ORSEfPtA+1kq7DbLxgTVpT9CrqcGQ6nMNOeGMzsFq2jkB6ZPeqX40krJbq/BklS+tUpxdegC Le0w1Djs4YaNopVupYYS85KvabSTVUOs1U0QrvTAh4b+IehuIWiTx7NaK57KBUdLJ80TGjGdd5Sx +XKXRAPP8eepfukBbfRCUWstgq/dbgKdhJ1S2ZnH7V+2B4cKpwrpuZ5Mk/55EgBuRiVPL6OBv1C9 6FysIpXxhP30nikRPhK+LPc8UNdMKNyiIfkOJni0m/H8x6qwVfgoI6QUbxi0TuMiPfpIspoFquMq ia2KwfaFnN0a98Lcrqqo0uFRXJ9wKXTGqZCn9vFVkG/xVlcaLmVBq6sccg0/wZfVUB4CSNYQY21Y 6xeUx2Z0uS+0cYZGzrPdCuTLlSoq07nDVvq+53GzgEofocEL4uZbaRZAzWSkuvQo1pWKXznlhrJI FlpFh2Te91qW6p5Lni4oYwj3eC72Pbv80yVUkIRVYULHUkIGYoRilF4ymEcxupLUSpev1tIrxmuQ xWHQhYnOVemQEKYg+5ACp4P+6hHcQaOjdHr+D4/OR4SoBAlS6d7flYQnXn4wNeE6wE2mqoFAq6sm yE4+1NI/fyyLSXcaRSzDL3cE7So49/PoE3XnXv+I4A8PrwpEf0Dh0pCOpnHnnG0lQiGnua8RMX0e oY4wBNKpbqXspCu1XYd7eSbsko4znFXga+J5D4IWT+mORUUP8NLKSvcirtQeYRX9MeIacguVm1dc 19Ho5wXb5y9MpGc0ZSxXrEoTJI910hxWislm7GUPR7k0t7l0D+Z2w7iSsBSPUgqqrPNkMRjvBgmK FzkL5mx8q34jnkm12fqKTJ7oNf0zC4VD7TKhPBFWbhjRc1g1IKIhcCvVLMqtOqL1qimqw/HRsCyv F2w3o4dnOQiejOOqNa0kQ7VYIRqU52VHDae6IOVJkPDG4xCCi7xOj0EB1mPbzC0M/VWFy0BuuN5i I3z9Sp0L5eqHhgRquyB55AidS4ptOBfnj8rxhCd+1oI0/iv1j8yiNltbOgSjUoLPRQMvSeBXLksD ME7rGs0CqLiN6E/yWgdDGC5tiAX98SJ4EBeEWVxstcfXX6t+lERlXVQhqpR4YV49n4TRCUJcL/dd z/qo6Bv/pUfJq50BlRNwO3s+ciRxzAyDMwW+ehrAFzbhE4U3MEXUrvfCZFMcG+wr+MB5m8SId6kF Dpj0bKDK+nNAK9oz+TJ+vhjgDKflaTl5IEHvKjTTxJyJLPvBLCP/rdaq9AHBHUOyAp8WkyRUtuOj HlvFQOoJpG/BwHYhW5mQlqoyxmFqIhzBbs7cPx9L8bSmoKs1dhEN6OzvlhiMhVwwTBcDrosjOC9s GfG0Els6A7+/6cqXioJ1NdwiuCycBmai+YQD8iCmfTRnfwCbpM+EwK0eG/5aWlFjHPbBs0QjbC6V NCBOZ4IXCvVq8jSYdhl8ykrFZyHwNNNVVN440AhkprvAeTJBxOZir/rCbKSicukDMKYWkm+ahH7t /CE84AW8gGKdRsfp2QSbYYURMvh2H42NSETl+dLr9G4Q1MRrxGA1yg0FT8Glp1sIOsdHE8xCTjc8 8TljdavU5vOUDckjIsCm0mMEgliFoEJLUUYdnjvJn3n+RKEt7WY6cHMWvK281GU2kCBZgN9b3p6f x0sF9Wg8kI0EolHCdK0XHoYHok73MosUl1TwClqFRWQ6pD+7vZlWLunWmEqkds2aHQ0J0x1Vgxz8 8wUHag9HpcrW53lASqB2QvYsigVxWd95eiZQC8HdyeNt/RO6tM7HM0cGlJUxDnvojhFw30cZIVtv p+W7IM0fNidgYWC6gyouEOAaXI8rUunZODGV/RvPHk+pNIpoJwwpBXk6aLa1c5MxwYt7PgXPCPJX FHIEcSI4CvWXRSQyCzb3sq/UNUMYbdEFT59fdXHf/KTEXW5Vctm4cVpfmOheFM5RrtUpJpDOeEE4 vmxNSPD4Tbp/Wd5q6VIyK99t+rOakhqFF8Xpeb64RuiMK9O0e59iTzwNmWSr6LOVOCU5jSm0n8Zb mSU7zpSFi7HXC5R8gTbSBV1SF6VhjXH7Pb37pyR+K8D67agGGt0/czzoqNHGICJeeR2ik+Q+VmpS rOyCOObNUNPbtUga2is0YIjoWL1OGX8W/8/4QtvsKIEI+W7TW/9F3HRuN6zTj+N2OLDATR3rqVno Y+yMQ2OSRBWBPcc7ywgoWaAHpIfrOKQRjJ+LF8GNEmTOZnmlOVbb0BBzdbVgK4IMcIGywXP2KEqv lA6gl4LVtvZ5VY3OiFeKcmQxgLjDmfeUUsiFyRPCEfQLW0eR/KE0h816gjFqTnOnkM9r+PBz0BhU fq3z0klEwZnGVV8xu6rtDi+G8S80CK2HDwXNW1R08sqk9W8UN2cET0MIuqELRJKgCfuLihS8yugt y2gFEdSZZ/uFNwuI8K8C0hXqQ7DCXSEIhJX1WdrnGw/JqCnpvZSh7MiipldEi0Zx3ufCxJ2mcLD+ w5fB5tBZJI9E8bwDsKvvmSjII/gE+pfgVQtB1p5AIxFIIJ78kq7UyYWDhpyzR9MiR06BnkOxq5+b G2BS31asBM4bs5RsZWknk6V38yrlmBECmcdauH2XXp4ZISpztBRXfI07iYJeX9I+h/WljQkOLi/M 0+kxwq6kiTxIQ/T8MxYedAdVviV4fkOhVgF5jkZStCBjEQDjz6JHiGCxTbzQKio7h0BW6u5AVUme yISrcEedxvMjgiAf5agR5S6C8kmBZcHdYbyPjeAJpGv1kNCgOg6poKwAGIg/IPCOy1UhDRHU1kF0 CNTvHCmt6GDP4/0bXko54eNFl2lJ2qpGqAJbfb1KEHCQZCBydyBNs4kIwKQrcRFOR0GbTe5CE4TF NV685vRxJW+oQNvO8uBIrFNgGUNtTOUKGP6wZaBEd7mcK/vJo2lOxeLPQeqbjS5FxD20fK5lYZ/7 dYHIQuUr/V5Lmr+u4ofaTAhLApkgI0Shf9m1Xke8kiNb4+W69IMS+GlvqLaHv7XLpWvsjVrKHA8O dwT6QI12nXYG6yXIlEVVBreyVVPMfvAnFVTvC3xMgt7RHGOCukeBGiQofxHs9jUPI4qSFxb+NY17 b1fJ5bBgdmdJyxE4i3O8DxLx9Fy6lXCmay0ql4JcHm7wwkEIOoMHxJjX27Tuph+gaf+/RfQsDU82 XJAmmJT4ZEXb5tg8fDyZxt+tfw3ZerYKLdi4CxbnbXDxfprOmd6CJ3IiAbjgoNfPCLrzkDK9jKWG FGuKnEixpnan96PjoVzmSyiQgRhGQX3IioLGOtMbiKz4KJhcCgZcgbMB5btRDk8wZMNBaYyLA3hA Eig/lPLQhL8Cn5heC9PaRTdclbZcjWEV7oLaDKuonelvg2GZqsmKlNq402+QYZmuzIqCrnXp/J1/ 6FNPb+tvWY8l26yUb61L+bfJjuyTX2T2DBnwo6nl+3xbkJxWwUeg93rNBkofN/ON9n/2j/12TTPA Pf317bu0bfvn/efd/wGtq753ZW5kc3RyZWFtCmVuZG9iago3OCAwIG9iago0NDk5CmVuZG9iago4 NCAwIG9iagpbMyAvWFlaIDQ3LjUxOTk5OTkgIAoyNTcuODM5OTk5ICAwXQplbmRvYmoKODUgMCBv YmoKWzMgL1hZWiA0Ny41MTk5OTk5ICAKNjYyICAwXQplbmRvYmoKODYgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMTkuMzU5OTk5ICA3ODAuMDc5OTk5ICAyNjUu NDM5OTk5ICA3OTAuNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk YXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0aGlyZCMyZHBhcnR5IzJkY3JlYXRlZAo+PgplbmRvYmoK ODcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0MDEuNzU5OTk5 ICA3MTAuOTU5OTk5ICA0NTEuNjgwMDAwICA3MjEuNTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNPQVNJUy5XUyMyZFRydXN0 Cj4+CmVuZG9iago4OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzIzNS42ODAwMDAgIDQwOS41MTk5OTkgIDI4MS43NTk5OTkgIDQyMC4wNzk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3NlbGYj MmRpc3N1ZWQKPj4KZW5kb2JqCjgxIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIK L0NvbnRlbnRzIDg5IDAgUgovUmVzb3VyY2VzIDkxIDAgUgovQW5ub3RzIDkyIDAgUgovTWVkaWFC b3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKOTEgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BD U3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUg PDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjkgOSAwIFIKL0Y4MiA4 MiAwIFIKL0Y4MyA4MyAwIFIKL0Y2IDYgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago5 MiAwIG9iagpbIDg2IDAgUiA4NyAwIFIgODggMCBSIF0KZW5kb2JqCjg5IDAgb2JqCjw8Ci9MZW5n dGggOTAgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dTW8cNxK9z6/o8wKW m83+BBYBLMleIIcAggTsIcghsDdZGOtgtTnk72/PhzzTfOp+ZE1xhjOiBVtWaZpfVXz1WGSz3v/j 8dfi9z+L93eP/y0+777fPa7Km7IZtn+Kcvx6dyio+htbles/RW/sTdttpJ+/rZ6L59XD6mH893ll 2s2Du2/jL1+qKDdff37+Y/V+W/lqK3m8+2n8319FVfw4/v1a/PzLKPyyK2/9gW+rfmjHdpSlseOP /zn80diytjdjo8woL90f1x/+9+qffyv+WDesuuk3jTfbBh7++M6OZW4ebI5q8vP+0V3p68Ga+/9h wUHtG0xhK9sUjekLU/zvX6vfxrpPUnPbjDW3VdHYtqisPWnd6143tT1Dr9c1d60503h3fV/Yvi6q un+p++Ek9vy88ODt0+r9p2GccMXTb8W2Be+2356+rZpqbME4E4unL8XfxyZ9+KF4+rrq17/cCuqN oFsQdO4jHzeCZi+4dQV2I7B7wZ1bxr0raDaC+ruguncLbWk7eLXwiFst9gXKgEf4iLm9NaX7CWg6 PMLbAWVAXzR6C49U7iPQfSjDtUJTu4/wWrhu3fEwt66iYDboWfLHp6kTCpu2tm2n81YwKz8FP1K5 AvPJ1ZyGOUBLww1GUobbUrNt6RBi/L07pu4jxmwExi5IBGiI4MdNFwRcEdCOWsGWty6o6WexD9oF xg7DTud6ZVgt2A5wQbyMDwwewMhMrzakffvS0Ip5jzgwPlAPBHoC1XIfdR7Tn4O+4xRnumaiOY/J AN2HQYbZQbvPbZ8TEh0/Z8rpeERxOBTGcR5D9ymn87BkFxwQYKAMsHWuF5hiGoqq7RRysGEcci5m 7YHABtVyv+/Rf4FtU4T1mNocUOkom3stL2bGVbJ8itElz66hMBuWOB0MBx0wmMgIKByUwE7BCjlI 0xmFK63wlacHSHN6DroFHwX0PEpLwaSg6RzpYNRBc3Sx+gp+ROku7YwHfsDCEpbz1J1iLYKluCBE wh0MUAOYMDzsJAAhGogxljad2uVu7aHMaZu2m+K4cauF7gs4LbUxFOj5KNPODimYB7QcfHj4pMRH zuQrucNxH0G7hZbSNbMKtwynY3XlDJC9dRuWCny4U04FPtxaPLrPg5B8pruFghr4XgG21B0g+ATE Pj0IGn3Edi4mgTmEB0RwPN629uWc5jjX0Jb91Dd8UPM31sxaAxBHBYvidB0ZXZStE2g6X/8ClaDg wEcMPyFmH0ueESk/JwLQf1hq8Gj6KcODyoE79xMWoI/TLw4XYKhRFu+gF4+YEm0IIj1fNnFth/eO exydCSKI9MOA0Mk9xw2OhPp+mGI9N25Ov2E81HbwTP19u4nui3nstcIj4YxEBVGiLLwFcYcY3ClO +Edj1MMJB8KFRjxILxQeO8pi23oyCZH0Z+MP5Sw8RhDjsFO6214a2wm06fYjZUb8IJueV2vN7BjD ZBBs6mjYHIcxl46BWrDp9OwGX+IIYL123YuHAflynKUxjbOhe5pjBDDn6C4Psi2+jhaErfmBXK5L jWMVdD9KcFLYI6zCN5I5y+HHfwRxfb4dF25S5wqyNbaeoLRkn9TDhJL10XqOrps/usNN+0zATueL h+FGcXThvNDDn3iceOD1ctMG2OY4DnYqeBdDELoRRB1VTl7EiG2f6GwGzCmwdsG6QMPaI5092EDb 8OId6sZV7lZgyr2kdSYZ7gS6p6nhE9AXu1WuMe4zfr3rq7njwpWZ9G+36D/yDHLVvlboAm8R7DHV LfW5gqURt13BcpzTR+ox4hwI5P5RgBiUG3uATDjIJsMo8iEy0nTf4+QLG6yps+l9tfjCW8jbOb2d Oxmw3tipum4KsAftAMHM+hyaDma5xMlmzFKlc0Pl37mBYtCtK5iZhEu1ZIG+YGYCLRkdGC5YIeg2 ld5esODj66RmiQhwRQGHgWqhDHciGwA212AMlGHVUMqWARBMBejEU9F+FmRVvhGBCQmIEnSoAjhM Nqm3IxCo0rj81AAxgjIo5zcQVevpI8C1KdsysF3kloGFUr/vETF2GQrnH6dFB5u5Qxb4qNIA6c2C JAQze/oq6NBk7pAFWZVXJNBEhzZzhyzQUaWBDSq6srgmRp+KQBMd+swdssBHlcYN6ydDrbMgGjoM yXMHA5tL2SUlyR2yIAmBIjrUJip3yA7nYgUZHS5UoIkOVfLcIQsyd8iC86BDnXzcoYIz33RlASft K9hXh2phVQArCygUFiP8tSogV7B7D9VCLRkdsuBE6NBE5Q7J8OQsIAL+Jnwixp8FJ0SHLnnukAWZ O2TBedChz3GHLMiqvCJBEDq0hSlfA4fKrm8aaKyd1nLwIv2Wfbb7dnxyP7HdFoT0AfC6PrzA3rmd g5tX4DZ4uFD/4JHKeWQXd+jmmw4N2+1XLjSsghfH3Wqx0MHtvts57Au8fU2HENsB1cKo097u9pEP 7tVoHXNAAdRCxwP1cuuWARd3mQDjX7yapBn94061Z8rRGH5ZgcddNho5xqBz/D4gcdLGeqHpbyzh op2a5XUnXAy/kU9yTZUg1UyqF2IoXcrUTG2MZslVTPcUPdtVN51AJfAAwQUyp7ykS8Or9fXFWbYH 0PHb9uARnlwiyn2/p0kke905HaLkd7ajeDI/oOmCKx159ynCIDiCHnyyjUBbuSIA2TWsSnBTHB8z OnWvbBAFnD08v3scJ9xu7kU8mGbghCM6v2EIULZCOiJ+UeIrDRFciS6YMqfxQxp39nGU1UhtecH+ 0AMP+eIJrgYEe+AjpBF9iBI44XESfgOfRt6wGKaMn/C9TXApRwu9etsj97rCWiDoUsdF7G+/H7CF a4RxQnE90aMWCGyC+75TXZFFQZxkkjvyK5MFMULBUjE8uosXIgu4JE/4fqYM1lEuWU/lAuArvB// 2GidmcC2xyykmZJ2Z4GXequQN2tnhhpOa3/u+4J9A2cK4UnieWIcSTBXkN1OcGs939jidIznDuYO WLArA1fAcnAENgp64RN7JhIBm/4hKRU9MFnBcD0SrqbKP7jff8W/CPCCB9UU8s/ggh8aBpTezenD E0FgkqOZfNQavmF/6j+VDNaSEwscpoBM8e0g7rMFOfME+0MU+s+1u56IolTSZvG3Hvh4gKLoOZGY a9Hj0KE25RQe6DrSZzME+8uDvRohoigB40SQTMIEeS3cdMNjInN60fBj+/dTNBQnYBOcooTDgzzW uQCXcQ4i8kkpIMacsoYn1UN2xaeLxgpXsAFzwdEcSWcoi8HwOF9c6J271PANR/rkvpxCXbLhHLqA lSQzS+vYqYbT2r825Zvx/qjApYA5C3LjCoIVgrUn16RPpmiNc9s0fSTHMQkjOQ2D5RnMOQ3UYOP8 aBLFsTjrJNvU05kcvr8kyWEtOKsT5diA4Dw9D7ELUifzMgTLFRp4QajT2MH2wC26avZYenskJJ/D ZQXf15WVf+8umeaGn/9GyxS8kRTjTMNVcfjTRHfD9yRT4fAXFCC/KgChmcRVQtUaJxY0eJ0vW9Lw OKab7QqN1c1twYUsPiUnW6OEombO6GvcBNKXzrv+B9WC4NKSXvem9+9cTnp9qYKISa9VrNC9TuOo 3uYbWq5GoHihU18HIF22sbcj4KqUZMKdCbEvASx4U3Ceemnk+zYjbhacSpWJpcpRmUBddidZ4KPK ZG5BPomgUmRsQ/ZRWZBVOdN9jSk2lNmLZYFIlVedxFdzilXZi2WBF1F8U5kKFYniYJP3Yjm/7KUz pSYqjL+tuX9VAkUba5PHsSy4dBzrk6ejOWPipdvYEBXHkkH+LCCCmWN9CjZWlyZ5HMuCy8axuqwy H8sCYmPfLeymGXZ/wNbc3z3e/bQqi7+Kqvhx/Pu1+PmXUfjl0FwXCntJT/Wq3Vb12gGXfTvF5IPX Id0z8Lsggin3H7l3n9nSHEhZNLgjBMez3Vko7dY6G987a7qXbtmtZzEH7y25HbX3bpNmXvBv5zuO xPP1l4XE2tpc5XeQVeRM2jIH5yLGr+J57JxpN63cffv8bQFKyyWjfigeVv8HCZ0QzGVuZHN0cmVh bQplbmRvYmoKOTAgMCBvYmoKMzAyOQplbmRvYmoKOTQgMCBvYmoKWzQgL1hZWiA0Ny41MTk5OTk5 ICAKNTE4ICAwXQplbmRvYmoKOTUgMCBvYmoKWzQgL1hZWiA0Ny41MTk5OTk5ICAKMzk0LjE1OTk5 OSAgMF0KZW5kb2JqCjk2IDAgb2JqCls0IC9YWVogNDcuNTE5OTk5OSAgCjQ4Ny4yNzk5OTkgIDBd CmVuZG9iago5NyAwIG9iagpbNCAvWFlaIDQ3LjUxOTk5OTkgIAozNjQuMzk5OTk5ICAwXQplbmRv YmoKOTggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIw MDAwICA0ODMuNDM5OTk5ICA1NDMuODQwMDAwICA0OTEuMTE5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2Jq Cjk5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDYzLjE5OTk5 OSAgNDE2LjIzOTk5OSAgNTE4Ljg3OTk5OSAgNDI2Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzUkZDNjc0OQo+PgplbmRv YmoKMTAwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcy MDAwMCAgMzYwLjU1OTk5OSAgNTQzLjg0MDAwMCAgMzY4LjIzOTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9i agoxMDEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxOTUuMzU5 OTk5ICAzMTUuNDM5OTk5ICAyNTEuMDM5OTk5ICAzMjUuOTk5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNSRkM2NzQ5Cj4+CmVu ZG9iagoxMDIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0MTgu MDc5OTk5ICAxNjcuNTk5OTk5ICA0NzMuNzU5OTk5ICAxNzguMTU5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNSRkM2NzQ5Cj4+ CmVuZG9iago5MyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAx MDMgMCBSCi9SZXNvdXJjZXMgMTA1IDAgUgovQW5ub3RzIDEwNiAwIFIKL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KPj4KZW5kb2JqCjEwNSAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAg UgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1Nh IDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjkgOSAwIFIKL0Y4 IDggMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iagoxMDYgMCBvYmoKWyA5OCAwIFIgOTkg MCBSIDEwMCAwIFIgMTAxIDAgUiAxMDIgMCBSIF0KZW5kb2JqCjEwMyAwIG9iago8PAovTGVuZ3Ro IDEwNCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj9vIEb7rV+gcwGN2 8w0EAfxYB8ghgOEBcljkEHjjBAt7kcke8vdDUZwRuz+1vmaxmqRGmsHuzNBiP6qq613Vb//85R/7 f/2+f/vhy3/2X4efH77ssoesbI9f+6z7fjN+YJuH3GaHr31j8oeq7p9+/bF72j/tPu8+d/9/2pmq f3H40f3j8xRZ//371992b4+T745Pvnz4a/fb//Z2/5fuv1/3P/+9e/jLMN7hAz92TVt168gyk3d/ fh//afKsMQ9V93v3PPP/PHz437u//WH/22Fh9qHpF2+OCxz/+aa0mWkfus3Vs5b8dHp1GP0ArNDv 44Enra81+yJrin1pmr3Z//efu2/d3KeZqyxvrSmrJvj7eOY8H2bqxrNZe4BeN8uPXV6U/e9Z2T23 9qHon3fQr0xx+MNY/7mtDyvsn7+M8z0w/gEx30ZrbvPhK/i7s+bx2vLyMO1xzeO5iuZAJLg25/lo Ly/jfA+M769ZCc6BNYfWEMJLCjifx/UP93kUnM/TRoiWlOBc2zrrh89ceq5tk/fLydw1eM9f1jwa 53tgfDV6rm1b9cwtc2mj7ljb4XdYm/t8tJeXcb4Hxk8E58CaQ2sI4SUFnM/j2qHnSDifp40QLblr fhaoLYiXSVKgKop9UTS2k8t7Uz6Lgc8yUWf67/Fajk8Cou7pwovvH3dvP1X7buOP3/bHFbw5/ng8 LvpNUbT5/vGX/R8Pa/rT/vHX3UGwDw9s/6A+Pcj7B83pQeF/4jjGT4/D9tNAuiryK4R0VRaJIC1U kp4uvHhxP7Yy3X6yOrgf875/UJ1W+8n/ROvv56P/4F3/oDy9kp0HwWjQ2vtEflxHEX7FvvdegVlM 4b9SeYPmH/1Zan9hlQcPeADbx91+oNs/ArmdMC3O4kM9a/0HPiozH4RZc4FWKdG1nelwjuhK29Gc MS9YOKLFZD7UR2em8h6Yd/7SP/ifADQcl27yC9N89B+890EGh7f0KQbGgFn8BwPqmguDwjr87Q6v zEOMaQsHM7gw2AssDD7xk3/4EQ+5j0wOQw4hO32Md4zs8IG/O0QMfwW2D+vgUIa9fDrPDuatg58P MeWeXhnY9CWJSbdvjf8J2AsdNOJYwl4AQEnoFDDnv1L4S0eYArLpoBweyJVhL0CWMMs7NQljyyCe Wh+kAGNOc75sRBjzE+ZTA0qtT3SlGhQFYwDX5oeS8wJOYkBAnBUCTPmhhKUDxGBQ4OKc41BZaY7T thde4RpKEnIQKEaUtPETMIuPlwjipyJKwsUFIATShlmA5cDSQdnmshOmBRA2auy0fHYvWLBfqBZ0 RulLQrhwTDmigBnwMTiigNap3IsgSyq0kKEACDk/hUEBdRqyIIJdwkLgJHNOP11RBAl8PRw2Yunc GKFMWWXpwKWpVZDGwIPN8d0CxBQ0kjRaHsctB1BgDA15UjVBQgY+xo1G+AQnUw4wHxyon1I84aHk 8oU7mQQGzVZpH6a1n04klsofHvSAmYM/3LTVsJZcxa1mWmfQQScDZM2cJXeXbkv/EAE6Y0/7FD13 cEyPpt04nSmjwXZqsoNsgAcwfy62V9IWuF9WA2J5XjkQQwYJuBWQFH9FQFJJ+LJAVU5xkLcrMABA H9lugeOCuhDiyQINTION204OLYl9y8kBjF4eHUjh2Y9wNGnEILg6yaflDh54IGBbK8UK87J06HQt +ww2BzBVCK9FOBEFhjTwIB5AEBAM5ZZobfEjBrjle3mvxxxtFcQLYA4dj4L4AA2PSOIUAh/IXTOa z7dy65AQHikIfXELnrJcxC2nIJiFR6lgLyDXckYOsFtQDdKYr0XZuHgxlNNreDe5X356zkNMhgvE aaarRtxpmFJ3VGHkhQmuYyvGxsYTvgQRlZn+jbpwMSdIieLpTDzCJoApSByNsCXOS886Zo7QbMYI fiHw9sf6dy6lxQhi1OBV58ZWkri/YPsCRZBzFK7VUc7G3ReDH1KFbZdVcC8aWVIc+8Ae+MGNCWMD qriClSQ/ie+Xx/VhUCqmIoJbnLVtPFdxpo6aVQ75bybni8YpI3C7kZwvDVUITwOo+TCGv1KVbFfA C5hfsV4BFb5dr+2sWyc+oJKDDrMAbgMeryleM54xbKBER6AIg8LBrUCNbM5RKuI6cX3bvDgOVUI1 fVx/NGjCuP5plqFGbVwuBdoPsH9eyAMRoZweGt+eglcKbgnTIPTN5xO0tYN+iV9sK4Goe0SI7GWR iNBCJSUJc1Y0GGqeTfBg3ZNit6DHpclEv6YYoqAA4qYihIDLCO+sBqUG7G8VPmVuNFKJh05wPqbX OKPunESrt03uIhfUOo0qTkAuDf9KQgAc6uB+4fSQpOKfCnZBORA6AblgB67ElWmaJioI7XMHb4Th KFB0gLFzZwLPTxS4CZfM6Mzz7ce69XqIXNqtIFKnoebyoCunQkH/Cx6pSeEBf11KbcKjPcuAR10B OGySrL/p7lqVqtbptcOCZG0UY0CFoNVATE3PN6XC+osquDmBjKbBbyQHgUODG5KcjyfxcGic/VhK nuu6bR3sX7F2FdFZQGBJ3B1vZHMrVaPzWihurQZSRVT4afWsXMb09NPIneHpuxH9TQSJktRujuAg 003LjXnRLsF0I126VJAt6F2jHJWf19Ahb9p49iDwZAvyinkokIbOVdRxoOwIviVwbgq8SAJjXIAY jfCyhtSmXe0icrookCN4MlfReLbmMvnNsXJ9EjwofSBeVJr3itvdzIMyP8n8FOqVkChw+iIrQthH 8cp76E5Pd9fxVGaluxfqYl/Lh3jFdtK9u8WjyAmvnP8sSCFfKZ11mYIKjRgmfUXFjqYCSKWphiD3 grcA0MtC1ZBZpo3eLCSyqvhtN8txBGaDQE+ibvw0gpCKbNQ1FZSvNG1Fr1j3FhSrR0gglaIuW7ns 4YrdYVv1mUguEgGeA7oDTMuPA20syj0Cw140RFJeBJG/8R4Cl1QpQf9shRgWntJz5UYPx6tWs/7S 0PO/O8VIEZ/npUoTJ+0Jp78T7eyFXR3hlC82q4WLkQofcgBK0HYC4fPKpyTA4IVwoPnJ/0RNZyl9 evWv54JpbeYPCrsdhJe5IFYDchY0pElLhe0GQLZKOVzPfsq8dIEkCOdd0memx2bSVA0s4o7l8DhT twdg9x9YQZjkiqIRAHfuQLiajhxy79nM/mZ90snobF+v2YkiXRC7FfgsNTz6nAqTMD+BBixo9hjw DyioxGUZXkaSYgZBKIYzBwEBpaiGipCNpS+ToNxa4ge+O5en8lM95/JM6VE1zimMuESAtkRScVBr tBHiOhuQQ5LuNBq5gzfAHTXESVVGExAPZaPDSZAAv8wFfim0Yklb03UrhWemb+eFS0I8+j89dI1t VqhumYPZyMmQlg5H+Bc1Mgi4T3t6/3LBGUM/p+AOyBQHN5GTYCXpmST9cJFaFq6iYFvs0bVVM6VW E39eIoJCd9VpNlpM7eHlBtSvS9VAR5IaOdUL4/Ot/DjKyHIARpYkk8WfJW/9B/7CJLcMcz9LRPsK js0kfammi0vE5Tqu/ByiXXCvk16qkwYjb591x8IPGOU+auFSZet7YorGf8V/kPt7s/4sReVLrdcb Ja1eNHceJTU+KCVx1NrniiidbiGieeloQSCZvwLbHVhrG157qMnypeCzv104XLh2DZABER0fGHth qTwaDytbO9ZctRMaHd1jzWSMRVpvrpVXfL3xSklrl5uKjEh6y3HrJLa/6cw00bp0+Bi6kDj2Bcq6 Rr2I4Own4WN6WbIKunlt5txgpFCY/7otNXq/btGqCY+5XVqMSw7+OrZuu6mHgFsHHvmR1i/aG9N9 WxHaRZLyw7sycVXKhAajP90Wu6r6oRzhXbIUeabzvCocNESItRRFW9u9sGCluuJFgnFIliv5tKfn Gos6UGtYScuIRg1ip0CNiFfybo4Ku50RV9cQQafbUleNxGv0y6gv3Py62dIDqxGbrw5Bhbpqg0Sn oE0U7xgqI3r8q3Qu7a86rJvnQjO0eXwvdJH7RwyDwkOp2QnbfFhb+IMs01ZhKYGh4TK9cb0loNjN NINr9wBspatXms4C0+nj+m3LS7u9tv4wKsy+bYN74XloXEtZKItIUsOu0C8JpwUa4soxP1NJ0tts Uzj4P4MH2K4vyVX6iPYqVmPCHdlWFUoah6yxbRCkr12j2hY2p8hYXIeCTSoIsEd4QhTcxmkuhskb 69D/bWkUSaxFfm5Rfi7TnUVDGAwMswj2Go3gDoIClI0QzN0OZCuNTRObybaywqHCa7YDBYkOdC8R RXA8u2SthtCBZvipFaHXx8hUOH354lrdjmXIiYq3xxOnAs206qwL1dfdbidJoxNBAlaaAk4VZ/R0 bgfWpaTinXfG4iYrdCXBxiXAM/AJjpv5w6BxHGE/SzSxAO9VYaT1S3tAhSRVSF3D3D7alilUpTq3 KjMnu02R5H6x0eRMz9fpBh1YBr/1L2EcsH1pOIkHD7kX8DfwFeIgcBChEREUci6krK0UsRe4fvRo RsPBNNPsykuX7gT5XbzphS+rOAd53VnbtL4WPrFW1vbAl166dl9dkvYIpooJ1jMtBtM6QI1oPaNw uyK6Rm8881vDTuPtJjXuZJve0kPSF2OlDOubik9EE50K2z41vl+roUt/keyldSRp6MKZI29/xY0c wcIEF6vQEjh+twKebMiIoE7tNEUdArWPUzL1tqOXGzbHu5DxtJMI1znV6jgzxM520+9divBfTC9a 2PCl0VxZBLNY517tI1sugu4HRDeF0EJS+m6eu/Sx3dBJBCIEVx5N140ld/wKbAUNn/AyzWITEubM 4pm8ddmSQJ0W9L+b3nTR6EVB26oILn0rms0yxWVbsb80kvCSWN88BigI8C2TZbRZllOY2jmEGy5y UyjozbP54nSZYoHoK0hVeHAdlDgxTdABl9OZ8ELK862ppDx7BcZIUq6+UAytsi4xL6ORr6QuLBP9 3LgGepWOsg96jLud71i+a6DBE6Wngc6MU/a3FI2QrZDnoXLx1dWEeyIyDhQKXJdSBSJynyVq22sS U3pmnQKfLrv1BNFAuQ63HtLkU5vSuEt/TTF2BS3u7iOezR9v0kd8xdr1XPd24TCUrWvoGjSmIj1s sEHAXUNnpzKgoc/vclZm3f9DGttr7i2HZ5Dq45gbwcdI056QK/VUZmNSaIQDHDKNNcpI4RTivIL8 TEHJG/fm63VluIacV4GqKD6YMzlZZ4mOWdnWm3Ro8O2q3po4vd6WHEqFbY2DF7jyVKW4VcDYBaxw uq8m4gIczk+mB3bQal4kUx+5BfeIcOEJm5veHIJXdUbUbXN5w4FMTzY31+Cy1nFD2NMNdGU7fMFx 9f8t4jq78GD92a9CLLmq3atGhyZgo7rmoV4o8yEC14qd7gyzcGea8VlK7X/Cr2TKzxcASDdqTePe u/FaN1pmjVPKmHajaqsu3VVPA1v3vX/qlmGqfrzhx9cf0tvnPu8/7/4PS+12jmVuZHN0cmVhbQpl bmRvYmoKMTA0IDAgb2JqCjQxMTAKZW5kb2JqCjEwOCAwIG9iagpbNSAvWFlaIDQ3LjUxOTk5OTkg IAo1MzMuMzU5OTk5ICAwXQplbmRvYmoKMTA5IDAgb2JqCls1IC9YWVogNDcuNTE5OTk5OSAgCjI2 Ny40Mzk5OTkgIDBdCmVuZG9iagoxMTAgMCBvYmoKWzUgL1hZWiA0Ny41MTk5OTk5ICAKMjk3LjE5 OTk5OSAgMF0KZW5kb2JqCjExMSAwIG9iagpbNSAvWFlaIDQ3LjUxOTk5OTkgIAo1NjQuMDc5OTk5 ICAwXQplbmRvYmoKMTEyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbNjcuNjc5OTk5OSAgNTg2LjE1OTk5OSAgNTA1LjQzOTk5OSAgNjA5LjE5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2 My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzUkZD Njc1NQo+PgplbmRvYmoKMTEzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgNTI5LjUxOTk5OSAgNTQzLjg0MDAwMCAgNTM3LjE5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIz dG9jCj4+CmVuZG9iagoxMTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsxODEuOTE5OTk5ICA0ODUuMzU5OTk5ICAyMzcuNTk5OTk5ICA0OTUuOTE5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw NDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNS RkM2NzQ5Cj4+CmVuZG9iagoxMTUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICAyNjMuNTk5OTk5ICA1NDMuODQwMDAwICAyNzEuMjc5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjExNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzEzOC43MTk5OTkgIDIxOS40Mzk5OTkgIDE5NC40MDAwMDAgIDIyOS45OTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMy M1JGQzY3NDkKPj4KZW5kb2JqCjExNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzQwNy41MTk5OTkgIDE3NC4zMTk5OTkgIDQ2My4xOTk5OTkgIDE4NC44Nzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRt bCMyM1JGQzY3NDkKPj4KZW5kb2JqCjEwNyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIg MCBSCi9Db250ZW50cyAxMTggMCBSCi9SZXNvdXJjZXMgMTIwIDAgUgovQW5ub3RzIDEyMSAwIFIK L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjEyMCAwIG9iago8PAovQ29sb3JTcGFj ZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4 dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAg UgovRjgzIDgzIDAgUgovRjkgOSAwIFIKL0Y4IDggMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVu ZG9iagoxMjEgMCBvYmoKWyAxMTIgMCBSIDExMyAwIFIgMTE0IDAgUiAxMTUgMCBSIDExNiAwIFIg MTE3IDAgUiBdCmVuZG9iagoxMTggMCBvYmoKPDwKL0xlbmd0aCAxMTkgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS4/cuBG+96/QOYDH4kMvIAjgHdsBcghgeIAcFjkE3jjB wrPIZA/5+1FL6pZUX1MfxSbV6rFnsDvdtEQWq4r1YrH49s+f/5H96/fs7ePn/2Rfhr+Pnw/5Q140 /U+Wt79vpg26fjA6P/5ktTIPZdW1fnk+vGQvh0+HT+3/Xw6q7F4c/rT/eBoi735///Lb4W0/+KFv +fz41/bT/zKd/aX979fs57+3jb8M/R0feD7UTdnCkefKtF+/Tb8q3RQtJO3ntj2XX48P//vwtz9k vx0B0w91B7zqAZx+fVMWKs+PDc1VIL+Mrw69H5Hl+jzteBV8ZZEVeVNmRdk+12Lhv/88fG1HH8cu c9NoVZS18/N0bGOGsWxmrVVH/OVli3Zji+5zXrTthX2wXXuL/1J1X5SW7bp60EP7uZ9vjv6PpPk6 gbkxw4/z8wzmKWxlN2wP83SsumMThG3WPpnLuZ9vjv4lzJHw7IDZBYOLLinwfJnWz/N2Lzxf5g0X L81hTryWSlVnVtv2uTriWqrr2nRTNvO1VLfyaxBfs/mL9jO+Jv18c/QfbS3VTV4f++9hnozVTrWT qxK2efs4l7Gfb47+o62lOZ4dMLtgcNElBZ4v0/p5jjcvPF/mDRcvzWE+qfMGlNu6dWNtVrRLubUK MlWcls2nMEWrut8pLH2LQ9G+LLz409Ph7ccyU3n29DXrIXjT/3nqgX5T2KLInn7J/niE6U/Z06+H o1kxNOiuoRobTNdQjw1WPtH38eFpmH4aTFeNukNM17lOhOlAE+1l4cVuPnVrU5qLE2ra+Sil5rDU ErhJQyMatHxCwSsfWKe6kE88yoaPcpRcPgGIruiwJYUUGmD6EnQlG7SEY3iiI/i1lNOlN+VwtoBT OTkgg67ZKNgH0OUn+Ype/QrgFF7RAMc7+QQ0yFGGpbo0CtAWQJdIHoaNQn27Yt2+Z4DheoFFyJeY fEUBTmFFwXqBVwDrlAuR2MBBnNhyvSBt5SiIMbrmAIUgUICTAacaliltwD44f8ArcvrQqQJCrV9i gCCPJQY8Bhz0Id4irPwXIYJOmS5gzWmgnOwUEGSkNgUxbuRcjJTaxoHkCRzyFVDiigsUOTlj45Gy 9temOWdtkA4BlAOBsl5aIm056BJSA1YO2A4wW87JMH0pgwKGRXwAYPQJFGywGgLwAbSFUYAuEkGw xELgSMG4qOZjMO76yaH1SWkLIlhJLoTJGc7anOmojRtRsOl8haFIcRpg4scwjECOoS8mOzXQB/AY vCKXB5hfaFwBCiVLgZvAGwwg2eFILOEUsE4tetTZ4EauNxShD1xAdHmgk8hnK+WHAWEQQBfq0Oh8 xbptHMu20Mdla6vT7PvJNuOoQIV+snZBBEHgCRpAzvdzKySdCkkns0AFCqkCI5gChtEfmD4AxjEG k3MEJswCpNBpLZ/gCAI4gAmV7BRe4figoCuAFPgDQOccBOrlnQAMG95TJAOvwxMwW6AtzJYzP2BM go5Y/xiBtQEwwLojsLn0ChcGnE8dVk8McXGtOFUzeYrDNhLJAdIBMEb5FEUfH4XzqUTyYMBWKQgV Q82Vp+0UlDhUfHhwJZcWYPHzNfj6KLlKenI5TwUdvkI10mB8jWaQ6UFX+YihQrZYJVsG23ocSFv5 CAw9WHWLI+WglgO0sGxAxlovZtAIgQauD7ipA6wHYQKzXslwM0ULpkAk86W43qLw0PWgU2C2dLEO m6nKUPJfKYiruST2QJlD8sRQCFXlmixavpyTuYUVwNoByh8kIjWFkR0cu94LvO5hPYO1yEU1VSoe KnQnNthu/WLMrEjiCAGPcUi5pIMnYJnGMOQ2YdwhLL/AllrLTrlFxT00rsQ501HhOITUr1tz3AZd r7N5WCCK3itzM1M4PBaFTwRHNGKoyubsO3lYCnzNbUJ9j2gECJSAAAY38m5jsCLG+OSgDxgWpHaM kOB6ZyRNZDaA+nx7gFOOk4Fy0N3ZH9cJJVsJqbRNRIfyhwWtzt1qIAPAEbDUI4SaInrzETSQySsn fnbi/3vbEgu2t4csuI04vVH4w0Mkc0HHZRLs2IJPFLBbtJe9oG3iQy7/5bq1bxozW/xa7lB7zD9g hylgvzXA6N2LfRoAOg+YOZKXzIq53L/S0u5AZwylFSOUcyObhlrnaNIFaA+aOIBqjccPeTZCQOpJ DHzECFsCYBB22GirwBTFfAXt1aHxiG1xlcxfSZF6E7BOA4zcJDsSHljn1tVejFxfMRVDJZnKCdde FlQdbbLl6axyQGYjhNvxcNejxA/dmb+QJQC+B6QAIMOA/Ajg9fXpkCFBpnhKSp5cfuir6eRdLQt7 /ixOMzue8jnh7DHAclK81uWMCfd+mCfp2XCnns8FkiKoj5BklggOXUg050bmt6+rdWWYtrRzKXw/ djDHGNrBcJIXzBq+iRUQ/0sSYTfqeKLH1MoFhy0E6KjIpHqE4I2FUzCywcrzKdhQCjhSBaKqGT7Q oEik6m+UvrLewlAqApp7s605HZBFgQHyUnK/BseABwQBYXL22CmEt/huq4cnLcUhjgtkiJAhDKMk 2U6z75hWwmgVzbwB0C2kLqfwkwHJgDGPUy0RtPTUVRpLJ03t1sufZ2adx/Pc6Fs5aG84HysyXbKb jxahLU9CAM5bDti3Eg1XPYESD4TAO5DWfSflQkMl1QQ8AcP0bKCU5NgJ60CFgw9yGBi3lg28HI6+ wFwgztN4BZ0esM152wdS37gWDNjV2GtEJIoMi5HKkyS3OELgziNdjCPoNntaUVIj+Q4E7Ju+5oNE cIAnzUGiOJlM1UzSDZJ8Iv0v+BEwPX4iKOB8MLdPwAUApuLJxCl2o5FU0ODg5QjeS6G0c9S95BOu l44otnmyAo9UJEzrvI6SujJzUt4m/GEg2itH8Q5/TBpAWmxyyigkKLtl8OP+9hdsUc2ZlBfIgQZH VZWbGP22qS4tuitlcq7mnaaJ3PCYkq89MZG5aWwB1zZFDN2n6+9wHXYm3GTqNGqFVYZouTBeXBE3 AuNtN95EHKhazfGa0O5bMkip6cxto42U8ndQLeLKXZzKzllqm4oTXLCDf255vIJbwpJzuU3mYeZz roMQx/rj5CEMwmNRASgM3gebGge7qoNTWOtkVJBbdLsJp8+JfaMt/W2OkqTOgAp3abWg/t1EuzEt MyC6GyMAxmPZHEFJQh6bxOX3nr1zf46Dbex8ScZz4Bf8Al63HmvxcsDAP4lXnPcm3kdp8jltfLep 7o8Ne7OgdLJDEi70KA9f3o76Sts5Tnhlld2EkSBZJVo+fVE3J3JC6nuAY803XD0wxpMuHTlDMSqe l8acRgm4GGnLa6CWAJOaH3YdoAFLbdOIFi/5zTNS4N4OFCJUlU0jWtdS39be1P9xMRIbZa8XIxmw YWnN/FUBdcJjpb+E8QiJwMUEgFNYQECoGJzMDQi43IAzHQwLNgfcHEWvovO4dsDEI3bjT2wT726p Kl8hxzhggLEU9iSMgnvn9H6q+9+XWZitXXM/BOEPvUIG7YQ/7t/rvYrX8coiyDUBfKy/Ew4RBA1Q kSLFEktiCHhcScOvxuFXe8IdefG8k8r4y3V76Xrg13GSoFYn8eVxkgCEQsA5gZ6Tpgn8jluFIDw9 hrgHp6xZGFfxYXiOPxxHkHltCGrA0QKA/aMcZf05ieG00GT+2shhAHaYP8AO8+d4H6ISC524Ckus AkROBu/cA+UTTMzbHfqox4hrjJQIun/rUdAEXuFlQgL2PfhmW0Bl5oDNtk0SfbephR+lxkVADupu d1YDKomu31lNU5IvymELIyQMrKiA7dqAuQA++HZtEsolKfzHdyzWb7SHHJFzrNsI2yB1cdoG8Tho tI3QpgmHeBdmsKC7Mg1FVTMUvqaTFYPvtmiSr6/qmDLv4tp0yvly+KH4kim+pUymu1Fa25x1TUmX GNqjsk4wtsng3eYeqt3KghiSTzXlnJQxKvDzdRyhoFSUfMOdZUXfSHluXXJpL6EKvA4TQzWyAfJS dlMK744zu1ZlMjkTHY+SrMnP5yM3sWqwGJQjH/lKMd0Vl2zUubpCITkX+RI4V9aeudAJ3toqPRK4 DHajI2E3slEDMuUDLFAeiFx/NsvbEbjSdequCp9wZoDZxh0BiQ9eoTTJxVr3EyaBJ24VJhkklzmJ 5R9REaqmA6qtrBdCKV3Y+zs5YLriCiOXYkIITeYISGrFjCpHhshtClp3pWNGnGxV1uFGOtfjipmd x3SWjIGAixd9ZxtFP4wZ6N/B2f9Vm+URzu1HOTjTu1djFveN3Ku9RuMiVgWOsqCq04JC+0pm11gj pTbKcXAeebfayk42chU3CurdvshX+N5ld1535JHdrqrXVPEv5FK7FPsXPxRqLIUaQ5BFEfbjcZtN yhlGNfyvREBdzBAQcnVNhALbOCytuOJBiPWXqvjc1QFh4FjWYZmP569+WIdx1naZn88sfX+G3L6o uUa1IxwRtisDsoDTXIdlrJlxZkh0IYZVEiMMxK9LC7ja6m4CRR5Bb9Dj9PQp4jRgwyuGUhokqLmm SmJAttheTOE78kd1NSfU3Uj+gAtM7tkf5XtVnOnoTcweDghMDoYF8Qn5hR6pLVyfOGoUpbaMXp8g iyLpi5NFsicP1VYz0EI8VM6YMWo784yJCNc188tXPPzxgNtGuDbg1ToDLlEPyDFJk5QYJSi+Xtrh hWfrc664SvXwYeHeKEh+u1DMGlqwX8iYQ2/Zw6EOscQcsjeKIC1PlhhKK26aQborzc7h16PyGtgB cjWGQx2tKGGZn2+L/c4OjPML/eBuXCNXB+8jTSI/3zvYS7XIAD/kwrgpblsLCbkEnIO76/Pe9VxA 3HH0bJtAaAy55LBDRWmhohl+gKTy3zxKBrk76/ijdO2+5Mf9fFMWp8l9BAPjspoKHbC/3vx8ifzA SxNlbKWigJt+Hd7XyCkXTCuw2UwuLTTsBgZ6L01B2DYZbPBiYRxQhYMhoEDATh4BqQ1OKWpYWVcL esUZ98NMSg4BCt7JJ2QfwwKaThh5SiJysDnGbrWKynU6zy/dExcHyAWEKiguJJPHHUUsQyeqrJ2f R3+tE+0vDhhPj6SdaDTpZ+dQr0Nb+5u9tGCosutv+PPlOTTB+1P26fB/b7tTDWVuZHN0cmVhbQpl bmRvYmoKMTE5IDAgb2JqCjM4NDUKZW5kb2JqCjEyMyAwIG9iagpbNiAvWFlaIDQ3LjUxOTk5OTkg IAo0OTYuODc5OTk5ICAwXQplbmRvYmoKMTI0IDAgb2JqCls2IC9YWVogNDcuNTE5OTk5OSAgCjIz MS45MTk5OTkgIDBdCmVuZG9iagoxMjUgMCBvYmoKWzYgL1hZWiA0Ny41MTk5OTk5ICAKMTQyLjYz OTk5OSAgMF0KZW5kb2JqCjEyNiAwIG9iagpbNiAvWFlaIDQ3LjUxOTk5OTkgIAo1MjYuNjM5OTk5 ICAwXQplbmRvYmoKMTI3IDAgb2JqCls2IC9YWVogNDcuNTE5OTk5OSAgCjI2MS42Nzk5OTkgIDBd CmVuZG9iagoxMjggMCBvYmoKWzYgL1hZWiA0Ny41MTk5OTk5ICAKMTcyLjM5OTk5OSAgMF0KZW5k b2JqCjEyOSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQyNi43 MTk5OTkgIDgwMy4xMjAwMDAgIDQ4Mi4zOTk5OTkgIDgxMy42Nzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3NDkKPj4K ZW5kb2JqCjEzMCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEy Ny4yMDAwMDAgIDU0OS42Nzk5OTkgIDM0OS45MjAwMDAgIDU2MC4yMzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3NTUK Pj4KZW5kb2JqCjEzMSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzUyMi43MjAwMDAgIDQ5My4wMzk5OTkgIDU0My44NDAwMDAgIDUwMC43MTk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+ PgplbmRvYmoKMTMyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb NDY4ICA0NDguODc5OTk5ICA1MjMuNjc5OTk5ICA0NTkuNDM5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNSRkM2NzQ5Cj4+CmVu ZG9iagoxMzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIu NzIwMDAwICAyMjguMDc5OTk5ICA1NDMuODQwMDAwICAyMzUuNzU5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5k b2JqCjEzNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3LjY3 OTk5OTkgIDE4My45MTk5OTkgIDEyMy4zNTk5OTkgIDE5NC40Nzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3NDkKPj4K ZW5kb2JqCjEzNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUy Mi43MjAwMDAgIDEzOC43OTk5OTkgIDU0My44NDAwMDAgIDE0Ni40Nzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+Pgpl bmRvYmoKMTIyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDEz NiAwIFIKL1Jlc291cmNlcyAxMzggMCBSCi9Bbm5vdHMgMTM5IDAgUgovTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQo+PgplbmRvYmoKMTM4IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBS Ci9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2Eg MyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjgz IDgzIDAgUgovRjggOCAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjEzOSAwIG9iagpb IDEyOSAwIFIgMTMwIDAgUiAxMzEgMCBSIDEzMiAwIFIgMTMzIDAgUiAxMzQgMCBSIDEzNSAwIFIg XQplbmRvYmoKMTM2IDAgb2JqCjw8Ci9MZW5ndGggMTM3IDAgUgovRmlsdGVyIC9GbGF0ZURlY29k ZQo+PgpzdHJlYW0KeJztXUuP3LgRvvev0DmAxxJJURIQBFiPPQFyCGB4gBwWOQTeOMFivMhkD/n7 0Wu6pfqa+ih2qR/jsbHrMS2RxXqT9dD7P3/5R/av37P391/+k30d/7z/ssvv8rIZfmV5+/vddMDU d9bk3a+sLuydr/rRr993z9nz7vPuc/v/513h+xfHP9p/fFki73///vW33fth8d0w8uX+r+1P/8tM 9pf2v1+zn//eDv4yztc98H1XN76FI88L2/71afrXwjQuv6vbn9vxXP61e/jfu7/9IfutA8x0/9C9 NgA4/eu7qs59dWfyojgJ5OfDq+PsHbJCP08nXgWfLzNflGXmXPtcWWf//efuW7v6YW2f28YUpa+D P0/XtnZcy2VlXvoOtXnVot26sn2j/VW2477un6k6/PvC3bkWMiPHTQfjML6f5ykwf0eabxOYGzv+ Cv48g3kKW130P/cwT9dqejARttn4ZC/7eZ4C80uYlfAcgDkEQ4guW+D5OK2/z8ej8HycN0K8NId5 Y1nyVZXZ2rXPacpS4yrTqyk3l6XG1a7XUW6+fzG+x9dknqfA/Gqy1Lim6n4eYJ6sVRZ5D6aEbT4+ 2ct+nqfA/GqyNMdzAOYQDCG6bIHn47SeyVIkno/zRoiXlPBc5E0ruL1xnfFzO+6bHqFzGMT4HubJ PE+B+dX4uZ2zNj08c95ox5uyhwdgm45P9/Iyz1Ng/o3wHIA5BEOILlvg+Titv4vxGDwf540QL81h fnFPG3DW1tkB5zLfmqbWy219qhcz8DnNcSz631NYhpGA4/i88OKHx937B98iIHv8lg0QvBv+eByA fufL1tl+/CX7YwfTn7LHX3edmzwOmH6gOgzYfqA+DDj5xDDHp8dx+9tgui7zG8R0y5E3h+nG+xvE dNO6ZNtgOvFw97zwYr+fJmvPo0f2U5p2O0WxZ5yfKLAwUMlXPvUD5WHggxywEmn3co6PcqDsB9x+ oMjFE4WjcMCycpUC4JDLIoICkPbUTCZLUTUzuhS+n7Q5rFJLMsAA0IWTEnZbyCckggpLl6WktIBT OYfjxOa7lVxYPMjdcmJTjAFbImCNXIWyJcyBqwDofFIgwwfJYwA68NgWkm2Bx2r5REmf8BRBABjQ RUOQB/1qXlwgVwqEAe+be4FjI0Xf1fIVOQAYNHIV5yXhVLSWme/WfJQiZySLAb8ARxlKScmmFrQW TAqmASQdBPsnCel6sYVJTUFtFswhIUUNzNU6sDoIA8DBFR3gA+CQQok4hc19pHuBSbkfAMoBts+d HI5kqvlg+7BbI0E3DyvEtLYBOfW9c1EJKz+BFAYaqVDkE0WAkxcmNVKLI8YeqN0D5xoIBcsC9QFS GIDtgwGSAwZM9hoFSyhXl9GUw90CTuXmgAxgX2AVnAPo8kG+AnqdvgI4hVcMwAHmFQbkKjnoD1gF aAugSySPy2pQ3+Qr5BZMkgQM5QWEkIsYOGyAU5AokBd4BbBOuRCJDRzEiQ3mBLYPrgJgjMocoBAU CnAy4NSAmNIBnIPzB7wCJhokGwi1XsTwxMNFDHgMOOiTnhDaFULI8UEPwKiTgVCBq4s1ImbBvAKx YS9yWUsJhduX8uLANmwic2AJFXjMOj0ec/FmXgV0oD7oQslSVrIDOgJAyoBjtMBjVs6BcChi3cdL NmKdmpMEa4qiLicF2gIpgS5W7gWQDIKMHAR0gWW5qyA3p0nK6hQBOg8pQcGC3V/vWm+iHDexLxGu AlzugLoANQ7GglMOCCUdo4RlER8AGH0CvS0Q5AR8cC6MNfMqYtrEa9yE3Z5HsvHIc62SjZBqSHYC Xdaf1YFyBVypSUgxEMDPc3S38ISi0bL5m9FKZW30YOHiTk5qYQ5gbXgF4i9gPOmABQQFboyW8AEY o1c36MLBfeH6GwFU0gAplSi8DeS7hUMA6I8EugRurhSCgLYU2TkbR9X5K3ibzpHOg14Qa+OREggr xyZZrApHQdALBngmCycDj4gH7M3SKjxuCK9AtgOEXuGVBB67mXQhxBgHPTbr4jTl4KydaweQBsqF EUknCnyK0Vou2VSQIzJZgNg8RYDzGNVBEfH+WCRrGA/vb489AMegkyC6DwZofdwdQ9M0hwBBp64V WmiN5EKFvIwU6dBQY6YSfBoIsy+ZOW4rgE951mNy4pcaTicYvRsqVPO+PsztfxZ5voGnYnJ/IxZY PoTays/o+HbGPEbH7Cy52bmbi1Syeb09NhysXm3euPAo6IrX8xdhbWPyGX15Wh/yOs3hHHPSiiWX jZ+9YBlppUJ55KfZU5tXcwmA81sggWqyWzCONJeWJ+hi0iL3+xQyIVOOwJynNnFJgKU4krk7wS9A QCEC6JuUv1zLgV8v6VnjuNbUIRlUPFcqZ+83+RxyUKfAYQluccJBk98OKvDPGPFUoL3blz9g0Ra/ pjICckxhlPUheJssJ3WjHcz3I3hVnstHtika4EqKa/H1RVk/0vnNGD9nwjfPmUB6W56zbdyMvsjs D0xforfFqylBktG3Xl+7k+LDUZdtk1rRM8UCyrKaC+95nLpY9ahhHZ2JxzHy2PoKsoToWnTt7ImB n/4MPEEI2O2zFIs6qYdxQBaLQrmtDj5a13OKD3SfNnJsznkhfJI/VRQKaB7EsHxpYBFRLim538CF Bz/CAMLk7nHSbW6ApALFdYEMCgchXOUs50JjGYau5fyOkCoECwHr7gNzSSKqmOEVuBCENEWIHgI+ tnBJpmfaQ/ee6QHj+M8zJzbiee7irlx0OOF0TYGOHXC6801pXvQXZPSN2J+4qpBsBk9AGYt8gicP jfl6U0MzTOIXBipp4eAJWGZgg6KQHDthHSjL+CSXgXVrOcCrc80R5gJLtFFgrDNhZflyUwWXJhEG fH2G2dWqThUdxl3e9cdKjB3wZB+NDAgeFeVdJdb34UAkJ1AuYbc8zzHi7M7X5f4s94kThI7jkAN2 ziv4BTZ81ffnMUzG20klcAzVdXqHprKy6Ro24eobHTresUzhYArn7hTG5QoFjAP45hvy6Ym5bkUz Y4eIzmmwfTCn63NWR79u4gseuRAB0Gi4CMUyIfpKO24hU/HmchpeHEczDCQY5YTEAl57wbG+RfDs 5joaamj6+uVscbUN+0J3sEvNOxMuKc8STHpLyV0O6do5T0YESmEgUMV3meS/SuxHJ//czye93gTC M9nxlOjqDyRVzjrCMGCj+PGE5lZABW5EFyK9hI3L3NY5f0zcz+6TUbeWezqKRlfBS/G5C2qu13dk Wwi4XOq4BSdlp3HRSq+rML7EXXR+OwWXDbyiWoO4CWWEHIXJofWlfKZteJlXb9J4NG6Gk27DLCHl A5lrqrmuO8/V/IZJpTdTdeyLJh6lVxL8wuKKhHxhjRswHvxa325C5ZbkLIG8K8tcfAXnFWvcXCT1 bgEWTiO8bSgmdnPA4FR045W6zudz2qgYPi8IHnvmuT3ednVxAd6O6D7pL8dTZWmP8dRtlsiqVVd5 t8/6gUKohDsB6P8Fx/cIjPGk9EBioka/QN/s88cTPgZxzk9fLAEm/QkIiMAAdp2jt3O8+x1Pe4OO xqhEqIGcXsadSP0qr6Kp//YxCLbKtX4MwoJnTNtHrrplJDxm4jVMxP0O9NcEnIIAAaE0OJk7EJId IpgOlgWfA76WQT+/E9GBU68Zc1XGE9vqfU+j8iv0GAcMMLaFPwmrYFifdu5/hTEm2L4Kf9QrdNCV 8Mftn6VP4/VrrQBHdqBWHSEFHqOfIkO6rG+TjB/6UBSxJl4Fu2NfrH4dlUV19aJp8PNZ66uCRsxN y3VAwfNSG6gKkklpIyvBwXapwkeCOhZFTEHlkwAgADt/BXAGYiDnwMpgKJMaN5MvIFHuDr+TQSur cAAIIWE3xzvyZWe5UupuUJrczplzKVdBoRoyIu1/k8Aqb/YVcLRPi+Ek9ESG2AmvDuVVMPzqjwfa E8Jg/LJQoZImpYt0Ajvw3rI8CKoQ5Ioo14rIXOLUvuHmw0OOwEGzqfSZSkhKvtooeXJe0qkfhC87 uhTB1L9rT69/jR5uU4sQyoKHq1EZf0s+8D2oWgAE1g2cUTGmtuTAwknvgi3GOjexyg+BR406Empc IvrKwiu0Wa1Kh9OEUmiNsl3+hIbvud6TSgoZ02zTiGxL6jen5D5RNuSZw4qla8rZhfz0RlvXRJRY Ujd5mwbZztdzNcVj+Qr15vxsFlGk/QOcZ05P9ahy64Jb+RFd8SWdPAxMrrtUivhhGVoPg3f8m5Sp ahQ+rzfrl72XOfFzAs7NRWp9VldEM70E3YdViut7CSBxE3oJgEqhCvUIQjbpRZSQ57e+KwwWFfHW qgmtmC6qhTWMkmuCDLNJkRFXoFiXhrMCCwXC+6uOTtySxdrtE2+ZajenTILvnGBRNtGgKd4AAMIP ubz7CI/a8MZjvBVVQuOUC33EZZNqwIQDe8JtxGUiYfwMk/ClxpS9ULbk+dpXo+q6coCVqi5wCaBh C70L4udC+uRqPw3jfYewfa4+tixNuJoJ2JsTjWneQVrIvPKTbn8RdNrGL+UrDtR0bvMhXM6m63sN XDYYu/FNdoSaT+glusk3sWxZzqVB40o14QJZg5TXdRZbc0XkxohavgDZFjcvCZ8lTDfIyk3pV33T 5RBsLpvxF8iJ/LeIyHV4sl7ofMi56NtrFu2Bdrb9aeOVB2CIgTIQ2z0EjEdvEzpoTfQSBIxlVkCg 4iF1o4Vp5l88wW1ByFoCPZJx4lU7+Qr0gw/0EjtMil9NMXDDbHNJFZwGFpJUGvPbp9N+lDiHdSDu O2qQAppWQsQdL+/y8LRQqAaz4o694LocUPCTfAIoqsnuWqzaNbs90gH59cnkkCNb1GfZp5oiyedQ r8Na+zt7bsEofD/f+MfX76mJJ5+zz7v/A5p6Gm5lbmRzdHJlYW0KZW5kb2JqCjEzNyAwIG9iagoz NjY1CmVuZG9iagoxNDEgMCBvYmoKWzcgL1hZWiA0Ny41MTk5OTk5ICAKNjEuMDM5OTk5OSAgMF0K ZW5kb2JqCjE0MiAwIG9iagpbNyAvWFlaIDQ3LjUxOTk5OTkgIAoxMTkuNTk5OTk5ICAwXQplbmRv YmoKMTQzIDAgb2JqCls3IC9YWVogNDcuNTE5OTk5OSAgCjQ4NS4zNTk5OTkgIDBdCmVuZG9iagox NDQgMCBvYmoKWzcgL1hZWiA0Ny41MTk5OTk5ICAKNTE1LjEyMDAwMCAgMF0KZW5kb2JqCjE0NSAw IG9iagpbNyAvWFlaIDQ3LjUxOTk5OTkgIAoxNDkuMzU5OTk5ICAwXQplbmRvYmoKMTQ2IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTA4Ljk1OTk5OSAgNjY0Ljg3 OTk5OSAgNDk4LjcxOTk5OSAgNjg2Ljk2MDAwMCBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzUkZDNjc0OQo+PgplbmRvYmoKMTQ3IDAg b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDgx LjUxOTk5OSAgNTQzLjg0MDAwMCAgNDg5LjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAv ZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGll dGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoxNDggMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAxMTUu NzU5OTk5ICA1NDMuODQwMDAwICAxMjMuNDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE0OSAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM4My41MTk5OTkgIDgzLjEx OTk5OTkgIDQzNS4zNTk5OTkgIDkzLjY3OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RyYW5zcG9ydGluZwo+PgplbmRvYmoK MTUwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDYwLjMxOTk5 OSAgODMuMTE5OTk5OSAgNTEyLjE1OTk5OSAgOTMuNjc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzY29udGVudHByb2Nlc3Np bmcKPj4KZW5kb2JqCjE1MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzUyMi43MjAwMDAgIDI2LjQ3OTk5OTkgIDU0My44NDAwMDAgIDM0LjE1OTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0 NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3Rv Ywo+PgplbmRvYmoKMTQwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRl bnRzIDE1MiAwIFIKL1Jlc291cmNlcyAxNTQgMCBSCi9Bbm5vdHMgMTU1IDAgUgovTWVkaWFCb3gg WzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMTU0IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1Nw IDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8 Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAg UgovRjgzIDgzIDAgUgovRjggOCAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjE1NSAw IG9iagpbIDE0NiAwIFIgMTQ3IDAgUiAxNDggMCBSIDE0OSAwIFIgMTUwIDAgUiAxNTEgMCBSIF0K ZW5kb2JqCjE1MiAwIG9iago8PAovTGVuZ3RoIDE1MyAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCnic7V1Lj9y4Eb73r9A5gMciKVEUEATw+BEghwCGDeQQ5BB4s1ksZhaZ7CF/P3p2 i/zELooqSuqZHmPXbY6aKhaL9WbV+z9/+2f279+z9x+//Sf7Mfz98dspf8jLuv/J8ubPu+mANA9K 5u1PZoR60FU3+uP59JK9nL6evjb/fzkJ3X1x+Kv55fiKvPvz+4/fTu/7l5/6kW8f/9p8+l8ms780 //2a/f0fzeBPw3ztA88nU+sGjjwXqvnn0/SfQuWl7j4347n7z/bhX05/+0P2WwuYfDAd8KIHcPrP d7XIc/PQTbkG5JfLVx90rmopSm28n6cTKzXAU2SlLFpQ8rxqlq6KsvlG81M2482yTTfe4ECL4qFo AJbuuKwe5DB+nufJM3+Lnp8nMNdq+PF+tmCewlap7nMH8/RdRrdgImzW+GQt53mePPO7MDPh2QOz DwbfvqTA8/xeP9vjQXiepw0fLTHhWQhVdJMKm56b8bJDqLBhcMbPME/mefLMz0bPzZy6Q5ywaaMZ r+oOHoBtOj5dyzjPk2f+RHj2wOyDwbcvKfA8v9fPzngInudpw0dLXHiWRpYjzFO8SaPMiM8pDPb4 BebLPE+e+fnoWZpS9Hh7dt6li1Fg2rBNx6drGed58syfCM8emH0w+PYlBZ7n9/rZGQ/B8zxt+GjJ hnlU02pQWhbpProosqpUotH2MlFm//1X85KvnWoToUCJ7s8Uln7Eo0C9XPni4/fT+y86E3n2/ees h+Bd/9f3Huh3VVnI7PtP2R9bmP6Uff/11KqLw4DsBqrLgOoGzGWgcJ/o5/j8fVh+EkybVtLeHKZN LszNYVpI1WK6uilEN2ItEaIjbZyXK1/s1lM3RtjcekSumyMq5PmIVi60n9yBx26gdBeo/E+IT+6K y26guDKpdF/7gYQDJoU5PjoD4oMDusjJzYoAHXBaXjY8euekqq2dE8qF1H0tvQ2ip0ShlqAdVveZ JBB3UtgHhKwgNwaWC3tJb51LIAgHPEEfGBpBEUjmI8PiChyAZBLruDiaXwBOXRQK40LKcYIaK9w6 QfLRea0S7mqBcPHAaJK2AWU0jwEM1QzrH3i/qrwbQ24/HkuaHujVAhnCHCQpi35A5JeRfmPqK7DT RwhANS5CYLcBqRESlkSZ/OSKXOmsNoAdABw3wx+2oakAkQO7X7sbpcjVMhw6EH0SVsvBQAujbAYC SAZGHiGTgXABY+7iAt7icukA+ojQaunTAPwD9pbWpjyAsQiHUnr3BZRpUgEN4DAR/OOL+xVAkItk WgIPCsc6FOoOg3o8HeqREkBSuApIRQoPWNsj3+abs23hys4A/Rz22t2Wwj2lAcoE0Is7KR59DoPW 5eIBQt3DcIsrk4KYo+fgUPpJ8cJIltfW4tFxQenf3/RWWlrH47B6kc9uugyonnsKsQSHJBsPsNZh MQA7aYsfFu0B6ijH4U9oe7CIj9qrF8aYXhx8HLgS7XiJOHRfjsq3pBLWvmyqkVyhZIBD9TidWu9g zxfCHVG182ZZuI+g4ewuMKWnzfXwP/RpW81P87k4f3a8/p6nQiIBAS/oCMYon6QzxqIY4QlmTAbA soKvAHbcIyW/UJMO9uwuIZNC5zZ321WTeaUur6SaC4d0k+0vkys7KyHt4u8XSG9ZYaJBp7+y3MEZ c2BoTQ6M1sct9JKAWBYdmKIPbkLt54rGsJPmIj67TGhGLXFhzSGsdBC3hs+juTLMVgqCCzFyZWl8 b9nrKEeEpQFBQJjLPZo4EGFxMlitAYEp2myjlZQk0fAk27A8KYHF0U6HnSJMpZ30nEKX9tknY3sx vmdAEJmkQR91iNsGRJk8BtYSNwfmPcEAR8pWxcfXCxW8tzSnCwiy0SebtPqQ0y3PDArQpiLY+A0r xqFHbKWDXwqL6Gj1i87yQda3POsLwvh8cUpZjtyT9hogOiIsfs8JY+EWlfKtBSkbwsc0s4yIUybJ bz1s8DNh0ixvDgfLWkitJyCdk06USZjeupJZ1sY6c7gvsA0AxzaK9D0jljLVe4fhFfbJoCkcXnqY sx2xiWxAHxKgveAwzlKcjxlvl4siiMrFx0tWRj97K/Gyuxz8AVx5KYx1SEwPEBfAhAHJEWKLwSsf oKPQCgdpSAUIR3pS0ukc40Fm8NsruGLgCgOx3FpNc+aEbC8pqVz54ChKB0HAP+RHB6cSuKNxv+IO KIgwu28ptAMHn2WlzrcypXQ3P0WuNx45kOJ8ST7tpWsfK4xgp+RxmblwE6HE0XGdG/ZSH0RDDcBp qPRYaZ8oYxPqJjcueBIYgPzpy2Sb5AinufR5lLg4fQs24CotbeWAxIWB5VnlYAcwXgZRhTe4elim ExGyjLkE7fPTr7RYZG6jPeJuVIT7anlmDZrBJK/HE0S/1iUhvJ9Lu54iHEubGBdoSYNCBYpvgIgl L4sFaCkAO52Zn0SPQ3FA8wNatIHaBhY8fcc7BpDQFEgOC0SPuk/AFXc6vBxxpjY1SSqnCs7dJFlw 2N+USRIjURiOQxrnvdKFRf13+8J94m5fEOS/s31RHz9R/WD2xaJjmNA2WBuZEde3/25fUPtyty8c ArnbFyRPYbMvitybO3ZYxg2xmOGyKIcgK+SC/DOa+kOTH65RYUSi/r2ix0KM7VvRY22QRFiEe1gN jI6rcFj9t8/Hrl16ZzFAIjKOkhTxTGmRFMr4toql8mOIlkIztyRGaxpFXxgbqxwXdWiHDEOtmZCd olkEnDK6muzy/CkoMYixabJoQ8Cd/k1qqaSRscu1aSzbmMYCWc4gb8j7mqTI3sCoy/CU5TS3nNuS 8FM4WLTUoxRSjyApOA5JikAsv+d6O+ZEqtoC9Hrp9KeI4rlJCDPCWooAfRsvaOlwsoAsZ7KfQcAx dJ9AfdqjxrLwbX1WBZffGkILBHKH4Qk64HVYJpxk0p2kVIpLyzGv5eAfB8Ep7Zunb/3zVGPostYm JzuijkYSqZ2kCsI2qtE2QfeA7haMrN94E7JvR0eL6CCDFLNTaD8CpzSktAjyLH+lY8kUNkmRugJH ObCpAXvpjjatuTn/2apRGfA8XcFy4Uv7op9te7vZaHzbtO+shkpP9ZQJFbgVPuEJml5lPyCkS/Sw HyDggPdqd8fAj3MNsoHnXcua8mRWXAPEveY2qLtwYOsrywVQP7hPwBwAx0fg6HC3FECF98JXXFDR CQP7DRV+EVZ3NQJYB+Cd3irAuwu7zEnYH10SGQTlZBKgMw+ou1SwLdvy9aVxehiuS5Ml/bIB2idd QSlJ1fiI7lKbdIGju+JtlH0WY4xFtODZpkwIBwkBUqHGBUfTt4M0CIkPSqy0I6vcZlMRZbVvJhbC keKXpgD4UIw9WFAJFFRC5lmlc5M9jx/rB5EXpc6EGD7VzWgDuBCm//CjEa/6wdRlofLxV9r+pu7n 7J5sPw6PZ9YXcz3M2Xxon5y8rv1VD835myOcP06/nB7/kKrlbpdqo4XTFXud+D0soW8V1SDTLGMS KZafwYgQVZKqECiiNsmb2mYtmxHVqyrD3fWLnrAdDhfirQW518b4O84tkzbMZWmR+YoERkznB9qi o7PyaUhT1H73ZTMmqXO4Uj/P7dPA0m3mZppnBBQDozuVMkhtlLgRVtENd34OTdZg4fyFDF7tYVtB b9OgZVNFcGXsqCqsvb13oztsN7qqtnbq3o2ukcKlzZlmY5JXYPG6a8ri7K4pyzl3TTm6VkrtumvO /pnJN3U/5+iuKeWcu6aU45zSdde0v+qhkZa7ppszvbumZC0qcjPidEdmeFyXDomkbbqRbePSeZWt 1la6UroMtwlLOJafiNb0WZThyntX9OjNYa4h6N5qjWAY23ij7q3WCBTu1Wqtzu2zf2+1Zn/lllut 9XzdhN/Ovbdao9j4vdUaVXii0BbRHb3VGtDHSn4qSmv5K7qap5bRm/R955CeAdoErWxHZIVFFO+g 5TwZ2fQ5mjlkQZV7E+oDwgx0bTAGL3pKd/baYhe5hcKjGNJ3//Zh/du6sijm7t9uBGSXtjLBCZN/ u2oE7/P4Uc/4tytR9b7o9oPt3+5/pe1v6n7Owb9dCTXj325GxzmV49/uftVDo6b+7X7O5P7tStTj 7r8p//Y9HREwsmv733WS4N5DdwO9phTSYhj3vB8K9NC8HxaVXRVefCQkqUUXF0jjO0075F07007e sk8Fy1d4Kte6XirrvGyT0beZBhIBGkfEcRMhvZHbiC9YWhW1F7A7eyQAu+GyyrKu7d0/qmF0FKG0 E429FZ9YcQ34hJ3bd4plVnoU7nd1KKzZ5AVj26hDyiyX08CIUmRtQKe8AKFLt+1YLvzZ/J3Vxd9Z zfo7q9HfWYG/sxr9nZXt76wu/s5q1t9Zjf7OCvyd1ejgrGx/Z7WNv7O6+zu9guBN+TuP3hLzeJUm k9h4AaVrsXJNRIT5KJZB2dULn7AhcqeiCspHVFACsebJtmJR0OrC99qAzDGOvg43nCN7VBkT0BqC IzMGtpKhu0xKM5gjUexyXg6TJrhN248I0n6bvlkOrmxyv1TaqWo/qfqwaG3b0HISSR+wMbQuRPci 9Gzu2uZzxqY62DoG2RdzEZ68or5Nxh5HlWmW8ptkf4WY/uF0XjFZBxIdPvRWkj4iXH6EkgLWFUwK X/EYdSyMXRZefND9kulLOMi3PD2fDqhg9f7PCYbuClZ6BWvP6+WkzyYNLz+sGUd7qJJ0/359HjsW Tq38IWNAMgyQXAYFN83caEkODIFWQui7oDtlmNC7D6AD4dI0RjMD+twuV8oCXLyeXgNLeHuM+57D MgTDmCTtiP52XGE5U+ZjWM6UYiYsZ8aSOGYoiXOJrvW/0vY3dT/nEJYzhZkJyzWjw5yFccJy3a9k bn1zhHODsJwpWZsSHFbW0o4mEC4Fbb7fcBAuRbk4OufthmJuO+0tx73YvSJs0uYoaDYAj5FADxs5 7yLipXyBKxZ9VS9wGb8mxk36yGJaPSSp+8mlsZiLxmJmNRYzaiwGNBYzaizG1ljMRWOpZjWWatRY KtBYqlFjqWyNxWyjsfC2Ubodwn/jGguqDkfdKdCt0DlGe2VxuQwXSW/fgbr2JqWxOMhhbiBFHOWA xH3aWRpapodFY6mTBrlfFX9g8ZcFNJ6jc9HojaA74LnGFpdmVIuzZlSLOc2oFoNm1H6wNaP+V9r+ pu7nHDSjOp/TjJrRYc7c1Yy6X8nc+uYI5waaUS04NaO3IE22uWV+hHwnuogVXZdheU23t5WXGXO1 Bp6I6FVP7kuEu51H3Spzmy1FpNUc9lY1n2JUy1Ex2qmbW8pbhbd4kLe5mxsQrAVIl8tTeqNm9MQU md4sSXavT66t5LB5YTGQw8qTgNxPjhbXm7Lt4nyVJiACQd9hoV1ipA0YcJRZ6tzTJbs2ocN9g2WL cvlg+2kNjPZ47MqVV96uUbl9hOAtdNiX1gXuFgvBUSO4sodwWThqeVaEyURv1OHp1W7T6BW2ko65 QPYk/ZYkKntEDSd4gl4L4COieiN945HPDrD9lFbR4fnPlhcz4HnaHbjwpX3V40yUs3n3Ontn8ovN +dlddUGqDGBQ98ieBrj6WSF1GTR1OAWg7Zf+J3AOAHXQiK6V9/ccA2DX2j0GVyAbqL52Kba+AuoH 9wmYA+DoSViAuQeco7zyXviKCyqGVqC1KtwiQFjd1eDmAd7prQK8u7DLnIT90SWRQY2eTKLmGRJA tkvF7lK2B1o7JL/ON0FaCSzX2zj0d/o2G63CHLx88CrrLSQMGHGJJkK5As0A9oG8dxiAdtLyjCEy QCqU0aPvYUZE9GEOmi5JKylgo0LzedYWZBE23+IjurV5rC1cVRl/5gKWQl4FRxKDgxxwHTaJ7580 aBDUGS4UkQK33OERUyuFntR9Yujo4RgKZT38oB7g/C7AAPBP1tGy9tGybuuhSuN0Tp0qO19Adfs0 rzJddLmB8NxjFgukyNuWZOrScgQUX+2QsZqv3x4LQKGVxYqkG3IXoEW6VhPgKAffCsTxwSQQrpjh XWZ50GXKiQup+ZO9NIsVuoN6+OvHc6xW/TX7evo/njByZmVuZHN0cmVhbQplbmRvYmoKMTUzIDAg b2JqCjQ1MjcKZW5kb2JqCjE1NyAwIG9iagpbOCAvWFlaIDQ3LjUxOTk5OTkgIAo0MDUuNjc5OTk5 ICAwXQplbmRvYmoKMTU4IDAgb2JqCls4IC9YWVogNDcuNTE5OTk5OSAgCjgxMy42Nzk5OTkgIDBd CmVuZG9iagoxNTkgMCBvYmoKWzggL1hZWiA0Ny41MTk5OTk5ICAKMzc1LjkxOTk5OSAgMF0KZW5k b2JqCjE2MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3LjY3 OTk5OTkgIDc2NS42Nzk5OTkgIDEzMC4wNzk5OTkgIDc3Ni4yMzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM2NsaWVudGF1dGgK Pj4KZW5kb2JqCjE2MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzQyNi43MTk5OTkgIDU2OC44Nzk5OTkgIDQ4Mi4zOTk5OTkgIDU3OS40Mzk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3 NDkKPj4KZW5kb2JqCjE2MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzUyMi43MjAwMDAgIDM3Mi4wNzk5OTkgIDU0My44NDAwMDAgIDM3OS43NTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0 NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3Rv Ywo+PgplbmRvYmoKMTYzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMzg1LjQzOTk5OSAgMzI2Ljk1OTk5OSAgNDQxLjEyMDAwMCAgMzM3LjUxOTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2 My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzUkZD Njc0OQo+PgplbmRvYmoKMTY0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbMzQ2LjA3OTk5OSAgMjkyLjM5OTk5OSAgNDA4LjQ3OTk5OSAgMzAyLjk1OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIz Y2xpZW50YXV0aAo+PgplbmRvYmoKMTY1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMzg3LjM2MDAwMCAgNjEuMDM5OTk5OSAgNDQzLjA0MDAwMCAgNzEuNTk5OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5o dG1sIzIzUkZDNjc0OQo+PgplbmRvYmoKMTU2IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQg MiAwIFIKL0NvbnRlbnRzIDE2NiAwIFIKL1Jlc291cmNlcyAxNjggMCBSCi9Bbm5vdHMgMTY5IDAg UgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMTY4IDAgb2JqCjw8Ci9Db2xvclNw YWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+Pgov RXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYg MCBSCi9GOCA4IDAgUgovRjkgOSAwIFIKL0Y4MyA4MyAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4K ZW5kb2JqCjE2OSAwIG9iagpbIDE2MCAwIFIgMTYxIDAgUiAxNjIgMCBSIDE2MyAwIFIgMTY0IDAg UiAxNjUgMCBSIF0KZW5kb2JqCjE2NiAwIG9iago8PAovTGVuZ3RoIDE2NyAwIFIKL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj+S2Eb73r+hzgJ0VH6JIIAjgfQXIIcBiF8ghyCFY xzEMr5GJD/n70bNb5CepRKqklrp7B/ZoKIkqksWqr4rF4ts/f/nn+d+/n9++//Kf87f29/svp+wl y13z75yVP2/6BdK+KJlV/85WqBdT1KXfvp9ez6+nz6fP5f9fT8LUL7a/ypvdJ7L65/dvv53eNh8/ NSVf3v+1vPrfWZ7/Uv73y/nv/ygLf2zrqx74frLOlHRkmVDln7/2/xQqs+LFlNdleRb+WT388+lv fzj/VhEmX2xNvGgI7P/5RmQ6M/ql+msJya/XV9vaq84au+5XHEWfyc9WO3HWunwut+f//uv0U/n1 67dNppwUubGj1/1vK9V+S5+LrLAvuvxM1e1K51VfZlleljvxIuvysv+N0PVDMiyXRf2H7Nfz60j9 1dD81KPZqfbf6LVHc4+2snNqdqhp7n1LCFNdA21++bUt13p+Hak/pJmpn0doHqNhbFzW6Ofhsf7u 99usfh7mjTFe8mnuRJCDCRk3b7SuJFdWSrLzZdZ8TpMNov7pk9KUjMiG14kX3309vf1kzmW7v/50 bih40/z62tD8piRan7/+eP5jRdOfzl9/OVWSsC2QdUFxLVB1gb0W6PCJpo6PX9vmr9PRxumqo0V+ qJ4uylm1Tk9fe1n21MHwtadzZjxP9kXsR+ueqgdvoKekqVhSdx0lPwbdIJpu0NcCSz2ROapAfKgL hLiUSBW+Y8ICGKCGEHctyOuCfIIQEX5XCKoSIcMnEggJGyN+COt4FxaQdWRF+Fk7wKBxsOd14sWa jVyJy4bYKJcVGxWmJUV9Cju6nXA2JL9X8GG4C3othl6DJ2wwaduOVuHoqRg63oVDEX62nQJTwgO+ Ak/QrU3oIPgKTdjHsLXQfOjC9/GUwtSEOoAOsrU4DEB6AhfSzQ+ZDoeBoQvFp7D50B9QKcm46l0g Q1QrmbPrd/OwRIuwRLmgB6QOH8E5k4Uthi6ABgLz0q/AUMBgQQHJiUg69DyMHk0pDNb7qzhPlssV 2CwFc2lgetp7iotE2B/0nImf3SCXUVDDKyOKeFmvx8uhFjKI3nfp+R4v3JHJcgZ+UJn0+KFFFVNi FzoEJgyt26CAY+hgYELxjzzFoYWhx8IC5O0PoXj8dB3KOUhNIFITMjtbWWL6792leSltrry0iIRr rlxVWpR/2+bi26m24l2uVdbdMv6bpqmzfrK6VM3jZ/9F1dWp6if7nytvNdRc3uzo/Hb6+fTuDyvB T6FEydZSuMVCLBwTz77Sl+tgnEaemtPMGR9oDDg11vbcem0XI5bsFAvDK9A74XRsWbj3BKAxRxXg Z8EKAikApAMdIelI6Yho6b0CdKi4CcvJ26o20Xu8DSAOMBuyf1ggaR0OPQ2SEFQFsACqSvguqEra IAEo2TzRszYHIGqIdLGPSDyNKpnDehhxjkwRlmDWcICHPNc+J+7L3FyKlGsVovKxcdkIGUpBjiUD eErwWIwB0qdRH8uovcZFuuxGgaA2FyCoiyEgqG0L2sqLAAjWt4z/pmnq7ICg1kNAUOuuTh0CwepW Q432gGBd5/pAMB+X8ncPBC9tfwLBm2E2aY3Phk/MthFmo715tC6ATiMVLiNEm3J30t0MlMLwkgsi 4l0qEliILgvnz5k7RJfGLGApevXrVs5MGpDSHvMEvBWPUAFcr25sHQpBKOFz6RNBUJQey5WkGxF7 lUIccluX7ORVulsQwmZtFfZibRVuyNqyWWsZlReBtVXfMv6bpqmzs7YKM2RtFaatszChtVXdaqgx nrVV17m+tWXlKD6LRz0A+sABAEJcFaEyga+Adtnz0vgMF9Bja6nc47pbaamw0jZ27jaLBLbw+4RL 1Dl9EXUuHxJ1rhNLzoSiznWyrfemaersRJ2TQ6LOya5OGYq66lZDjfREXV3n+qLOWUZRJ2Uot0gL B72h8aY3ghawG1YxZ/dlz005x5/rSfGjy0F6+AQL6Rz2LMO8XMlponJfLD3URB2jlMNXo6qbI22h 4SUEr9GN4/PD3cjf0RM5JhCOKYt49Noh3WNrrNnRlsKM2fApegKNRW4ujAe01uN1hCQrYoOFfgep /Wl6HLFF65f4tQB07Icj1+6xmWrLGnpuRuA6g8hZE0uzqBPZqeinY2GvjgWpjDdST8dCFTBu/T5h ciwonXWOBaXFgGNB6dYJUF34joXmlvHfNE2drWNBKTvgWChL2zqVDRwL9S2ZeW92dG7gWFA62BS8 yLFA468ZC3K0QUdvBHi6HiKhwdP18LQ2+KFyXgq/vozZxmJJ3/TEArhyN9baOwVceor4sOuhNbuR 1SDMwJeiSFYk5Swuy9MhK4D1oIPooB7wcHLBqeIKp4pBOFV0cKoAOFV0cKrw4VRxhVNmEE6ZDk4Z gFOmg1PGh1PFNnCq2BZOHV/BbO3O2gz5JJC2E1yzW9SqbPhKgv8KuJ3mVJL9cV7Srnta7dGsSyok ZJgRtxkL8rGXraAzwqhonoLgLOghWoKS5uaMSoEweiFvJKdCFKUcgWc4DjRU2AQponhMCBinfQkJ C7s3Qp9ruMQZLaO12YFj+wRDQqU1R59DxOpMj47cTpR037JYltZLK874zgPlhgG+JTsdl9joOli2 ZEBzadhLRvAoGO0ZYdpkMpQUsABgCb9LyykaPpBh6TNkXUJCGZbF8CzzZ+ptEuE91u7tlF31HHJp BCxwiHpd7F2v0eJihhW44igwT2xRb9m5jgv4omYktEuw+W7jlQUvNdSh6cGOtxtnRKjQsyHBkAQk FG8UzjAL4neazvAA0vtpODyRwGNhDJwKt9vhE+C1T7Y1OOSr6RS0zoMOA96X74M+luHU12EqZhkW QA/K8CvaDOv0hVJL+q2VH8IpRwN2GigkINgEzAcTm0ZS8b4cXCikPZeAtUAC02KdIWPPDPcP0EFb CdA42mMEldI4gF7S40jkTNvqdMbIkPR+Cklymo5GvJkKXOTZZesucCEUhBuvMcJ8hJMnKpWhFMce C2Pkxphuas7BZ0dyn04VQPNBAcEGcFDZMQKWGDkpZo8cthb6FDbVg/YI9Qt8JWFjvgC5Tr6CmXDC VyTQAeoVCiAkAOQHfAXGFkgPO7n9LMvoq4h5CyqJTHYwFt4Q84qAPoUZNTdhQgwX4mADB9GDDeoE mg9QgSPFBPQH5L6AtsA0JQuwDpo/4BVQ0TCzYaDipxhaPPQUAx4DDoqJ6ycmoYmYhHR/kAbwjPDx 5JwkPeAM6hUGG9oSflaRA4XND+eLpndzrpHWhYPHVMxWRILH7Hw1z0I6GfoGKEfBqUCggEk/L1QK PKbCOpAOxl5382f2znaKTAwljIuCbCphJ8NERg6CcYHP0lAhbBzjUBqxZAI9c16tr19mQAVw7oC4 ADFOn90AXQgDBcFv8Z/F/qCP/yLNFZzICf1Bc+FcNc8yTeV8iZvQ2m1mNpo8e53ZSCnHzE4Yl3hb HUZOgEstpBQXAmh7jmwtPMGptPRTaaWyNiJYcNyFlSqoA1gb0BboSrJAQX+MOIimmg8dRHpqELGB ezDeAYAyGSglJxA6/+jWAuYHcZEwLqSjSvYCtO/s+NdCmDE+weNfYQQPffzryGofLBFBiKwLGcNN fLcInwDaIVcHHqA6MnV6lYCHDnr1E9lFQCr5igQGgD4kPfxjlN7uLNviEnHzYGfZpiSnSThkMyEm aY0zA2fQAQCfXlZOaG38onHKZmPSnUpnEWKJ1aeDPRjyHd3HibkL44IL6wmzjU7dXeN0gzlx8fAZ OhKHI8VTozEu0U4z6KLnHZ1BkBZMtJSJ3yDHkqwLNlRvotrgs7Q6WCdPCj368ZFbKZtkDh+zujD5 YaG9eXuguFd6mm4U1aqcL/ogFcle41xZTkIfwcoc2qQoiI8k7DGaUurgd6F5P0Gu0RtO6Uh7jo3R CUmh6Ry/AFAQkSeECpOjjV+BuZ8QS71GAovH2g2Wvql7IeZX1hcgHMNwmPQ1iJPpEP94KDkDa89N m8GhLNxF/9KHL0Hb4vNZ0Jtrae2KCXs5DlVM0JUMGmibFMcJ6cVmDCXtu+OYpSPDsIz3q2MP+sy/ zqaivSjCw0jglI3BDAnEjp7mMX7DF8eJmOscoVFrJZtdvI433Ref0Pq97HJfundcecPAsdvvRq47 lhSM92RK0CtsdKIZeuNmwiSc61FeaOM440sYEoEdCBxAcGx8grVbiRwjApGTsDgYs0NuWgFJOcq3 DEah/iGccnSaO9rLRm5r3ttxuss8qPeUL+xWx69zJA8c2Qs9Jcf3GtOBh13QOchWsU91Hcd7lUI4 UNDrZGIEzAwQGSk1lkHcatNlELe6GMggbnWb7bu68DOIN7eM/6Zp6mwziFutBzKIl6VdnTrIIF7f aqjR/QziTZ2rZxC3OacQO7D+QSsaOyQswP358YFYq2R6OpB2RR5aJ0H6bN/F8c7z0rnyZvKNdkng Z+kUB+Qe3RnpGmjWBkXp4nQJa9StK/zBYjoZwxp50WtGDek10+kgo0O9Vt8y/pumqbPTayYb0msm 6+rMQr1W3WqoyTy9Vte5vl4L8xUk6LXjSQKRW6/tz/1SFKXJWwFvc0phvY+lx9sboZiHRw93eLDc QsdTrn1O3NcKA0fy+9KiHRuXdTwebFDAqQsUcHoICri8VdvlRQAF6lvGf9M0dXZQwIkhKOBEV6cI oUB1q6FGeFCgrnN9KOCK0Xl+91Dg0vYnFLiZ1pbW+Gz41NobaW2OY16g0xI2/XAsnyWoz4TAZTq2 Zm7sxUJ8UeeD782Z+8MXrro5t3GbbD272coOvTxCLw0nRCzEhxFhGuC1EfqhQIeqD2C+MvYTdFCU Hsv/oOtI1J7gYhH1mfQr3S1u4TLQnMw7A81JM2CgOVk0xlR14RtozS3jv2maOlsDzUk1YKCVpV2d KjDQ6lsNNapvoDV1rm6gOdkd5MmxBokB99scbXijgxz3hYsmKH165hJGl4N0erV8xY2FS8MfM18+ 0Pte4uf2RkeOHmairhMq34p6rUfbQm/EpXNFQOP47NkbGQHMseGH2V0zI0kBw+6alP17qyQYUM75 0+OxRE7CfkaGzEl4jO0m+mWbbZRr4mAWVZB3Wv3oO9ru158jlfFGamf5/28Tg5FZv0/4VMijIk7c psDhEN/ENEjBgqQfPiFBU8phwAmGId/xuCwqpMg50SK9pEAr3fAAUNqjAU/AGYjHxwv73M5+166j BMZL0SDxGx4e0qxnkXbuQtjTExAr27da23FlTe3aTnkpcW2nLG3WYeoLb22nvWX8N01TZ7e249zQ 2o5z7dpOeRGs7VS3ZOa92dG5/tpO+ZlORXOs7QArAOPDJG7Pu5haCKQzAe1IaT0t1ukIBJF7XPe0 WMs+sYXfJ1yiThQXUSfskKgTrhV1woWirr5l/DdNU2cj6srLHEVdVdrVmfuirrnVUJN7oq6uc31R F55SvWwrLanjZ8RE0fA13sR5LnRTI/dc6F6B24+PaJdmoM48GbMNKk5PwsFg8bjscvL7owAuPUV8 2PXQmt3Iaj434ZS9DpGRdNQwfepafPJRNjilr3BKD8Ip3cEpDXBKd3BK+3BKX+GUHoRTuoNTGuCU 7uCU9uGU3gZO5dvCqeMrmK1dJpshHyAtYR8LiIL47QGPhWvbo+6XxWTAMNC8TG+TpZe6EkaOzr+V MEG2RNcsgOuyn/sZRb2LSdjHFouSRLrMXULLHitbIQgYstMxLIyug2VfHDSXFjlkxLiC0Z6xV4ZM zzcDcJHeiYHvJiTYp/OLJyj6VdIkKmv9eXh/ebyjrGaGyT0j4XpCtD9D+nA6xmfNBOMM6kJkbozQ A58mCFbgOif4bukPWXi0iHDeYIOPaZt8lTMinOJDUQ53yuOiAMC9nNAITwi+FaWFck0Lj9fR5ZoH XbiXMxxZmm/qlfGeXA9DFdNPDuDQN1KPsToi2ATMB8KB1rb0kYU06Ik/7AY1QfwZuQmAZcZiMnmU JvYpNI52d0CltLeHdurToJjhoPoZOcxD0geTmr/krv0H8yi8R3veJyqrJ6WZOlhCuM4FLyHwKhtG hSDEzbUAlDxoORsWiFBGfQyfgPNuh71hyf1QASSrdXBKbc/F3WKX/hLih5DIsCtaQTHV0IJqqBre ipXaUG2Mf8Lx3TZUaO/olodlbW2sj4d2OeLlz/m1bK4wNd3tr2/fU6PoPp8/n/4PHtzx1GVuZHN0 cmVhbQplbmRvYmoKMTY3IDAgb2JqCjQ2NDcKZW5kb2JqCjE3MSAwIG9iagpbOSAvWFlaIDQ3LjUx OTk5OTkgIAoyMzkuNTk5OTk5ICAwXQplbmRvYmoKMTcyIDAgb2JqCls5IC9YWVogNDcuNTE5OTk5 OSAgCjY5My42Nzk5OTkgIDBdCmVuZG9iagoxNzMgMCBvYmoKWzkgL1hZWiA0Ny41MTk5OTk5ICAK MjY5LjM1OTk5OSAgMF0KZW5kb2JqCjE3NCAwIG9iagpbOSAvWFlaIDQ3LjUxOTk5OTkgIAo2NjMu OTE5OTk5ICAwXQplbmRvYmoKMTc1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbNTIyLjcyMDAwMCAgNjYwLjA3OTk5OSAgNTQzLjg0MDAwMCAgNjY3Ljc1OTk5OSBd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1s IzIzdG9jCj4+CmVuZG9iagoxNzYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFszMDguNjM5OTk5ICA2MTQuOTU5OTk5ICAzNzEuMDM5OTk5ICA2MjUuNTE5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwj MjNhdXRoZ3JhbnRzCj4+CmVuZG9iagoxNzcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFs2Ny42Nzk5OTk5ICAzODcuNDM5OTk5ICA1MTEuMTk5OTk5ICA0MDkuNTE5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1s Lmh0bWwjMjNSRkM2NzQ5Cj4+CmVuZG9iagoxNzggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAyMzUuNzU5OTk5ICA1NDMuODQwMDAwICAyNDMu NDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5o dG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE3MCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50 IDIgMCBSCi9Db250ZW50cyAxNzkgMCBSCi9SZXNvdXJjZXMgMTgxIDAgUgovQW5ub3RzIDE4MiAw IFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjE4MSAwIG9iago8PAovQ29sb3JT cGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4K L0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2 IDAgUgovRjgzIDgzIDAgUgovRjggOCAwIFIKL0Y5IDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+ CmVuZG9iagoxODIgMCBvYmoKWyAxNzUgMCBSIDE3NiAwIFIgMTc3IDAgUiAxNzggMCBSIF0KZW5k b2JqCjE3OSAwIG9iago8PAovTGVuZ3RoIDE4MCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCnic7V1Lj9y4Eb73r9B5AY9FUmKLQBBgPbYD5BDA8AA5LHIIZrNZLOxFJnvI348eVLdY n6iiKEqjntYMdq2hRLJY7+Kr3v/l6z+zf/+RvX/8+p/s2f77+PWUP+Sl6X6yvP59NyyQ1YOSefOT VUI96HNb+vz99JK9nL6cvtT/fzkJ3Va0/9Qv+y7y9veP599P77vOT13J18e/1U//y2T21/q/37Kf /lEX/mzbaz74fqqMruHIc6HqP78N/xQqL3X7XJfn9M/m419Pf/8h+70BTD5ULfCiA3D45zshzqIo H3T91xKQX65VbesNsnzPw4ZnwafLzIhSZUVRf1eo7L//Ov1S937tW+fKSFHqyvs87Fsp21eRSXmu Hor6UdVoV22P9U9ZlxvxINvyGv9aFM1HQtJyeW7+aMsv7XzztN+Q5pcBzEbZH++zA/MANpUXDc07 mAd9KaHbZwqbW34dy7Wdb572KcyJ8OyB2QeDjy5r4Hmc1t9dvAXheZw3fLzkwryyLJ1VmZW6/k6k lCWjisKqKUeWjCpbvAgyflJ+wdegnW+e9pPJklHaNM+C8KVRlWzBBNic8sFYLu1887SfTJZcPHtg 9sHgo8saeB6n9Xe3PAjP47zh4yUX5t6cGzBu8+SmaDEjaq8gE2UvNl/iDK1of4ewdCUeQ/syUfHD 0+n9Z52JPHv6JesgeNf989QB/a7Gjcyefs7+1MD05+zpt1PjVtgC2RacrwWqLaiuBQX9omvj05Md /jqYroy6QUybWnzWwXSki/YyUbEdT9X4lKMDMvV4RK2FHFgqCtygwJACSb8QUOUT16gs6RePtOAz 7SWnXwCiz2y3moUUCmD4FHRBCySFw37REnwp5erXoZTD0QJO6eCADLLiesE2gC4faBU5uwrgFKpI gONH+gUU0F6sqE71ArQF0CmSbbdJqG9myO1HDjCUFxBCXsRoFQE4BYkCeYEqgHWWC5HYwEE8sam8 IG1pL4gxVuYAhaBQgJMBpxLElC3ANnj+gCp0+NCoAELNFzFAUICIAY8BB31KJoRShgshgs4yXYTM SaAcbRQQpKg1BTWu6FgU1drKg+QBHLQKGHHBKxQ6OFWkI2URbk1znrVBO0RQDhTKfG2JtH0dLsRu eUXPCnKA0YKxAF3o8JH5E/JYuX91AXodLNB8Jy+JadxGPHjJpoApCAKA+YHpeMoBoaiJjugW8QGA sV+g3Qd5icAHz4VAF4oga4GSiOk53BREjHYbyUbne6+SjZCmkOwIusyPGtF6UDGFwSmetrxUsnRJ abSqw2jFsjbYF5xCoo0qaANYG6pQ5QgzE3yBAgR55i6m8AEYYycR0MmDmav5sSkqaYCUlSicl+JH S1WOAv0RQRfPHIo7Y/zQ7WHI2xXE8WdnPjnge362eWannapppvtHNI3UzSKGVj62EJ0eKa6IAv1O v7CiNlFglbUQ11YVraNpAeiNTvgMZYNyAhBB+0WPCBoBQGi/MqeAQL9n+gXATqtYVTsA1Scpg0Zg rgiw+plFEYDKVwFJgcGcYTD87PPAkK61QGM85reUjVCYfr1JIS0AfLCdoD1LijYP6wGnXRetLLcq ijU1B44PlJ7QLTQKi2f8WCjoWACQQi9QAICB0+cxDQNIP9Hh83CAhw++FTQaMVqAFMbCshSsCmK3 wLjgwQGPgbzzkPJVWOZHJAPGYHCUDDb0mIIDWIoVD+sYXDWkstYsv/Zb0pJC0BLr912HIwv6ST5n ydKny4o6ihgqswAeASQBTngh8oRSE1VwbZlnGlaIArgohVIBwD4moFxrhYrchI9+voQgWQAd89VQ BJ18GJxSEJrIIdIaBgfaDwYHCKL4sPMK5wnQ18Bp8QjaAUDlccjb/ghDzuLQt2skQuaWSZQqjCtS gI9Vui2KyunWzqlOmSVBkcw7nNAGGGHwY6ipR9sPVSDmSKE+WUiRpaw9HfTLi+F8pWM5N4Uel5fd a579T1NcuFfnGVQuclCE48vPd8EmEeDkj9S7+nylZEg4KTCcFDLPTCPL3/tH8yDyotSZEPbJ1KVl s/e76h6e66BRP1SmLFTev9JuTd212X7ZPNrPM6dioW2b9UPz5aC75lUHzaVmD+fz6dfThx9WipGF Eg1b0+2vi1QWcmACG1f8SAGjXwCzIMOxoGMQgAihBbifbn60WsBCKnhBvATympJfzmcpNaKyATI2 SMBugIe6LwaTNSOxFw3hkFZ8oOixFVNeDqjx+VFSQHAWKncLrZqQrvzfTniyjbthvbzlFkeri8XR xZjF0aW1DvUDsTjtK+3W1F2bvcXRYsziaNG3KajFaV510AjH4rRtrm9x9Dmlk3wzXLuSgTkUOx/P 8mE0II21Fgn1+KCNCF4FSPkJYX5KJHRub6kJyl2FcDPCHDNDFsFScw49MFq3utj51wrWd+KA8dPU eDYL4os1hP/mgqeFc3nl2eXL3VqyZI6guTqCZtQRNL0jaMARNL0jaFxH0FwdQTPqCJreETTgCJre ETSuI2i2cQRNSkdQSqorWNsREGmzTk3M0mkKR+FmLOVW4Tyq9YidFDBez8anlS1BEtB5PR8BeqjZ X7jeYnJXP/AbWubLdsBy9V0Jqg/SFN5nM9fkGwuMlo3n0FGCwaWLcF7fLbyrZXI0Bbw0fJ4tQPwC LroTHru+0Ak2xhWP+1I5ERsVWdD5/W92V+3UWNawLwGb2RJQf00/OIkpkL1V33wf3qx9lomXaQY4 c3b8F5dnEkt6vgoJxQI6mD69JJV2KLWzA/ivsqVc5ZWLk3Qm5F49TtyLlGJWdZPQIMYX9OyYXjqF bqaVKu9fB+yGTxFcQkgPbr1i2TLFrlxrhi6XViTxOPmJat5wfyS98LMi8IWM2EC/c5/j7WzkV+0+ wivjvekprAjmTbLIdkwvjBEqica8XMFyzEjMtg+brTE1Czt2jak85yNrTOXZrgc1D+4aU/dKuzV1 16ZdYyr1eWSNqS61bdYP7hpT+6oD7DxcY+raXH2NqaQXkixaYwJWAMYHIbaXEkwtSIJCYpfS725N Zf7hIlwafiUdleKU3CpncfnBJdh3GRDzeQ6ST/nSUGU3e2qVcZXONqTkhx8da0XM3iZxNi5X5wRM 1W1yqnydffoRbiINE2M29MzfV8UfNdtoaXwvx//ZjSCo6UCiUpx/D1XBS09Anh2pvC+LzPtB/LE5 1EHzty7i9E6qqMFcogadj0UNTeKA1sNvMwg4UUP3Srs1dddmHzWY0ajB9FGDgajB9FGDcaMGs0nU oPOUUQMfLgdsfOXNcwKVdSxQEMrdW5x1bFcJ4pClQULu6JhtJpjiD8/PEhAgf5EuKNBiRlCwBm+P SD9FIiwm7Ebrplt/m4pO4Co5nqn46yH5kzNrnd3U8uoYqVHHSPWOkQLHSPWOkXIco6ZN6xg1ubvQ MapLbZuSOkbtqw4wxzHq2lzfMVLbOka3byq2XkfYzIcB0CKOHYIqeNXj9Dfgodr7ipdtmAQy8LzM n5Xnp1QiKMdP20UIyJZ+chKvp7h4PccRpz0I4dC3WHanlD7rhOb0hu4LAwXDIh33bPNtJDnGDMPl VQ57nEsBtQMOsrJXZgU4XPw8JvbLWwd+mYM/yMwb+ohrx5LMfOe5K6mvc6fz696DeotqOsl2svXu hdVG9GS5qzBoo3tQ8fRNxC7nFQVoGQfJopxmoY32GWwypwRzbNuszQesvUZcZ83P9IMXx89+Rewx mn8ZTcTJgnXmUYDH6EkczGAFX8CcY3TQs0yQz40cn3PtA6MoCQYxM84jQbqEGXhIckQLAKWQsajQ 4wp3YYDbXud8HT7sbQmIPnjTGOGORziwIOm8W8jvB+HPLc6/yB9VMq/nU2z849e4AQ4+5IHB8XM3 0CjvGPArFLyLmyBdSMAlyRT04a3JC7PZnUti9geQQgEka4PDDR5OnmgUElchxiBToYfppmQOuvVc 9z1VAMMHi0QL4KZHMUfBMpTTZTDlcLSAU8h3B9aDTTQfkVQQ08qxVfD2TEiiNz9xJa5wsrnYkbZ8 LvY5N/8x1K9myC2fMpA9xp0k4ypIFMgLVAGss1yIxAYO4okN5oRPSpoipzPgA/J2wlhATNkCbGN+ SklMewySzWeOZkUMQyBexNgs6cPrBhYKYSXChXBnty0M/GQIsyGDNRx/olobcrIiGWgVnMrhFQod XMKsvpUMt6Y5z9rs5EYA5Y587jO7vYd87svgWINxj3Tls5luy3TlVRFuo4684aRR6AXUFqAQzg6D k8cWHLnHCdMducc3zz1uROljC8w97pl8m5pqPHKP0y/edu5xdnRICKzD4gy8BKsY8Or4QR1BWwV1 8yYSp5uiX5A5EqcTOF7rsoYjcfr04G45cXqEvMzfPwlLRQE7/QL2nCXZYafPjtLZKHF8ii3Kt7Pj ds2kPwl2wxktvJ3MP5Z4ZOidbbV2lKHXVGV/5s5UeuTMnans+bjmwT1z173Sbk3dtWnP3JlKjZy5 M83cSNemImfu2lcdNGp45q5rc/Uzd6a6ZDs/MvQ+HRl6Jyh144kcd5Igbj+3ibUZegfyfztb7W8q Q6+om86tyWmeRav6hyanKZWtfeieHKPTv9RuZW3b7c2OqcbMjqms2TEVNTvNK5k7NS/Arm93mn6K hIbndpj3SNR7JOpl27jDRL2ORrgZab61TL2iWTrd1ozu1hPbb062W4uiEqTqdRhzt8YsnUuoBi6h GnUJ1cUlVOgSqotLqFyXUPUuoWj2qLY1MreqrPp2JXEK7UuZO5Uv8G7iFaqUXuFxpcU+reZx8+GR tXeugmiz9joK4kjbu76krpi2t6ZlYbyD4U//3kFinSkVelfXOtxj3l5HPu5L6RyJe5Pri50n7q2Z XfeG/cjcu+vMvUNS7eww2eul7nWQcuTuXWoBjty9s/2fI+9uK4XVDJQdiXdfz2eYmD57Rfv/pmeQ jqS5W+jyDS9vrtWd6U9HHfMBs5X7dqs9IteX1R6Rn0dWe0Ter8o0T2S1p3up3crattuv9tTFI6s9 deml3YKu9rQvLVDFcLWna3f91R5B761YtNqzl/y5e7Jf+93kyO9VP2ZJd6kV97tEVIJWSRE0v6XD gjzXec6UJPFWxPVum/k38h9n8JgvVj2DV8ypEqFCbveu4+AYYeHyN4jQYR53aR5jZn+jrUEatVz4 KRWTKIQ1h0k2WUTsO91LiuhNuD3CgUATy6vlbXaIq1K7nIqk46/iicghDmu1fPSUgpa838Kffpg/ 25/kkAE/Mc1PGcNY+EvXEyRf2Rmx06j2svRiCGDnr6Wno0Pfh9eoKS7s4P1JPmhjj/qM2L5VLqiQ pSGkirhfgF25CkjOtUZajze9bB3g6tH0GTG8zCeUWCW/W0yGmp1MngQcU4pI5RBzxVHoYNJo+7Of MqskihIl2+9ORDXgDDmrZEe4KkIiWCsbMMGS4GjbKrtjkkz0rMIgEVflrBKCptiVwU+E8sflIigX MSHNuymhcCxcGNDS1VNwrTOm6oDB8JuDeOGfSvh4vUO1NPYHRknfBVzI6m+sRZn2Rdy6uX21yPsd 6BIWV+FqUU+eGk1RCOIwdfmooNrxE/0iMHdYLCLKyk2GaMk+vKjVXmOZU7LCLaNXVFghTgakdDKd CbiglCJJDTbM1r/ZSw2F0G1z9p/n77E7ab9kX07/B9Vq+E9lbmRzdHJlYW0KZW5kb2JqCjE4MCAw IG9iago0MjQ2CmVuZG9iagoxODQgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjczNC45NTk5 OTkgIDBdCmVuZG9iagoxODUgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjU1NS40Mzk5OTkg IDBdCmVuZG9iagoxODYgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjM3My45OTk5OTkgIDBd CmVuZG9iagoxODcgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjcwNS4xOTk5OTkgIDBdCmVu ZG9iagoxODggMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjExMS45MTk5OTkgIDBdCmVuZG9i agoxODkgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjUyNS42Nzk5OTkgIDBdCmVuZG9iagox OTAgMCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjM0NC4yMzk5OTkgIDBdCmVuZG9iagoxOTEg MCBvYmoKWzEwIC9YWVogNDcuNTE5OTk5OSAgCjgyLjE1OTk5OTkgIDBdCmVuZG9iagoxOTIgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA3MDEu MzU5OTk5ICA1NDMuODQwMDAwICA3MDkuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE5MyAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMxOC4yNDAwMDAgIDY1Ny4x OTk5OTkgIDM3MC4wNzk5OTkgIDY2Ny43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM2ZyYW1ld29yawo+PgplbmRvYmoKMTk0 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzEzLjQzOTk5OSAg NjIyLjYzOTk5OSAgMzY1LjI3OTk5OSAgNjMzLjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzZnJhbWV3b3JrCj4+CmVuZG9i agoxOTUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIw MDAwICA1MjEuODM5OTk5ICA1NDMuODQwMDAwICA1MjkuNTE5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2Jq CjE5NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAw MDAgIDM0MC4zOTk5OTkgIDU0My44NDAwMDAgIDM0OC4wNzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoK MTk3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAw MCAgNzguMzE5OTk5OSAgNTQzLjg0MDAwMCAgODUuOTk5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagox ODMgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgMTk4IDAgUgov UmVzb3VyY2VzIDIwMCAwIFIKL0Fubm90cyAyMDEgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Cj4+CmVuZG9iagoyMDAgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAv RGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+ PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0Y5IDkgMCBSCi9GOCA4IDAgUgo+ PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKMjAxIDAgb2JqClsgMTkyIDAgUiAxOTMgMCBSIDE5 NCAwIFIgMTk1IDAgUiAxOTYgMCBSIDE5NyAwIFIgXQplbmRvYmoKMTk4IDAgb2JqCjw8Ci9MZW5n dGggMTk5IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUuP47gRvvtX+LzA 9IiknkAQYHpmJ0AOAQbTQA6LHILebBaL7kU6e8jfjyzLssTP9EeVi7bU3T3YHTdHporFYr2r+PEv 3/+5/fcf24+fv/9n+9j//fn7JrvLimb/s83aPx/GA7a+czbb/Wxr4+7Kqht9fN68bF823zbf2v+/ bEzZfbH/q/3Hwyuy7s8fj79vPu5fvtmPfP/8t/bT/7Z2+9f2v9+2P/2jHfy5n2/3wPOmbsoWjiwz rv31afyrcZmp7sr2czue+b/uHv518/cftr/vALN3dQe82QM4/vVD+0Vr8ru8/e0SkF+OX22hcI01 RVkHP48ndq6HJ9+aoq7udni27dJdXuzWk2VFi9KsW3Y73uKg7MDNjPXHbffl3fhxnqfA/Dv0/DKC uXH9T/DzBOYxbD0+O5hH7yrt/hkftun4aC3DPE+B+X2YlfAcgDkEQ2hfUuD59F4/T8ej8HyaNkK0 pITnvKjtbvqsnNJzXjRFB0M5hcEbH2AezfMUmF+NnvMyqzs8lFPayEubdZ992Kbjx7Uc53kKzJ8I zwGYQzCE9iUFnk/v9fMUb1F4Pk0bIVpSwnPVPtG91kzpuSpN2YklM4XBGx9gHs3zFJhfjZ6rshXe 9QHm8bty08lLgG0yPlrLMM9TYP5EeA7AHIIhtC8p8Hx6r5+n41F4Pk0bIVrSkoOmKTtG4NFzO153 h82DwRs/ypTjPE+B+fX0DdM0bq/oTWV3C0rZwenBNh0fr+Uwz1Ng/kR4DsAcgiG0LynwfHqvp/pG HJ5P00aIlqYwH8yOBpTwWbp8mbeYyVxWt+ZLq/Zs//uv9i3fOl1dYBGY7s8YmP1IwCJ4OfPF+4fN x69lC9v24ZftHoIP+78e9lB/aME2zfbh5+2fdkD9efvw22ZnAPUDthuojgOuG6iPA7n/xH6OHx/6 9SfCdZHbNeK6KNz6cF1Vq6Trql4fXbc/zQpxbVogEuFa6CZ5OfPFbkHN1rhTCzLO7IjH1MUU3NGC vvjw1x785pP3FZN7XzGZP0dFnyi6gXzGa7NP/hz+Wswe02Y0Uvuv8d9rLUUIgHrfDRQ+UZyBDImC rh+XC3MAlr+y1eLiPtPV+nDAXuLmwvIBY/AEwAGQAhxAIAA6J/bG/wrA8aMHOhIZ7pTGcosj1xAf /7xy3vH3QbWGEQScdlyd4ID4pAtz4Gsp+cNWuXr+MQSeQnkbbh3ffv8J82U2YP1aLiOQXj60FsfS 5QNiCPaB0yVlIRE8RYO2YbWcg8ATnLUDHBzrArkNkAYkymWE6oqKESqcbX8AWQrdKUQ71w7gKyDZ YQDgoGsR7INx9LV8cQLFpmRsOmL583lur/lFa90GtW5jW+uklZA7R87hs70zWd45lLoPZdONunag 7j89bowp7+qmyF02/GM5/XLZz9s9u/ucNd03ttOvZs1h3vbT7tnxS3f/aLPJlwd4Hze/bu5/SGtT WDMoFcbfLgFL3FNJM0eIAC1yKuEnD8gX2BmojClERIT2P18fUtRLRzu3f4sxw0jea8jZMOLuvd1F krmRIuZvZoQipqEAUGqPeAu1VBCF9/7iFmu5FC6bMhkkIU7uX+efkPkKQITqCicE9j/XVOYH7xUa d5zvKFD3ifPvY9E19JjdiO8CY0qhRtn7+VQFahQgiJtu6ZSkfKQk5SeVpHxQknJUkvJBScqnSlI+ UpLcSSXJDUqSQyXJDUqSmypJ+ZWUpPy6StL6xcZxtTfi+Kn0GQCN+zO5CsQ34iocf7HaqsQDCE/A Nsz3VSPnhZPLrWKx6+UcFfJtuKbOrKMAlYOcheCOhpOIK43vNuOUs51SM+72efHtT/DzRAmJeJ4L 8Zkv7aiti1+foDZbdvkmg7btIC6W+xsEZABH6d4XNRBfNiA3jC+M9u8tjwPlafIbsaOvjGL7Qz4S iz3tjN5b+wNAwz4goNGEwumlT5BwDoozy42F9CYx+sJ2dFSaoC6hEV7mJx98Y0m8RdyLB5BCwImH BvlqU2AsQqhrRAJho/g2cJ2Ge9dgLUmsAEGgA44HB4yLTjC3/QGMHdKdM5YyyPm+hIjTQB0DqNGu RrfgBINY5+kpsC8waeELarlxfqGndC8+qvLwWojh+jlQplHYbc7YOcsFRkbZJfdoRkSsuZ/sKhlf CCkQOxUwJ5KRxKFSUA8vo0tblR5hgq4nQNFttAVForowoSv3kcpT/gSWpcAXARxDwZ+BnJvKqQiK oUaYBB889MjFEhh2oFCIs0BURExjQtuAbJnnLwm48Gp0EBs4lRe6t6rM2wdYnUCz0YiJKhhT6P32 j6V1dKcUvHsRrJ5HUFQy3kxzk1MnQAgwUEAIBFFRb+FUpqGVQTY3Xx1YglzUCYz666TvCfgjRAwA pzSpKo2CWdT19IC4PahjFyUlCGQ7egEzDaGbZ2WQ7KjDDrldkhoKHnPkrqMkzkculuaXf3BxkIYt J/HhrFjlSmKACGpfNDyrSYKB3NsCSAZJd6Ps2DX7UpJo/mWWecLgqjLImiCaeREOr9oEGcT5tsZh 59WjETl3nLdxpsujE7dSsBcbAuOcCl4La+FzCJQSml+TRhfO82x6UhfrSlUJ8PHDzRV/OMo85sNt Bb79n/TYsgubBkD9QMpc6HK1XmCAUEsgwiLhOqnG0QbXUZKDa5p8upeYfhpRgsAZ5o0y0hYrQN52 DsVShMF6grVLyZ+K1nxVJExhgq+dnx8T4Tik3SlU3HXUUcKbYggyRlTqBhWzTs6B6gPiICWR6xNc agFSNTKceZiVRp5UVJAk4pT3SBLURHPzcz0ezreSRX8pY6+8ZnIXlaVx50tMzyS+/QL1aqn+ysWo EzwAItD7BDa/AHSNs74UQXejrGeBFcQ7aMAh5Ft5mxYxKWNqKly6yZcuk9JEVG+k5oArSqBKa1Ah 7wR5HctyfqcLld1PocO96kJ55FLczSRrDfFKajaL8sBYec1mj4czT0QkFO/RDzbomZJNm/lPQB0o pNPDa3ut+1w+VECXBUlT+uQnKLe8SXVlud/xZkYfDq580GPdJwBfGBvIOthLE97y+VwdmbigJQAo G9QrqeGSx4wN8NykkFASP5VA7PFAmCDP7m2lgAliBXz3NbwO1+mRmld2yi8WU6fxBpqm6rB6exBT 9gs9IBypCi3lFxNJftfoyTmlGr0VeEeXwtpc6Z0PUfaeQLFRaPUkCTksxCXyzoWutw06AiRXZZjr 9WbFJHMruPZ56AcBAT6cJrOs55jV8FowHnm1g0KpT8xGUIYg6ZYXqMnVOWZ12J0gCBmABU5bu0ru ZdAoswBtWBC11eDlnIdwwwZ4ub+4NL0VaAxS4z6ZCDHENxtv0+KhX0GnJUHRtkavTI34KY9bCmqs klSTFzabMq4FC0jFuk0Vbl9ll2y4Qhr9YlKjFGqBI0xbjfzuhXgplusr1aigi0jz4lnBoIXSi77w AkJ6y2Oanpq3uSstBNiFAiI3Hq9LwjD0+i/rsPbhfhFeEoGci6th8y+ci+BtvBCF84OlSJT1MEyF PKaYKl1gmNxtkySNjZt+wJbnM26dsJervaMcodpyMoOjOz8MLOEpHNL5+foqFyFdqYV/z5ddmDIX wiFec4JUPWgBEQlSkJg0P0HqRNt7yDLyk4r6dnCgbID29Z4hFeMort2M/vMLy5Cq83CP2VeUIRVR RcMnkdwJl6Qsc8W5KQuRQBHhWt4LHFRSeIJ6wZEcuA3DGQY/dGA6wsEVuGNhYL52HUq0uNBAL92U 16kk7ItjwDqM+3jpCa8hFNSdcX+EIAWCCz/u9JrPtznoEfk9GhdjgFSii1NJXE1x/WWabhMRmUnX aQrVK3ZDf9T3DAA9ztUcW/FpVFDzuFIEVaVRMefHmtGpcZ0CtusUnwniBHxSBYNK4nxP4dJVkdMa KSEKNfcqmQcCL3BM6gV36SfMvNPhocduhRqZBryTPe3rkuSqKJWm6wqlPm8rAVRFGswP3+EclCwl 196AZIfozGpaXSTqq9izmKGDmYZncLGOHxXPYEQFIi+P0GgxksTvx3dKwHMFzUu5UIrIqhGwZYVa OJW+LRzLArP9mi6ZC714LpvypeukMl+J6xZ14a1OYBwnaWh5kAflYLbzxFSe/k0rDHn3QQHbiQBM o6CMm6ACc5qzUJ7/xo1Dai1GRMG4VgZf4axMpRYyzz1S1vCdv98vQyBVsCcizPqIrg+wGC7b1tYI T4fX12EZq1CltNwmqBqr5VczCzyU4sVdeBNxbTx64K4iYPacHwh6FnLf0WL54zXNeNNyzsNrNPpd r6YPhLunOoeG61Bw39J8luJgDn4+eHySX3RCZd9SkKzixFGJvsy3HiJiGigvuTS8jqc4Ya2YDvez 4fTGpYgDMLCsN4fdA4YpvrpcBt57nTuhcWN8pPaJ1CNI771JUeXmuWgCnWM+6Crl91TEYhYhl+yC PtoaYaEbZYAtpfg4tjRC27mYN1NuaGNdh+e8bXR1XKKGavh0mH9uLth/jaZ587nheqyW5eTYU9J1 lb9cwVmev5e4lvntuyQ9YBLe/3DpVZt2ei5flVKWiHXbyuNlGkmTNHQQcc3dNQ0KHXlQzL4D+hyo IA95SJv3olJo4BGRicWNAx6Nm8+GJR3/5peyLIbbOaC6N9WI9Va5e0ku/Fa5hWs9UQ5JdQfgXbCW gNKlw/2rQYLyvgAanWnppElqQUMeuEvvWi48HL5bVOocM8bxF4gdvcZWCsYMOi9vpWAL9gRPdemd IuOWBtAGwfc89oIB9CKe/HLmBhtoemD9m3QEV9o4bNgAvRV8bcMAy4LOEbAYmAMwBMuFthCwVfCW r/75g838AmeHd58IKIbQbOIMQSCGADKgTJgUVsdJ5jMoKD5ka+ytYUxlD7CsrbeGMXUVD7tCKwnU /LnBJegPqREGEFwKLjAFNEpwUrQHluSL36jnh0Dv5xU3EcaUnn51ocvSWu8o82PIwyCCMKHCVkV4 m2iMBx2FsDhe+cWTsHmgmedUxhoCnu5cNP0Pyjnv3yJ04vBkHdWVIddR1fXlc9UQr/MTbQxccvjj 6YNZ+psLbOicdmP8o/vp5JmSr3N/W+9QzbrEdbZ/ti/tak3Zgd3/9fgs1Yi+bb9t/g/5JphNZW5k c3RyZWFtCmVuZG9iagoxOTkgMCBvYmoKMzgzMQplbmRvYmoKMjAzIDAgb2JqClsxMSAvWFlaIDQ3 LjUxOTk5OTkgIAozMzkuNDM5OTk5ICAwXQplbmRvYmoKMjA0IDAgb2JqClsxMSAvWFlaIDQ3LjUx OTk5OTkgIAoyMjcuMTE5OTk5ICAwXQplbmRvYmoKMjA1IDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5 OTkgIAoxMTQuNzk5OTk5ICAwXQplbmRvYmoKMjA2IDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5OTkg IAo0NTguNDc5OTk5ICAwXQplbmRvYmoKMjA3IDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5OTkgIAoz NjkuMTk5OTk5ICAwXQplbmRvYmoKMjA4IDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5OTkgIAoyNTYu ODc5OTk5ICAwXQplbmRvYmoKMjA5IDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5OTkgIAoxNDUuNTE5 OTk5ICAwXQplbmRvYmoKMjEwIDAgb2JqClsxMSAvWFlaIDQ3LjUxOTk5OTkgIAo0MjguNzE5OTk5 ICAwXQplbmRvYmoKMjExIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMTA4Ljk1OTk5OSAgNDY5LjAzOTk5OSAgMjg1LjU5OTk5OSAgNDc5LjU5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2 My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzSSMy ZEQuaWFiIzJkcHJpdmFjeSMyZGNvbnNpZGVyYXRpb25zCj4+CmVuZG9iagoyMTIgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA0MjQuODc5OTk5 ICA1NDMuODQwMDAwICA0MzIuNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjIxMyAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI0Ni4yMzk5OTkgIDM4MC43MTk5OTkg IDMwMy44Mzk5OTkgIDM5MS4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3NDkKPj4KZW5kb2JqCjIxNCAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDMzNS41OTk5 OTkgIDU0My44NDAwMDAgIDM0My4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMjE1IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMjIzLjI3OTk5 OSAgNTQzLjg0MDAwMCAgMjMwLjk1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoyMTYgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAxMTAuOTU5OTk5 ICA1NDMuODQwMDAwICAxMTguNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjIwMiAwIG9iago8PAov VHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAyMTcgMCBSCi9SZXNvdXJjZXMgMjE5 IDAgUgovQW5ub3RzIDIyMCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjIx OSAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NT cGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8 Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjkgOSAwIFIKL0Y4IDggMCBSCi9GMjQgMjQgMCBSCj4+ Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iagoyMjAgMCBvYmoKWyAyMTEgMCBSIDIxMiAwIFIgMjEz IDAgUiAyMTQgMCBSIDIxNSAwIFIgMjE2IDAgUiBdCmVuZG9iagoyMTcgMCBvYmoKPDwKL0xlbmd0 aCAyMTggMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS2/kuBG+96/QOcB4 xIcoEggCeLwzAXIIMJgBcghyCLzZLBb2Is4e8vejV7Ol+kQXxSblbm/b2LWGEqlisaq+quJDH//8 7Z/Vv3+rPj58+0/1OP19+Hao7+rGjT9V3f1+mBdIe6dk3f9UVqg70w6lj8+Hl+rl8PXwtfv/y0GY oeL0p7t5fEU9/P72+Ovh4/jyw1jy7eGv3dX/Kln9pfvvl+rv/+gKf5za6x94PlhnOjrqWqjun0/z fwpVi/bOdNddeU3/2T/88+Fvf6h+7QmTd3YgXowEzv/5QWgllewalWeR/HKq2lGhnBSNscHrecNK TfToygjX3PV8dl3XlW76/tR1UxlZ277bXXnHAyP0ne6ol7Rctn3lvvzUzlOg/Z49P81odmr6CV4v aJ7TJuuh/YHm2bukUsMzlLZl+awvvp2nQPuU5kx8DtAcoiE0LiX4vD7Wz8vyKD6vy0ZIljLxuTV2 VFexlOfWuOEZIZY0kHJP86ydp0D72eS5bevheqR59q5W2IFMStuy/NSXUztPgfYL8TlAc4iG0LiU 4PP6WD8v+RbF53XZCMlSJj67RtuhTb2UZ9cYMfBTL2kg5Z7mWTtPgfazybNr2pEcvZQN19iRHKBt UT7ri2/nKdB+IT4HaA7REBqXEnxeH+vnZXkUn9dlIyRLmfgshD46TQt57spVPbx3SQMp9zTP2nkK tJ9Nnrs2tRreu5SNrrwxgyEA2ubl874c23kKtF+IzwGaQzSExqUEn9fH+pmUx/B5XTZCsrSk+Rh2 OHDCN/nyRvecMbbpwpdKNNV//9W95evgqydEBGL4nRMzlgQigpdXKn76fvj4xVSirr7/VI0UfBj/ fB+p/tCR7Uz1/cfqjz1Rf6q+/3LoA6CpQA4F7alADQX2VKDpE2Mbn79P/S/Ea9vdukJe204cr47X TrfXyOsO9q6O17J26gp5LUUHDWV4nZgmeXml4tAhVwm11iFRm154ZO0V9Z6QKzSl/9NQ0NAuz55o acEPbBuK8tFSLlHCItp4YOlohgL9ShtQxdEq8JbPhDAxDrBQZTsjvlDKoHeUMmhU3NPXwlgmsAyq QPf5KjyX4Qn+LZR08WkPqYsYKLa3EVUS9DTwlsE0JdsYbW0BG8Nz6G0GN0LpKNsjlO4LS3rAxJ43 dEd4EO3v1D4CHfBaQHMYO3gCXms2y3KEQFAAFT+wdADm8tIOVXibAm1QBgm7PlDnybIZRVkfRVmO XHevgCGYJd6PYbu/IuxQB8YSOASUsUYG2pBfMhoIQwK912SI9QZEzRUkdDdCDRMAM6ENnnTe+IE8 8KaNtiEkJ/4R9oEV1BRrCEoGbQCAgnzw48L2VorNo490gN0GdIQC3oDmCK94GWOZLANCl8eiuKNF kQ9UYqAzwCEQMpB+XmGAQwm6zlIaIbngHABh0H3oLQ/9fF94idmuDhHdB9nm45wSLIxIUMAT/Gt5 92GXaDtCPoDrYLfywemZ4WZDDAi8RoGPAmPJSz/wEDiUMJY5QgU+dkzAjwAYZDH1qm6DQsUnrNCd Bp7xDhbPIvC4eJcUBALGDgpY5UYp4zWVNxA5HN+E2JG3fnyVKzZUqm2J+PPuNO9fJyDZdokB3zgC QcCEoOZSfcDEGKg/vDeHCiXIMkgZ7+qUcOORY1Al4BzmMeVShsYywj7y9gAGpkjC9npMiBSU7Zfq 62DGCkxZDs2lvVWOFowjdUp7lEk2qkaQgYFx4INF3hvkTUiJzGEeN101hEMlQtCUmcbrcRdj5+/2 8Q7zIIg6ekOYoOTzPiVCrohZACog6B4lTKtvz1jCE5jChEb5Ca73vWaijPVXdinLanyvqMOkobgn BPLAxe3zAjlwCa0d7zAkzAvkyATukz4BBrH2AH0d1pHHkCNFh3La8iZrNABPsGEasjnBg+KtDP/E Pi6V7IqXbC+TT9sHZnKEA1eMTNiZMoOZ4CBfTZoqISznE1kR4x+RDcsBZnx8FMCuPNbd+JU0/Ew5 b2azzB1ruaSMz49FpBhZx6zI8oN9rGzI/z0VQMIkxsrw0c312JCdEIL3f4vIcobulplPunABOc9Q NUYQQ5VvfVIe426DGeWINaCgEICHEA9sX34UEdu+UbSXwXNNSDq91SL6BDQssh4nIaNQxqPmgw6g jM/sJsx8JcRL17sQoEwib7KG2u9jRW+IHyk+CZlg2raHbYKud3/Xu24iBgpI355fLRQcvlEeP1am zpz4G7NUJ526dFev9CpZ8Ml5fvBGN8cug+3InrIu6D6jnZZhf/o9rc0Gr0Sx+sHLdoKOgcHkF0kn BH4sXJbU0zMnAqXi5PI9j2UeNExOc27RXMydsBsqUyIfXuyggPWw0Ojyjl1CsMQ7FAHZzmPa9YZ1 QtebXeLzsQkbLFfUMGEymT9eIWE3CwBowqLQIstmL3aP9vaZ9ITVSCsSk7DlNIFlCcnmhHwDr9sJ Gw/KJJN2XXynmzZIPI8Y/PZ5aDTBPeSnNPj9w7xQ8T5HwnbyEluOd8oV8Nn4QgvpiFyKsdXZQros aS3e2eHn6/hTXdhtBBe7bi5iYztvMNgUNk5oloBDPtKJ2KrDRlwohYF9F3kMdyuDrwFtZ5MWaEKA Q9u3GSVM2PAuRkros8sK2IvxSvjRz6FB2/3pLKmBK8bLt9ogVfCUuN03P5bcyaitdzkiVvPwk/Ms kMesokrQ/0tZeL3dtkcoRIJkXopdTsim8b3lU5Y5ZsUSMgEJYf3bnCrK+w9SsepB/XyogpiTY9ID wgs+ZuU9nTfaQTVZ4cYfPImnQL3RusRdzkDDpEYCKidkwXP4xrdp1K0gVWQadZcVAQmrli9lpuVS EngJbk4KFgSsZR4rrYLZh4hEQYko910fWl9m5uU9HygcYZUS0JOHIP58L1Zg+E0eETvWMuxxStla vj2BUWaNyeWedxgw9Xmssj/peiervIvWqVHshAjXQRAu4qTxVXiG8BF8kfRcwvK4DKeAREwibZ+a QaRPyEXz2ckcLjovDvwRQAk5oDda1ktFCgYqKa8a+6mAGe2SjlQ+S57HTpvLXwi/i2l/20hoS9L4 FtVsbmOXYxgv15DzMsYup8LuQwDC7yTJEOZkOZaPF6ntZ9BmNcrtBucZRmr72qCUII53uNh8ZpmT K1ibk2U2fLv/neU0tISU8KVkY674SF4YfeAH+x0VmILnQ4eIuYz3/DkbfiVM9IxJHqN8+qRD8maU 17qbY21AwsqXhBDuwqZpjQx+rCdiEXiJFEeEsvMjxfskGdavXxF+8DsctodBmNDZZxHwLqdLRig/ b0ASBKagd31WqM2fahMBfQHTf+5Gg+FbHOZ0+rQ9tXr6+Lmsp5/g9eKT3RHP8x/03vjSoZvDJ9XX TggdzHXrvziiAlm61wYVVjdBlSmxJ6gwzZP2WELbnfQeM/2z+NbSAoAOQ1uFr34Gvs9uqK0AmWzC b4mm9E0++t4MpyS2yi4HY9O6sIT9wglJRH7ChFolzU8Q8DY4Yc8A712C78x/5TQhPOUTPLwd3768 P4HJKWcc8evm+CQJP9gJ4VjCYtUcaxHZTUeA4rh6lc+r7LKIOMEBSVjWEBK6M09zFJYY1ATzkEEe tCRt5NwteSaLRshp1HF0+cWHbFgcs2MiYRE9lUzgagIqRZzmz9sl/lRNPhPLvyXhWyZ8X/hjt/PN QZ/74Sa3lFTUMur9KWAZTYLAp+a1pVVogYJ9avQt2py6+94iFCuP7OcjFEFZlxDDoIsPEhtwiV+L G3KECRBt4ZdkgHY+gHkAywm9AeL5/gKt43vnERxtRNa0w8CjwGZ9sNhFArbo+EyghghZV50oN3X1 7K/FnegMSHfphgvjhlLZ/3+6euz4Ze6sa7Sq/U2zrGymdodn+2tthxrVsqq2x3a7q/7Z+Uv7m7Je VPb0Ph5+Pnz6Q6HoU6jh7GvbvfHifQF+MieBEJkj8tlzIVAGJTDNSQmMWVMC0x6FtbuiSjDcNMvK ZmrXK4FRa0pglG9XgRL0Nyei1EIJhnZ3UIKOjKtTgoi5+e3bnxMWre+zLilCW/fZWLZn6iuDxtsZ 7NlV2LMe9izCnvWwZ5ewZ2ew167CXuthr0XYaz3stUvYszvBnvWwB5noXT7Em+V8dv5oM/7bJKzh 4TUP1vZK8Pxoals+5BJwN4M0twppzkOaQ0hzHtLcEtLcDNLcKqQ5D2kOIc15SHNLSHM7QZo7Qhoe wZ7wmQMw2OyH1t9ouWrE2V0w5R6xJH77+t0pQnwloyW3axokPaCgyDFKF8PUKdkCBe8y++K8VxqR faERfUL2RUACTdEqEK9DNgIyJ5Cmgyq3pM+6Ubslfc51Dpwz3jlwrl1xDpw7eqn9FXEOxptmWdlM 7R6dA+f0inPQlfp2NXUOhpsTUXruHIztFncOeot0lIHriXf3SvrssstI37Pe0XXnmmQ3Gkfd664l 6l5XOjnQw9VS96abZlnZTO1OutfJsUPd60uP7XZXS90bb8p6UdnTu4vu9ZB/bbp3yzWRgluuaUXj pTlpvFxB267UHjVTUrSdbpplZTO16zVerqBtX+rbpWg73pyI0guNlzuhrfKCdcs1vW54LjrXJGs9 gzS9CmnaQ5pGSNMe0vQS0vQM0tQqpCkPaQohTXlIU0tI0ztBmj5C2i3XxHTulmuiI3WxTP095Zqk 8F4pn2uSDffELddESGdzTUgpbXRaMzvj+mfaKLRxS2BddwJLCi29xyG0WvE4hD66vv0V8TjGm2ZZ 2UztHj0OoesVj6Mr9e3W1OMYbk5E1XOPY2y3vMchtDnKwPUE0bcEFi3Y5dQkpDThxMjZmSbnKXTT nhS6sWsK3Rxd/f6KKvRw0ywrm6ldr9BNs6bQTePbbUCh+5sTUc1CoYd2d1BoI65PoW9ZMVJwy4qt aHw7g/B2FcJbD+EtQnjrIbxdQng7g/B2FcJbD+EtQnjrIbxdQni7E4S3HsJvWbHXDc9lZ8WEnUGa XYU06yHNIqRZD2l2CWl2Bml2FdKshzSLkGY9pNklpNmdIM0dIe2WFWM6d8uK0ZG6WKZGZsUaN/2g RSH3IrJd4cYGPTTMqUj+MBE1ssjQ/tOtitwL+wml9TcK8sbJ6m59QbBHUizbnwR4niSh41NTkcbd 2CozF0xdlgumIYfETII9S2vd05GmXICEG57a+Zk+sb6xNZlPctyvXoxPUirSPu1RDcBE85ICkAos 5ANlvoC0HB0N5LXjxiuBVOXystNqsnket/UDkRokU1DIuSd1JtiadYwmehWwb2aDu9/qpeuvMAPh 05/H59Tjbb5WXw//Bw/BMXBlbmRzdHJlYW0KZW5kb2JqCjIxOCAwIG9iagozOTY2CmVuZG9iagoy MjIgMCBvYmoKWzEyIC9YWVogNTAuMzk5OTk5OSAgCjYwNy4yNzk5OTkgIDBdCmVuZG9iagoyMjMg MCBvYmoKWzEyIC9YWVogNDcuNTE5OTk5OSAgCjYzNy4wMzk5OTkgIDBdCmVuZG9iagoyMjQgMCBv YmoKWzEyIC9YWVogNTAuMzk5OTk5OSAgCjY5OC40Nzk5OTkgIDBdCmVuZG9iagoyMjUgMCBvYmoK WzEyIC9YWVogNDcuNTE5OTk5OSAgCjQ2Mi4zMTk5OTkgIDBdCmVuZG9iagoyMjYgMCBvYmoKWzEy IC9YWVogNDcuNTE5OTk5OSAgCjM5MS4yNzk5OTkgIDBdCmVuZG9iagoyMjcgMCBvYmoKWzEyIC9Y WVogNDcuNTE5OTk5OSAgCjM2MS41MTk5OTkgIDBdCmVuZG9iagoyMjggMCBvYmoKWzEyIC9YWVog NTAuMzk5OTk5OSAgCjY3Ny4zNTk5OTkgIDBdCmVuZG9iagoyMjkgMCBvYmoKWzEyIC9YWVogNTAu Mzk5OTk5OSAgCjU1NS40NDAwMDAgIDBdCmVuZG9iagoyMzAgMCBvYmoKWzEyIC9YWVogNTAuMzk5 OTk5OSAgCjU3Ni41NjAwMDAgIDBdCmVuZG9iagoyMzEgMCBvYmoKWzEyIC9YWVogNTAuMzk5OTk5 OSAgCjUxMi4yMzk5OTkgIDBdCmVuZG9iagoyMzIgMCBvYmoKWzEyIC9YWVogNDcuNTE5OTk5OSAg Cjc1OCAgMF0KZW5kb2JqCjIzMyAwIG9iagpbMTIgL1hZWiA0Ny41MTk5OTk5ICAKNjY2Ljc5OTk5 OSAgMF0KZW5kb2JqCjIzNCAwIG9iagpbMTIgL1hZWiA1MC4zOTk5OTk5ICAKNTMzLjM2MDAwMCAg MF0KZW5kb2JqCjIzNSAwIG9iagpbMTIgL1hZWiA0Ny41MTk5OTk5ICAKNzgzLjkxOTk5OSAgMF0K ZW5kb2JqCjIzNiAwIG9iagpbMTIgL1hZWiA0Ny41MTk5OTk5ICAKNDkyLjA3OTk5OSAgMF0KZW5k b2JqCjIzNyAwIG9iagpbMTIgL1hZWiA0Ny41MTk5OTk5ICAKNzI4LjIzOTk5OSAgMF0KZW5kb2Jq CjIzOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAw MDAgIDc4MC4wNzk5OTkgIDU0My44NDAwMDAgIDc4Ny43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoK MjM5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAw MCAgNzI0LjM5OTk5OSAgNTQzLjg0MDAwMCAgNzMyLjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoy NDAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAw ICA2MzMuMTk5OTk5ICA1NDMuODQwMDAwICA2NDAuODc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI0 MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAg IDQ1OC40Nzk5OTkgIDU0My44NDAwMDAgIDQ2Ni4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMjQy IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAg MzU3LjY3OTk5OSAgNTQzLjg0MDAwMCAgMzY1LjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoyNDMg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5OC4zOTk5OTk5ICA2 OTAuNzk5OTk5ICAxNDYuMzk5OTk5ICA2OTguNDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8 Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86c29iQGhhcnZhcmQuZWR1KQo+Pgo+ PgplbmRvYmoKMjQ0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTU1LjAzOTk5OSAgNjkwLjc5OTk5OSAgNDAxLjc1OTk5OSAgNjk4LjQ3OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMjExOSkKPj4KPj4KZW5kb2JqCjI0NSAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwMS4yODAwMDAgIDY4Mi4xNTk5OTkgIDExNy41OTk5 OTkgIDY4OS44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAv VVJJCi9VUkkgKGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzIxMTkudHh0KQo+Pgo+ PgplbmRvYmoKMjQ2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTIzLjM1OTk5OSAgNjgyLjE1OTk5OSAgMTQ2LjQwMDAwMCAgNjg5LjgzOTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIxMTkuaHRtbCkKPj4KPj4KZW5kb2JqCjI0NyAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE1MS4xOTk5OTkgIDY4 Mi4xNTk5OTkgIDE2OC40Nzk5OTkgIDY4OS44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwK L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMveG1sL3JmYzIxMTkueG1sKQo+Pgo+PgplbmRvYmoKMjQ4IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTQxLjU5OTk5OSAgNjY5LjY3OTk5OSAgMzE2LjMx OTk5OSAgNjc3LjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSkKPj4KPj4KZW5k b2JqCjI0OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQyMi44 Nzk5OTkgIDY2OS42Nzk5OTkgIDQzOS4xOTk5OTkgIDY3Ny4zNTk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvcmZjL3JmYzY3NDkudHh0KQo+Pgo+PgplbmRvYmoKMjUwIDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTIzLjM1OTk5OSAgNTkwLjk1OTk5OSAgNDg1LjI3 OTk5OSAgNjA3LjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWFiLXByaXZhY3kt Y29uc2lkZXJhdGlvbnMtMDMpCj4+Cj4+CmVuZG9iagoyNTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMjYuMjM5OTk5ICA1ODEuMzYwMDAwICAxNDIuNTYwMDAw ICA1ODkuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VS SQovVVJJIChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pYWItcHJp dmFjeS1jb25zaWRlcmF0aW9ucy0wMy50eHQpCj4+Cj4+CmVuZG9iagoyNTIgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMjMuMzU5OTk5ICA1NjAuMjQwMDAwICA1 MjQuNjM5OTk5ICA1NzYuNTYwMDAwIF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rp b24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWp3dC1iZWFyZXItMDQpCj4+Cj4+CmVuZG9iagoyNTMgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszOTYuOTU5OTk5ICA1NjAuMjQwMDAwICA0MTMuMjc5OTk5 ICA1NjcuOTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VS SQovVVJJIChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9h dXRoLWp3dC1iZWFyZXItMDQudHh0KQo+Pgo+PgplbmRvYmoKMjU0IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDE4LjA3OTk5OSAgNTYwLjI0MDAwMCAgNDMzLjQz OTk5OSAgNTY3LjkxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1vYXV0aC1qd3QtYmVhcmVyLTA0LnBkZikKPj4KPj4KZW5kb2JqCjI1NSAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI0Ny4xOTk5OTkgIDU0Ny43NTk5OTkgIDQ1 OC4zOTk5OTkgIDU1NS40Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlv bgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtc2FtbDItYmVhcmVyLTE1KQo+Pgo+PgplbmRvYmoKMjU2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMzI0Ljk1OTk5OSAgNTM4LjE1OTk5OSAgMzQxLjI3OTk5 OSAgNTQ1LjgzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9V UkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1v YXV0aC1zYW1sMi1iZWFyZXItMTUudHh0KQo+Pgo+PgplbmRvYmoKMjU3IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzQ3LjAzOTk5OSAgNTM4LjE1OTk5OSAgMzYy LjM5OTk5OSAgNTQ1LjgzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9u Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTUucGRmKQo+Pgo+PgplbmRvYmoKMjU4IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDU4LjM5OTk5OSAgNTI1LjY3OTk5 OSAgNDk3Ljc1OTk5OSAgNTMzLjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAv QWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvd3Mtc3gvd3Mt dHJ1c3QvdjEuNC93cy10cnVzdC5odG1sKQo+Pgo+PgplbmRvYmoKMjU5IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjQ3LjE5OTk5OSAgNTA0LjU1OTk5OSAgNDE2 LjE1OTk5OSAgNTEyLjIzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9u Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc1NSkKPj4KPj4K ZW5kb2JqCjI2MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEy Ni4yMzk5OTkgIDQ5NC45NTk5OTkgIDE0Mi41NjAwMDAgIDUwMi42Mzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjL3JmYzY3NTUudHh0KQo+Pgo+PgplbmRvYmoKMjIxIDAgb2JqCjw8Ci9UeXBl IC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDI2MSAwIFIKL1Jlc291cmNlcyAyNjMgMCBS Ci9Bbm5vdHMgMjY0IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMjYzIDAg b2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAv RGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4K L0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOCA4IDAgUgovRjkgOSAwIFIKPj4KL1hPYmplY3QgPDwKPj4K Pj4KZW5kb2JqCjI2NCAwIG9iagpbIDIzOCAwIFIgMjM5IDAgUiAyNDAgMCBSIDI0MSAwIFIgMjQy IDAgUiAyNDMgMCBSIDI0NCAwIFIgMjQ1IDAgUiAyNDYgMCBSIDI0NyAwIFIgMjQ4IDAgUiAyNDkg MCBSIDI1MCAwIFIgMjUxIDAgUiAyNTIgMCBSIDI1MyAwIFIgMjU0IDAgUiAyNTUgMCBSIDI1NiAw IFIgMjU3IDAgUiAyNTggMCBSIDI1OSAwIFIgMjYwIDAgUiBdCmVuZG9iagoyNjEgMCBvYmoKPDwK L0xlbmd0aCAyNjIgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS4/cuBG+ 96/o8wIei09RQBDAHtsBcghg2EAOixwCbzaLxcwizh7y96MHmxLrE1USh+rWzM4aiWV2s1SsKha/ KhbZb//y5Z/nf/9+fnv/5T/nb/7v+y+n6q4yzfDfuWr/vJk2SHenZNX9d3ZC3dm6b/32ePp+/n76 fPrc/v/3k7B9R/9X++HlFVX/5/dvv53eDi8/DS1f7v/WPv3vLM9/bf/36/nHf7SNP3l63RceT66x LR9VJVT7z4fpP4WqnLiz7XPbXtF/dl/+5fT3H86/dYzJO9czLwYGp/98I4yVuml7yiex/H3s2tJS jWzpuuTzlLBSnh99ltZdHh9PSptuPFVlWvGL4VF3MrBC3+mWe0nbZX0nh/aRzkOCfieenyc8N8r/ l3yOeJ7w1vTceJ7Hd6mq5wZ4I+3jWEY6Dwn6lOdCck7wnOIhpZc95Dyv68dp+0o5z9tGypYKyVnI SvVMiNiehRT2bpiBEQ+kPfA8ofOQoF/MnoWUg4BEbBtC6kFAwFvUPhlLoPOQoL+TnBM8p3hI6WUP Oc/r+jFuXyXnedtI2VIpv1FL2zsC6p9r1fQ80DkVt49zcKTzkKBfzj/XRt7N+DpZW90/A29R+2Qs gc5Dgv5Ock7wnOIhpZc95Dyv68e4fZWc520jZUuF5GysGuTmYns2Vg+8uZgH0h54ntB5SNAvZs/G mrp/drFtGFtXvdyAt6h9MpZA5yFBfyc5J3hO8ZDSyx5yntf1Y9y+Ss7ztpGypUJyrtsgoHsWVWzP tZJDbFDFPJD2wPOEzkOCfjF7rpUa2Kli26iVHtgB3qL2yVgCnYcE/Z3knOA5xUNKL3vIeV7Xj3H7 KjnP20bKlmKeL2F0A0Hlpti0nTAdclNdOH4W5vzff7Vv+dzHnhkRruj/TJkZWhIR7veFju+/nt5+ sud25F9/Pg8cvBn++jpw/aZl27T/+un8p46pP5+//nrqAnrfIPuGemxQfYMbGzT9xkDj41c//p1k rfq46NnJWkn1/GStlXiOstZaPj9ZW+Oeo6ytbZ6frGv3LP11y89Osh7lPGSU2/+Sz1ECdsX3WWFs fWkvql57M6KStl/ZrPCjVJrIQQwNepRDwzXI932DEAvS/dQ3GFb+duEbrm9oRlbf0W9AFznqcFeB tmBxtUCF2yxyKUDCNREGyu9+6DOZBO+peAzViiUvVoYV8fO0hsxNk+8LHRddlGx6M7H2IlhHRCCp pMV7KgLqoURNXZbhGhT1g6oZZUJXkU4GAmXQdIlKZes7002Ux5MwZtrwcPqyal2aexvjB9PEFmXf MhzJXt5TMb0jyhCwXEAXR5VRcUTVJzrN6Srlp86Eht3fYpuE1Dq1RmITn+iiakiDkpuNSbTkI2vS zh3bmjqOI7loqnkwBQHzkmpe3FN3DqZAzQlMUljqMMC+qHtf8RZAUh+41+JMABpgSXQ2IesZ7pGV h1+7zII8oEvNsg6uAkb7kUoM3A1ljJcpCoh20YLSoKpETsExgmk7utojqyAhEDsdjJacTSnFTjpN 59gNnWnn1ZadqR/QRCjUu0rqRfx0HlUuE4Bg8hZDBKvuqaR5L/+O8kFpAGNAw0MXu8AYbZDvNnMq PlKvSmn4qTjxiBSXVdQUeZkCp9jgRlPMtikPa2p3IfphO5TrF9+6CVBOuGnD8RbfxsZjhrhe3wL0 JyGUcDG7KZPdhJikJkoz+thK6ziOxIBRJVWjbMjM1bdUo9E7qNFWRI1OHVyNtorFAHPtWFpr5Rn7 R+rrxRYvzAT2Tcj/FAjsJaywALo/bgnsn7rEjIP7QCcuu6B6XDb5xnv6DXYdl5BTc3Sl3yU21f1q 2JjLFFW1nTYccIpqFysMHSsNAlZEa3Sae2FPYBUEEhThw2sxAgbsCrlIavNIowRjfEhMbU1KGiWx 8RxGWvBaNiRGP8KmsVZEaxmZCDEBntf28t2UjCw+I7AqEdBoNw/xFyKtnIAGgBOEK9S7VvBaQc2G xmIYFLHhm2i48A26oJffHr8YoWMPbdTBPXTH8bKHPlQE08kzYncRRL20bVJtLkUpK3b1YJXkd/Xg G3RPCzfKXrf9iACew7afdiYVHUA+2UPsiWA/0vFAFp+uG7ju02wpvEUADmJhD6ZgAfZAohv2Iyc+ /6lCburUa3lwhXsFsBbDdgu74bcLDAROiwR6PkUzGioiHoojsAFkyAKLFYjHzkPYLaGfR84TsWva wGd9YbRQFgOj/TDvzOTIekbynUbgGfIAmSIk5EHjdvAK+xcZrOMOB0gdADAPb8EcQNlUlSsUBdtP GYqC/QtgDMYCDdToYLTXGcuK1BHMF9ALO8UyZJrjUFjWMevFBp3AB3ahi4NftEW1oG2YDrC1ukfq zPR7EtrZEJj1W02h4YCBmaErICRgdkRE2zeAdONCWlLJaUMn26tv7kzQFxTSvmT0tU+NDV9kwheI wFv4ijW2LmPFnIDR8jU2LFw/VClHN9sig8/IOOLyAMs2LDGAN6lnl4pd+qEOgcI6pAEGzwOMTxxW BLgt6PqJfABCZzEawgfA36AGHivCWGCBBXls5xSGj/lV0EsinTqhISkCY9GkYC0ZRwuDgy68SUFc xONe0BxoH4S8PRpFIEwTVj4dNbExVh75yfQiMb+pmthitmGRbovUiGosRqmmDcfDeR3H0aiPnYDv 5BkraccqBiOvnKdkEQigKXgtggXAfds3gQumJY264AQf8U2GD1utlDFM0/JlrzB8toYXTyoUTClO bIo6zxULI+vVrxPwYzYU0l8YitNljt94xcUDGq6SZSuR3wCR8fmNnHQXi75mFLMdTOySI1Gq6ZZK GXIkVtfThuOtnR3H0ZTWdErjCSa6mKqKTiUaZPpCicUiFeoGVxz4hXUCaur4gwtwToHupIJAcDCI NyxdayHsZrMfJbz+jWSYkVPAHAsgCwDqILHrZHLK1c5tTxEaFVKEQstpw01ShCMSWl3rdxvIrSVh 9/kkePjdMKjbAKKwPALWgSoNdpMB3qJquk5DdoId/opKNv68D5vxWZGLAYm95mK+LqL2ErkYKArH 1yaC2CXU/pKqI7Wr4lXAVLAKHAtgdhxHrvfYyZlOnssrRcbBIFM5ojXZHFtrHceRGADSQW7I167f Rms0MbNrSm0sIX1NqZWSqb3En3j3wIoTDxAaUDT6ErJuwexeVOrqNVPFQa1dMlXSdcU7xuiwJFkx bTjektRxHE8D8Gk0EE8dXl3IEJQ4s3aj3A4MH10pf68LvGWPY26v+aGtS22+nd4Gj7XOJJqrr/kW MvGy8y1lsESAWxjH81gCcQCV2VHyOhCUaxq2v+Z1yDd2yevABhEwBgVmf6y8jnL9PqENG4e6aqYN x4NjHcexJzl0XqeTZxxnFsjraGGI1vqzygfWWsdxJIZj53X0cFZ5wu6eeR0XblCGvA6L6XCXnKaC UjeBTlYr2FiGPiVTLo1KzVwEuewNkVjnVDL1ETSDKwnAFYCN8A0KX/jF+DqHGjGgpWPJIKrv2bUX YAOIkC/iyjgGWqKI6yoSw4pgeAvItIRJHVVAkNTjsTtiNRDQbQ4S7yKgIocJ2VPBK6Y6HzFTxjQw BsicPX2acx3YHmrIOeTYX+FnnAwFfP1vOIaG4yE6M1zhNwEvq1EEJBtKIICb4MROS5EQUvmmMnAk ICe4VQoWRnR820NQaMBrpsqhYBuOJVzn2kM4/g8NJZHkOLrXTbQdVqAXdS1H7qaaHY9OmSpqON7q 4TfVxmmBmxXsbg5GupDchi18cBywE0MDPXA+fNU5RtywiLGXKMFbsi5ghH03uLKTv1WA/7mAY21e 3ah8a96et2w8XefuSNiJgIY/wt2RZRZ1GdJDucddrZTxcdfQcDyf7Y+7jqM+dubdH3edKOmPdN+k dcTXTtcJSPBADRJ/V6KlXSCrDM4K8BRytv0XA2eIwDWOUPsIl2PCXZjDhBYjkkvt4Lu0SDyWWBIr 3rDJSh6v3LzOJFPzBbCdsdVCxNqoKXNQWg9rGCSLIA8K5zlABCBYsAGIEOo0Hx4bgfrUAg3gAwYH rAOnfBd4C1g8hFBwyjHjLbzmYHJCShsOrtMG7MKrAUbLyxScEwwOaEBtJ7DOCyhDldAFiPI0PlHt 85yyQgZlo24Tx2oW7BSjPtpFQPg12T/P9mPaaeLIeAcCIkv8fNvScEG58BaqB4+bN3nHtTLcZKgJ Z/g0Pfj1RNqYKGxeL9kUqAE4BTcF30gUii4JGWiw2pfwK55UDRIGx66N6JVgXftIERNSBQMBPbBT WfCjg9vEWetHxVCi/mZL+KG2JQMB24bff2THgjeSAOvsIo0CApCduKEcdqeA06dNS2UsmZeA81hr hwP+ONzB6qaJb94w4Rtg/zxc4LX7geUMtQkNMGVYCIpihi68MYNmEnntJdbBzAClsTJcDTCLrCBa JA3kNtHECjXsAcl9qm5aRU2dSo5AYIJ8omuKArlDeMyD0Je8+u/kqUXN2D8yUgIN8obo8zQL4RJ+ BcAuvud1JpLXQLjMOi9MDhSIsPEboKlEvdtSyP2CM7aOJtEOmLGV4OYzMrYKhgfpV0jhetcAVv3E zCmwVgNrsLmZmIFbfljJu/4bZmydlp4XvHcMxlMgh7nCkcNbwF/w6wUywma++NUPMy5sJFNivQAA Bcd7MTwEPvjRgqvnlctmwlZom80U8+rnk7qwoKAq+WjxKmCQ3wRZgWu2JxhK2BjcOagnN+o/1U3V gQ9aPgG/Kyc21oHO7sl3W/Cu0d12vH82d6J1iWchmv7BNn2rPQ+/b989fWvXC3vXflOrKnxo487W 0+2/2z/LvseZdJWBruy/G720qwiuos6B32+nX07vf9hpyRCqP1XtGpc0iowdKZgTGbsnbDQws0SA /dKf3MW4lE9L8vsY0CVRB7rgm4DTEiszEIUEKu9FFfzICB+WU06Bj1msnzOfm6oJ87kR1cx8blrA N8y77onM5+FDG3e2nu5lPjdVPTOf29YL3faJzOf+Q89gPZ3PA93953Mjwi0JEIhC9SHghgwcJdlZ s32C89u0K2jAKgj4BfKfPG6gY1mR/wa3yuMGQAXAKas5Xh5FEA6PX/g9JtaL5OThtpxhWIYrTci6 AVzx6GRiY+9KuTdrRvdm7Zx7s8EN2RrcW/+hjTtbTze4N6vm3JtVga4C99Z96JlSkXvr6V7BvdlQ iwvurUQVyvaypRXBV4ECCWQMYmAWaayo3OCnc0alE4wWurDVMBmZBg0HbjAugrULtoiLwRVXjfPZ ibn57C5hQvdE53P/oY07W083zOfazc3n2l3otk90PncfyirqHPi9ynx2lx+Ovw5cyaiAWpFqx3gk Y7HNKOfisyn8rjBPI8Nb7eFHULk8xElc4QU/pLakFxgcsJ64wmtpcAX2r/EtIPVEwl0srJGCDhde s8IXJ2q1N4UAJfZNjVKxkymxb/rs7PBpMrw46ib8HtpVjBmyD4jVWBlex1JLYQTVWtYFI7TPMxih bfUYoX+KMYL/0MadrafrMYJqnTdihK71QreiGGH4UFZR58DvFTBC+57L9IVYGiE+r9CM0pFdSm0z asJLVPMnfn15U6JgxZ4djyKA6va9EJzgfPUBL2XINYHDA07ZhM2KPaqM6n2WjxUhX0apTYbTzAgK obAalkiexm2R+hPBi3PE+23fskb9s5aa2tMpgSJUJZukmDOKr3jvz25QoYQAzWzf08LdJ1oUr6AG mMfqOWeVdqmbu40fWtxLelqOV1Um/NYHn+MttCWtKidGvOfkHN5z6oLLnAK8139o487W0w14r27m 8F7dXOjWDeC97kNZRZ0Dv1fBey78fGTq0pwlKLYdvjyjxEqBPEqR8hBHadAGTacNNKw4aMoXl/KV AM8uXL922ghpgIB4KMY6fAAvK+Dc5Ozh0xxtY0dH29RzjrYJAXDjwNH2H9q4s/V0g6Nt9JyjbXSg q8HRNsGzhs6B32s4WlEFUQMcYXecc8Bn4qabhWqC1PULSwX3Rc7wPp8t+JvuuJcAX90VNK++epWv XlFAymsfZLpHIcgKHF0qbypaM3oMz2rGvQtzccPdE3Hvw4c27mw93Yt7F6aace/97U6ebkXd+3D1 UxV1Dvxexb2by8FegHyHxbPXAaeK2rOEyVrMOG09Gqd1c8ZpL8FY90SNs//Qxp2tpxuM05o547Qm 0DVgnN2HnikTGWdP9wrGWYvVxlnkSAh/jAJzMvxFHnx1PnsFzYocXYnjgPyWRUaNJX9rDYgQGuhr 4QINf2vmQgPIY0WDo6wXQAVIlNcL/QYObkXOmq1kLbgVrISzSUbAQvibDLan13n9Qxesbqc0dgFw +BYqjxXRd8bCSxlbY1QQwoNlJg7nLDWAHhIL7RYXkqxiKRGMyLDd8hqMENW95GBET/Be++f8vbUj YXvT8H99e8w91fv5/Pn0fyvg9CRlbmRzdHJlYW0KZW5kb2JqCjI2MiAwIG9iago0ODE4CmVuZG9i agoyNjYgMCBvYmoKWzEzIC9YWVogNDcuNTE5OTk5OSAgCjEyOS4xOTk5OTkgIDBdCmVuZG9iagoy NjcgMCBvYmoKWzEzIC9YWVogNDcuNTE5OTk5OSAgCjE1OC45NTk5OTkgIDBdCmVuZG9iagoyNjgg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAx MjUuMzU5OTk5ICA1NDMuODQwMDAwICAxMzMuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJk aWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI2OSAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEzNy43NTk5OTkgIDc2 LjM5OTk5OTkgIDI2My41MTk5OTkgIDg0LjA3OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwK L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzpicmlhbi5kLmNhbXBiZWxsQGdtYWls LmNvbSkKPj4KPj4KZW5kb2JqCjI3MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzEzNy43NTk5OTkgIDM3LjAzOTk5OTkgIDI2Mi41NjAwMDAgIDQ0LjcxOTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0 bzpjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tKQo+Pgo+PgplbmRvYmoKMjY1IDAgb2JqCjw8Ci9U eXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDI3MSAwIFIKL1Jlc291cmNlcyAyNzMg MCBSCi9Bbm5vdHMgMjc0IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMjcz IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1Nw ZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwK Pj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjggOCAwIFIKPj4KL1hPYmplY3QgPDwK Pj4KPj4KZW5kb2JqCjI3NCAwIG9iagpbIDI2OCAwIFIgMjY5IDAgUiAyNzAgMCBSIF0KZW5kb2Jq CjI3MSAwIG9iago8PAovTGVuZ3RoIDI3MiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnic7V1Lj6W4Fd7fX3HXI3U1NsZgKYrUz0hZRGp1SVlEWUQ9mUSj7lEqs8jfDw/jC/7gfsbX UNwqqjTTlMGHw/Hxedt++6ev/zj/6/fz2w9f/3P+Zv/98PWUPWSF6X7OWf37Ztggq4dcZs3PuRL5 gy7b1m8/Tk/np9OX05f6/08noduO9p/6Zv+KrP39/dtvp7fdy09dy9cPf6mv/neW5z/X//16/tvf 68afLbzmgR+nyugajywTef3n9+GfQpqixqS+rtsz/8/m4X+f/vrT+bcGMflQtciLDsHhn2+ENnku HmQmb0L56dK1xiI3UhS6mr0eAs5zi486CyGqskalxuzHKVdF8z1ZVtTtdVv73Q0NtFAPqr6Wfrvs +sohnO8z8Bvy/DLAuSZC9zN7PcJ5hFtH0Bbn4bukLPoBGeE2ah9+Sw/n+wx8H+dEdJ7BeQ6HuXFZ g87TY/3Daw+h8zRvzPHSGOdeDBiYFIvmllY1ZZQQqhYnZ1Gc//vP+i1f2rkTMUNF+ztEpmuZmaFP Vzq+fzy9/azPIjs//nLuMHjT/fPYYf2mRlsW58efz39okPrj+fHXUyOQbINsG8pLQ942VJcG5T/R wfj0WH99iMgR+EH1cJ1FLvOqZof+2jyITDVs2V1o07Sq+p6o7NW3kxD6oTKFyjN3U487awu3fba9 7nqcx11z3cOtr5pnhy9tblqk+s4O3281e73/6bpAfbpClna4mrdMDZfIRf1X/WHSklroltTG0V5k 3uhAQ1a0DeryRDdcYjDmH/w+n9qG4tJQMqjZe9YlFz7fQBcOFDCFLrnP0B/9LgAUvpa/hX+c9gfm nY/YO/8tHHX6hOCow+dLvwsgxgcKugDqvAvIFWgALoSRA0yBYkAgiinSFF7LP385r4uPjKUCZmXl w1g+UFIsfq1QdGx9GAFyS3qyD8d2hrVbzXSzEC7KcHGZDvfBW/zXIpU5k/n8gFIJEIPRDuXt28je aN0x2X3WDfh+oGHExwBB+JxKIIXyjCk2nDEpPs5QfbrJ50doGC5B1lF9W06p3arPNCK2lHNf96Ln eoARC2MJXQAovJZTLIF5uZV3wWduApHCu+Bkp34Qfj68NoLJPtPJzm0S+DiwQIEeoC6W20b4tXsR sTPeZxpZV70EuyZi4qZwUBO8VuR0wnBpQLugTQI+HNAjNIBxGxsWsuHCXBSzmHInFya/T3WZU6YD EsLI+W9BoEDCBDMK37Ivg+sKHoC6MF4XZS4cdFPENs+Ni9jmKpuI2OZK2Mhqc+VFbLubetxZW7h9 xDbPy4mIbd3aw62vvIhte9MiWA4jth3c9SO2ucr7wejmlcgWjCjyHjfufM6asMM2sSoCAjs89MGN CIDBDbMIqwK+ljuhIGlA4Kt00rsUh/R+fdI7H5iht0lvU1ykt9FT0ts4KWtKkN7tTT3urC1cJ71N PiW9Te7g5iC9m5sWqXwkvVu4G0hvY3pFKUB6Q14Hpt5yszkg+A1PAGeBOPOnzYRKWNFLWhTegNeC L8JVAresuUxM4eBEeCs8IAKKmIpidO95cgicJOCYNDzEo1mgnGiOdgKzVcYKcOcwgDN5FzDnqISw eiNJcEIJFU4yzryg0HmkPkW0/yXF6taw7wKozrsAO0AXaPCng/zsAYXcFzSAcAtoqKgWWm7NIlDu mPlP4McFuG6QDPR5O6k4kGYWEeBDUCo8y0DnAx9/6AJVC5hQXcPxwLdQswxJyCUqVbEhTOVrMuBM 8DykT6EcmBkmd+UDhSlDRciEGfLuwt03uUBKZc4FUkpMuEBKSeuqNFeeC9Td1OPO2sLtXSCVVxMu UN3aw7XlicOXNjdlNurs8N3CBVKqtwBiSg6X+zcBPA/6jCtrPm9AWq2R0TiiM55MgBAHl4k8Rgri zAcKKiEgzso9lRSW6nJ/GPQ9evu8PIj6NggUVATwB7wFSLhG1Ay/Zc1CFVWYOQoFcK5v7iaZuAAU nE5uusHU5jYDvncVgeG/RRW+BFmjRhflQ4IaXfWRWohrVDfcT0R8Haprnx7AUu+ZSMFgcO7TcCLb ly7do1zJyGFQMJbZK3PHpHv0hYNu8nUKIZyvUwg54esUok/LNFeer9Pd1OPO2sLtfZ0iMxO+Tt3a w82M7+u0N2U26uzw3cLXKS5FMDR7u0225/CGXrXw8uNhgg/DKvkSlE2gVn1hlYJBAl5bJVOqhavU OfjyFSlVy1IJlKouL0pVV1NKVTvlpw0o1famHnfWFq5TqrqYUqq6cHALUKrNTYtUMVKqLdwNlOql NmmbAOIq64/Bvoe1kAkW5XF/b0JW8yK6iCIT7nhys4PO55ASAsDM56EMBnOTSB04fDF48GW8fM3E kXYdA32Jadei0rOIHGlX8pYXlXadsV4GT4Cigi4J0665DzWBGWUGZpSZNKOMM6MMmlHGmVFmbEaZ gRllJs0o48wog2aUcWaUGZtRZhszSme9GSVBBS5fAsmzNUkWUXN1zg0NmGoUKNpmEZVpsCqMq3OO Oq8hDHDOl6+8QIM3IMHDt63hCb4UJcLAy6Ct6MK5mBJBMF98huCrZiNqNyNUT0B6ly+aSbF7UESX UM8siRWlhbOili9WjllFhZqWejM4yaiEiOChkKX51CYMYOaIODPIvwQRgbzyiKo6Cgkx/0iAs0aL mQMWvEXMu3UK4vnSe+rwB6wz2K1iCtjaii6Kj9jrKgCP0M070ojI3MXqwP6hK09x/PmGail0F0iq bZa3wuDyaA6wEHiAUEQDsuy9rzFAhaBwM4z9k0TElEfU/LOPCMTI+PeGCDMeAV1l/c9eFAIP+PCg Uagvk0bKKGeIRaSJIhZ8gz8AFT7bbNy2ij20nIWSxWp0cYnV6GIqVqOLPlbTXHmxmu6mHnfWFm4f q9HFVKymbnVwIVbT3rRIjWI1HdwNYjW6V6OYJljFFg/QTlwZrbF/GSz6CC7PXeRX8AhuxG5U3BXn JkBE/XJEVCWB9l6JDdfYZ1F+9J9IEUVD6zUBqgFUDRDofCdO6hPLTwnVd+nUN1+cz5eAp9h5IGKr b25XLV9G8lxSN2INBPDUXjUILCyMCfevsedbwAY/FNOAfRVT7AnILdMEb0GjOrreIY2YMmKWIEeN xPUJs22NxLXCwqO8gbzlRZc3gPsAq8qh7njn5Q1lJp3LXGb5hMtctictVfbKc5m7m3rcWVu4vctc ZtmEy1y3OriZ7zK3Ny1S2dBl7uCu7zKXWW9UBrjMMDu5QAOFv81ms3dTeqqkTzEII0+sevOD0VgE CV9Do/UB4bsES2/QnPPlBm9IUgHCWTciR5IiWR+xfJtyakC5D99Va3nuMsRYAdsUGhLE6gPSjKCc qCkyp76TWNGldBnB5RMEhMpRAs0ExmHes+l/mPeEhHdk3lN7H+qb1zHv40PqaYRsroO/5pBlhyw7 ZNkOZRmEKnwYsDRj76EKdcnul2oqu1+qPrvfXPmhCtVn9wedtYXrQhVqKrtfqsLBhex+e9MiNcru d3A3CFUU267E4L46ut3LYxcyQdU4SjzowoumqG5eKzLxPMcqRqSAYk4ni8gaLT97A1NAEUXj8LXA VHxzEr4dAbcrZqI9t2414YsQyRgkYaTyRtyLcoz7freB4IG5FJtx9fpAh5czonTjW3rwEBmtVODz MKASN0GA/H6UDCiQ/KOvY0Tht0zoIb/0Wir/kZgg4SrJi012H1Tv2OgBawZEEZfH3RXdjTovKMU2 rWcoq6OeYQboESRgX3cECa4jtpuAJxQ47D1IYAb1DGaynsG4egaD9QzG1TOYcT2DGdQzmMl6BuPq GQzWMxhXz2DG9Qxmo3oG0xuFG50cds9bRy5X3xBci1HfEUnxdIf2ps3W8zwJCJaAuvqIY9KWH2iV ZNEAZxgqV3ErHY5pRFn1XjcOvf/RT2JlV8JZ2Smc+aN44fGw5Q9bfhboy7blqZGyL1u+khdbvpJT tnwle1u+ufJs+e6mHnfWFm5vy1dyypavZObggi3f3rRIjWz5Du76tnwle1seU08brZJcnhPEDNgz rd+idie3ogIigAlKoGOsuQQjhyXhEY5bCt+GJwB5vBP0O5wbBdILGnhClC6IRZruZPPCgHUIz+QM pzi9bM2Nx9JY90okHP/dZkwCFp4un5cB1v02e5Vxdg84JuOoO186uHfnuqWRGMWx9XagwDz8P6/h 3tamVoMTTKrJE0wqd4JJhSeYVO4Ek2p8gkk1OMGkmjzBpHInmFR4gknlTjCpxieYVBudYFLddIJJ irxMAvN+t/5gRKbiJcXdI/YiDtirhW/Mww2giM06+U5FwB9888YU9X97926uvXedPeIj/J+UaZbL iSacrCBjYaby0Vx+5u9Gq/sPR+TxcEQCZozJ5suuD0eEvOWVOSJAwztzRIy4JKKMmEpEGdEnopor zxHpbupxZ23h9o6IEVOJqLrVwYVEVHvTIjVKRHVw13dEjDvB4iWtPOMWcEBwkm9Gv8rZC6ucG7KO +QqGBt8jN8VCqxRkB6LS6HXELrp3tuJj+QY2EdmJmLUYy0MT8VIljWXlDr04JNEhiXYgiVLMbcii r7KKarcbHgcs74ooEdjL0Vs8Ex1AQ3CjuXqIGMuZOZZGcF/OEaGHE6URhwnODVI8mrV8R8SAwCs9 vmqdwGuKSP0qZeb3wzERGy8GnAEfEDPmIdJ0R5ynEQj6WCI7A3RnIdGjrD5YuB3RTB/GNnsCpotm loNoZjkZzSxdNLPEaGbpopnlOJpZDqKZ5WQ0s3TRzBKjmaWLZpbjaGa5UTTTnSOTpKxilezcq6oS nZgU/EjT5YfzbHOy/DZkT1KZ8xrKtxfZt8Ax/MxPHN2IQy9XESHRNdBpTOLLKTjb+FU86sw3eIsI mR1lFESU3b/PkGI+qCw76rkDZ//hePgEua+9eVTtKfWOR309Uc9dt9p67vZq7HjYm3rcWVu41vGo ryfquZtWB9ev5+5uWqSG9dwW7uqOh8rksx/Pm2L14Urb4K6yZmu/pyvxZCQPg69y/k6KpcVQwYDj 7zfgFp2cZFyTgjoKCD/zLa8o3e+oZH1foXSVHUdSzAHdmVl8hNKDJeZrs2h55Py+CoNVpgYW7dSR FHWrs2jhSAp7U487awvXWbRTR1KoTDmLFo6k6G5apMYW7TZHUqjM7cm+0W6TAdFEbpwFGAU8mhQR K4rYXpHHwbm9zs3G5YuUMOwP0xO2U1m+8i9JdPmZ0iB7PaNgo5FbftwqPzwgYIo9rxOZxgJ2xzpg 2TcmLCPOV6EF6PgWcPmh2hzFDqwU2ckEwCp4/lpeTcbzQhHcDE/wiQjSbsoEepCZ/Zm9HhlIAc9z A2PhS9upUts9xdRUkbqZKeLiKwqfQe20Nj51B2JuxlsAjtXzcykHsxUYAzGD2TUzU7TPXdU8InP+ FDwRbAtHWovZleHSxXgsgsXlJFCh8jFUWfjT5dP0LJW+VhpQ+qPfUHjzWM5EoS5dxJwpfHnE+qGD 15Q+kHceqrbhNprZgSjLNQbCQbUCFRLrcp7M1ki9Rnf/wCpr+l2hIQ7me8oQ/hMigiHgW4APfX4Y Smk6DnpuHLJudCvTY+bLEfuaoTCS/lB9njbLLg05EHFQNpA9FMb+OEky5VXXLFNjaurHG7n/45Rn 5bDh++nrQHGMQY41E76OaKF5YNeJa5ncERd3VHznWw1ASiA2hMW0T9sP9IlP/iD7b5kYdd8lho+x kwsCVFf4QpVgrfpGYhL+4xTI/OMAl8aBUkZKOpErszxS5E67Ch03xkO9oh2kW+ydUjtIfwk5WCYD Dgb7p/JtNwhB+1LZuiwDo4pLZaodJjQ7h7rQNbw2MrJaY2Qc1ByO0QTTxrdKUOcqf2RmVoxeI5k/ 3GgdVb5QgC7+WxYVtxEVK5VT/jtXsVKJi4rVw4bdqtgLcVG1AXFB1KMWNlQtR0AF/Tih/cDIA8UM OhW0LjgOoPw4AYCK/ltu1Kj17/mpZgCh25G0/3z7Eatqv5y/nP4P6ZyG5WVuZHN0cmVhbQplbmRv YmoKMjcyIDAgb2JqCjQ0ODUKZW5kb2JqCjI3NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzEzNy43NTk5OTkgIDc3NS4yNzk5OTkgIDIyNC4xNTk5OTkgIDc4Mi45 NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkg KG1haWx0bzptYmpAbWljcm9zb2Z0LmNvbSkKPj4KPj4KZW5kb2JqCjI3NyAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEzNy43NTk5OTkgIDczNi44Nzk5OTkgIDIz OC41NjAwMDAgIDc0NC41NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlv bgovUyAvVVJJCi9VUkkgKG1haWx0bzp5YXJvbmdAbWljcm9zb2Z0LmNvbSkKPj4KPj4KZW5kb2Jq CjI4MCAwIG9iago8PC9UaXRsZSAo/v8AQQBiAHMAdAByAGEAYwB0KQogIC9QYXJlbnQgMjc5IDAg UgogIC9EZXN0IC9fX1dLQU5DSE9SXzQKICAvQ291bnQgMAogIC9OZXh0IDI4MSAwIFIKPj4KZW5k b2JqCjI4MSAwIG9iago8PC9UaXRsZSAo/v8AUwB0AGEAdAB1AHMAIABvAGYAIAB0AGgAaQBzACAA TQBlAG0AbykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl82CiAgL0NvdW50 IDAKICAvTmV4dCAyODIgMCBSCiAgL1ByZXYgMjgwIDAgUgo+PgplbmRvYmoKMjgyIDAgb2JqCjw8 L1RpdGxlICj+/wBDAG8AcAB5AHIAaQBnAGgAdAAgAE4AbwB0AGkAYwBlKQogIC9QYXJlbnQgMjc5 IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzgKICAvQ291bnQgMAogIC9OZXh0IDI4MyAwIFIKICAv UHJldiAyODEgMCBSCj4+CmVuZG9iagoyODMgMCBvYmoKPDwvVGl0bGUgKP7/AFQAYQBiAGwAZQAg AG8AZgAgAEMAbwBuAHQAZQBuAHQAcykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FO Q0hPUl9hCiAgL0NvdW50IDAKICAvTmV4dCAyODQgMCBSCiAgL1ByZXYgMjgyIDAgUgo+PgplbmRv YmoKMjg0IDAgb2JqCjw8L1RpdGxlICj+/wAxAC4AoAAgAEkAbgB0AHIAbwBkAHUAYwB0AGkAbwBu KQogIC9QYXJlbnQgMjc5IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SX2MKICAvQ291bnQgMAogIC9O ZXh0IDI4NSAwIFIKICAvUHJldiAyODMgMCBSCj4+CmVuZG9iagoyODUgMCBvYmoKPDwvVGl0bGUg KP7/ADEALgAxAC4AoAAgAEkAbgB0AGUAcgBvAHAAZQByAGEAYgBpAGwAaQB0AHkAIABDAG8AbgBz AGkAZABlAHIAYQB0AGkAbwBuAHMpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNI T1JfZQogIC9Db3VudCAwCiAgL05leHQgMjg2IDAgUgogIC9QcmV2IDI4NCAwIFIKPj4KZW5kb2Jq CjI4NiAwIG9iago8PC9UaXRsZSAo/v8AMgAuAKAAIABUAGUAcgBtAGkAbgBvAGwAbwBnAHkpCiAg L1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfZwogIC9Db3VudCAwCiAgL05leHQg Mjg3IDAgUgogIC9QcmV2IDI4NSAwIFIKPj4KZW5kb2JqCjI4NyAwIG9iago8PC9UaXRsZSAo/v8A MwAuAKAAIABGAHIAYQBtAGUAdwBvAHIAaykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19X S0FOQ0hPUl9pCiAgL0NvdW50IDAKICAvTmV4dCAyODggMCBSCiAgL1ByZXYgMjg2IDAgUgo+Pgpl bmRvYmoKMjg4IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AoAAgAFQAcgBhAG4AcwBwAG8AcgB0AGkA bgBnACAAQQBzAHMAZQByAHQAaQBvAG4AcykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19X S0FOQ0hPUl9rCiAgL0NvdW50IDAKICAvTmV4dCAyODkgMCBSCiAgL1ByZXYgMjg3IDAgUgo+Pgpl bmRvYmoKMjg5IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMQAuAKAAIABVAHMAaQBuAGcAIABBAHMA cwBlAHIAdABpAG8AbgBzACAAYQBzACAAQQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAgAEcAcgBh AG4AdABzKQogIC9QYXJlbnQgMjc5IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SX20KICAvQ291bnQg MAogIC9OZXh0IDI5MCAwIFIKICAvUHJldiAyODggMCBSCj4+CmVuZG9iagoyOTAgMCBvYmoKPDwv VGl0bGUgKP7/ADQALgAxAC4AMQAuAKAAIABFAHIAcgBvAHIAIABSAGUAcwBwAG8AbgBzAGUAcykK ICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl9vCiAgL0NvdW50IDAKICAvTmV4 dCAyOTEgMCBSCiAgL1ByZXYgMjg5IDAgUgo+PgplbmRvYmoKMjkxIDAgb2JqCjw8L1RpdGxlICj+ /wA0AC4AMgAuAKAAIABVAHMAaQBuAGcAIABBAHMAcwBlAHIAdABpAG8AbgBzACAAZgBvAHIAIABD AGwAaQBlAG4AdAAgAEEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbikKICAvUGFyZW50IDI3OSAw IFIKICAvRGVzdCAvX19XS0FOQ0hPUl9xCiAgL0NvdW50IDAKICAvTmV4dCAyOTIgMCBSCiAgL1By ZXYgMjkwIDAgUgo+PgplbmRvYmoKMjkyIDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMgAuADEALgCg ACAARQByAHIAbwByACAAUgBlAHMAcABvAG4AcwBlAHMpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rl c3QgL19fV0tBTkNIT1JfcwogIC9Db3VudCAwCiAgL05leHQgMjkzIDAgUgogIC9QcmV2IDI5MSAw IFIKPj4KZW5kb2JqCjI5MyAwIG9iago8PC9UaXRsZSAo/v8ANQAuAKAAIABBAHMAcwBlAHIAdABp AG8AbgAgAEMAbwBuAHQAZQBuAHQAIABhAG4AZAAgAFAAcgBvAGMAZQBzAHMAaQBuAGcpCiAgL1Bh cmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfdQogIC9Db3VudCAwCiAgL05leHQgMjk0 IDAgUgogIC9QcmV2IDI5MiAwIFIKPj4KZW5kb2JqCjI5NCAwIG9iago8PC9UaXRsZSAo/v8ANQAu ADEALgCgACAAQQBzAHMAZQByAHQAaQBvAG4AIABNAGUAdABhAG0AbwBkAGUAbCkKICAvUGFyZW50 IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl93CiAgL0NvdW50IDAKICAvTmV4dCAyOTUgMCBS CiAgL1ByZXYgMjkzIDAgUgo+PgplbmRvYmoKMjk1IDAgb2JqCjw8L1RpdGxlICj+/wA1AC4AMgAu AKAAIABHAGUAbgBlAHIAYQBsACAAQQBzAHMAZQByAHQAaQBvAG4AIABGAG8AcgBtAGEAdAAgAGEA bgBkACAAUAByAG8AYwBlAHMAcwBpAG4AZwAgAFIAdQBsAGUAcykKICAvUGFyZW50IDI3OSAwIFIK ICAvRGVzdCAvX19XS0FOQ0hPUl95CiAgL0NvdW50IDAKICAvTmV4dCAyOTYgMCBSCiAgL1ByZXYg Mjk0IDAgUgo+PgplbmRvYmoKMjk2IDAgb2JqCjw8L1RpdGxlICj+/wA2AC4AoAAgAFMAcABlAGMA aQBmAGkAYwAgAEEAcwBzAGUAcgB0AGkAbwBuACAARgBvAHIAbQBhAHQAIABhAG4AZAAgAFAAcgBv AGMAZQBzAHMAaQBuAGcAIABSAHUAbABlAHMpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19f V0tBTkNIT1JfMTAKICAvQ291bnQgMAogIC9OZXh0IDI5NyAwIFIKICAvUHJldiAyOTUgMCBSCj4+ CmVuZG9iagoyOTcgMCBvYmoKPDwvVGl0bGUgKP7/ADYALgAxAC4AoAAgAEMAbABpAGUAbgB0ACAA QQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuKQogIC9QYXJlbnQgMjc5IDAgUgogIC9EZXN0IC9f X1dLQU5DSE9SXzEyCiAgL0NvdW50IDAKICAvTmV4dCAyOTggMCBSCiAgL1ByZXYgMjk2IDAgUgo+ PgplbmRvYmoKMjk4IDAgb2JqCjw8L1RpdGxlICj+/wA2AC4AMgAuAKAAIABDAGwAaQBlAG4AdAAg AEEAYwB0AGkAbgBnACAAbwBuACAAQgBlAGgAYQBsAGYAIABvAGYAIABJAHQAcwBlAGwAZikKICAv UGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xNAogIC9Db3VudCAwCiAgL05leHQg Mjk5IDAgUgogIC9QcmV2IDI5NyAwIFIKPj4KZW5kb2JqCjI5OSAwIG9iago8PC9UaXRsZSAo/v8A NgAuADMALgCgACAAQwBsAGkAZQBuAHQAIABBAGMAdABpAG4AZwAgAG8AbgAgAEIAZQBoAGEAbABm ACAAbwBmACAAYQAgAFUAcwBlAHIpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNI T1JfMTYKICAvQ291bnQgMAogIC9OZXh0IDMwMCAwIFIKICAvUHJldiAyOTggMCBSCj4+CmVuZG9i agozMDAgMCBvYmoKPDwvVGl0bGUgKP7/ADYALgA0AC4AoAAgAEMAbABpAGUAbgB0ACAAQQBjAHQA aQBuAGcAIABvAG4AIABCAGUAaABhAGwAZgAgAG8AZgAgAGEAbgAgAEEAbgBvAG4AeQBtAG8AdQBz ACAAVQBzAGUAcikKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xOAogIC9D b3VudCAwCiAgL05leHQgMzAxIDAgUgogIC9QcmV2IDI5OSAwIFIKPj4KZW5kb2JqCjMwMSAwIG9i ago8PC9UaXRsZSAo/v8ANwAuAKAAIABTAGUAYwB1AHIAaQB0AHkAIABDAG8AbgBzAGkAZABlAHIA YQB0AGkAbwBuAHMpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWEKICAv Q291bnQgMAogIC9OZXh0IDMwMiAwIFIKICAvUHJldiAzMDAgMCBSCj4+CmVuZG9iagozMDIgMCBv YmoKPDwvVGl0bGUgKP7/ADcALgAxAC4AoAAgAEYAbwByAGcAZQBkACAAQQBzAHMAZQByAHQAaQBv AG4pCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWMKICAvQ291bnQgMAog IC9OZXh0IDMwMyAwIFIKICAvUHJldiAzMDEgMCBSCj4+CmVuZG9iagozMDMgMCBvYmoKPDwvVGl0 bGUgKP7/ADcALgAyAC4AoAAgAFMAdABvAGwAZQBuACAAQQBzAHMAZQByAHQAaQBvAG4pCiAgL1Bh cmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWUKICAvQ291bnQgMAogIC9OZXh0IDMw NCAwIFIKICAvUHJldiAzMDIgMCBSCj4+CmVuZG9iagozMDQgMCBvYmoKPDwvVGl0bGUgKP7/ADcA LgAzAC4AoAAgAFUAbgBhAHUAdABoAG8AcgBpAHoAZQBkACAARABpAHMAYwBsAG8AcwB1AHIAZQAg AG8AZgAgAFAAZQByAHMAbwBuAGEAbAAgAEkAbgBmAG8AcgBtAGEAdABpAG8AbikKICAvUGFyZW50 IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xZwogIC9Db3VudCAwCiAgL05leHQgMzA1IDAg UgogIC9QcmV2IDMwMyAwIFIKPj4KZW5kb2JqCjMwNSAwIG9iago8PC9UaXRsZSAo/v8AOAAuAKAA IABJAEEATgBBACAAQwBvAG4AcwBpAGQAZQByAGEAdABpAG8AbgBzKQogIC9QYXJlbnQgMjc5IDAg UgogIC9EZXN0IC9fX1dLQU5DSE9SXzFpCiAgL0NvdW50IDAKICAvTmV4dCAzMDYgMCBSCiAgL1By ZXYgMzA0IDAgUgo+PgplbmRvYmoKMzA2IDAgb2JqCjw8L1RpdGxlICj+/wA4AC4AMQAuAKAAIABh AHMAcwBlAHIAdABpAG8AbgAgAFAAYQByAGEAbQBlAHQAZQByACAAUgBlAGcAaQBzAHQAcgBhAHQA aQBvAG4pCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWsKICAvQ291bnQg MAogIC9OZXh0IDMwNyAwIFIKICAvUHJldiAzMDUgMCBSCj4+CmVuZG9iagozMDcgMCBvYmoKPDwv VGl0bGUgKP7/ADgALgAyAC4AoAAgAGMAbABpAGUAbgB0AF8AYQBzAHMAZQByAHQAaQBvAG4AIABQ AGEAcgBhAG0AZQB0AGUAcgAgAFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuKQogIC9QYXJlbnQgMjc5 IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzFtCiAgL0NvdW50IDAKICAvTmV4dCAzMDggMCBSCiAg L1ByZXYgMzA2IDAgUgo+PgplbmRvYmoKMzA4IDAgb2JqCjw8L1RpdGxlICj+/wA4AC4AMwAuAKAA IABjAGwAaQBlAG4AdABfAGEAcwBzAGUAcgB0AGkAbwBuAF8AdAB5AHAAZQAgAFAAYQByAGEAbQBl AHQAZQByACAAUgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4pCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rl c3QgL19fV0tBTkNIT1JfMW8KICAvQ291bnQgMAogIC9OZXh0IDMwOSAwIFIKICAvUHJldiAzMDcg MCBSCj4+CmVuZG9iagozMDkgMCBvYmoKPDwvVGl0bGUgKP7/ADkALgCgACAAUgBlAGYAZQByAGUA bgBjAGUAcykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xcQogIC9Db3Vu dCAwCiAgL05leHQgMzEwIDAgUgogIC9QcmV2IDMwOCAwIFIKPj4KZW5kb2JqCjMxMCAwIG9iago8 PC9UaXRsZSAo/v8AOQAuADEALgCgAE4AbwByAG0AYQB0AGkAdgBlACAAUgBlAGYAZQByAGUAbgBj AGUAcykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xcwogIC9Db3VudCAw CiAgL05leHQgMzExIDAgUgogIC9QcmV2IDMwOSAwIFIKPj4KZW5kb2JqCjMxMSAwIG9iago8PC9U aXRsZSAo/v8AOQAuADIALgCgAEkAbgBmAG8AcgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBlAG4A YwBlAHMpCiAgL1BhcmVudCAyNzkgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMXUKICAvQ291bnQg MAogIC9OZXh0IDMxMiAwIFIKICAvUHJldiAzMTAgMCBSCj4+CmVuZG9iagozMTIgMCBvYmoKPDwv VGl0bGUgKP7/AEEAcABwAGUAbgBkAGkAeAAgAEEALgCgACAAQQBjAGsAbgBvAHcAbABlAGQAZwBl AG0AZQBuAHQAcykKICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xdwogIC9D b3VudCAwCiAgL05leHQgMzEzIDAgUgogIC9QcmV2IDMxMSAwIFIKPj4KZW5kb2JqCjMxMyAwIG9i ago8PC9UaXRsZSAo/v8AQQBwAHAAZQBuAGQAaQB4ACAAQgAuAKAAIABEAG8AYwB1AG0AZQBuAHQA IABIAGkAcwB0AG8AcgB5KQogIC9QYXJlbnQgMjc5IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzF5 CiAgL0NvdW50IDAKICAvTmV4dCAzMTQgMCBSCiAgL1ByZXYgMzEyIDAgUgo+PgplbmRvYmoKMzE0 IDAgb2JqCjw8L1RpdGxlICj+/wBBAHUAdABoAG8AcgBzACcAIABBAGQAZAByAGUAcwBzAGUAcykK ICAvUGFyZW50IDI3OSAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8yMAogIC9Db3VudCAwCiAgL1By ZXYgMzEzIDAgUgo+PgplbmRvYmoKMjc5IDAgb2JqCjw8L1RpdGxlICj+/wBBAHMAcwBlAHIAdABp AG8AbgAgAEYAcgBhAG0AZQB3AG8AcgBrACAAZgBvAHIAIABPAEEAdQB0AGgAIAAyAC4AMAAgAGQA cgBhAGYAdAAtAGkAZQB0AGYALQBvAGEAdQB0AGgALQBhAHMAcwBlAHIAdABpAG8AbgBzAC0AMQAw KQogIC9QYXJlbnQgMjc4IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzIKICAvQ291bnQgMAogIC9G aXJzdCAyODAgMCBSCiAgL0xhc3QgMzE0IDAgUgo+PgplbmRvYmoKMjc4IDAgb2JqCjw8L1R5cGUg L091dGxpbmVzIC9GaXJzdCAyNzkgMCBSCi9MYXN0IDI3OSAwIFI+PgplbmRvYmoKMzE1IDAgb2Jq Cjw8Ci9UeXBlIC9DYXRhbG9nCi9QYWdlcyAyIDAgUgovT3V0bGluZXMgMjc4IDAgUgovUGFnZU1v ZGUgL1VzZU91dGxpbmVzCi9EZXN0cyA8PAovX19XS0FOQ0hPUl8xOCAxNzEgMCBSCi9fX1dLQU5D SE9SXzIwIDI2NiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3JmYy5y ZWZlcmVuY2VzMSAyMzIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw NDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNy ZmMucmVmZXJlbmNlczIgMjMzIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1s IzIzSW50ZXJvcGVyYWJpbGl0eSA2NSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwu aHRtbCMyM2NvbnRlbnRwcm9jZXNzaW5nIDEyNyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25z Lmh0bWwuaHRtbCMyM3JmYy5hdXRob3JzIDI2NyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25z Lmh0bWwuaHRtbCMyM0kjMmRELmlldGYjMmRvYXV0aCMyZGp3dCMyZGJlYXJlciAyMzAgMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhdXRoZ3JhbnRzIDk1IDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzb3ZlcnZpZXcgMjYgMCBSCi9fX1dLQU5D SE9SXzIgMTAgMCBSCi9fX1dLQU5DSE9SXzQgMTEgMCBSCi9fX1dLQU5DSE9SXzYgMTMgMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNSRkMyMTE5IDIyNCAwIFIKL19fV0tB TkNIT1JfOCAxNSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM1JGQzY3 NDkgMjI4IDAgUgovX19XS0FOQ0hPUl8xYSAxODcgMCBSCi9fX1dLQU5DSE9SXzFjIDE4OSAwIFIK L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM0kjMmRELmlldGYjMmRvYXV0aCMy ZHNhbWwyIzJkYmVhcmVyIDIyOSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRt bCMyM2ZyYW1ld29yayA2NiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMy M09BU0lTLldTIzJkVHJ1c3QgMjM0IDAgUgovX19XS0FOQ0hPUl8xZSAxOTAgMCBSCi9fX1dLQU5D SE9SXzFnIDE5MSAwIFIKL19fV0tBTkNIT1JfMWkgMjEwIDAgUgovX19XS0FOQ0hPUl8xayAyMDMg MCBSCi9fX1dLQU5DSE9SXzFtIDIwNCAwIFIKL19fV0tBTkNIT1JfMW8gMjA1IDAgUgovZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzU2VjdXJpdHkgMTg0IDAgUgovZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzUkZDNjc1NSAyMzEgMCBSCi9fX1dLQU5DSE9SXzFx IDIzNSAwIFIKL19fV0tBTkNIT1JfMXMgMjM3IDAgUgovX19XS0FOQ0hPUl8xdSAyMjMgMCBSCi9f X1dLQU5DSE9SXzF3IDIyNSAwIFIKL19fV0tBTkNIT1JfMXkgMjI3IDAgUgovZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzc2VsZiMyZGlzc3VlZCA4NCAwIFIKL19fV0tBTkNIT1Jf YSAxNCAwIFIKL19fV0tBTkNIT1JfYyAyNSAwIFIKL19fV0tBTkNIT1JfZSA2OCAwIFIKL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RoaXJkIzJkcGFydHkjMmRjcmVhdGVkIDg1 IDAgUgovX19XS0FOQ0hPUl9nIDY5IDAgUgovX19XS0FOQ0hPUl9pIDcwIDAgUgovZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTAgMTg1IDAgUgovX19XS0FOQ0hPUl9r IDk2IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTEgMTg2 IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzY2xpZW50YXV0aCAxMTAg MCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3IxMiAxODggMCBS Ci9fX1dLQU5DSE9SX20gOTcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwj MjNybmMgNjcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3Ix MyAyMDYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3IxNCAy MDcgMCBSCi9fX1dLQU5DSE9SX28gMTA4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRt bC5odG1sIzIzYW5jaG9yMTUgMjA4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5o dG1sIzIzYW5jaG9yMSAxMTEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwj MjNhbmNob3IxNiAyMDkgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw NDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNh bmNob3IyIDEyNiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM3RvYyAx MiAwIFIKL19fV0tBTkNIT1JfcSAxMDkgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1s Lmh0bWwjMjNhbmNob3IzIDEyOCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRt bCMyM2FuY2hvcjQgMTQ0IDAgUgovX19XS0FOQ0hPUl9zIDEyMyAwIFIKL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmRh c3NlcnRpb25zLmh0bWwuaHRtbCMyM2FuY2hvcjUgMTQ1IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2Vy dGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yMTkgMjM2IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZGFzc2VydGlv bnMuaHRtbC5odG1sIzIzYW5jaG9yNiAxNDEgMCBSCi9fX1dLQU5DSE9SX3UgMTI0IDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDQ2My5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZGFzc2VydGlvbnMuaHRtbC5odG1sIzIzYW5jaG9yNyAxNTcgMCBSCi9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3I4IDE3MiAwIFIKL19fV0tBTkNIT1Jf dyAxMjUgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwNDYzLmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0bWwjMjNhbmNob3I5IDE3 MyAwIFIKL19fV0tBTkNIT1JfeSAxNDMgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1s Lmh0bWwjMjNhbmNob3IyMCAyMjYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwNDYzLmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkYXNzZXJ0aW9ucy5odG1sLmh0 bWwjMjN0cmFuc3BvcnRpbmcgOTQgMCBSCi9fX1dLQU5DSE9SXzEwIDE0MiAwIFIKL19fV0tBTkNI T1JfMTIgMTU4IDAgUgovX19XS0FOQ0hPUl8xNCAxNTkgMCBSCi9fX1dLQU5DSE9SXzE2IDE3NCAw IFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTA0NjMuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmRhc3NlcnRpb25zLmh0bWwuaHRtbCMyM0kjMmRELmlhYiMyZHByaXZh Y3kjMmRjb25zaWRlcmF0aW9ucyAyMjIgMCBSCj4+Cj4+CmVuZG9iagoyNzUgMCBvYmoKPDwKL1R5 cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgMzE2IDAgUgovUmVzb3VyY2VzIDMxOCAw IFIKL0Fubm90cyAzMTkgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iagozMTgg MCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3Bn IC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+ PgovRm9udCA8PAovRjkgOSAwIFIKL0Y2IDYgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9i agozMTkgMCBvYmoKWyAyNzYgMCBSIDI3NyAwIFIgXQplbmRvYmoKMzE2IDAgb2JqCjw8Ci9MZW5n dGggMzE3IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJzlV1Fr2zAQftev0PMg zp1OliUogyRtB3soBBv6UPYwUtZSmlLTh/39yZZjuafWplnC2i4msfXl7tPnu/NdMv9W/pQ3T3K+ Kh/lpjuvSgEZ5C68JPhjNgSUzUhB85IWKTNFi262opa1WIu1/6wFmtaxO/kvd1tAezxtHsQ8bC4C Uq4u/NVvqeR3/76TVz88eN3xNQZbYZ3xOgCQ/PJ+uERDNtP+Wnkc+LIxvhWXX+RDI0xlthWPQeBw OUOrlCsy4x33l1yPOC4rMT930kuufsmgYBZO1VYo4xda5VpW1/LEa8q/yupOnFU+CnuToqa/Y4UR qaY4JOlOas+KZy1rU4PdNtQCKgK2BfIIqBYwEVhwoGAALjhpuBnqARWAIrpYZpG4kOYWK67jdEoY 6MNlqnDHyFTPuk+mgoseiZDmLomF4xzLN9ydee3uIMTM4S7/mpdMuBnEiChWInDOCgB5RdCSi8co HrJdv3V9r8G01zSJaJSqLG/6sU93bobAvShjFBjls4b2wnbjrW2EbDy4Xen0wX0hlsRiSQsWOh0e FYSRjCQJ6AouaQ2D+lry59xwF26hDE+i46SJRaIj2dbGQvg3Q4ggP8IQ2p91pLUR2iO0tsiqNX+y k4ky3cmSXs/nRbLL9IjRYRf7+rbpZEukc2EIh0sMwTES07N+xplDWn2QmUOa+plT5EPg3c6cGFxM ftAloZycDV1xDTgcA/6jKXX4v331hIFciz+XKzJ4ZW5kc3RyZWFtCmVuZG9iagozMTcgMCBvYmoK NTU4CmVuZG9iagozMjAgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAv UUlNQUFBK0RlamFWdVNhbnMKL0ZsYWdzIDQgCi9Gb250QkJveCBbLTEwMjAuNTA3ODEgLTQxNS4w MzkwNjIgMTY4MC42NjQwNiAxMTY2LjUwMzkwIF0KL0l0YWxpY0FuZ2xlIDAgCi9Bc2NlbnQgOTI4 LjIyMjY1NiAKL0Rlc2NlbnQgLTIzNS44Mzk4NDMgCi9DYXBIZWlnaHQgOTI4LjIyMjY1NiAKL1N0 ZW1WIDQzLjk0NTMxMjUgCi9Gb250RmlsZTIgMzIxIDAgUgo+PiBlbmRvYmoKMzIxIDAgb2JqCjw8 Ci9MZW5ndGgxIDE2MDYwIAovTGVuZ3RoIDMyNCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCnic7TtLbCPJdUVK80lNPPHYu4sghp0awkZmAC61mEkWgSYJtkW2JO5SpEy2NB5fss3u Itkjspvobkoj55AAzjEwfEjsJIDhiw/2KYHhm6/2xUEuufhk+LAxcgwQIIAN2DN+71X1j6S0Gknz CZDhUKyufv9fvX6iWIkxdp39DVthrNNbu/er2+HbsPN38N4fjo8HwXf/4Zuw/k94N0bSdp2fNf+E sdIduH53BBs3/vTG9+D6Q7j+/GgSP7n2r+wncP23SHUcODarsDfhGuldndhPpuwK+x24/nu4Fr49 kX94sPNtuP4BY39+nZVWb5a+DhDsyv0r/wS7n1OfKz9lg/KnGCvfuLqycn21XF79L1Z79h/sN8/4 5z+8C5TY7sB02XtMPHt29Y2nb5T++dqk9NGHrPTs58/wLiuzwdNvrA6ufAe0vMbYp2/dvvWF27du D1bZr6OVz/z6F0+/ce3mL/8nvHqXlZhb+nn5r8tfRXt8+vabt93yZ37zi/JXv8PQTvD+q/sfOX/5 e3/2v2i0hX+u5lJiV9M9wLk2efpZxm7+0bP+s/7qgCjl/5VX/x30+4i5sH4T7EU4IPN1eGsKC//+ oPQX6f4/lu7pdYndKH2k12W2WvqVXq+wG+W39HoV1ut6fYX9bvlDvb7KOGit1tfZrfL39foG++xK IsMnPvWtO1/W65vsjx/09fqT7MaDf9HrW2z1wY+BY2kV/fwOccd1ib1V+je9Bt1K/63XK7D/VK9X 2Vvlil5fYb9f3tTrq+yN8kSvr7NK+Wt6fYOtl3+k15/4wvrK5/T6Jhut/1KvP8neevBNvb7Frj/4 IauzgE3ZMQuZx4ZsxGIm2B3msLvweY+9A6/7sOoDhGAbABOzCN4hk8xmE1aF3SbzAb4GK4ON4SVY N6UV0ZWETwk4h/DTBUh+Bq7vplwt4HQIvB4Djg/QKIcNOM/HsQGrx4C3z2YA4QCsTdQkYdikkQAq PvycAkwf6HoAJwA/AO423eOM1YPpcegNR7G449wV9955577oH4sNL47iUNqTqmj6Tk0Y47HoIlQk ujKS4aF0a3wB9V1EtezDyePAH4oNe3QCYkM+tvdnwhnZ/lBGwg6l8HwxnfXHniPcYGJ7PkhWVLFH CkawrZB7tg8XG6BMwA5gEQQHZ0M5C8w+WTsCGwVkwXtg8/vwYvsyjLzAF/dq9+8XSc0RWsZrQNSU T2MdcQnfQeCDiWKwOCO/x+C1dbYGL1fTOAQaNcAN4DMET0qiF5LPa0BXAg4bxfF0fW3NBaKHs1oU zEJHDoJwKGu+hNubOQmSGEnidDEb8B7GnaTYlRBBATsCWIzUy4k/pLQFd44BZkSYHtybkl4xxTpa LSQMzA6kejhnyXk9svyaFfLrJG04vJbprmLAhlXeaouZztnbF3jxM1WPy69Zy/2d6ezBHU6rmHYw Cidk6wPYC8ADHycLarZL9CZELcsmj2Qa0T2p9RoSF197var9rryluKkYU/FeJbkC8r5P+FOdsYpD AFRjHWOejgKbaChLc00zJinm48khOIxDRT2hgNBKdhXLkhJexV4lFyUV8hziuvQZkVwO4NhaP05Z 4ECETohKTHcS+wxgNdaZdCeVMeOAVQvljyF+VfQjx8wmuDOlrHGBg0PYiTQuaRBTrPXhbkx3FQ9+ CoeqzmYHJJsRFWWTI4qBEVWlWFtmQnt5jRIdwkJUKmlnZMNqzju4npA/la95roJEgF09QY9qquca VRBBlFU+KNqetmrR+6drnVhOSTtNIzomubKoyzQ6IntMzsQhyYYBVXVfayhzHF36iTyq9ImWeAwQ DtFTMIn/MI7HurIlHnKIt0sSe1rSdcpOS0tnA8WAKkPmg3wtyiywWAl8gI91NkQF2CRXMovla0Ae T5DONknOqTYXY01ZQ50l9in+DOgUFNr3E/rM6sdZfBHTSYQnq601qhUsdRou2uRYny2KO9p8QDK6 OpLGFKdhuqMkRZu6OZ/noy45QW06ET2qGWO64qlGLkmK/vJz1hgWzlXFKamhNkWPit2Ex7x9oo/V KZGSaw2yCLPJR2eXoMhn3h7LZKtqf48JzzuhmvPUOyHVWZvqSkY32YnSiEzyZf70kLrOSdIi4XRE WrmEX1lyHlZSvecxONxLTttKLspUzrTmzpc+5XuQk3Wm8yCJk0O46y2xmGRPyM6+zuQpvNTpZVNF lSlG3u9K5mSHL82UEVV4QZ+RllFSJJ0UJ0mtW1a7XToJfPJ73l7LrMpzlsv78Ly5GlHVTM7qLNuS TMLOYZz2HqHGKFKcUkQfwM+h9pg6DzGqeFpVX2SlOlmrvs6RWJ+Hg9RS28wkPh3Whivk04Eriz2E PrJL95qwJ6CP68KdfbhqwG6D/GLQHbxfoWx8CGuk2GF7REvR6MJPpP0IdpC2oGu8+gDg20ALcU32 JeJhArUeSNaBNdLegd0WfJoaDjHqsLMH17jeYtiFKn5twLIodxAPZVGSWrCfcS1K1SSOiWQ7cNUF +tv6rgG0m0QP5a9Sf4TrtpZTWa5L1NFGSBlp1kGiFl3h7h587gJcj+xpkM5K2jbpsAn3lS4mSaA8 oSSqw+cu8EaILZDLIisgJ0tDVsmPqE+D8JHrBwSlJOtoL+M6o1LTtlRyoP33U8490r8FL0H6W7Bj kW8MoJ/QTWJniyig3JyssUf6GWSHDnHYIDi0ItqzlUZcN+eVOtkL/YaSN4iTQRbpLdUkoZb3zrLo 4CmHLdLPJEu1CLoHdjQBvpnuqHhskq51bWtFU8W9iolWzrp10hE9+0XgauqYMsh2RS3QTw9J/kwL 5QFD/6znbJZ5v629m8hjEWdriVUeUi6aBGWQr3tpjmxS/u5oyffSCMtqwJ6Oz04qWdG+SR4lcGep HYpWwrvowQbFU0tL2EutoSD4KXRV7TLhXHPoOSdO63bx5M53jVk3mu87q7lam+8EVBXeItjJHFy2 q56W1JmVPevke7dlT9jJ07Hq5ZOuN+s+VO1Wz0T5rtel/lz1gFHalQTUBwZpZ3JEd7MzfapnJ0Hh OQ8523T2V1NeyVmU0VJ9pU3dAnKLlljz5BOKLzwZTum8V1yOaB3rzgT1m2lY3P/K3NNwMv9Z9IFY 6oNEl2WdQ97+Ifl7qp+lPLIw9pM1TTdkyXNZZhO0gJq7Tea8nkUfUltn81MFtMEwJ7lLtuZMzfCQ J6d6lcy4Xv3U6bJn1q/TPIgX5kHzndeLmwfxpfMg8ZLnQfxM86BiJ+/kZMpmHQnk2SaoyyYs/JXN lcTCXIn//1wpN1fKJgz/N+dKvHDCvrq5El/ytPY6zJX40rlSptHLmSvxU+YFL2euxNnzzpWy3zpd 5lwpy7fiXOmk0/fk6ZJ6PledxOs2XeKsOF1aPt14OdMlfop1Rc6Cr/eUiVOMLXYzL3/KxF/jKROf mzJlz7ovc8rEP3bKJF7alIk/x5RJvLApEycb7APV90laZW0D7r+82RFf6vNXNTviC7Mj8cpmR/zE 2VE2A3rxsyP+HLOj0+i+2NlRUllPPlEWJz78HBOf/JTmMic+/EITn8VntvNNfHhu4nPa3OEyJjTx Av33WDZp4MQHr2qMbdIXtPCravhlt/T7ceJOJKXoy3FwdLcmzvDFtprYGh9PR5HwJtMgjKUrBmEw EUYoD/WXwBIe9EW6mfoiXZ4N5xn3fRnaQomWfhuPv33qP774vb0zf+VPzHH2Im6LOLRdObHDAxEM 5qlwvivDiRfRl+a8SIxkKIHXMLR9UL0KuoNagAYWC4eyKuJA2P6xmMowAoSgH4PFPDCBLRwQmgNk PJKJnRwnmEwBHAHiEVAHK0s/AutVyCSVu0DMFXYUBY5nAz/uBs5sIv3YjlGegTcGJ91BioQgesEg PgLzV+6SJKGchoE7cySRcT1QzOvPYoky8AJCFdzsjGcuSnLkxaNgFoMwE08zQg6hMiWQnUUAj+pU xUSi1pwCJBpVczyqyHMtCEUkwQ8A7YGoWv051igckJ2ioWOuTEeMjkYQWAsI6IbBLPSBoSRENxBR UBXRrP9YOjHuoH6DYAzBhgo5ge96qEe0zrkF5Ox+cChJAxVFJEAaBH4QgxsitYtemWYRoO6JaGSP x7wvtdVADMgSu6Bn4ENchGIShHKp2iI+nsqBDYxqSqji3Yl9DNkC6K438DDQ7HEMoQcLIGq7Lmmu TIcJaocg12xshxwZuTLyhj6JMVS5CkgYobYDRCLESOSJ5jkhSQ4MyGD2eDkBjZPIkVED8fzxsfBy Yc5RnVDi1+kJFhcRGhL9kqSHhJiTISEdBaEbiUqahxXkndzgFUzbCpkMPNPS+dKXkElIdQY+QJsc Bl4qmHwSQ8YIezqF9LL7Y4k3lO5AGRc8c8rIjsXIjoCi9As2wajLotsVM9/VAmeichJOaXiaV6Ng jFlNbkMn2WKM1QNyJQGc2s6BPQTFIA/9gGOoPl9QFVhBwQIR5XiAQm2bYrPTtkSvs2k9NLqmaPbE brez32yYDVExenBdqYqHTWu7s2cJgOgabeuR6GwKo/1IfNBsN6rC/NJu1+z1eKcrmju7raYJe812 vbXXaLa3xAbgtTuWaDV3mhYQtTqEqkk1zR4S2zG79W24NDaarab1qMo3m1YbaIJwXWGIXaNrNet7 LaMrdve6u52eCTQaQLbdbG92gYu5Y4ISQKje2X3UbW5tW1VAsmCzyq2u0TB3jO4HVQHEOqByVxBI DaQEGsLcR+TettFqiY2m1bO6prGDsGidrXZnx+Sbnb12w7CanbbYMEEVY6NlKtlAlXrLaO5URcPY MbZQnYQJgil1MnNwRNgy22bXaFVFb9esN3EBdmx2zbpFkGB7sESLxK132j3zi3uwAXAJiyp/uG0S C1DAgP91kozUb4O6SMfqdK1UlIfNnlkVRrfZQ49sdjsgLvqzs0kRsAf2ROe1tbzoI9xbjA6AQmyt YMM0WkCwh2LABi/AQnSZTxw5jTG2dXKr0khlVNXOKkWtKgIQwls+JK7aoyUcS5BZdOqo6pYd2Hgc V1XppfIB0Q0nkSq97qGEChhhKQlCHmAxOfIiynQ4AieBOvNEZI+BGWBhFhEU1Ep7DGhRKmYhoXhy GE5DD1COQi+GYiLsGeyG3lf0MRzqY4o0EJkGyCUrDkr+UEZTOKW8Qzk+rgFsiGcZSeL5gyCcaNXJ fE68nrQKsRgScTeIeRAOa4Jz6rgu3Dqd9U8eLqcP4qoPEufpg3jWB4lz9kF8sQ/SRd4hSlFyZixp ULOGhV+kVxJJr8Rfj16JKz+8sF6Jq4S9UK/EL7FX4lmvJM7ZK/FCX3COXomf1CuJs/dKPNcr5dO3 0C7BeQ5F4rLaJa7bJXGhdokXxKXnxstumbgfiAu3TPxSWyauWyZx/paJz7dM4jwtE1/aMonnaZm4 ZezvvN9BsY3tc3VHPNP8It0RT7ojcZHuiOe7I3Gu7ogv7Y7ERbojDNZCoqSNDz+x8RHP0fjw0xsf cYbGh1PjU+wdPr6hiRP496hp4DX4qF3kbwbXaG53AO81mp259Fu9Gv1+dQp7xd8Wnv4XhmtH3oG3 5kGxelKbjqZrumKe5285fwvjjZeqZW5kc3RyZWFtCmVuZG9iagozMjQgMCBvYmoKNDE3NQplbmRv YmoKMzIyIDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VG b250IC9EZWphVnVTYW5zCi9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpIC9PcmRl cmluZyAoSWRlbnRpdHkpIC9TdXBwbGVtZW50IDAgPj4KL0ZvbnREZXNjcmlwdG9yIDMyMCAwIFIK L0NJRFRvR0lETWFwIC9JZGVudGl0eQovVyBbMCBbNTk1IDM1OCBdCl0KPj4KZW5kb2JqCjMyMyAw IG9iago8PCAvTGVuZ3RoIDM2OCA+PgpzdHJlYW0KL0NJREluaXQgL1Byb2NTZXQgZmluZHJlc291 cmNlIGJlZ2luCjEyIGRpY3QgYmVnaW4KYmVnaW5jbWFwCi9DSURTeXN0ZW1JbmZvIDw8IC9SZWdp c3RyeSAoQWRvYmUpIC9PcmRlcmluZyAoVUNTKSAvU3VwcGxlbWVudCAwID4+IGRlZgovQ01hcE5h bWUgL0Fkb2JlLUlkZW50aXR5LVVDUyBkZWYKL0NNYXBUeXBlIDIgZGVmCjEgYmVnaW5jb2Rlc3Bh Y2VyYW5nZQo8MDAwMD4gPEZGRkY+CmVuZGNvZGVzcGFjZXJhbmdlCjIgYmVnaW5iZnJhbmdlCjww MDAwPiA8MDAwMD4gPDAwMDA+CjwwMDAxPiA8MDAwMT4gPDIwMTE+CmVuZGJmcmFuZ2UKZW5kY21h cApDTWFwTmFtZSBjdXJyZW50ZGljdCAvQ01hcCBkZWZpbmVyZXNvdXJjZSBwb3AKZW5kCmVuZApl bmRzdHJlYW0KZW5kb2JqCjgyIDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAov QmFzZUZvbnQgL0RlamFWdVNhbnMKL0VuY29kaW5nIC9JZGVudGl0eS1ICi9EZXNjZW5kYW50Rm9u dHMgWzMyMiAwIFJdCi9Ub1VuaWNvZGUgMzIzIDAgUj4+CmVuZG9iagozMjUgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvUU5NQUFBK0RlamFWdVNhbnMtQm9sZAovRmxh Z3MgNCAKL0ZvbnRCQm94IFstMTA2OS4zMzU5MyAtNDE1LjAzOTA2MiAxOTc1LjA5NzY1IDExNzQu MzE2NDAgXQovSXRhbGljQW5nbGUgMCAKL0FzY2VudCA5MjguMjIyNjU2IAovRGVzY2VudCAtMjM1 LjgzOTg0MyAKL0NhcEhlaWdodCA5MjguMjIyNjU2IAovU3RlbVYgNDMuOTQ1MzEyNSAKL0ZvbnRG aWxlMiAzMjYgMCBSCj4+IGVuZG9iagozMjYgMCBvYmoKPDwKL0xlbmd0aDEgMTYxMTIgCi9MZW5n dGggMzI5IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztG11vG1n12km75ZZd tgusEIjlbmClFs06S8uuUAuIiTNJvHXsYE/S7ROMPdf2tPaMNTNOGh4Q4gUkkOABEB/ijTd+AEjs G7whXpAQL6B9WBC8IVZaCaSl5Zxz73zZTjZN0g8k4sa+c+d8f90zJy4rMcbOsa+xBcaa7eXLb736 vZ/Czrfhd6c/3O/d+9D6J2H9F/hdG0jH7b5Re5mxkgHXrwxg4/xnnvw6XLtw/YnBKL5z7mPsD3D9 TaQ6DLoO+zj7IFx/F67Pjpw7Y3aGvQeufwjXwndGMnzuJ0C79EvGPvcyKy1+v/w6QLAzV878CHaf U58Lf2S98jOMlc+fW1g4u1guL/6NVe79nr19j3/iy5eAEtvqWS4TTNy7d/YDdz9Q+vETo9KbX2al e6AZ/pRZ7+4PFntnfgZaPsHY+y88f+GF5y8831tk70QLH3nnr3d/8MRT/3orPHuJlVhQer38ZvkN tMf7ASYox//5dvmNu39GOiX1++tf/Pg3X3rfZ99mmnzhJ+FUYmfTPcB5YnT3o4w9ze517nUWe0Qp /1Ne/B3rLbRYAOsPgs0UrzIwKCcUZn4+XPp8uv/D0mW9LrHzpTf1uswWS//W6wX2dFno9SKs23p9 hr23/FW9PsveV/65Xp9jF8AKan2efXThRb1+8pmfXvyGXj/FPn3tO3r9NDt/7U96fYEtXnsLOJYW 0dcvEXdcl9izpd/qNehW+odeLzBRuqvXi0yUP6XXZ9iHyq5en2XPlb+l1+fYUvlXen2eXS3/U6+f fOHqwnW9fooNrr2g10+zZ6/9Rq8vsHPX/s6qYOkx22ch81ifDVgM0XORddkl+LzMXoLXFVh1AEKw FYCJWQS/IZPMYSNmwG6N+QBfgZXJhvASrJXSiuhKwqcEnF14dwGSH4HrKylXGzjtAq9bgOMDNMrh AM79cVyF1S3A22ETgOgCrEPUJGE4pJEAKj68jwGmA3Q9gBOAHwB3h+5xxqrBeD/0+oNYXOxeEpdf eumK6OyLFS+O4lA6I0PU/G5FmMOhaCFUJFoykuGudCt8BvUVRLWd3dGtwO+LFWdwAOKqvOXsTER3 4Ph9GQknlMLzxXjSGXpd4QYjx/NBsqKKbVIwgm2F3HZ8uFgBZYagElsJhu5BKCIDyyGLY6PskC8i sGBA9r0MHrkCL7Yjw8gLfHG5cuVKkXJC98Vpukj2xXmS9Ii4CoBYh2ciSy/wwZ4xuIdRkMTg4qts GV6uprELNCqAG8BnCG6XRC+kAKkAXQk4bBDH46vLyy4Q3Z1UomASdmUvCPuy4ku4vZaTIAmoJKhn UwfvYZBKCnQJOgZsD2AxrE8nWJHSOtzZB5gBYXpwb0x6xZQYaLWQMDCVkOrulCWn9ciScVJIxoO0 4fCap7sKCQdWeavNlgUOEXD8Fz9SqTn9Ajff35nOHtzhtIppB6NwRLa+DXsBeODdZEHNtojeiKhl yeWRTAO6J7VefeLia68b2u/KW4qbijEV7wbJFZD3fcIf6wRWHAKgGusY83QUOERDWZprmjFJMR1P XYLDOFTUEwoIrWRXsSwp/1XsLeWiZIk8h7gufUYkVxdwHK0fpyzoQoSOiEpMdxL79GA11Jl0MZUx 44A1DeWPIX5V9CPHzCa4M6ascYFDl7ATaVzSIKZY68DdmO4qHvwQDobO5i5INiEqyiZ7FAMDqkqx tsyI9vIaJTqEhahU0k7IhkbOO7gekT+Vr3mugkSAbRygh5HquUwVRBBllQ+KtqetWvT+4VonllPS jtOIjkmuLOoyjfbIHqMjcUiyoUdV3dcayhxHl96Rh0GfaIlbANElegom8V+PTiJV2RIPdYm3SxJ7 WtKrlJ22ls4BigFVhswH+VqUWWC2EvgAH+tsiAqwSa5kFsvXgDyeIJ0dkpxTbS7GmrKGOkucQ/wZ 0CkotO9H9JnVj6P4IqaTCE9WR2tUKVjqMFy0yb4+WxR3tHmPZHR1JA0pTsN0R0mKNnVzPs9HXXKC OnQielQzhnTFU41ckhT95ees0S+cq4pTUkMdih4VuwmPaftE76pTIiXXGmQR5pCPji5Bkc+0PebJ Zmh/DwnPO6Ca89Q7IdVZh+pKRjfZidKITPJl+vSQus5J0iLhtEdauYS/NOc8XEr1nsbgcC85bZdy UaZypj51vnQo34OcrBOdB0mc7MJdb47FJLtDdvZ1Jo/hpU4vhyqqTDHyflcyJzt8bqYMqMIL+oy0 jJIi6aA4SWrdvNrt0kngk9/z9ppnVZ6zXN6Hx83VSPfvQmuSZFuSSdg5DNPeI9QYRYpjiujb8N7X HlPnIUYVT6vqg6xUB2vV0TkS6/Owl1pqg1nEp8kacIV8mnBlsxvQR7boXg32BPRxLbizA1ersLtK fjHpDt5fomy8AWuk2GTbREvRaME70r4JO0hb0DVeXQf4BtBCXIu9RjwsoNYGyZqwRtqbsFuHT0vD IUYVdrbhGtfrDLtQxa8BWDblDuKhLEpSG/YzrkWpasQxkWwTrlpAf0PfNYF2jeih/Ab1R7huaDmV 5VpEHW2ElJFmFSSq0xXubsPnFsC1yZ4m6aykbZAOa3Bf6WKRBMoTSqIqfG4Bb4RYB7lssgJysjWk QX5EfVYJH7leJyglWVN7GdcZlYq2pZID7b+Tcm6T/nV4CdLfhh2bfGMC/YRuEjvrRAHl5mSNbdLP JDs0icMKwaEV0Z71NOJaOa9UyV7oN5R8lTiZZJH2XE0SannvzIsOnnJYJ/0sslSdoNtgRwvga+mO isca6VrVtlY0VdyrmKjnrFslHdGzXwSulo4pk2xX1AL9dIPkz7RQHjD1ezVns8z7De3dRB6bONtz rHKDctEiKJN83U5zZI3yd1NLvp1GWFYDtnV8NlPJivZN8iiBO0rtULQS3kUPrlI81bWE7dQaCoIf QlfVLgvOtS4958Rp3S6e3PmuMetG832nkau1+U5AVeF1gh1NwWW76mlJnVnZs06+d5v3hJ08Hate Pul6s+5D1W71TJTvel3qz1UPGKVdSUB9YJB2Jnt0NzvTx3p2EhSe85CzQ2e/kfJKzqKMluorHeoW kFs0x5oHn1B85slwTOe94rJH61h3JqjfRMPi/lemnoaT+c+sD8RcHyS6zOsc8vYPyd9j/SzlkYWx n6xouiFLnssym6AF1NxtNOX1LPqQ2lU2PVVAG/Rzkrtka87UDA95cqpXyYzr0U+dTnvA/TjNg3hh HjTdeT24eRCfOw8SD3kexI80Dyp28t2cTNmsI4E82gR13oSFP7K5kpiZK/H/z5Vyc6VswvC/OVfi hRP20c2V+JyntcdhrsTnzpUyjR7OXIkfMi94OHMlzu53rpT91ek050pZvhXnSgedvgdPl9Tzueok HrfpEmfF6dL86cbDmS7xQ6wrchZ8vKdMnGJstpt5+FMm/hhPmfjUlCl71n2YUyb+rlMm8dCmTPw+ pkzigU2ZONlgB6i+StIqa5tw/+HNjvhcnz+q2RGfmR2JRzY74gfOjrIZ0IOfHfH7mB0dRvfBzo6S ynrwiTI78eHHmPjkpzSnOfHhJ5r4zD6zHW/iw3MTn8PmDqcxoYln6H+BZZMGTnzwqsLYGn1BC7/X ht+MS79MJy5GUoqOHAZ7lyriCN+Cq4j14f54EAlvNA7CWLqiFwYjYYZyV38JLOFB37qbqG/d5dlw nnHfkaEjlGjpV/f4i4f+8Nkv+R35+4FiirMXcUfEoePKkRPeFkFvmgrnWzIceRF9h86LxECGEnj1 Q8cH1Q3QHdQCNLBY2JeGiAPh+PtiLMMIEIJODBbzwASO6ILQHCDjgUzs1O0GozGAI0A8AOpgZelH YL0lMsnSJSDmCieKgq7nAD/uBt3JSPqxE6M8PW8ITrqIFAlBtINevAfmX7pEkoRyHAbupCuJjOuB Yl5nEkuUgRcQDHBzdzhxUZI9Lx4EkxiEGXmaEXIIlSmB7CQCeFTHECOJWnMKkGhg5HgYyHM5CEUk wQ8A7YGoWv0p1igckB2joWOuTEeM9gYQWDMI6IbeJPSBoSRENxBRYIho0rkluzHuoH69YAjBhgp1 A9/1UI/oKuc2kHM6wa4kDVQUkQBpEPhBDG6I1C56ZZxFgLonooEzHPKO1FYDMSBLnIKegQ9xEYpR EMq5aot4fyx7DjCqKKGKd0fOPmQLoLtez8NAc4YxhB4sgKjjuqS5Mh0mqBOCXJOhE3Jk5MrI6/sk Rl/lKiBhhDpdIBIhRiJPNM0JSXJgQAZzhvMJaJxEjowaiOcP94WXC3OO6oQSv39PsLiI0JDolyQ9 JMScDAlpLwjdSCylebiEvJMbfAnTdolMBp6p63zpSMgkpDoBH6BNdgMvFUzeiSFjhDMeQ3o5naHE G0p3oIwLnjll4MRi4ERAUfoFm2DUZdHtionvaoEzUTkJpzQ8zKtRMMSsJrehkxwxxOoBuZIAjp3u bacPikEe+gHHUL2/oCqwgoIFIsphD4XasMRas2GLdnPNvmG2LFFri61Wc6e2aq2KJbMN10uGuFGz N5rbtgCIltmwb4rmmjAbN8X1WmPVENZrWy2r3ebNlqhtbtVrFuzVGtX69mqtsS5WAK/RtEW9tlmz gajdJFRNqma1kdim1apuwKW5UqvX7JsGX6vZDaAJwrWEKbbMll2rbtfNltjabm012xbQWAWyjVpj rQVcrE0LlABC1ebWzVZtfcM2AMmGTYPbLXPV2jRb1w0BxJqgcksQSAWkBBrC2kHk9oZZr4uVmt22 W5a5ibBonfVGc9Pia83txqpp15oNsWKBKuZK3VKygSrVulnbNMSquWmuozoJEwRT6mTm4IiwbjWs llk3RHvLqtZwAXastayqTZBge7BEncStNhtt64vbsAFwCQuD39iwiAUoYMK/KklG6jdAXaRjN1t2 KsqNWtsyhNmqtdEja60miIv+bK5RBGyDPdF5DS0v+gj3ZqMDoBBbK7hqmXUg2EYxYIMXYCG6rDtd OY4xtnVyq9JIZVTVToOiVhUBCOF1HxJX7dESjiXILDp1VHXLDmw8jg1Veql8QHTDSaRKr7sroQJG WEqCkAdYTPa8iDIdjsBRoM48ETlDYAZYmEUEBbXSGQJalIpZSCieHIbj0AOUvdCLoZgIZwK7ofcV fQyH+pgiDUSmAXLJioOSP5TRGE4pb1cO9ysAG+JZRpJ4fi8IR1p1Ml83vpq0CrHoE3E3iHkQ9iuC c+q4Ttw6HfX/R5xOH8RVHySO0wfxrA8Sx+yD+GwfpIt8lyhFyZkxp0HNGhZ+kl5JJL0Sfzx6Ja78 8MB6Ja4S9kS9Ej/FXolnvZI4Zq/EC33BMXolflCvJI7eK/Fcr5RP30K7BOc5FInTape4bpfEidol XhCXnhtPu2XifiBO3DLxU22ZuG6ZxPFbJj7dMonjtEx8bssk7qdl4ra5s/lqE8U2N47VHfFM85N0 RzzpjsRJuiOe747EsbojPrc7EifpjjBYC4mSNj78wMZH3Efjww9vfMQRGh9OjU+xd3j3hiZO4L9A TQOvwEflJP9ncJnmdrfhd5lmZy79Va9Cf18dw17xr4WH/w/D5T3vtrfsQbG6UxkPxsu6Yh7rP34y 9l8NdaTHZW5kc3RyZWFtCmVuZG9iagozMjkgMCBvYmoKNDE4MgplbmRvYmoKMzI3IDAgb2JqCjw8 IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VGb250IC9EZWphVnVTYW5z LUJvbGQKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVu dGl0eSkgL1N1cHBsZW1lbnQgMCA+PgovRm9udERlc2NyaXB0b3IgMzI1IDAgUgovQ0lEVG9HSURN YXAgL0lkZW50aXR5Ci9XIFswIFs1OTUgNDEyIF0KXQo+PgplbmRvYmoKMzI4IDAgb2JqCjw8IC9M ZW5ndGggMzY4ID4+CnN0cmVhbQovQ0lESW5pdCAvUHJvY1NldCBmaW5kcmVzb3VyY2UgYmVnaW4K MTIgZGljdCBiZWdpbgpiZWdpbmNtYXAKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9i ZSkgL09yZGVyaW5nIChVQ1MpIC9TdXBwbGVtZW50IDAgPj4gZGVmCi9DTWFwTmFtZSAvQWRvYmUt SWRlbnRpdHktVUNTIGRlZgovQ01hcFR5cGUgMiBkZWYKMSBiZWdpbmNvZGVzcGFjZXJhbmdlCjww MDAwPiA8RkZGRj4KZW5kY29kZXNwYWNlcmFuZ2UKMiBiZWdpbmJmcmFuZ2UKPDAwMDA+IDwwMDAw PiA8MDAwMD4KPDAwMDE+IDwwMDAxPiA8MjAxMT4KZW5kYmZyYW5nZQplbmRjbWFwCkNNYXBOYW1l IGN1cnJlbnRkaWN0IC9DTWFwIGRlZmluZXJlc291cmNlIHBvcAplbmQKZW5kCmVuZHN0cmVhbQpl bmRvYmoKMjQgMCBvYmoKPDwgL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUwCi9CYXNlRm9udCAv RGVqYVZ1U2Fucy1Cb2xkCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsz MjcgMCBSXQovVG9Vbmljb2RlIDMyOCAwIFI+PgplbmRvYmoKMzMwIDAgb2JqCjw8IC9UeXBlIC9G b250RGVzY3JpcHRvcgovRm9udE5hbWUgL1FTTUFBQStOaW1idXNTYW5MLUJvbGQKL0ZsYWdzIDQg Ci9Gb250QkJveCBbLTE3MyAtMzA3IDEwOTcgOTc5IF0KL0l0YWxpY0FuZ2xlIDAgCi9Bc2NlbnQg OTc5IAovRGVzY2VudCAtMzA3IAovQ2FwSGVpZ2h0IDk3OSAKL1N0ZW1WIDY5IAovRm9udEZpbGUy IDMzMSAwIFIKPj4gZW5kb2JqCjMzMSAwIG9iago8PAovTGVuZ3RoMSA2NDY4IAovTGVuZ3RoIDMz NCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicfVgJfFN1nv//3ntJ2nI2bRJK W9qQNgFKjzRX09Ar9KZnep/0ogf0oqGtoTeIBSuXIMWRozqgUFlkGHQGQRTdWdZRRhmmy/hhXE8G 3V3dcZfVGdq8zu//kgq67r6Xl/e//7/z+/v9HwFCiIQkEoZENbU6Gk8s776ALf2EyBKbN9Q2bBjM 0GD5MrYZm7HBq93DivV7WA9pbtvyCKeT/jch8iVY/7y1o772wO7DV7A+g/UtbbWPdJI4kkSIohPr we21bRuWv6FXY30fIXAB9zQQIpoQTSEFXtjiowS8ffDHMXWwxjnDn3F+BbENcJvvewvC+Zuiqfth EA6ESSdALLM3uJVcA9HhTDVeKjFeMl+5Qo6XQiSXy8RilVitUas1SjmnizYZjSa9JlStNumNpmgF 58UkD7zUsel0T1xQ0IJlGvNKKDaEweb6mBJ/xRIP/q4YPJx3+uJS4AP+KUsYU5b9Lst8XbKr1gC6 2tFCc2XwIoVMPm+j98pgvRlkPosiVv/q1brovYVTSS3equXhMfAUQQ7DkUodUqkiq5FOo9GgpxSp NW5i5XJdtBEJUyKtywVaTUadnPKg4LQAS3xiLx20OV7bkZK8/XJv1YnHavz4OwGbc+JrlsmkDLf0 dWOF0kcmgve8ZfNshyzjg2EABUf+9fHH/nAgR1v9aMHadG1kQGnulRnQrgrKNKHURpCob5GeRYT4 eCu99bpoucKbyk5iGIGgGdmKQD+vDRMRnG36LJM1I+JAxcDWzg9wZuDs+0yzqIEokA8VTlXJdN5M qNxoMojFGjGK1VvHNB/nP9m9mwH/8HyNbNnCwNBlzHHOAiv5W1ecpfw0wLz5b3MsgJcmgylH6ezC tU6h/lm0AAJKb+GGU/wnEEQfSoVoapbKMR3luBvp9iFoj/Aj6VH1SwS10w4UpFpt0GMH0zz89p6M jD3vDA/+895sgMzd7w7F1qSEAqhTasyWmpSQkJQargHyD/9xdOyD8dzc8T+Mjv3pZ3l/Bn3V9vzc karo6OrteTkj1XqX5LhqpEDqkhxuK5fhG1W23CU86Nv0a/y/eq5zYo0gv8N13QzzG2cxc+dX16C0 fAIJJ4dxlXPIsecDfpHjd5jdTjtzZ/oL0DHbgYANyP0w5DoGudbinitIDCHUdOl2wawSeTPqotHA JZRhCf4rfBVUGiaxXKEEQQYGtdFkogNNnFYdAHDnIz7RD3w5v8gM4/OwVL5IEWzR2U8+Bznax9Zd HIcFMjDxz0N327p8yCqrCwhR+C5UBa8JYxpPTwI/sipW5d0RGD7fw8vDS+IbeObAvsJo47GwCDlc HnwsNSEh1UfKeUg8JchjHyHiw4LNu2wMJYVG9lDBJTPhH0XXB0GN1ekF8P2Lufh885GEVUeaovI3 JrskucEOkG11Bj0osQuf/SWTW5hTCFKTbRfuiggiVnI2Mp8QRBGWpT+EEh/uLsTyt049z39y6hx/ C2JA/YuTnG3mPiumz/RZdv7MPaoZB2qmDjUzDyuCWkyIRvg7TC2xCzwgj28DB/8qc4LVIgxtHOD9 mHPwHPUMNNARnCl4hkFNmTSoBe5kMuolSvSMkUnIlYbJVqWsWLBv7JlnIGiSs7QVAbDMLYYB2DX2 2JWZ7ewA6jx/9j3RX0RfE38SSS2dE1SsEFPrlodygkYNagahgv0Ji2eDjs2Sal22yR/A35Stex0S IO5qVLZxGbTV1/NHq8dbzQCWtvGK6vG22Ni2cdHX0Nxo2n5wwlb07MER/Q2GuaEbPng0/yUIb29p 5P8GGWNvOrZc3pmevuuN3u43dmYiv72z73OFKGkflDQyRwkQm7DgK9chHMi4Qv4TpqpIdxH4T17/ ZcdEHGdzZjWULINrzLUZ/tfXoLhqO66Cvs8VotSWzlkJ9SgK3tSr9BqXjXjvgqAgS350tdZz3gII 2qwdTt143ELjAHM4Is+MClq7yD9M76xk7lyvXhEGZWWMCteOw7WDRO+QldTLBB9wic2NvBKxQmlw WaOveM6JlJyf8+n5IfHN+VWDmUpI2/ZKl/3cRdQQSDc1rG+DgJwne6v6szUs+ycg/tGWXEtyd/vW dS2nHUkA1ktfSJWRW3cA9LVZ1lf3FiY8MvxMPVKyHSl4BcIQ4QR/h1f466CDMH4KNR2LclQhlTIS LWCaRMwoFlM3RikavQUdS+SueCZz06miMULQNHLERPZctSbEQVPiuyM9ryf3gU5nfXfIVBTg5T1f LPFaIFlaFmc3KOQiz4WeS8pF70BNeSH/6Q1++GRLO1RVn4BD/wS+Rc3td2GNyS+/7dGMhJ6mHJl1 LXRETh1M2Loxb4k1lWKvBemsRE3JySrUuFJw4IejLaVXMEbZj4wxjsK48anGhsnBlHhz7K56feNT xm+MJYkhEJJYqjeVJyqVieWiKefXtlwoP/6HAftUXn7aEsgpYDnQVY/kZPVXRGkrhrKzhqpomCcG OMXUMZfnpMnUOW8y4cxl/j+wb4wQViw6I0QSGp4YkQzuQtCVFH4n++WMQnSGd8LryI0DufmZ4K2r BMszyOUmdxTRqNVus/N54Ftz3DggKPpQS/2pgXSABFNgTkW9tvmQ7ht9aVIIQEhSqb6j1sXN/bDN BTlQemxqqHPKtiIpYink2hipcwJ0VUNZ2YOVWhgbyV/XXyFwlIIIH+7CSpgzT1b8cF5APUFP1W0y YlIQ7pnRd7pp4M3fAqTsuNrf8MJg9jz+64Ca/I6tEOi/pCKhuNqPudAw0WkByPszf2fXHw9kWzom GjZVAbx8IndMFx4FUN2KO1tnb4gWI85QMoSkRPMAaFCrEldGgqmTUqBEjwME+VBKaHpyW2fIuTcx enP/OoCIhme7boxvA+b4E0dflPBTC2ENBO/75HgBRO753ZcFHQkIRzsdTx7z5BY2HoizlQDE90y2 ljxaY5WtDGgoq2kedHwzk9R3wV6y86kV4QtV4ZaVRfUAvV1I5yjiugH1hbhO4ViIl4IrvQoL0JU8 QMdr+fv8f/GYmHFj0930EU1NV3InMITi/HLksw/5XCVIWKMOoXwyMl/pQzKWUJs1CW4VLZi0QtTt ERFZwt97YcJ5vqryF/ePPv75yVpPfmrxi3vLn6jVga5hX2Xe8GqFfJEHe7t6LL7LAdB2nf/o5Zf5 j97ZlLX/d9v2P0011Nf35s50zPuCTOE0TJBe3srR2OhHwt0ZwJz56dUPGaDiJ9wJDtFIpBtHG+xP A2lQmH9gdkWdtmVc942xLCEEQpNK9EaXS3G2v/2FSaoqhZKjt4bM9o01GnUC2mFFhdnlVoMVWm3F cG7WcKUOJSTl47kcxHN/pIgGTZlMABu1Roa0yd3gaQJWc+ce/49wBPwzs7yVS5dFLvUzF64IDFep pHANI+ptNnR6hBGvXJsFIPK8JRLha9HiecrI1GiRwHsqn4Rxg2Yza3An2QMQESAEt5hjWKMUgIXu a/IW/TDMmdQUWZKTDlU1vNC/NqH3habIvMz0lRCaWK4vaF7M3zLEJF0evv9uGjjv6yuS1ZjrJVea 9EVx1GriiznbZG0FlD/3wfC2m+P5sCg0PvKQPj8uKCkxsX610QBw9HA91/shGNePZGUNlEZFlQ5k YQJoIC6EEWW6cjcBBQX1cQo0wOvOcygZnWhqxoP96/0wzsOVFXBvC2eb7zM91hdeni4EHMlNAZkl 02GuOOjOgV0RQsh+KYq4ck648FDfBRo93H30/KPE6IGZIQgi+h6wqPjmjBs9+0Hgw7gnUwr6FEKf SgWXQ6OWB/qmYyISbM6NeHcB/2XK8IXN9ks70mHL1vpKSHKcbhm8Fl/MgBd4zfetTCyuAsx7dmFY FHFye542PzYIPm1/qS8poe/F1sGza+IPNJQ/2RQDUJi76Q0/c0pAhAmgvvw21b8WJRKOCO1FFrjO ECCjYtGFKoELH+fPOr9iUiFonM/kd0AfE8kOzIx+w18B61dMG/L7DPqxxZ1lefvSIwfNOcRyIe+l PBm8OY/de598AlBIaevyP3989LPCzDTUyfzRRwEeHWXvzcwfvGjNzM7OtF4cZO/hmggQ7BW0fCEb l1F6DEpgz8ycAN75IXvA+R6DZ5AvnAN37zI0kJPi2fdF5xBL3L7rCsmCg6oF7KA6ULqEzc1hDAZH hU50zjkJheKQYPPxsuoj9jgwtz1T92zTslW+oFzcdPrj0Z/z373R1HRp9umDHxSH/ppVzZL4Uk1K ZtbYG92PvL4jDcoDEs1dFx9NBeh6n//07Iv8p7+3g33wN5Sq51CuvDtz/f5MgdKdYt5xGlhu+m2u cubWg3MFUF2cQFveiHNChNxDGY0ZhkTsKxPQX2mgbiZcGiNN1tUquqC3kmKjQmBaA7egpq4KU1fO 03cRZIQsA4abp46PWT4DscaGyzMfITTbE1MDjACBfn4ZiUxecaXviqBob0NmTORSkzRGaxvc3xgW 4L0epKVHzI33w9g82OEtj2oyFeAZAShfJrRwFdpLCKWQHnpMgolLhLD0g8MfhUwfJYb5v44AI69Z 29YHTP+m9Y0cfwdSh8622q+OIShZHScb0nrjI5lS0ZmZWwYzME/u2LYXKspqj3auWTd2tbfjVzsy YVUERFIJHUEJLRbijkyQkDtFmJMEZmQaeA+GGk/2JAJ896WzDTkOcvT0OBjf5G0X7R9/DciTL1zt 3NzVAbheEnKjQX8NJ/GuWK9x+yTFQMGMFT/gx5220oDE/iDPx3Zu4bwlsgWW13p3Tq1VRgTOB21M 4tT21nMjaRhZO56pKhtNQiQXi33tpcm2gLc3dDOgjMuP0FFvLbVxdcnWFbIcjMJb2ozdO5+ru3S/ qKkD1u1565GmswPJsCYlxqoOWlLfBnHJvIPZ7VhTm6EOTa2xONrw8M2SU7OzokIhHwymGbZOKXeH iDmwQc5UePYSqFZRcblLp5iJoVeSlQaNDPoG2tdDWoL1dLezEQWX09IB0NHCn4eODjzg2Tv4/WAw +2cUlUe0n1+XvG999lOxMYZZAiW2giKwOc9CffX6OoqCaPtmtBGfOY/8Pp03SqVSE2eeYZibyyvW 58g0lnDVAlB6pAy8NiI6M0tC+/aORuYdfeFq1ySYQAOaI1Trx1DrduRtEXKHnEVTHUhNQi6uoslH CCsNPcakFT7xD5ml1ZhJlWZ+Num8iBz4QgUAf9InobIZNC+dgdDWsoLpMHYKeB9eDii1CNS/AfW/ HDOuBOFbkGlO23MmQI/xDyE3RD/IQTX0xO+yA4lgA2yqapV3WDRAWv/phqbJwWSoqB/ohIxdr9m7 Lj++Drr4zoi8EkbA9boegJLcaGbjVobp37ixFxysQrrUe2V/RuG+FkwULRv3FzXviU4+P9Qy2W+1 9k+2DJ1nFgdmFa1K0/lDS0lBVqDzKjNi39QH0N/eOUxg9iY/wE3MetHIJELk5Camddz1b3ejBM2z 7wlxaQX9uufj9tO585fmR5++qAikGnRoHxerLt5ymLW9EzVjv08KWB0kBZ029ca2jgvbUuLtx+tN tSHSUBV8k10tutjci2ZdVtewGTrAVrSnydzVETU0/kLZse9s3Y8ArNt5afPmV3ek+y+dr17B18E6 K7uXOTgcV98CsGdoaL87Rmci/ovnvhkAcx0G+Bsf/yd/A7ZjTnOLXTl9lmKREkem48h5QhZKR9Jv C0rmFjTzp85f4E/hex+UXr4EpXgiCUVDznHedt6EUv6UO3OwPvxtwXVzC0HP/9Z5nkZ15nknPQnd YCLxbPs8zmlk3wL6VUEkWLaPzgdG+Ds2e7Foiv+W/yt4UKqEJyz6TVi/aM3/EIJtP7pQT/Hiwxix gPLovnAOe5O/Tojn4zjiF+LDwkoPX2YO/0TXiIGzEws+4WwgGWEmSSBjJru4z0g6PiNYJvg+jP1m SSDpE5uJF5YddByWbdjXi88ubIvDsduFtT4jFuyn645h2YHvVFExsYonySjuVy7MsRMpvlOxTscI e+Iz4qZFi+1HkL4w3KMY5z6H9RPYbsLyEXxbsX6KjsX3MXxHcvbZm5RGfALxUdJ14S5pFDhdRjaT i+RfMDbKoBgceO+Df2fUTCpTzzzO3GZ4djW7mR1ib3JLODUXy41wV0RSUbTIIXpL9J24RNwu3ibe Jz4m/k4ilyRKSiU/l7zmscgjx6PH47an0jPDs8fzQ89/80r0KvLa4rXHa0KQtJkkUr9xaeJ/XSJi xV6Mq9gtJcRdBrIUa64yQxbCaneZw/ZYd1lMlkEhWUs6SCdxkC7SQppIM9mCKF1JotAbo0gRsZES d02L2U8YWf2T47VII72DSR32/H/zg0ky2UDswtx2rKndLT34tAort2GpHVe1YM9a9z6teLeQemxp wpIDRzXjGsGkljTgvQGfuZ2Lsa0VWzZhOVWY2YKjO3HlnofoWvs9TcGYz0ThrcU46yoZSA7OacP1 uoU9CnDFdqGUhdxsQAq6cdVapOv/Hvdwj6s9C9e3IhWtpOHviFEsQmVuZHN0cmVhbQplbmRvYmoK MzM0IDAgb2JqCjQ4NDgKZW5kb2JqCjMzMiAwIG9iago8PCAvVHlwZSAvRm9udAovU3VidHlwZSAv Q0lERm9udFR5cGUyCi9CYXNlRm9udCAvTmltYnVzU2FuTC1Cb2xkCi9DSURTeXN0ZW1JbmZvIDw8 IC9SZWdpc3RyeSAoQWRvYmUpIC9PcmRlcmluZyAoSWRlbnRpdHkpIC9TdXBwbGVtZW50IDAgPj4K L0ZvbnREZXNjcmlwdG9yIDMzMCAwIFIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovVyBbMCBbNDk2 IDcxNiA1NTIgNTUyIDM4NiAzMzAgMjc2IDYwNiA2MDYgMjc2IDYwNiA1NTIgODgyIDc3MiA1NTIg MzMwIDc3MiA2MDYgNjA2IDU1MiAyNzYgNTUyIDYwNiAzMzAgNTUyIDYwNiA1NTIgNjYyIDgyNiA3 MTYgNjA2IDU1MiA2MDYgNzE2IDYwNiAyNzYgMjc2IDU1MiA1NTIgNzE2IDQ5NiA3NzIgNjYyIDcx NiA1NTIgNjYyIDU1MiA3MTYgNTUyIDcxNiA1NTIgNTUyIDU1MiA1NTIgNTUyIDcxNiAyMzYgXQpd Cj4+CmVuZG9iagozMzMgMCBvYmoKPDwgL0xlbmd0aCA3NTYgPj4Kc3RyZWFtCi9DSURJbml0IC9Q cm9jU2V0IGZpbmRyZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAovQ0lEU3lz dGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBsZW1lbnQg MCA+PiBkZWYKL0NNYXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlwZSAyIGRl ZgoxIGJlZ2luY29kZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2VyYW5nZQoy IGJlZ2luYmZyYW5nZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwMzg+IFs8MDA0MT4g PDAwNzM+IDwwMDY1PiA8MDA3Mj4gPDAwNzQ+IDwwMDY5PiA8MDA2Rj4gPDAwNkU+IDwwMDIwPiA8 MDA0Nj4gPDAwNjE+IDwwMDZEPiA8MDA3Nz4gPDAwNkI+IDwwMDY2PiA8MDA0Rj4gPDAwNzU+IDww MDY4PiA8MDAzMj4gPDAwMkU+IDwwMDMwPiA8MDA2ND4gPDAwMkQ+IDwwMDMxPiA8MDA2Mj4gPDAw NjM+IDwwMDUzPiA8MDA0RD4gPDAwNDM+IDwwMDcwPiA8MDA3OT4gPDAwNjc+IDwwMDRFPiA8MDA1 ND4gPDAwNkM+IDwwMDQ5PiA8MDAzMz4gPDAwMzQ+IDwwMDU1PiA8MDA3QT4gPDAwNDc+IDwwMDQ1 PiA8MDA1Mj4gPDAwMzU+IDwwMDUwPiA8MDAzNj4gPDAwNDI+IDwwMDM3PiA8MDA0ND4gPDAwMzg+ IDwwMDVGPiA8MDAzOT4gPDAwNzY+IDwwMDc4PiA8MDA0OD4gPDAwMjc+IF0KZW5kYmZyYW5nZQpl bmRjbWFwCkNNYXBOYW1lIGN1cnJlbnRkaWN0IC9DTWFwIGRlZmluZXJlc291cmNlIHBvcAplbmQK ZW5kCmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8PCAvVHlwZSAvRm9udAovU3VidHlwZSAvVHlw ZTAKL0Jhc2VGb250IC9OaW1idXNTYW5MLUJvbGQKL0VuY29kaW5nIC9JZGVudGl0eS1ICi9EZXNj ZW5kYW50Rm9udHMgWzMzMiAwIFJdCi9Ub1VuaWNvZGUgMzMzIDAgUj4+CmVuZG9iagozMzUgMCBv YmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvUVhNQUFBK0xpYmVyYXRpb25N b25vCi9GbGFncyA0IAovRm9udEJCb3ggWy0yNC40MTQwNjI1IC0zMDAuMjkyOTY4IDYwOC44ODY3 MTggODMyLjUxOTUzMSBdCi9JdGFsaWNBbmdsZSAwIAovQXNjZW50IDgzMi41MTk1MzEgCi9EZXNj ZW50IC0zMDAuMjkyOTY4IAovQ2FwSGVpZ2h0IDgzMi41MTk1MzEgCi9TdGVtViA0MS4wMTU2MjUw IAovRm9udEZpbGUyIDMzNiAwIFIKPj4gZW5kb2JqCjMzNiAwIG9iago8PAovTGVuZ3RoMSAxMjA2 OCAKL0xlbmd0aCAzMzkgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nKV6CXwc 5ZVnfVXV3Wqp1Xf1fVTf933p7kNq2ZKt25Zt+ZSl1mHZki21MQaDwZjTYDCQMBzLHcDgAWYCIcxw hSQTmJiEkJ/n3F1IyE42A9llM2Q4bJXnVXW1LMuE2Um6/Lm/qv6u997/nSUMYRhWg12DERjWNxSJ f+E90ABPboW2Y3L3wYl/nBs5BP2PMczx7lRpdHzs/S4zhjlfgWfpKXhQdxUegPtP4d45tad8ef4p 324Mc+kwDEl2z42NuqyhMoa5nfD7TXtGL9+LdWF3w/0puKdnR/eUDn746y/h/jQcYj1GkO+gOzAB ViO4T5CAFcyVb2IUm8CVNQJcRIpxXICT5MMY/lwOu/wsxn9i+aF2LIfZzuLkr5mrcbfwJD65A8Me ev/vMYxsEhTZ3TCE4VgHhuHjAtgJE2FYQmFTuGwKWwdOM070Z8yUYP2Xz3SQ78C4R2HevTBPi8HJ bcihcChsca2Gu9QiIXchImmD2fFMmr2IV5k7/8/r6JeXj2xsbbKakErtD+Tym9EdnzPvMp8g3WBT xmlTyPDs4vcERb0hGu8obmhrbUukXG7Z4jPEO+8zfrXKYQuFYPej5z8mO8leLI61AxeElX0TmspG GW1le6HD7nGzV8Zd+SHBH5CiED9CZHNXhqACUqvcrqbMmkwk5HYa9JIHFVZbMrW2Z7I8sqUta3Mg 5HN3FDZt2HFky0hjo0HPuCKxRCBoshD4arHe6PLE4uiz4c7ViZTRjKR1Woq2OEOhUMTh1uiczlWd u3fddv/MrnzObPL71/RMzxzWofdQvczlbsuPbstm3S6FHEjBbgC+bhGcxsSAERtlSwH/Ujb8A3To nB89wbyPzhw/fpx8/jiMLDAbyJvJJgzQZVtOcIplBcvzDEogDS+SNM8aVQL/ntvji8abW3odJotV pdMpelcVo0rG/waqqVXIZTJJLUFIauVShUxy7rWdvf3pRpMFRzU3EghvbjoSIyOLVxs9PpfHStfU 0ha30+cx49eCTG6Hk5e4k9cvP7snlaDw3/Dn/x76t7feAgoIy/H33niDpffbMEsPkswAFYpkRRgO e4UcLYAqmXJzV0LNAgtkl6iSUhWmghiXK00Wry/SDFjxaLToBRzHn8YRjiNCZ7MG/alk+2A+Fwxo NfhLfak4bZFINFp/sDU7sHgbMWR3Ox02nbZGoNEaLSarKuxxmfTyemBdKLKqa3wxArQdB15byDWg m9Ms3irH9GSqnGavlOPrUJdI8sMSQgouLdAGWqJaQTClvhjJ+OTm9mIsbqEl35U3ZbY2REI2q0qO cLXJ6vVnGlZNrF4djqi1CGmpaLhn7eze9YNhAghHIKtngAnQ2zVj1+k8vlgy2RGNW2kZfGhLPFpI JuM+j0HHbATcO+3xWIt+jdenkHtcLS3Db4J0TRa50kZ3tJfGbzoyObGq6HYlU6M62mI2qlWkmNKa LU63+9zffDhfJt7d298Xj2o1Gm0s3tu/d39vXziiUrNnivauxXhbsR1shRpzsNzj2WRjTQaPTxEw wuFQVOkmtyOTpaVtZMsVzK9fR6cPbdva1kpb3xgceuzfmYG2Zp9brSL+Yv3a3pYWp3ORERRhdDLd tWbboUJu8bdIq3a7EnHY9/D5j8ibAFtd2HZAJCsoCjb28PLxVAXGPkjxwspkUitkIvKkL8iRUoCE XEsi50cIWWCSPcBaqYN2uBJOt0YrkRBCs80RCDY2dT3U1w/GI58dGlj3cb3UaPYFMnGv32RWqgWv iM3GeKxnzcyPJsYpavGfBttafV61Cr3WkG4MhExmFArM4YjcW0MKkFRiNvq86ZQvAMJRoOH19+zq bPe6FVKcbG6PhC0mWb2oRqW2OeKKXDrpdWuprdufZ8L9Xp+QtkYjzU2pTSQurNHpQpE1Q7E4q32/ A8lQwKEQ3LBUL1c8nkuJqgmpKh73gKQiiVTruvaOUERrQC8IRaIasVj4jKhGWCMSkITASFuCvubG oUwm7Se+KRKRyO5obO7t3ciQ+KuZ5sZUwufV66w07bA5TK2JmNMORJMCEZzptfOfEF8I1rFYUaUS KvBBlE0hXGbeqWWKllK89nTT5eh5ph8FfTs9QZ/P47DrtHZgfCKRfnRggDh1HBmYfzm+WO53uZGA EJAioeBmOK4IWFps/wb+EMuHfeBPLhOMYHm4qepgVcorvUkqebE30YrcFyMGNalVAX8htzWbiIFx NGkeMnt9Tc1reydum5gqFK022tpeKI0fG+9Z25DxuAxPyfUGpzsSb96UzXt9KjV+8uj4ROcqhxMU 1wNU5FflOxJpK52Ibd185NoHn7j28KbhSMhoDkVa2vL5cDDgsFOU3VHoGCuxtIDKkdeAtoH/RqyK pWwU/sPXmCKZJE+e3UCefOABVievBd3oAslrWcuLeI/t4C1bBq/YV6KqC8IV9onnDdllc7RlR7bs m90w0pq1g4+85qrffHrgslcorcubTOXymQa3j9LqND5PKtmYa0z7vGCDLbdPzRRXgUd12FYVZ6Zv R9rbjqFjtzK/vmpoIB4DHKioWHxw6IqrBwGlKrVaGY8NDbKUfcx7mDo24hABbQkFuDhE3MncefSF F9A//5zpQj9B/7aTmROcPjeK1zORxXvYeX0g3SmQbmkZpXbefi8nJ8ULcvlVlXZ17JK0PSts9vKL nLLSbfkdY9f/65HrnC9LdDq/r61leHVLU9Cv0yGrPZkqdLTHE8lwxOuz0HKF05nNDq8vLQwNNGYc dvUrdZTW7ool2vvTaZu9XmbUR4JtLcVMQyaVCAXsNLBoHiKNZMpk3rL5OVdDMGy1KZXSerMpHMp2 BgNmk1KurJfVUyqj3uNKxDp2FNtDAZiFVBqvr6Wtzxb3eY1GaT2SK0xmjyfU4nLrDDKFQipTqCnW lWYaWL5BVEjeCBGGBvjt+IpgAiXwH59h+v4WSUS1NXW1YpFIUAffdbU1SP022bSY01pou8NCUxRt tdloixZ/E1ZlkdcAyGsE/a5a3eWqtOT9hcuks6SEPEKPoGBgVefIyPbR3rUsz6RvKLL5/cNNLXan TIGQQua0tzQO717VqXxNbHc0NPb1j92ybbSpxWjELY/tnsnnjHqkN/hDTS3t0s2ppNGcSK/tHS/1 9mcaTOZUclbS0ZoNR8D+Bv093VMTwA1cxWzAXwb0EaxeJRS46glmg2j/58dYTkHETu4CnYOoPgFh T9WxpKo2hDVi/w29pI7EWnOdqwpdXZ3Z1ljU8AQaPUEs+uwuPXAf3a2Q0xa/P3527QlYE/UzG4j9 sJ/tAmpFDp71qZXWmdhPaQLB9uLmN3YUi8EAhLhwWyzueGNzsZ29xdUnDl29UN49t/eyfXPlhSsO HrvpyoPlhX1zB/btnt1XvvIq1ibcAlGOgezGEtgQ7Llk9y8NXRwKNrpJZpZ7UIU8k0Z/QDeqCoYr Com4z01bdDgfpTxXiVJeRGy4hhsstNcfS+Z+vG37zh04GAK1y51I5yByMdP1Mmm91RKNFpuAeA/o WDeqhTDO7gzrzUaDTikna1VquyMaL5xNo5f0FpPRbE54vHpjvRSBfdEg3R3HFz+4rL8vEqZUIPtk um9wz0zvQDJlhJAmHhteD3J8GbBpBcSzNlGx4vApEDpLvRouBxeUgqF0rMBlSoH2SGpN+qA/m03F 3U61iift6QqhhMEKJCZTnZtzeb9fpQYtGexPpq22eqmWgkmtg/jCuT93ON02h1YnIrUas8lioqIu j95UL4OQKhLqXlXCf8Zi7kmwak6ISTcsi6mqoc1Ky5ZJXmzVuNh0pUUDNyJcYcecyGTNNAwMTW3v 7mlocnmUD0nApDjjscameMzpZBlpDARb2jrzbVk2TkVoZtfbfcUimFKn9NEajdbm8PnDv4eDezzp dD7X2d6UcTtRqqelzRfUaKUS2pKK91gbrHa5khSKRRqV3RqL0RaKkknVcgruErHeu4YGEWRKVjoW L6qDZpNCLhTeEzGaVWqJTK5Qa+yOdAOgFz7kac7vGcBeETaCNVlLiKwmfISNrL1l8Z2bf4CYf0S/ X/x/0npZbb1IDKGHuFYikUruQT9FVzNHBMUv/5r4K5cXogmTvl5iNNkdHo+L2QR62YveJa7G93J2 AHwr6sWj6N2HHwaJlLH7yA3k05gQwzIphFKIKhMj554gPrzvXjSHZu9jtr0Do+6Ac7aAN2phbUXV lC7T6UsCz6VMp2oFuMSVuiPQtWpoYGigowBAouzOaLwpHY7aHRqt8Lti2tqYGeifmV432NJIWwPB QsfgUE9vLm/Ff75/x9BA9+pCIZ/tKHS3sN4CeCCzWAPhJsWajvZEzGJCOl04UuzcuL1vYHVXLp/L Z/Odd2IXU6gC8hBL4YdA4Qje/A569D7mTubEvey4awCba4DGTSs87iXYrOLSkVoK75K8/Vged19E PlVF5xor3dK2cWThuk0jTc0ms/ivRBD6OxtS3Tf1roV4M5FqbotP7Iw3pCMhoKnQceRAV7fkxVqf t62lv2/TZcPr0mmDXql2uNONXYPZ1oBPS6H5Lau6Y3Gj0WbNJDvbuxUN4QgNzjXbdkV7OGTUS2rR A5Ddm42hQG5XSxNqbZuVbi12REJajckciebyXQ3xlD8IiRYptlgCoWQKkDnJxS1FrJbNjCsxGUoo EsA+G3HyhcV5/MofvcLcwUjQpygLKXL2VuKKczcdJ9oX17BWuQS8nABeGtlMf6WmV/MW1g8Q8grO FXiFueQEMKHQvm3H5dds3wGip5HDns+Nbrvqs6NH3+7rv+eB3l7U33fvY91d+Mlnj1y3cSQQioQ3 bzx65MlTR64dXh8MoFPPMk8j6dEjCB05yvyO+d0tt9x6DKTL5nM/BnpWxmEfMfrHXn8db/kFU4MX 8atPMgFBcXE7/sjiD859xqLiTZjXCvPELBfYqB44QaFr8ccXt7xOXEmeZJQPLn4oKD5QQdoLgLQH 2T34KFbBOlH8ubsgZX3qLvQUvoNZh07diU4x6+6E8fPApU0V76yFw8wTqb8891O14IMvaYw/sZ8/ scLGnZhdj5hZ/Hc4cO3r+NziCTjr3+LpL/+a9b2fAOP/GQXY1dhx6JOPUIA5Aw8rv4CH4Opj3BqV 3z/iRhCyyjiEbYMd98A4jkcIIuME9494nHmdefVN9BCz8CMURP63mQX0OHqF6cCDuJTZjL61+Oni e+z8MZg/DlHS0H9eF+GupbpIpdywQneWJXTsIhREL0JhvZTSWu16g0otrkMnwT99Axper1Qa9A57 ZGPQr8YVWrXZ5HRGWv1+g76+Fj3Fz2p3efBn+1JJu1VWrzeEo7nCwOIjF0opQpVGbzSZVR6n3WRQ yKLR8bDbYdBJ65dqKkuz1617avE2QPm3IfYokP1YK7b1Aso91UqLQ63lXC+1nHLeDFxSERKtrKoI L3aGZAECi3Cke+2ehlg8EKQdGgHrmvEXgfrnENdFpJ62+LzxWHbP2u5IWK16WVJvskTjq5uTlRKT Wul0ppLF1XGwllIJbj80ObVmjT+IUJ1Yq3HYE7hModGB62Y2CQiP22UxaSgxoVTrDRarPul2GXRg SLy+1d2TU4fGe3vTSQjZ1ZH4+uEbyz39kbiaMhsbMgMDgAMKcPBdwFGSjcGJ5b6McBAJVZUH1eoe /6AaV6sSxJenb6+phbBcXFsrrq0T3/3jl/5yKyEkRaSArJXA45obv3dEUCeG35CAFMKHKD2P/t7o sNNOt9tB251WJgRRyiM6fzAShZA45AMpq9FTzAbK7rL7wpZQKBoO+g34djjtLXDaNaCFgSWtvSRb plZky1oKtLrjBeZLtowbjw30zZt8Hp/XadcAiz0+h1NViLGFK4jqPyJOnVsHCb1+vKszEqIohBME KSBOEPCBYLK2zmAKR9bUHudi2fP/i9RzJwEj6uIjNIXcVSnGgdlk20URHR8ZVfP/THyFW+YxSWyL 9w8chAgV3XT5UH+ci+peqMR4p3AePYu/kNXTlmiko5hOuh1qJfgYVzJVzEeiVsj2nt0VjqJbb0F6 PIUCwVFSozbotRoxeuwsKIzTYqG0NaRSYdCbTUa0e19ffzKlNYBHTiXXrbt8ob83GgXKgYjEwBCG zp897yR/dv4oa6lEEI0IyL/77zt2AP1ltJHcQHxcsVMqNk6BxjprM/EhsfHuuxns7rtZPn0T7OZq 8C4N2MZLvUsmebFmXZSfUV+ncisLBauRydLYvG549tDmLa1t5oor2r7lwOpsWyoB4fwpc0vbQHdL i9+v0cY2bSxv7+9tyFgsLymVTuBcZzwW9/r0BrXK40ol23OphNPBFslK6za05uyOSHh4/aGD9z5/ 801bNsfCSCazQUTYZ93s89od7R2jY9dujoaRlW5o6uufaW/IsEUIudJqi8Vzq3N5cPZmrcbnbW4E Xj3K107sWJzNfpdiF9vSy42lKITXPHRx5TK1VNJ1LL34IK/xBzpXbds+yXjRA/u3bM5nHTa5wuaA BH99IRcK6DTM/13T8833fzHQ2Oh0KuQDFYvadw7VdmVbIyGDHh2aWrU6FFFTgqJK7fa1Ztc3xhJe v8laLzaZ/aFMI+7dFQkxOyDvZUuE8cUns8GABRJ8xi6pNZsiYdajvMxW2kEjgoCHBFt9Fq00nCu8 BO9qXn6R1S8dbfV704n8YCEXDuk06MWVNXfBaeaKRCwRvqR8fmnNHQNO+wF3jwh6wNpfgUFoKahG h38IgdVyTNWyab5aHNqlil21jM5WC1E1zFzuEaphN8FvS614jURG/S5Iw0xmjdnuDATjqabZ3v54 QmdAWg1kM8msrF5aWycUQnITDBQKm4rNTcGATsdWG7q6ey20xWFzu/x+2qo+YQgEY/54xKfX6yid ycy8AszQWWlP0OnWG2UypFZpc42ZoM+g6x7pGygMhyNIIaet8WgePKjVDN6irlYp12sgzzUo1XUS symZKBb71+ba2DoqbYSdnG6Xu7WBK7AhJFfaHYDuVel0IGh32DKxeBRMd3jD2M4rArfuK29N6w1I QIhvlJBCsstmNqlVdbVIIuXStXxTs9/AGh+XPXrugfF9e8uRrrXjqVDE5lCqwb1BYqbEBOfPn/+U /IlgACTpBE2ZYN9bJSDhcq1Qk5VyTKhWlhRXOOcU+lNX+B8niMfvOvdwI9gVl06j0Xo8yVRzSzLl YWHKii6VzN4krpUr9Qabw2hUKsViIEupNOodVqNeqagT4zV/wmRBV41M4fLk8mOjubzXJ1cq5T5P ITc6ls95XAoZ83whGDCxeUSthM2dC3l/0GiC1LPWZAz688yf/fGT2Sjq/Edkoer1EM7XJRxqlkts +SiZ4S62lKFmizmV2Gl5pfcPGfACGp94tbx+OMK9V8PRs+DvXsBxMjK8bv/3d46+LJNZbeFooT2Z crpVarXKDeFRPhuN0lalHLczv7rtNhQM7DQYzRqtXEHWaCmLBdw7+Vtmkxk0zKiZBhN9y63ML/cO gLUw6MC/pYaGrzzQ1x+OquAsyfjQwLI4nmKj6iWblUB87QWi8Y7FzwkBhAPo6f+JywWkABGnyF3B oCcQ8py7W1A8e9wTccdjCWIHBPpoqWZQWBZdLa8WXBRlXcjVl+KsSqRwIdZ6d0rAvQKpESnlKnml V0Puevfnr+4RiUDZBDIF+wyacM9zewRcVwh4QQT3YkI49Sq6TmXQW002q6XY09NpsdpMFojQmasE xXOvFlrbYo2Jjg4TbbGYzUYtup3ZpzWaTRYLbeoogktNxNta0wT7Shzdx2wgXgUkiKq5FkQA9+EO 5gSaY8uWx754BDI5JIVRMX5U5XWtAklhxAkYueGYcPuxz9l8rwu4dF0lb7NB6sq+UUA28rqzf0PE F7XEm+d+QozeThoeOHb2l6xlPwSWvQ8iCiuWY/+a4JKMdUVBXbSC51XkZaoeVZBKUGQfcnkKHZtG JqY2juQKLrfbVSiMbJoZH9lYKLhd34GA3uPNNK7uaWx2+1RqSuXzNDZ0dzY1+Nxaitn4Ef7Y94/e MDBkdzrtQ/03XP/90zdcP9BHWxFEBX0D199w+sGZXdks+FmkN2az0zMP3j81ncsbzQiZjfnc9NT9 l3/xBWjXfmaY6ABuuTAfeKwVlT/uvfvywDFTfftNdCC7q6m5t2+93+t3eaw2nQbA7/C5fZl4lCui MdP4mrfeMs1294TZ4E5ACAEh4lthCwhvBUjKBpPhDuKH3EtzhH3IDJMuOMeqC++iM4oqG5dKSopq acBGXfDmVVhXayha7s0anNGUT6c9HkqLkEbn8cTiiUQ85vGAo6/W7pD4TNhqoyjIFZGKstm9AW/A 77Vb4fjI59lyhtkAI33ehkwH2g7Rh9EgrcdvZt9ZGoKBNrSjE+IuD0UdY2u2LneKeaIxDB5FoxXj 7MsORyjSxHxrJhA6xubYFNFDfIfL5VlcggKyjbj1uPcDhrrN9wHRgx9evBY/DPglmG/gL1bydKSC PJs4icTM2/Dwm4u7uBopSOw3FU6pUqwtSymq8Ku+7EkthTyO1FKQV639aqvvGikF7448T57ZzL6h tUM4FPR7fTa7iqqtU2usttAZJM5l0h5AnE7j9YCRScTiHq9GR2ndnnQmBwoVCsygzU2RkMOupepw NlO0RcKNaCTldmk1ktpjFOXxZRo6mYfbAkGDWSJFN+P1UgMY+izzSEemwesD+QBVd4E+BiEnFLMV RF4dqbvwk4uHibWLw/hPbybcx24+90/cmwmuJb71nY+3y1p+z/4h08rP+bOApp8BjxBb1eM/MEd4 cvFe2OdjGLGT/FnFVi77tJPvYOxfAmHQHoV2PbQboBWg3Q7t2/w3+9s10H4H7TVo+6CthXYE2sfQ +qAVK/e4Cr7vJt9B/fB9C7SXoT1Z2QP1wncZ2h38N7vmJLQJfo83+efzlXv0SaVh26CN8eeh+HWh nT/Lj7+Hn8/uFeDp+Tb/jN33PmhS6HdBOwRtP7QP4RmshQj+fCAPTA3XEPYGdgaZUQM6hvvxCfwz Ik9cSfyC+JTsJXcJhIKY4DbB/YIfChjhYeEZ0VbRCdGDor+okdU4ap6ueVusFIfFHeIt4hnxdeI7 xI+Lf1DbUvtWnbVuvO4f6n5V97nksOS39UmpWvq+rE92QPYr2WfyWrlNflz+nqKg2KCYVLyn+N+c lNrhPIKqFC/5mNDw0vNt2Gt8H2Ey1Mr3cUyEtvJ9AjOg+/k+CWP+ju8LMAleXV+ISfEA3xdhVxBR vl+DqYkzfF+MSckavl+HmcgBvi/BwuRpvl+PHRac5ftSLCD8OeyOSMA49gp3EraPMAsy830ck6Ie vk9gSVTi+ySM+Q7fF2A69C98X4iZ8Hq+L8I+xZv4fg3mJZ7h+2LMRPwr36/DGkgt35dgW8hZvl+P MeRZvi/FhoVXAsfnsL3YQWwem8YmsSmsjNHYSWhxLApXBnqDWAkbh+/V2Cj8GoReFzaLjWFh6OWx 3XDRy2YvcHcl+C7B92XcXHbkWphVgGh7EOasg34f1gtPp7nxo9DKMHoUxpawPfA9j83AszmIzb9u f6x9bu/B+enJqTJ9koY0IUMPlsbp1aPlIN01Oxam87t309zPC/R8aaE0f1lpPEyv7SoUB/Pruvp6 6ekFepQuz4+Ol/aMzs/QcxMXz8fg0NPYTo4QdutpONAsbN/Dfc/Bz9M7S/Oj5em5WbpnbhYesEed xPYDS1gSsMHS5P7do9DJA5lj8NssR+A8rBHiWPK1q+cXxkqz46V5OkRfstF/9WDD3NiFpZEx4B4r XWy4NL/ADouFo5mvXvYrFv26M/xpEq1gZ5JbpcytXRk5za29HkYMcaP6uZksQ8vcbrPcqHVfsWMf 7DgB81n2Xxg5xq1dhvvKynPQn+JFswsEOM+dYJybV6VtgUXcMs7+J+gByE1OL5RL8/BwepZeHx4K 0/2j5dJsmR6dHafXLU3sm5iYHitxD8dK8+VRGDxXngK579o/P70wPj3G7rYQ/ioUsco7D+o7d5EQ LiCnfW5+71zluBhwjuXYZRwferjhZU5PuSlD5dJlJbpntFwuLbCDp7if92JNWASuA9wVhkkXn2CM 3z/M9fbASGyqXN7bFIkcOHAgPMofYwxOER6b2xP545ctg4Xay2GhxKF4EsZWEB3m1twDKve1W5cP 7i2NlxamJ2cB8OGp8h4Yv54zUlVQsgCogPergT3BfbNwW+BmlOHooxxAq6BfAODsBPiUONCwK87x 67JjdvMgnOV3HQUi2NksWKtA3r9Mtge484zB/zQQPwe/sXPGuDX2cqIbX7b6f/XMAKf1CyUWtOUp APIyWE/MAUIX5ibKB0bnSyzIF/bv3FUaK9PlORhboncDWGdh6ujkfKm0h4Xzfg5rB6amx6bog3P7 6dGxsdLeMsCeHf6HVg7/8WDY/RW0/n/CYPfSaXgMYNh/AOB+WAJlbmRzdHJlYW0KZW5kb2JqCjMz OSAwIG9iago3Nzk3CmVuZG9iagozMzcgMCBvYmoKPDwgL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL0NJ REZvbnRUeXBlMgovQmFzZUZvbnQgL0xpYmVyYXRpb25Nb25vCi9DSURTeXN0ZW1JbmZvIDw8IC9S ZWdpc3RyeSAoQWRvYmUpIC9PcmRlcmluZyAoSWRlbnRpdHkpIC9TdXBwbGVtZW50IDAgPj4KL0Zv bnREZXNjcmlwdG9yIDMzNSAwIFIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovRFcgNTk1ID4+CmVu ZG9iagozMzggMCBvYmoKPDwgL0xlbmd0aCA4MjYgPj4Kc3RyZWFtCi9DSURJbml0IC9Qcm9jU2V0 IGZpbmRyZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAovQ0lEU3lzdGVtSW5m byA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBsZW1lbnQgMCA+PiBk ZWYKL0NNYXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlwZSAyIGRlZgoxIGJl Z2luY29kZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2VyYW5nZQoyIGJlZ2lu YmZyYW5nZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwNDI+IFs8MDAyMD4gPDAwNTI+ IDwwMDY1PiA8MDA2Qz4gPDAwNzk+IDwwMDY5PiA8MDA2RT4gPDAwNjc+IDwwMDUwPiA8MDA2MT4g PDAwNzI+IDwwMDc0PiA8MDA0Mz4gPDAwNTQ+IDwwMDZGPiA8MDA2Qj4gPDAwNTM+IDwwMDc2PiA8 MDA2Mz4gPDAwN0M+IDwwMDMxPiA8MDAyOT4gPDAwNzE+IDwwMDc1PiA8MDA3Mz4gPDAwNDE+IDww MDJEPiA8MDAzRT4gPDAwMzI+IDwwMDNDPiA8MDAzMz4gPDAwMzQ+IDwwMDRGPiA8MDA0Qj4gPDAw NDY+IDwwMDJCPiA8MDAyRj4gPDAwNDg+IDwwMDJFPiA8MDAzQT4gPDAwNzg+IDwwMDZEPiA8MDA3 MD4gPDAwNzc+IDwwMDY2PiA8MDA2ND4gPDAwNUY+IDwwMDNEPiA8MDAzNj4gPDAwNDI+IDwwMDY4 PiA8MDAyNj4gPDAwMjU+IDwwMDYyPiA8MDA0RT4gPDAwNTc+IDwwMDVCPiA8MDA1RD4gPDAwNUE+ IDwwMDMwPiA8MDA2QT4gPDAwN0I+IDwwMDIyPiA8MDAyQz4gPDAwN0Q+IDwwMDdBPiBdCmVuZGJm cmFuZ2UKZW5kY21hcApDTWFwTmFtZSBjdXJyZW50ZGljdCAvQ01hcCBkZWZpbmVyZXNvdXJjZSBw b3AKZW5kCmVuZAplbmRzdHJlYW0KZW5kb2JqCjgzIDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMAovQmFzZUZvbnQgL0xpYmVyYXRpb25Nb25vCi9FbmNvZGluZyAvSWRlbnRpdHkt SAovRGVzY2VuZGFudEZvbnRzIFszMzcgMCBSXQovVG9Vbmljb2RlIDMzOCAwIFI+PgplbmRvYmoK MzQwIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1FDTkFBQStCaXRz dHJlYW1WZXJhU2Fucy1Cb2xkCi9GbGFncyA0IAovRm9udEJCb3ggWy0xOTkuMjE4NzUwIC0yMzUu ODM5ODQzIDE0MTYuOTkyMTggOTI4LjIyMjY1NiBdCi9JdGFsaWNBbmdsZSAwIAovQXNjZW50IDky OC4yMjI2NTYgCi9EZXNjZW50IC0yMzUuODM5ODQzIAovQ2FwSGVpZ2h0IDkyOC4yMjI2NTYgCi9T dGVtViAxMjUuOTc2NTYyIAovRm9udEZpbGUyIDM0MSAwIFIKPj4gZW5kb2JqCjM0MSAwIG9iago8 PAovTGVuZ3RoMSAxNDgxNiAKL0xlbmd0aCAzNDQgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp4nLV6C3xTVZ7wOTePliKP0BdPuWlpSyWk71YqBdI2bQNtWpK0tIUtTfNoA3mRR0uB 8pCX4KA8RBAZLM/hcxyHYXV2Rqv7zajfjKvgMsrsKAIC47gzosu6s65Cc9j/OffeNK3o+PvtfglJ zj33/36fWxBGCMWjjUiGUL05J//FHf9VBjs/gE9Tp7vXuVNbxMH6jwhNvNLlsNo7CwwahCa9DnvF XbAxXhb/NlwPwvWMLk9odfi5tESEJvMIYd7ts1lvlFwGelMWwP29HutqP6pFnXD9HlzzXqvH8Q8t 5/4Rrv+K0LRPEZbv5waQAskV1XKgSsqFX86MOc4Zz3Gj42UypZzj5BsR+ul4xC9E4qvcFQoiHvF3 OGUSScKH4jz4Bmxj8TaHnORJuVNxArSMQyhRpVZlqFVqpxwNBmVTBj8mT8aN/eqLgDIbMBIQUqxQ XGRwAEPfCYp2oiIbyHjFRXL5jlF+llJ03L2hdCpuoXFoOjBKi1OmKlNTSlJKiosKszJl8tQU1fg4 pZrPykzkSoplzjPWDow7rGfOdFitHWdw19vwIgfJU2+fx/j82/L3H9786c1NmzHevOnmp5sfxqn4 3Hmyn+w/d/78ObwSrzx/jmrjvHtdsQx4qhHKUMYps4C6anxJsTo/NSVVlZmVmS6KUQBilCiWrQyE 1pGd73/wwfu4e10osNLd2RU8392DcU/3+WBXp9v04JRp+MI/Ywd2XvjnqdOKyVs16WlbtvzrJ1u2 4HT1QsrxE7CGHKyRwKyhYGZTqW9hCzmOl2Ivtty5iRNkb9RgZc2dIvIlYFwA48zBm2k8UftdwF3k IN5M+ii1AbhXBtTEewN4E9mguHh7Fr33HHCaIF+LpsKFSl2kAivSdzromUp5JheXFBekpKYoJpCD yvhxyTNmaFfN12FyCDsbli31/spp556NNPnw07sfLJmclpyIG5c8FXlf3n7CmqvF3auBwxSEZCcU R1Ay4wBv6rAClTotK7NIla4qUHEFeBV5HPPTl/2CnHuvueXsWcUR8uu7iGQYwVB3UUvze/gSRnie KK/sJshLqYmmT5bkLKEOkd3M0eZqHzUsoiLqW5vXT0hOypblpIxOaG45GRmUt//CU5iHsUxOo6n5 7g1FFlCLRlNyErgxH0gBbRk/FE3U39yvVpfNn1+2OjyvDOOyeWHMnzh27AT5iFw5fuLEcdnaxiX9 RxubmhqP9i9pxOjwYXKT3DwML5yEkw4fBm5LIY7GKpNQEpoh2qKIhlOaEKxUelm+EMhSRMlOUT8u am4Jv7N1G8bbtr4TXNp8NDBv7tx5gcDceRjPmysb4Jq/vnnMps3BJ49jOZbBtzZ38J8s5qP9Fnj1 HzVbwG79oKlS3k71hDxMThLo03cJ5SkJkw7C9OMuzGEcH6dKmZGW49MtwE5yaHHrMvdrdid+gXvO v+yRndpHSudOSU9Mwk2Nh7jsO/3HOrQ5Pd3Ap/nudXkRWFRNNZQclCSkaIkqJnsyQF150cKahfUH TBaL6YC5bqGusXHJEnLhx/DCOc1NFnkZ+TBv0sQlLYePNLVgPHliPrnEj1Xhw4dwCk6G73EqsCpE BDcBrCqLrR3PUZnpR95+px+K04fU20vA/gkg22SUDtIlq1PElJXEol5Qg9MVNAVA7jhFwuDLY4zG H/hXd/dtXL9xPXnnR89i/KOTOA3HP/NDsgeXzm13LdCN5wqc6+fPh+StJDdzJ07GTx+CSqI68sNn +vc655cBlIfKSZoUbcCdeT8jNrdokFHDJ0q2EqOAm0B1MCxtDZ/ftnXrtvPh1qUnQ3PnzZsbYhFw LPKCMoHl2fGTJEIGj5/M0cpKLE1HnrE0YcH9gtY35G8A3zEoB7QGVZPFUlVUlDHk9JJMcEkBiz3Y iVPRdIJqyh1bVTIH58xebK/SYxc5UNPauul5txfjHdtx2rsVlbtCHbbGYCgYxjnbt+KvcEaWQZ+R hRdWe7O3RzadcmpznPbjr//dUjzVkp2FU1K1WDV13BiMu3upRSAm28Bz45hFYkKfGkE2wjhZyWAx GRJin1lhzTDLGKitPhGjntmA+/1w23QcA144Jl5YtLBIUSZ9fZNWl0mkCqphO1LRexirqbnS04tY RSiZhJ14NtQhJ8mubms/9I5/6QMzJybI2yPx3Fd3igcMiz6dNrV2OlBZARbvAIsXjMiB1FSwaCqk Hq19WaoUsdTQkktrblGhUATkqaEV7jZnXn7mjI75eEJ7G96yhdz2da9etyLgD7mKCvGMTPf8f2tv X9Mb6fB6IEtu5U6cOGlKoSZlYsKoGfUNP/771tYJ42fg8UWTJk+bWpo7MWVs/P2LF58829SIx42n eh5DSH4VOtr9cEHzBRcLckR9XwBpQItEHGfk9tx5jVMb0tNwVXV46Qp376aNG9bg+/Y/MX/+P+Ep 5GM8BV8rnz+/sgsKRUZWLa6ZlZrS3fO7Na6VZ4DTswjFvQC20AIn0aO0rxSWFBZJWQaX4jI5Nivk L1UsX7bqVw47Jgc5nJZudEIkQlObzpu6Sh6ERVd5k6Ur2NosO9X5YDH0muuRJq5mzNgxU7pLCrHF 8kzkA67mpWJYNh1mHaktLxeXzIG4W0b0irHyXoi6QrGjpwnWL6ANpEit4sBFyhgXFcmk1pAitoZT tCaf37pt29bz4ZbmRVAx/8+PycAKa4etrbVl2U/Nppv+snlzHwr5hV7xKpRHfKz/zu1j/dqcjlOD KvLFY49j1Xg1Ti2ZNKWu9qRMaTLvf9rYgM2m/fvNJuqjHVBJPwcfgYyQOCnJyhihWIWgkQWxmSKG UJrkOrngOtlLTzYYqVgvhwJhv3ulq+ugeTE2WY4fOranugrr9evb2pa3rVrld+O0vbv1ellGVnvH E1eCIZykysTZxdB7iwrtzqLCryD//64RUik5ZSaePF01Hre1/98tJoswWcjfgsli1FDlhflCPi4S 4DojT9Epg1wmfyGXI9upRjUQC9Mgu+6j0InsH1bLZOoavGzgFTwLPsvI+6T3lQHSK28fHJTJI3Ju 8E6/jBsk4qTSC3krzESYpSdLX3wY90cuc0ZiJItoKg/+DD8dIZFj+F0ym3ob8ApARg4qIAIkmRpm jnQmKvcFacWnFuDnLl4kT0RWyA9GHpc9P2gifya38Hi8kFZP4KbMYnNpAs0VGUhM3zJ5VeTUctLH ZeO3uGzSFzmNn3objye36FzFZXDMgwNQ314D3GQmsVKMJeArDRUwiUEH37Fj3ly86Zl+8jJ56cgz iouDm35Z39BQ/0vZhsFN5NeHnoZuMk+a1ED/b5vUVN9zUntqb+ykpkyKnBZHNeABtpJXgYeYP5Np aSjC6rDsQuQsZxxM4YyRt+TttyOH7qLbnFOYjG8obkOMZgh5lD5yMs5SxoxU1OiK23sOPX2STsdX ruCHn9i5fU3f2r61f1rXt3r15YeKCrI/5Zp91WnpbDp2vfMOm46rZqRhvOHhzz/btCleqYLey4mR dw1sOzo28mJijztx55IUfeRZcpn6EnCUiE3VaSC82G+y0lUqigkFL5VWP1qgEtUyKjx3tbeosLCo 9xjZwNXirJ2PYFxVs7t+fpnuAnH+/MGSOW2y+bM1XU7NLEw2kS8jkAk22+/3ty2fPWG+biNpxkF/ 9kxM7ZQFU+su8B2dWpNZO0gWBIb5lxUe2a7/VzftfpxPzpNDZ886Hf+iTPp0yrQK41002C9rx8j4 85YlQOcITDAcaJAhaJ0sVmrWU2ILVolUW9+XvRLpnqWdlYdVBw/gkz8ilzaCvXt97o5HTfUY15se NbctXwmG+viT0fHKR3b89T8e2UEHLZwDXtBXdHdXVuDkVI1oPcUO4H0fSqXcRXtlgFOxqkA8gKUP cBvwtKcOYHzgKXKDkA1400XfvLKyeT7FxfUb/3yzbyOO3Ja/SpbjB4sc9uJi8XQSN4fRFXoubUfp mB5T/oItuAn/mTxBTv+VnCb7IDWuyabfniWvHLwky7hDjzVoPVgkXfE5zBC54nQTM8EL3Zd6VWo9 YKgMadKDIOU+duYVFOQ5nQVwJMgrwN3LLY31P1nePr68rnbZx7sexT88Qr4ml585ivHAL3GVs8PK XcMLKh7esqC8fMGWhysWcOfJTU1qMm6zvpw7eSLeuu39W7v34jdewytw4L13x6tAv30g4WzIkeg0 oJSmAbGqZ8ROA0Wx0wAVUf7W2nB3587y8tmzuk987XLhPfvIu48/tvuxx7Zv6eurrJids33/R51d u3fjsWs2b1KcIq8XT5sKjbh+rjo9VZ3v7Hz5q541eMqUIqyvy8h64AFjVWbGdHWuq+vvr65ePSEJ AhPq1F3m2QSUgrJptxGsl56uSpT8CnFKmxDzuJAsrMVMWJqjxVibs/Ti9eDc0tKHQtevY+c6iBm8 Zy/5fWQTV46Ldz1aUCDbh7NnGmsfmElejwRxfp6tPT+X9HKTZlg7fvCHFSux4mLb8vPeRXWs70Fm fw7SKMUahNU75I7IS2QHlxXJU1x8/45c/hKLx7t3lXOY1NOoZaPGwyw0U8T5hQnMle38dP26dX03 I/+Jn8SWH53qcRXAy7X69GlyhqyQnx1cFQ59dCUUxDg9Nz/o2LL11LObt9lDufmY2qcPqtwE9swh Fy0QoixVOeSuDMlbYuONEwONlng20yUmxfgWspJ70136EMYPlbpXlM6ZU0r6dlTqd+3CKjxu1y59 9fYD9bV4335ylVx+Yr+x9qnW/LxlLfl5efkty/LyucP0NOEtfeihUq/vodINM5ssG1+x2bDV9upG S9PMB9qW777qDwT8V3cvb3sAz2rJhVdLc54W5+aKuab4UurX7ATKEu15bjr2EFPkGssxJEeQY2hQ eJJDpskRuUSnZTgxFdFtcunVV8H+LnqahczjaeaVSFNJiTROZQoGYb0OShMeMd6fW9poNj/X3q7S 19a1/unRXfjIYRyH04/2vzxAXna1W/FGe2FBQaHdQR2lxkmapFTc3vZK/qTJcAr+4NbePfj1N8hB sut372HVWO7faDaWw4tmJkgNp1zFJOhjSmmOV0+HOSEVjo2dpJr0wHRxW6a80y9CwgxP+wjAJTJo GEnwb4gbr/34X/Fa+D1Ntg5+TbZyZVw6eQHXRq5GfoU7yJEYe47sQngT9yB9yhL5LZ2BIr/h5sBU 0EunIA6NvVsm+wqiSYcWU5vGng/EghAnBi879hSlDD3fip4SMgUD05LGopEiiyO8LGyrb3iwNiNz YNLY3zXUw8Qbrs3K6F3zXlPLMkdg2dI5C2ZmvTAj8W0AKllVO12NQ4E3La2t5FClOh3PK/v5Aui2 +irFz29kJSVOnKytNN4nb21sXheub8h9oGSOYa/JMm7M/Z9lJ6fSA3l21cIxo5a0Nm/uNNYWFjxY smj34sV4zPjItmkZWXmVufm6lOzMoooiOsKi12TP4jPCUygMfQ+f+Qwsc5FjT6HOkC9k06A/shM8 bY3J6jOch3yCJ0X2KZOu3e6/RqEeJV9wXwlQWF1EhxM191VkH55EPgHgL64p2q8h7u4AqWLnuzHC KU6VJBzh2EFfOO+53ed+Ns+ZmYHFBwQvXOvu+RTnaLcrEfkQPPQxuMkIMTHsicLH9PhLP/J20kdO CU/WyhCK3xfTu1iowVcZXoU5OCoG4cNhL+knleTfyV9JpeLindfkZfQDKea7swdo+PAAd4O7Kp1H fVwo8gPuqjCxWCHHcqJPO8cLoaIaL5QTDKmVIR96bCF7vrBoXV9hUVFh31o4JD7cf5RcIn+gvevo M3gmzjjaz93EqaFAIAQD7h+DISh3k8iuN9/C+K03QdLgW2+++RbI4yGX2ZNEBZNHlp54AXf910U7 3kzeIY/isBD1ylXRp5PSJE6Dfhb+x0iebBK5P/I8C/yrnDpSNvg5Vxt5gT7/Ik3s3MXO+9KzW6kw JsY8CpPOYWruJfEpV4Cd+9fEPgkTzl3koKxHeMglHP0js4aehJ04Tg9bX3+JYuZFheRRKi6bEe8Y qa3ZjKbkhFwWPcn+yQY5JfGR4+ByD6zG4r24GlfhJ7jbESUmhONuc5fIdHwN4bu7iJM9Zx3DeNDC ly5MRsDrwEFyzjh39Ty4f3uA/HnnTphxKss3A9+fQuzLlRNotGI1JHYJTXC12GNkcvIvTxkW4oWG gzh74wIdxrr55IsvP7py6dK1q19+dv2PH165foNKf4LlBqOSWCxWC7XUBE9s0C1YoNuAsw8sMhgW HiRffH7j+pUP/3j9sy+vXrt06cpHX9JY20aejvMp+sE7DiAYM0XRmMMxp2T2mLWogD0iyhQPIWlC q5WqGOsEqSJOlqSU9IiWvpl1ZPOLClub4YiOC4tbWwqK8KH7yyubf7LC7Xb/uLmy/P4L6+Cgiqfe X7r8scdPhVasbNm/2Fxc6LRt3rRv/fr1LSv79u0/8NLxkxs2VlTiyooN60+fevHqL/5h7aKsDHz8 BPlDFjdlXVV1TdXa3uqqqmrSWp2VjfvW/fY369fhmdlVmyOLEh22I7aWpoW9FeX386W2Q4df3P/w ZnsHCJKjXXysI78Ily9Yv+7U8VdfPHWyj441jUv6OwKhPnJr/5Pi3zng85dt4/KXj5v7n/QPOiNf EBPT4vex507K6CbgxHkITC2jYSa8WxC/L/oXE+lVIz+HnNyb0F3CKEEJa8VV+OxBn8gS0AXuNhpQ nEXPyd5FU2RfoOcUG1Cz4iW0DPb65a+iZu5V2POwvecUTuGX7ZWgSfLX0Aqgcyy+CT3LcPagHYoe NBBnRzUKE8DsQcuUecBzg8BDfhqu9wBvgFFmowHZWpQFMEcUlwHnS4DZgzYoXkP7lJPYeofyBPvt U55FA3JQBNYrgO90RTaaLu6N5YLQC06jM/B5lHv17oCsAH0c/y4qk5mQD+A7QEePsgDoUPmArnIW yuJu390l4pwAK0MjhbNUMkyrNnQYvYheQxegzmbjBrwdv4G/5vK5am4b92vZONlCWbNsrextOZYv kh+R31LEKTIV5QqrYoPilOIPilvK2cpq5RblaeWf4ibE5cU9HPdu/OR4bbwt/rfx1+I/HzV31OJR /lE7E5QJSQlZCaUJSxP8CXsT+hM+SPh0dNxo/eim0T2j945+cfTv7/OJ8VCDnLSSx/wVLPaVgsdG 90ujMBglwhUW/2YmR0ZxLUMTo/vymLUC+o1JXCthZm8T13Ewif1MXMejsfF+cT0aTRy1XVyPGZWI QkAZy2EGRKFRz4hrjDITEsU1h+ITHhLXMpQb3ZfHrBVoYkKFuFYiTcJScR2H2kdjcR2Ppk7eIK5H o9ypPxHXYyZkJmyv8Pl7A67OrhA/05bN5+fmFvAdvTz9i2Io4LB6NLzBa9PyOrebN1GoIG9yBB2B boddG4XhmxwBK2+2eoN8uc9tNzncDmvQwedp83KjMBSEQsymEN+L55iEezEdkzCCrSvIW/lQwGp3 eKyBlbzP+U06YxIaHAGPKxh0+bwUvssRcAC/zoDVG3LYNbwz4HBQRFuXNdDp0PAhH2/19vJ+RyAI CL6OkNXldXk7gY8NBKeQoS4H7/R5QTCrzebz+AGcAoS6gLrbZXN4Qf2ZaVUUIi0biNl5azDos7ms wI+3+2xhj8MbsoaoPE6X2xHkZ1KKDIE3+5yhHmvAkZbNJAk4/AGfPWxzMDJ2F6jm6giHHEyGYQga 3uW1ucN2KkmPK9TlC4dAGI9LZEThA4I1gWw4CPBUHQ3vcTCt/eEOtyvYpYnhoaE8c3wBPugAVwC0 C0QV1R/BmgoHZP3U0CHRdIxRT5fP800E6gZnOOAFhg6GaPfxQZ+GD4Y7VjhsIboj2Njt9vVQhWw+ r91F9QiWUoda4Ka1w9ftYDoIscREiAaC1xcCRwSFXeoX/1AMCPf4YJcV1OpwiHYDQVxe3jpMU58X IiPAe3wBxz0V50O9fofTCoy0kljD73usvZSDx2d3OV002KzuEIQfLICs1W5n2gvmA+Z+awAkC7ut AcbK7gi6Or1MkE53r78rSJFolFptQCRIMSSJgiM5CVFnF4xmdd+bgIgjyTFEDcTzunt517BQB3UC Dvq/FhgsXQSpKalvpBRxQNw5BOF7fAF7kE+LZmMa5S3d4NNo8qaJRgPv1IpZ0+GAfKJ0w+AHqkK3 zxUVzbE6BHnDW/1+SDJrh9tBbwjaA+0RjumyhvguaxAoOrzDrQLshmLczoe9dlHktOG1JU3Q8bs9 G4R6BtnNXEcdZeXdtIpAzkiAfqttpbUTVIN89PqiNeT7h9YwVlC4QEiH2ymIVaPnq+qNFt5cX2VZ ojPpeYOZbzDVNxkq9ZV8ms4M12kafonBUlPfaOEBwqQzWlr4+ipeZ2zhFxmMlRpe39xg0pvNfL2J N9Q11Br0sGcwVtQ2VhqM1Xw54BnrLXytoc5gAaKWeoYqkjLozZRYnd5UUQOXunJDrcHSouGrDBYj pVkFRHV8g85kMVQ01upMfEOjqaHerAcalUDWaDBWmYCLvk4PSgChivqGFpOhusaiASQLbGp4i0lX qa/TmRZpqIT1oLKJZyBakBJo8Pomimyu0dXW8uUGi9li0uvqKCy1TrWxvo7aqNFYqbMY6o18uR5U 0ZXX6gXZQJWKWp2hTsNX6up01XrzEBMKJqozZA6KUK036k26Wg1vbtBXGOgC7Ggw6SssDBJsD5ao ZeJW1BvN+sWNsAFwEgtwSI2esQAFdPCvgknG1DeCupSOpd5kiYqyxGDWa3idyWCmIlSZ6kFc6k/A oDo2gj2p84yivNRHdO+b0QFQFFtUsFKvqwWCZirGN2BZfOlX2xz+EI1vMcmFIskKqlBFNSxyhWIA YVzthfQV9tgSYhryi3UgocoNpRhtzhqxCNMyAhEOXUkowvZuB1TCIC0pkCM+WlR6XEGW79AOPT6x /wWtbmAGWFEoqJlWN6AFo2IOTyqpMfoDLkDpCbhCUFJ4axh2A641YksOiC1rpAaUy0j5A46gHzqW q9vh7tUCbID2NSaJy+v0BTyi6sx8tlCpVEtDfCcjbgfFfYFObVco5C/Nyenp6dF2SBy0UApRBfIh P+pFAeRCnagLhkYezYRxOxt+82HQzEUFsOoACB6VA0wIBeETgMOjFXmQBnYNyAvwWljpkBvePAyt Eq0gu3LArwNwuuHbDpDfpMOjJgZhhZUZvr0MsxxkcwMGpeBmkJQOj/KARh5I9k06EhWJxuwojf89 PceghO+tKYX9bm1dDJOuQmzHDnc88BtAK2HPB8eM7yMP/TQwmh5GMQjfPrgv0e9i9xyifp2Mkxfo USkpLSe764hytAEGlaET9jRMNh+T0svw/YxaUOTgA6ohuOeCK/rpFPWxiRaXaIaYFJSXj/EW9LYx OA9ACtQlChRakN0NvzbA9Iren4nSUFWURhrzIMW1s98gk8sGOFZRPx4+dCcMXBwMi96R7OOElZv5 jVKWZBziQOORyh9CPcwiDsZxyCZ0xw/fPuASZnIOSWNnGoRYzHXA3RC7K/H4dg4a5jfqXTdg2aM2 6WFx0AXQYYZHLeNhe7EaSfQDw2JTkDbMbKiJ8Q5de5g/JV/7AaqD0Q4CtuZb9NBE9cwBSgG4CrIs dUdpu0SrDvf+d2stWU6Q1h+N6NCIqBvSqIfZw/O9OEjZ4AQdAixagwxniKOdfVMeGvZLLbECIGyM ngATG8dUXx/zi+AhG+NtZxK7RElLoxlqETGtQNXHasSQH2Lr0pAVvlkRvAAfEjMiOAxWypchq8XW gVg8nultFb3VIVpmKN4Ei7gYnvU7fEopCzUjwKLIJ1r5+3qcwvQyeZ2sElDa2m9Y67vwqV16ozp4 WBa6WE5LlY3KHxKrn7AjSEvtao/xfWz0CZr7GRfBZmGgYmV4klZ2Ji31mTfGIp0ARzXqEvcCMbXU yqJIiGGJx0gbBf+mTrG1zj4s0qzMT99fguF8RtrjXrJpRJ+7GZ7rO6p6QKxADiaXZxhdaScYjUop b0Z2EYdY7xzDLN/DtLIz/LR79Ma0qN4jMSi81HnTRkSakDu1I3pNB8t9X4y8YTEfJC90w13XPazm QKuZrb1iRvvhLXQyK6uujihGrO8Fub87Y7pYtefZb1CU0cGi6dtjRdDuXnWc3g0zqOFWvpdl+Rjr xfrxf5KzQXE+40VtpKyTMopOEu7oLBIQMYZT9LPIXgnfnaLXhP7oZfYdOYf8/6ha365Vh5grIbE/ OodZqwbpGa96ZIQryqserixoCUyYJnbPAHs8zHYmuNMEV5WwW8n8o2N36P00lplLYE0p1qNGRkug YYJvSrsFdihtnl3Tq0UAbwRaFFePmhkPPVAzM0gTo10Hu7XwqxfhKEYF7DTCNV1XIzqdCvyMgGVh OUTxqCyCpBbYH+I6XCoD4yhJVgdXJqBfI97VAW0Do0fl1zBL0bUxKmeVKKmO2YhSpjQrQKJadkV3 G+G3AeDMzJ46prMgrZHpUAX3BV30TALBE4JEFfDbALwpRDXIZWFSUE4WEVLDNKT6VDJ8ynUR2xUk qxe9TNdDVLSiLQU5qP2bopzNTP9aePNMfwvsWJhvdEBfoivFTjWjUBeNo0amn47ZoZ5xKGf3qBWp PWujkKYYr1Qwe1G/UckrGScds4j5nppI1IZ7517RIXGoZvrpmaVqGbQZ7KgHeEN0R4hHA9O1QrSt QFOIeyEmamOsW8F0pJ5dDFz1YkzpmO2GayFkCJV/SAvBAzrxuyLGZkPeN4rerYj6up5F2TetsoTl op5B6ZivzVErVLH8rRMlb4yJMMmPjWJ81kclG25fKY8kuO9TOwRaEu/hHqxk8VQrSmiOWuNv0x2q X3rocTZ2/glF6/fwTh47SQ5NqLGzqCam5sZOBkI1rmawnhFwQ7tCnRb619AZKHaWu1cXk07Owow/ NAlL04hQw4WzUuwkbGczuzATBqNTitBHfNFJpYfdHervwunQwyBiz39BxlfQLCxijKQlzJlWNjlQ bsF7WPO7OtXIE6Of9X6BSw9bh8QpheoXFmHp/poRp+TAiFPW3/KBpMvfsn+A+dsvnrFczMJ0vtSK dANIOq8N2YRawMnueUZ4fSj6KLVSNHIupTbojJHcLnrcx+YLLTt/hUCaUjjV5oCF6FsL8TBSB604 Ff43MCQ2iGVuZHN0cmVhbQplbmRvYmoKMzQ0IDAgb2JqCjgzMjEKZW5kb2JqCjM0MiAwIG9iago8 PCAvVHlwZSAvRm9udAovU3VidHlwZSAvQ0lERm9udFR5cGUyCi9CYXNlRm9udCAvQml0c3RyZWFt VmVyYVNhbnMtQm9sZAovQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJp bmcgKElkZW50aXR5KSAvU3VwcGxlbWVudCAwID4+Ci9Gb250RGVzY3JpcHRvciAzNDAgMCBSCi9D SURUb0dJRE1hcCAvSWRlbnRpdHkKL1cgWzAgWzU5NSAzNDUgNjc3IDg0MyA3MjggNjkwIDM3NyAz NjkgNzA2IDQ3NCA0ODkgNjgyIDcxMCA3MDYgNTg4IDM0MCA2NzMgNzEwIDY2OSA3MTAgMzQwIDY0 NyA1OTAgNjkwIDEwMzQgNzEwIDY5MCA2NzggOTE2IDY2MCA2OTAgNzY4IDgwNiA3MDYgNTc3IDgx NCA2NzggNzY0IDQzMiA2OTAgNzI3IDk4NyA2OTAgNzE0IDc1NiA2OTAgODIzIDY5MCA4MzAgNDk2 IDY5MCA2NDcgNjQwIDgzMCA0OTYgMzA0IDQ1MyA0NTMgMzQwIDM5NyAxMDk0IDQxMiA2OTAgMzc3 IDc2OSA3MTAgNjMyIDc2NSAzNjkgNDUzIDQ1MyA5OTIgXQpdCj4+CmVuZG9iagozNDMgMCBvYmoK PDwgL0xlbmd0aCA4NjEgPj4Kc3RyZWFtCi9DSURJbml0IC9Qcm9jU2V0IGZpbmRyZXNvdXJjZSBi ZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAovQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkg KEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBsZW1lbnQgMCA+PiBkZWYKL0NNYXBOYW1lIC9B ZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlwZSAyIGRlZgoxIGJlZ2luY29kZXNwYWNlcmFu Z2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2VyYW5nZQoyIGJlZ2luYmZyYW5nZQo8MDAwMD4g PDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwNDc+IFs8MDAyMD4gPDAwNTQ+IDwwMDRGPiA8MDA0Mz4g PDAwMzE+IDwwMDJFPiA8MDA0OT4gPDAwNkU+IDwwMDc0PiA8MDA3Mj4gPDAwNkY+IDwwMDY0PiA8 MDA3NT4gPDAwNjM+IDwwMDY5PiA8MDA2NT4gPDAwNzA+IDwwMDYxPiA8MDA2Mj4gPDAwNkM+IDww MDc5PiA8MDA3Mz4gPDAwMzI+IDwwMDZEPiA8MDA2Nz4gPDAwMzM+IDwwMDQ2PiA8MDA3Nz4gPDAw NkI+IDwwMDM0PiA8MDA0MT4gPDAwNTU+IDwwMDY4PiA8MDA3QT4gPDAwNDc+IDwwMDQ1PiA8MDA1 Mj4gPDAwNjY+IDwwMDM1PiA8MDA1MD4gPDAwNEQ+IDwwMDM2PiA8MDA1Mz4gPDAwNDI+IDwwMDM3 PiA8MDA0ND4gPDAwMzg+IDwwMDRFPiA8MDA1Rj4gPDAwMzk+IDwwMDc2PiA8MDA3OD4gPDAwNDg+ IDwwMEE3PiA8MDAyNz4gPDAwNUI+IDwwMDVEPiA8MDA2QT4gPDAwM0E+IDwwMDU3PiA8MDAyRD4g PDAwMzA+IDwwMDJDPiA8MDA0Qj4gPDAwNzE+IDwwMDRDPiA8MDA1OD4gPDAwNEE+IDwwMDI4PiA8 MDAyOT4gPDAwNDA+IF0KZW5kYmZyYW5nZQplbmRjbWFwCkNNYXBOYW1lIGN1cnJlbnRkaWN0IC9D TWFwIGRlZmluZXJlc291cmNlIHBvcAplbmQKZW5kCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago8 PCAvVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTAKL0Jhc2VGb250IC9CaXRzdHJlYW1WZXJhU2Fu cy1Cb2xkCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFszNDIgMCBSXQov VG9Vbmljb2RlIDM0MyAwIFI+PgplbmRvYmoKMzQ1IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvcgovRm9udE5hbWUgL1FITkFBQStMaWJlcmF0aW9uU2FucwovRmxhZ3MgNCAKL0ZvbnRCQm94 IFstMjAzLjEyNTAwMCAtMzAzLjIyMjY1NiAxMDUwLjI5Mjk2IDkxMC4xNTYyNTAgXQovSXRhbGlj QW5nbGUgMCAKL0FzY2VudCA5MDUuMjczNDM3IAovRGVzY2VudCAtMjExLjkxNDA2MiAKL0NhcEhl aWdodCA5MDUuMjczNDM3IAovU3RlbVYgNzMuMjQyMTg3NSAKL0ZvbnRGaWxlMiAzNDYgMCBSCj4+ IGVuZG9iagozNDYgMCBvYmoKPDwKL0xlbmd0aDEgOTc2MCAKL0xlbmd0aCAzNDkgMCBSCi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nKVZB3gbx5WeWQAECypRSbRF73WxaKxg71UkRapC JEhQhaRJyCouEtUsyy3ddqIv8dlxosiOcknkkrjEiS9RihIndnK5nNK+xL67z/bZX3L2JbZE6N4u AZKiFN85h/mW+3Z2Zva9N/9rQ4QRQsXoMOIg1DvoD/2l8sQJ6Lkbru1Tuw9Mmk+43gL6TYQ0TZl0 amLywXYdQtoA9EUy0CEuLbodnjPwbMnsye6/8IfyH8AzM//Z3bPjqc8cfSSGkK6NWW9Pav8cotAx eD4Dz+RMak+6/zdvcuH5+8DEEOJwn8IfQTxUzPs0j0IIa5bvnJ+hSaK8mEeUFXEJ5sd9CBFf6UP7 L6P8L5gcbET1yHiZ4L2S68cUvxZ/bTtCn/vdLxHiJniLzNcQAa0JIWKCB19CfIQoqVFqNUqNTQSZ s+AHchne0PuPNXF/DOO2X32D90vep5AB1QEfRXy22YvsNqbRtmiEbSGVkml823K/2bQ8TiFf7o8q l8fxfol9gbGxI0c//5UjR0c2uj3Y7xvdeGzx7JmjR0ZH/L4XscFYl9yy7eChrdvqknrSaEjWbdt6 y7HtW+tq9FriwqN33LF9e5jGOBbZkTpx/KHPnzi2bQsVxBS1dduxEw8fykx1tjsdDmd751Tm0OHM rs5ulwdjj7u7c9dOkAX0yxsAHfBRJUJGjpFjxhTGeZ7tedn4HCP3vn9Yuv3h7xF1vyIiS+ekQklp Gb8YE/ziUqFQLD5PiPHp3ARv8f1DXMLhdJiNKiWvSKkymeEhF0QYHb/6BucNbgJFQWPSvAqoUF5V UkpapCpSyaGZQYE0fDpqzn/bXNCrFCcEpZoKj6uujg7ZLHIZPo8JDBt+Fi6gOJUG0uEK0y2b6pMu l0zOTSwN9IUjBqNQpFLArJoBYuHKl80Wm9GsUvO5KqVOq9cqAlZ7hVYoxiqF39fWliZ+Brwarr5N uHgeVIGQldlZEy0101SUUlAKM8M7xWwd4XK6PNF/ue0Yvf/736+sqKuoVOuKy4qK8bvEy0f//Oej S0M9BhLzuEUgMLoXcPoW7yICy8CRa/Ghkpql69StgC5KKgeCecA1erPJ7QoF66aaGuxWiRA/gfkl 6gq3pyUZos02mfw8KAI0wFmM2q2VFYJSrNUFqZbWwSU/ca6JDptN5RKMlSqXq7q6c+kI72LudqPR qNWVy/kMbyUI8U8AAhKw/2bOWkYYLMiWmSwwHYnKCl1MC6108v791XfKBKISgUBUViYQlv73q7nU hSWJVFwmLBNJi4r5TCt696l3GbIImkSMi/lCgVgoee8C55CVDvuj8apIgApbryzyFq8s1tfUBquo piYNadDrdBoVZ8+Vj6s0sGcGUtPUbDbSVG0VzTkEJouGr77B1XF7kALRIBCxxhYl1jyn/HDeCgsq LroWglwdvvW2t+Y3jtbUGYz4tds3b6qK67TPyeRWWyTa2ByN2R0yBVYp7dZIuLY5FnXYFQpCn3v1 rrsxNhtbm3dN30f4MTaZW1ozO++6bbA/FASAyhTB0MDgwdsHBoMhmVxeHgoODoDGTwLTJ4FfL+Nl wjSLeJpi+AELUFBrAaJguM57DpX0XgbtLOi55SqFTut0xJVymaBcrdbXuj0anUCEObUmi8lk1GnV alZVelmN36vXAmo4POJRLhcDOAJUY3P/0kXg5BR4QA7gsgz2HvNZ2DHmzwnkPnYMUHXplVw7/gl+ a0/uEO/ilRQhzPmX7mc0fifouQbmsZ5SRlMKDsy88/z58zzy8cff/z03cfl7y3Jy3gI5weaN0vVu ED62IrqcFV15rejQFFJOHJcKKypdntoC1lmDZ/DOqSANTkck3DqWrHe75DLiXC8dNhnEQkC6p6au f+kezqDJZjEb1apinlKl0WsNMp/dqq0AXShVXn9rx/iSH2QZyg1z3uZ2onY0zXjzvClG14CDplec kWn5dXStk6fC+QcKYKVgHBlju7LwtQKr1iGOsGxpa6PC4J6eKK+tTteEghYTCKHQ6sGtxNoybR0+ v0KFsUoeCvR0zc0PD/pZNweCP7bs8GZv8qor7c4QTTcHKYNRLMVYKiYNoWATTVNOR2VFbgTLZRZT KFhd2elwSiV2a3X18Dmn1a7VS8rNpuamzOQdRzJTHW12Kw7TKTWp12nkMm6JQqXTW2y2K9/943yW c2FuoDdMqeFH0b39c3t7+4IhuQLkCPb1wB5PQSx8CGJhM+CgoIeCd1gf+lSF0FdwG7SRNkrXxc8p r3ts49Ej547sSLW3gVKerLTYKLqxeePhrdtravUkNhqT9Tu2HR5obYlHPW5dbhMx5K9L9vRt2bbz 68dOjIy5vcSFQhCEjXZ7quu6IpTHpddLJevCoEioVugqdbmHcpUBt8dolMkLYRRwcSw3Al6lG8XR 6JoozwDALFex4eoaDOeFXsEwFfpgzxNd9Twyuc/f1T2XHRnx8dgtZkB+Di/vNhdg7nKEg/Vz3V1+ n1z2rECo1QdD7TVh2u5UqrC83GaJ0K2doaBeKxQQplunMp2dIJvHnSYkUlWF1qDNjfKK7BaLXqtU lHDKyys0Wn0FZbOolYJSh7O1I505PNHTE6F1WiyRBgIbhk9ke5hNVmGdNhbt6wUrP3P1Kvd1iBEm FGJ2Gsvz2oD8qGCq+S5+Xg8YxDYzr/MmVDAH+2of93WXu6V167appX8i0N7Nm5J1ZqNEajQHqcah hnqvW63Mvd3T84nct3BysCphMUsl/epKr7+uoTd3Gi+019Z43ZUV+B7YSl8AFMFblMldrvrkWFWY dnp0pKhMq/P6EtVEw02hYK4BTEPncUeWTjb6fQa9SIhzXIFArw8FmRj4DPy5HV1i8lwKvNkzL166 lMf2AcB2Dbxdl71R+ewtqlqXplzjGQoGwFEf2LS1pt5Amk2QvG3ZO9DUEKM9buNpezTW2b11+82P HzoyNAKpH/Z7RkcOH3r09w/c3/qE3GQOhRubue+vRa3TBamK3R4JN/T0NTYHQ1rd+sRv4+jj1UG/ 12xSKvKxcQF8cDvaBpkeoDdasNIovc48+fY10FWwiQ6zU4oC7JlWQLF9xTXyi1Y1gz/7+f5B7HQ0 1A9tGPkvLBRrdW5vgna6DGS5nPdsiU5DUz1dsz/KTCkUVWKxWGQmzVbKYlOqBAJOkc5k9vnjVeah hjqPS6H4bmOi2uur0AR88uGh+3e2NDrsYjHBrYL902vFQn6xTG40h6T1kbDDplJs2faPOV+fwwkG M1fM5WGRQKeB6EA73eDspCdJfShQlaBHuQS/pKLS420f9QeWI1SRGbQzwkSo8IeNUNeHK/P1i3BQ aZmywmqLxn1+g0lS/vXVAKbSaW2WkD95S1uLjqPW65yOUDA5UJ2wW2XlX7t21ocJbsHQzuvi3Mp8 hcrpqqsfWLqH8XBX3+TqIIo7AR2QNxmXfVt+Q83hKNtoJhVl4horOwMNju1aj6a63qPlFm7pHwwR eRd2DkQGl8YNbhg4eHHH9uewUGQg/YHm1kjMbCsHn5v3YQ2BAGmQignT0g+97olKrU5VIZFyi1UK vd5isXP/Mzeq1+jklYopn/fUqdwf5vp6aQhMmInAA4P7s719gRBETJUyHBrsZ7KUEZBPDbvrYquO tUXHitWCyNL1YUuxVjg+MCexWeLxvr2tzZWflerJENXVvftPt95uszYmR0fSJzdvikXVSvxNcVvb Hd5gyOXW6rj4L8MtbRSt0fl97V6v12+2KdX33Ys19++abmjQazF2e7t6pnceUJ8629cDdmK11SZT y/kYrmXzKsgMKemp87yL74eh/znovxX8b77/uW8xlRb0b8I/JXqJOaZfRhsVm/A7+KcPPcTIDjU0 Lw0zypF1NXqZV/31Smxe9ce8NA5HNm259faPLv0Jv/zIqZMT47HoC9jhau+YyhzM/QknZrdtbW62 24mXvnr8jrHNXj9v0eHcMLx49Ov3Tk001JP6y1+1WFpboK7ESAdMVPN+iMxMvWdm6ic6vCYwKtaW O1BX4enzDzxQVmrQhql+g8VUKVWqyp1qjVDCLXqF89SVds5TRw8mwkG7RaXgcIru5HAwxqUCGSDD njqal5eNUHKoytfGJ/OqxPmIpGQij56sqh3bvD+341tE/61bt9TWkIYXBgYfyR3HRx/t6eL8anNv X6LKZMZLl3iLejIS6+nbfry1eennuKOd+drQ1Tc5b8M+uVHnco3IAEkmsS6ngzQTBVjDWa1q89EB ryt96XXZAYcODWw48JNtOzC+9+DgQIhN9PJ17uMFe1r6V5GQNAQCzS0x2maWy2Ryiy0caWkIBA2k WHou4/WeuhNXEDT2+lIlKoVaCXEfP3JZxuQAeoWquEQOFYOmQoPnburto2iVWqWkqcGBAwt9PaGA SsEYFNU/yMTFOFTtT0JuPLQuA7ouQy5UsLY1hyBrIyDjDwt+Ym3jPIm1hmisfzCzraM7lrDayz+n bG87HA8FzCaFDCvVDmeiqiVZD9k/VNO7Mj/62q6M7uEStdpkdnq8BxNVmAmH1mgk6fZ6PC6bRaeV SrC7O1HtcIIvEAuNhgjVbRhxOIv5CpnREAySBoVcKpJLlAqziaK6P9HThevq7pK7dNpySQnfauvw aHUyhVAsgWpWIlOqjSa3B3aczRC4iTUVD5snvPgiZ9dLL1355Esvgba2QKz9K+QL6TUIJPOautGm X6OxgnWsT55XrER+vfa4fzWZ29r2zHwq997HP+74hlCvpQId7ZNDrS1hSqc1kPF4b9+26kR1JOYP miwyudPR1rYjtXBk6+Zkvd2qflZcoWHS44EdDU12l6ScNEQirS399Q31ECopmxWgcHy0szMS05F4 86avWGMen8FYXi4WGvQBX2OTxwXlQrlKIBUxtaiLKcUm2lr8PoUCy5QOZ3VtrzHkdGg0kGthSble 73D56hxOjaYclhBDeqHVuVzxBOjNB7Z7nj2DYn0FFAUK4qfP57TcE9zXLmu4r50+zWARMhnOD8Gb 16z6cvYM7boMrODP1x6y8NfU0VjGmE8k3L09WS9+skSvp+j2jtThjaPRWEUlLi83GrxumorHqja1 ttAUaRB9QxSPT3dTgEChiDBt6emNxgGMmA7vFjTV1Pn8kIN5XN0dmcn9ezYM1Nd4XOwhDFSt3kR1 o2iMDgNN0d09jBTgp4oIkDXG1sQsj/k4Y8arcFhJJyhc2OyCRJiS8oaXKwORWCSSinKfOJG7r4g5 UuEX8wH8zKuzl/G+orLSkpJiPodTzBeUlJUW47l3OY+DF/ZSgXDQ4w/ZrtRzXhDLZWoltHAiFvVT tO3KBt7iFb/cQBpNkDdJ9HojSRrknJ+x0YbxsTngvYw9HVUY89cZrvfKxzihKz/h3M9bPJ2r/nRO cRpGq6D6fx0shj1bAOmYgwXmbMGY+03u0nfwYu6jF7AIC36Q+yg+gZ/NNREeQpTbhB9demfpZUZT JOx3Br6mW85br7EimgGJNG9j+AeP7Zk1PVOqUhoNDrtzqqYaYtWPtbpwtKtHPrrx24akz683CEVt LXdxmk9fMaf7++NVepL5Bi83wrkCPLqBx7UlPl2w1ihePe5aPQEjNtvszkCoqrrHrNUbZGq1tLep MSzNDb7waolUJBULBARHUCoRSkRlP39+R09fJK7VE7j4Dg4mqhJH3Fx66awG0gKvxVJSajI4HU6H gdjJ8DMFGhaAB6ln6pBVFK+GifWpenR9+VVoRsUU1dHe39/Xk6xz2svLIbcOJKK+gBUyEf7TJUay Kj7YvyszOBCPGvTMAUs0VlNbUxuJuTwq4neH9o5t7GirramraW4cqfJ7SL0U0nW9we1LSDubGimo NQHTgVBr29bW+mS8io5QdJCiIPTFH2TkeDr3Pl6EekoC0XGFNTMjiJnGi1xeaZlQIrvFU6neeOkM 7fZYbUaTob6xIXkJPG0feFHz3zxdX5tEfMDp+sq5nhlb7Q1No2OTmY1j9Q1Wm83a0DA2umtibGND g836JNTedkc03tYdr7I5ZXKFzGmPxzpaEjEn1BTEt3906u4Nw1YbxjbL8Ia7T138xd13DQ6YjUbz wOBdd//iizfNNCV1Gq0u2TRz0xcenp1tbNbq9drmxtlZ0AE4La4Y8FvK7KVRyqOtjNGcxlO57+Du L+CRB7nVfzz72mX1gzC2B2SuAJlH10SOtXF2peQs4ADyqcIhSjjv2Vaqt8JJRAEKikK0qDCQ1bUb xxaObRxLVGl1Jd/kq+Q2ayTScRKCoMlM0VW1ockdoViEOTHEDU1H9rV3CJ4odTpqq/t6R/cOD0Ui UHBLpBZLNNYzVFfndChl+PiOzm4m08VGQzTc0tghjfn8JEQJ3NR4rCfg01aUlpwug8rP7+uYa6zH NbUzoi3NTX4vVItaQxDq267aSMTt0ZNibqnW4PZG46APL9i8E3RXvBwRWNfBKXl+6Q8v4y/jx14m 2paeJto48aUU8TmIyKOgvUrQXhLtQEfWaHAdZlYK3vWxdgWhBU1xwjeOvSs6l60/2Vp/nAzFS6Jq 0+ZbbhvdnKjW6tRKp50KRqugmCMlUuZYZcPAzPzwhlhUo5FIDaTPX1NNhyHiKn/L1EbBUHtrMKQ3 CkVlpXpIifs20CGdpoSJEUKRyRyrGuqLxExmCXPiJzGbEvH+gVjUbBIL8Z1jnd2RmB6iE6mP0d2d o1011R63pqKUCyHP46bD1e2N9VRQp2X+RxBqaGyvCtOM8su4ZWwuUE10hb1uo4H5j4Gk3GB0e8Nu t8diVapUSqvF43YvHaACPptFpVSqrDZ/iGoIR612Bfzs1hiNmP8XwvUWntRuE1e/y/zz8Ppfbph/ gsecPhetdMEcfm2uBzUW/xihqxT/BLvS2p+feBM1FcVRijeMuNwFdJyIIwPc74U74t+DSoAeJs6i k1yETuEL6E54Psn0wZwpuB+DeWdg7DO8CygDzyNFZ9n3xxgaxp+Cd8/B/E3wnhmnY8Yz82G9ODtv GG3h/hH54JmZe4Z9j5AKLpL5JxqMnYJxT8O9D67TcPXAGC/cwaqhLjmIzmEu9uJboP2aCBMHiE8S Z4jLnE9z+dx7uEu8Yt5O3ntF+4v+g5/kd/NH+ZP8L/B/W6wovrNEVEKWPFvyUmmo9COlXyy9UPpe WbLs0bIXBXZBjeC7gl8LH2a15UdHmTpwWZvX/bR4eKV/K3o+T2MkxjV5mkB8vCVPc1Al/kye5sKY f87TPCQgCusXIRHhztN8dJATyNPFSM75RZ4uQSJucZ4uQ1puf54WgB4v5mkhOsS7nKdFyF30Cnwd c0uY/xGznDA0Rnqsy9MEEuHuPM1BYZzO01wY82Se5iE1/rc8XYS0hDBP89E7RCJPFyMH57E8XYK0 nNfzdBmKcVV5WoA2c2fytBDluJfztAhwdQtqRLNoDh1A82gaIncGZRGJvgRXCAWgRYEagFpgAu5t KAVvPUC1oxk0DhkvCd5qNzRyzewF9ikN9zTcb2bnMiO7YFYDaobVkmgD0L2oB3qn2fEpuLIwOgVj 02gP3OfRLuibRZMf+H3UODt3YH56KpMlv0SGAoEoOZCeINtSWQ/ZPjPuI5O7d5Ps6wVyPr2Qnr85 PeEju9obmgeSG9p7e8jpBTJFZudTE+k9qfld5OzktfMRMD0N7jjNspYFehY+TKJBeJoBxlHX9I70 fCo7PTtDDqZmoINhdQrtBZUwIqCB9NTe3SkgkjB6HN7NsALOwxpeViUfuHpyYTw9M5GeJ73kdR/6 sIwNs2MXVkYGQXvM7qLh9PwCMyzoC0RvvOwNFv0gHv5/O7qMnSl2lSy79vLIaXbtIRgxyI7qY2cy Cs2yX5thR224wRd74YuTMJ9R/+rIcXbtLDwvrzwLdCa/NTthA+dZDibYeQXZFhjErdHs/4IegNzU 9EI2PQ+d0zPkkG/QR/alsumZLJmamSA3rEzsnZycHk+znePp+WwKBs9mM7DvO/fOTy9MTI8zX1vw 3QhFjPHOg/nOXrMJq8hpnJ2fm11mF4HmGI3dzOqhmx2eZe2UnTKYTd+cJrtT2Wx6gRmcYV/PoQS4 ZD/axzYfTLqWg/H8930stQdGokw2O5fw+/ft2+dL5dkYBy5847N7/H//slnwUHMsFtIsiqdg7DKi feyae8DkPvDT2QNz6Yn0wvTUDADel8nugfFDrJMqgJIBwDJ4bwzsSfbOwG2BnZEF1lMsQAugXwDg 7AD4pFnQMCvO5tdlxuzOg3Am/9UUCMHMZsBaAPLeNXu7j+VnHP6SIPwsvGPmjLNrzLFbN7Fm9Q/L M8BpaCHNgDabASCvgfXkLCB0YXYyuy81n2ZAvrB3x870eJbMzsLYNLkbwDoDU1NT8+n0HgbOe1ms 7ctMj2fIA7N7ydT4eHouC7Bnhv+tlX1/Pxh230DW/yMMdq9wk8cAQv8Drd9+amVuZHN0cmVhbQpl bmRvYmoKMzQ5IDAgb2JqCjYyOTAKZW5kb2JqCjM0NyAwIG9iago8PCAvVHlwZSAvRm9udAovU3Vi dHlwZSAvQ0lERm9udFR5cGUyCi9CYXNlRm9udCAvTGliZXJhdGlvblNhbnMKL0NJRFN5c3RlbUlu Zm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkgL1N1cHBsZW1lbnQg MCA+PgovRm9udERlc2NyaXB0b3IgMzQ1IDAgUgovQ0lEVG9HSURNYXAgL0lkZW50aXR5Ci9XIFsw IFszNjIgNzcyIDY2MiA1NTIgMjc2IDU1MiAyNzYgOTM2IDU1MiAzMzAgNDk2IDIyMCA1NTIgNTUy IDc3MiA1NTIgNjYyIDI3NiA3MTYgNTUyIDgyNiA1NTIgNTUyIDIyMCAyNzYgMzMwIDcxNiAyNzYg NjYyIDU1MiA0OTYgMjc2IDY2MiA2MDYgNDk2IDgyNiA2NjIgNDk2IDQ5NiA0OTYgNTUyIDI3NiA1 NTIgNTUyIDU1MiA2NjIgNTUyIF0KXQo+PgplbmRvYmoKMzQ4IDAgb2JqCjw8IC9MZW5ndGggNjg2 ID4+CnN0cmVhbQovQ0lESW5pdCAvUHJvY1NldCBmaW5kcmVzb3VyY2UgYmVnaW4KMTIgZGljdCBi ZWdpbgpiZWdpbmNtYXAKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVy aW5nIChVQ1MpIC9TdXBwbGVtZW50IDAgPj4gZGVmCi9DTWFwTmFtZSAvQWRvYmUtSWRlbnRpdHkt VUNTIGRlZgovQ01hcFR5cGUgMiBkZWYKMSBiZWdpbmNvZGVzcGFjZXJhbmdlCjwwMDAwPiA8RkZG Rj4KZW5kY29kZXNwYWNlcmFuZ2UKMiBiZWdpbmJmcmFuZ2UKPDAwMDA+IDwwMDAwPiA8MDAwMD4K PDAwMDE+IDwwMDJFPiBbPDAwNEY+IDwwMDQxPiA8MDA3NT4gPDAwNzQ+IDwwMDY4PiA8MDAyMD4g PDAwNTc+IDwwMDZGPiA8MDA3Mj4gPDAwNkI+IDwwMDY5PiA8MDA2RT4gPDAwNjc+IDwwMDQ3PiA8 MDA3MD4gPDAwNDI+IDwwMDJFPiA8MDA0Mz4gPDAwNjE+IDwwMDZEPiA8MDA2Mj4gPDAwNjU+IDww MDZDPiA8MDA0OT4gPDAwMkQ+IDwwMDQ0PiA8MDA2Nj4gPDAwNTA+IDwwMDY0PiA8MDA3Mz4gPDAw M0E+IDwwMDUzPiA8MDA1ND4gPDAwNjM+IDwwMDREPiA8MDA0NT4gPDAwNzg+IDwwMDRBPiA8MDA3 OT4gPDAwMzI+IDwwMDJDPiA8MDAzMD4gPDAwMzE+IDwwMDMzPiA8MDA1OT4gPDAwMzg+IF0KZW5k YmZyYW5nZQplbmRjbWFwCkNNYXBOYW1lIGN1cnJlbnRkaWN0IC9DTWFwIGRlZmluZXJlc291cmNl IHBvcAplbmQKZW5kCmVuZHN0cmVhbQplbmRvYmoKNyAwIG9iago8PCAvVHlwZSAvRm9udAovU3Vi dHlwZSAvVHlwZTAKL0Jhc2VGb250IC9MaWJlcmF0aW9uU2FucwovRW5jb2RpbmcgL0lkZW50aXR5 LUgKL0Rlc2NlbmRhbnRGb250cyBbMzQ3IDAgUl0KL1RvVW5pY29kZSAzNDggMCBSPj4KZW5kb2Jq CjM1MCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9RTU5BQUErQml0 c3RyZWFtVmVyYVNhbnMtUm9tYW4KL0ZsYWdzIDQgCi9Gb250QkJveCBbLTE4My4xMDU0NjggLTIz NS44Mzk4NDMgMTI4Ny4xMDkzNyA5MjguMjIyNjU2IF0KL0l0YWxpY0FuZ2xlIDAgCi9Bc2NlbnQg OTI4LjIyMjY1NiAKL0Rlc2NlbnQgLTIzNS44Mzk4NDMgCi9DYXBIZWlnaHQgOTI4LjIyMjY1NiAK L1N0ZW1WIDY5LjgyNDIxODcgCi9Gb250RmlsZTIgMzUxIDAgUgo+PiBlbmRvYmoKMzUxIDAgb2Jq Cjw8Ci9MZW5ndGgxIDE0NTY0IAovTGVuZ3RoIDM1NCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCnictXkLWFNXuvZaOzsB8feCoPQyPm5ApCqCQikj1kuACMGQYBIuXiEkOxDNzSSI 1Fa8tCLV1lqrrS21jnUcH8Y6jtP2qG1nprX13s60js+M47Q9ynGcnnFap2cuFsnm/761d0JAp9Pn Of8PJNl77W99l/e7rkAoISSerCUqQkyWnNzX6/5mh5Ut8KpudLc619Z1IsV/EZJyskm0OZwmfT4h 9xyEtYeaYGH4qngd3MNzMr7JE1rVqJ6US8i98YTQh90+u+2vv/rnPwm5rwSe7/HYVvmJhRTBPdIL XptHvPT26TcIuZ8nZOznhPLD6TNETXh1KX+eEKlI/uQsZCvnjOe4oRqVKp7nOH4tIT8ZSYRyovwU uUJBMocItzlNspRMX4zz0G5YpspjjjilnbxTvQ+sjCMkKTE1MSM1MdXJk96g6v7ea9LOuOG3vg5o JhLa10MI/4X6ItKpUkenJqYnpmr4r8Jfngt/qb7Y1XNRPRn5HgcqhyaZpMANkEzInJCuidOMhsu8 xIcKHioYkzKGdxylM2c9urOq+tixooW1K9+127l94cXc7t2VJrq0/tVwuyY5vNuRN43SlatQx3eB VyvwlHXMQ16j0989Cj98/e09muQvQK6v76rqFL+a5AHtaJCamQZSNSljUuBvzOjkOE1mGizmw01e bsFD+UgBfxMKJoBOuSljVJuNVuvCJ4t1NHfqjtnvW8yrH/vtQluD22lvaFhXOpdOy/vxnB8bKihd 4f/IuXABP/vQA8lJdNIkqzZ9gjB8ksG4qXPRYjpq5PifP3Tv/VMmm8snZk4YMX6efsPLNVV0xAi0 4rhUze8DDZPJeEIymBEASB4ITxwZp0nXZE6giBbqnSxrSYPHjhUuqF19fm1b29rzq2sXcN+n5qpt 281Wq3n7tirzgfAhTUKXPXfq3r3SLenW3r00N4feONscDDafPRcMgec54u+7yreB1PtIOiKTCgAU AOuC0eCVTCFzQtJIGYA4RXYc39Z7ZGiT8z9cor3B0ehaJv3PS7vpjud6rz6+/j84s2XTS4uWDuOW LvxFg0jvuzf/0KQxKbSzkybQUa/uodueff/5hQtral/GSPD3dauug+RUxSMsDtCyMYr4dPBIIlfw EOqkum40Vpp+Zoefn5kqjcYKs2WJ9NwO+sIOGlc1v5LPPzgpZTT1Bz78yB+gKclZXeNHjXrlFTqc Ju5+mY5MQnk5APItiJLRKI/BOFoO0/T8vPwHAWnu1mFHRibNkT4+dvhwTc07muRdD0xstG/tzVF9 vNX4VnUVeukRwGsKaD0M+VHFGQWocn4BcELUwFP5EDZ5qfmKVXH5iiO5n/9nVbV2jm/XkkX06NHZ S+vaX3M46do1tylHzdbn6xcttjjqly76n1WruLy8vNUN02dQ6nW/PtEQXtflnJpLaUP93nfq60et KdXRMSnZXZnJSWvWoG0FoNrX6t3MtkS0CnGEJAAE89G+RNpCV0tPTBgfeuedi/Pnt7erd0vvbQ3v 6cjMfLHS9AlXv5XOQutWgHXNYN0IMq7fOgy1AkwIsCCJkw1MhLDggjuqqqurdmyvrqK0qnr7zY5N lG7quPl1e0dHu+rzYOjMGQyyM6eagy93dko3pL907qZ0dydNosmdnZFaANLuUgtGf+dawNcfipQC xlFVDhwRB9Q4ll0esEtRlQvpEya/bLZC5ixZvDEpZcxY1eujhsRR6nD+PHwEmDlzgRnPI6ozQb82 vp5osKpQmkfTZ56gS+nSE9LiHr6+16o6eHtPBLWFEFkscykUMjkO0mSY0PFUgTH/QTmLVHuPHp1R s+DRc21r17ade3RBTfg0S1mrlaWv6k1u6Tc3Dog5uRSSNp7G7907NVcaw3L2HMtf2da4sWDrJJCp oJUCtj7Yj+KDd0GAn6irr9vwk7ql9Nj06c3PmC3HpheufBo+js1aUPNIa02VquPRGYWUtq6+ijDv MRllmLnde40GGoUcUZo5C7SoJkSTDxj9H8Qoif3RdJUqvfroH69d+uO1o9LlS3/9+hKgtVO1DF+3 96h29i6LdIJOQC2B1WxAl6ZDFBw/xmX8OXyIW34zfOqYJrnXRbvDfwsf5NLDn8Ke1/q6+VqQloK9 KC8xEpwRyDHeDx2dNfOx52qrIMFKahY0v2cX6XFuf9j2iqmybukPudW39xx0TstdtQr8Fuy7qr6k vqlEO+xP4mSGSRwgJ8jRniHIblRlfrp2A6Ub1n76h3VtlLat+wOd/s5blL71jnRKev+td955S22g r+6TrknXXt2371V6P71/36s//OQ30ivSK5/8hn7yCW2gtt98gvEykhB1E3RKDm2nNBUjS5WqSufe lr7kMqTV17jpn2wK1226qB4evld1qGcybZPWgfU7AbFy0Bf7AyQ5VhX2GynN+YqPsZ3hL+3g3u01 BE6fzLNlZlBoDU/UuZa3tC53LfjTk0+mpS+674mNXV1dK8+emuGuKC9faZiXmlp8fup999Jg87uL zRb/2Ce3gNTLoOMhIuGcUwAl5fKFC5KEVmyEqN8aRS9NRg8rYeJIuVZg28JakQQ1nNvcaayktNLY 2QnVu7KzZ+Pjj2/suf34Rko3Pq6u3PWS9KF0/oWXKH3pBfogzXtp156Tp6V2qf3kaUpPn6SttPX0 SdClv9OzPg89XpP8zQ2MplrI/MsQGUPgSepoivDQ1BWqZWED93rvY9zrYZGvP9B7efsBVQZmLPTa hazOPQibI3mihFMK6J06YBqIlPVIOqfk56n2mq3P7Zhvsczf8ZzVfLRtrXS7oap6fmWl0fLGwoWF tQse/WgN/Hz06ILawqPczFM+D6Ue36nTHq/X89/SlSe3jBg27mdZo0fXLf3FIvu0XFYXeara/fK0 3IYurD1SFas9iRArKB2KOEZ6AeZJHrfdpC9/dLvbMGlSXqo0Qy5KTadnzqIvjh+/0cobe59TuRGV M5Cd4yDSMDtTIdKgErAsO0On0MdoG53ygdR2Tmp7X32xN151q2eyelwv4UnPFdy7u28UPQF+VzO/ q9KTbl7Yt84sHZR+SecovNV5wJshjlUvlTEeye18X7oZXgY8b4/jr/RM5q/cHsfmG4iXfeC7EaxK Dh5lBo06maOhZqmuDRhnwlsHDDuFx45xOTHDDGceOOmIB0CYrCfdDnoqMXPm7Fn1xR42izro51wb t4E9gYBxcPeHr3Eb9oGuZ/r61IdhT4LcUfMEuSakZqRiVQAdM1Lp9r/R/GeepvTpZ6RzUhF9hf70 /Fl6/rxUKdnUObdbtmymOTRry+b9r78prZPWvPEmBTnAl7/B+I4hE1mvjjSF/svM1MxUjDFM4shs CtJoyV7MnL3S23Ty9vKysvLt0sWzHH/9sUfpHO1qiMFNHT3hP3Fnwp+WFG3ZXFLEOaVZ3y8I+KcX 0P319T/tmG9OSnU0Pg8BSNF2rH2ZkL2R6StTkBM4IzL8pfNyvOP0pc50BkPrpb72Dko72ildHwo6 lze3PC69dgJ+qOWJVSvVDReXTs2mnbulS9LvYCLMya6/UDZ+PP34V7SRNsJ7GuYd+IJ/itnPej4b 9TASMlBKCkqFcYxul56qgF5jqHhK+j493bMey+36HumsOif8K1qub3+iXL8fZr3Ln/lXhA+ALQeA K9ZTjZz76TT1gOqX4asXqBSGAK3uWQdHDxV5EnrHZlavppI5cr2PTjcAewZO+w/KfXR0DPbYU9gp QKXp7+FYLrjN0D0t5meesZip2SL9cENpOV3b9tlna9vKytdus8x/fOM/bm2A+mYxP1tOy8s2rC/X 68vXbygr5z4A09o3GSqMhvb2CkPNuIW16464GiltdB1ZV7twXHqD4+nfY0T//mlHQzqd3TxHq53T HCyaQ+mcIsyktZBJ7WCJAJaQgnxlZE+KnT0hTBOxeYHyNGbuQIOvGIzGeaeWu0bMqF3g/s/1G8Cj 3VQFs9v+A9K1igojnbWp0mSq3NRhhGI27uj4pGTa/gRNqs7OAedvvHFty2ZWmrGpjRjBPb9kyd49 dUuW1O3Zu2SJnG2A8kUyVM6pROV1RnU4fB93Kjydu9U7C46D0tyucHeXQp8eqSIKffoZ1cKwn6sM Hz6LpGVd4QKgPCx9za3WjMKKGPFdSjo4DWf3Am51+xxt0ZyNe57XzyvXv6AZ9ccrV65fv9p97c/d V6981n2V9Yh9wMEnc0jKUwIuLl3poPv27Jynp1Q/b+eeJ2SoNaNuXO3+7MrV7j9f6756/fqVK4j9 TWB0gk+Xz5rYD/GsefPCBeyKfLqEJ+e+Iu6IXG+wsXPxXeFbXeqL33jg2QywthWq+lDs+xCo+AcF nXdIy2nXJem4dPwS/ZkUuEQn0ol8ffjz8Lv0qFTGlXNjpBV0K8o/pPpC5QHuasYjPT8pT6Vm73Qd lmf6Ir6rvniNzpbefY2937mLVfMM9k5J/y71RVbbD0YqfN9Oyckq5zBWObEyy10o/8xZZ9PVitlP fL8ASul26a+tj3TNm/ce2AcQ8QtZfpOC1ER1fkYeOlSi5dIuKp6l5b37uvhg2dGynovo+06I4yDE MfZgzDZwR4ZG6bsFkVO4IvLBQTMO+k41+xnLfPr8C9Kf6hpEl0W0e98R7XTRkh8eevO5StN8y/PW pXWBoOhYcA0CmM4tU2UItoZnPm19hNLkxAkncu+5j86bt/VxcPv+hwtXBGfNHJWU8fq4xJGYiI9Z qwnXd1mqZvPGMDlmEpNlDMawmRO/Y5hveX3uNNeEDMq+a9jy27r6Tpo7dZfmAfzO4QNVF/UpkYCd 1wdhEL7ITVa6Er+MeQT5Yoac5X7bWwd4AjRypVRb4XkKSZPRSUlKV2GpTMcvVngZLaigytksXfXU nNkzZ3146RflutKWP5ylpylZs4bOKQ4/KW0zYFwbtnFvp5SWrZGaaNuO3GnhDvVFumz5755asoQz hb8sKd6wvqQI9GoHn+wFn0S+J4lUDfY9CfakjAGT0YPK9yTsAA1diy8LiY1L99cufLjwR49cdS+j 27ZLf1q+srXtkZaVgYN1S4tLXlzd7RC3bP57k9ej3vdBwf33z9E2O6bljbs3a7n3jd/7VtB77sn5 9dy09JLiNs/smcI9U+rrf3wyEEhKRlQcgNo+NjkPY5OzKg/dgIjkqzQSR6V86eLFM+Gl6ozebtWH vXkHpD20/kRkWpmh1CXAG08MiVhpznKfnT0bToNCE+7kHD2TsUahJDb9sDzHyiTnOZuBLmCqQKaH L0UnoRI4ie1Xpix2TsS8h9wuOU8L6fRufPtQ6pCkD6T3JJiKRvFf4gumrZE9N8mAaRQno0FHRTro KAmzJ7TInNjjIhcccJaccfQolxNzVgz/ZOBB0t71zT9A65/2dasngtaj5ciWZ/f8RJboqfjNz5Fz NTUn3q2tOffMs9J16b+2PkthTGy+6VpO6XLXTdXm3sXS5ed27HiOYmeHWOe+YLEeJ0d7qhzx3Hgl 6Fngw5lLuqWcuSbceeZKounYWTMjo4dyBLvj6DWbJvzt07SRo0bKBy/6sHwUa3Td5QjW82vp0684 ylH6m0+oDY9g7Ex2++gxqHC9EE/XQet4OD0wt4HS/CW6m750KXzzHCj+Iufs/Rq61imidKBaqAZx rFdhRKQepgdu3pRgces3vVuR5hTrMckyCqnoq3zOJ9V+9ZUm+dZnWzX8ViUWl8lVEk++OJhTFoq7 KR++X3Wf9I9wHgZkB9cSLuvt5n4VngbIbYXM3KnMLwO+ecJIieaqShmk2dgYwRG/etrH+nkH6+10 SIXBaDjtWj68cGGt+8qG9Zs6rki9mzoO/Ih+Dx6oZkBT/8GSOkrrlvwA2jrXejQ9Oam9XfqqJid7 U8ef/7h5i3IqAzRHjGBnhau8AyzKULp4pEiDEqmRih4d9rCMf6q6N7xn8pTJU3qe3UZ37pS+qqu3 Ny6sr19+0OnA72IOmk3zrdj8nx0RH0c3dfz313BUTBwpnMtNuYcuXtT50uJFUKzBgzeksXyydJDV WDjz8cm3fycd3Iooz+TKVScAL5wX1Oo4/EZVnZmRUaCGEM9QnYCO1FgoHQ5Ihwtpo7SrkFYGaCX/ +XsnGs5J7bT1XMOJ9+znaKvUfk6ZlnF2zMBvZlPzUxM1A9FNYfDDCJ04MmVMKhjKn5De5EY1P/XU HukH7588+T6t2/bEev+Kx9Zslv6y6cknN9GkZVWWi3Tb/nCbZVIWpR+dpx7q+ej8+PFzf7t02tRd u6SPpU927aLJo6DM8dJYekgzNtpHDnVpxt7CmIWouETr1ZdVe5XvvlNHs99Laq5Hwpdq74GbXcr3 +fD65StJh+pGPPx3wjYP/IFuPzZuP0ihOEcrP7AnziONJSRhZV9DX0Pc/uh/BiI/Jv5D4uS7+3rU o8hxbjp5l59MfNxmiPBkcpy/QVbwTrKC+5jk8NfJalU6KeCvkRVIqyqH52+TmUC3Iu4cOa7ZTKr5 veQ4PDukMZCgupWMVKeQncDrMny2M955pBbpcZ/mOjkDz3are8kZlMUthvtu4tBMhPvH4LWTBPkL 8JlCDsBrM7zWqYeTM/yL5IxqHDkMr33cEXITXgT4zeAzyCF8cYv7dgLtFXh1ctP7LnN55AO+Gfhs ZXLaYd2h4UHWEbI77gtSgvqoL5MjqkPkA9QbsOhV+J9Sz2byt8JrN0/6bvAE9M4jQe4I5TWvk0uA 32jyADFDX3sDfm/CqVykm+gF+k8um6vh1nDPch+qRqqmqEpVXlWX6iRP+WF8KW/ll/Nv85/zYfUw dYbapvaqV6t/pL4B079ZI2rOxt0TNzVOF+eM2xS3K+5HcafjuuOk+JT47Pi2+N3xB+Pfjr81pHSI Y8ijQ54dcmTIXxKSEx5I8CVsTHghoSvhg6FJQyuHLhm6Yeh7Q389tJt520S0GHkx/xWK/RlDh0fX C6M0lCTBHVX+h6Qmdcq1Kmadj7lWQ+90KNcamHkqlOs4qHWvKdfxZHi8W7keSu4ZskG5HjYkifiB M+WhU5PQkJeUa0omJIxQrjmSkLBAuVbFrPMx12pyT4JdudaQ7IR85TqO1Cf8XbmOJ9+7L6hcDyVT v/cD5XrYqAkJq4t9/taAq7EpJDxgnyjkTp2aJzS0CvgftlBAtHmyBL3Xni1o3W7BjFRBwSwGxcBK 0ZEdpRGqxYBNsNi8wegSruDCFLPPY/OaRbdoC4rCtOxpU7+TvGEJdxM4LGGQSFdQsAmhgM0hemyB 5YLPeSefYQmVYsDjCgZdPi/SN4kBEeQ1BmzekOjIEpwBUcSN9iZboFHMEkI+weZtFfxiIAgbfA0h m8vr8jaCHDsojpShJlFw+rygmM1u93n8QI4EoSbg7nbZRS8Y+kDaXKRImwjMHIItGPTZXTaQJzh8 9maP6A3ZQqiP0+UWg8IDyJFtECw+Z6jFFhDTJjJNAqI/4HM020XGxuEC01wNzSGR6TBgQ5bg8trd zQ7UpMUVavI1h0AZj0sRhPQBGU1g2xwEejQnS/CIzGp/c4PbFWzKipGRhTJzfAEhKIIrgNoFqirm DxKNygFbPwIdUqBjglqafJ47N6AbnM0BLwgU2UaHTwj6soRgc8My0R7CFRljt9vXggbZfV6HC+0I FqJDrfDQ1uBbKTIb5FhiKkQDwesLgSOC8ir6xd8fA/IzIdhkA7MaRAU3UMTlFWwDLPV5ITICgscX EO9quBBq9YtOGwjKjqg18LnH1ooSPD6Hy+nCYLO5QxB+cAFsbQ4Hs16GD4T7bQHQrNltCzBRDjHo avQyRRrdrf6mIG7CKLXZgUkQd0Q0Cg6WJEedQwbN5r47A2VPRI9+bqCe190quAaEOpgTEPE/+IwW L4IIJfomkiIixJ0oK9/iCziCQlo0G9NQduSBkIbJm6aABt4xKFnTIEI+Id9m8AOasNLniqomrgpB 3gg2vx+SzNbgFvGBbD3wHuSYJltIaLIFgaPoHYgKiOuPcYfQ7HUoKqcNrC1pso3f7tmgz43ZzVyH jrIJbqwikDMRQr/NvtzWCKZBPnp90Rry3UNrgCgoXKCk6HbKapXphLkmo1WwmOZaa7RmnaC3CJVm U7W+RFcipGktcJ+WJdTorWWmKqsAFGat0bpAMM0VtMYFwjy9sSRL0NVWmnUWi2AyC/qKSoNeB2t6 Y7GhqkRvLBWKYJ/RZBUM+gq9FZhaTWyrwkqvsyCzCp25uAxutUV6g966IEuYq7cakedcYKoVKrVm q764yqA1C5VV5kqTRQc8SoCtUW+cawYpugodGAGMik2VC8z60jJrFmyywmKWYDVrS3QVWvO8LNTQ BCabBUaSDVoCD0FXjZstZVqDQSjSWy1Ws05bgbSITqnRVIEYVRlLtFa9ySgU6cAUbZFBJ+sGphQb tPqKLKFEW6Et1Vn6hSCZYk4/HLihVGfUmbWGLMFSqSvW4wXgqDfriq2MErAHJAxM3WKT0aKbXwUL QBcRAQ4p0zERYIAW/oqZZsx8I5iLfKwmszWqSo3eossStGa9BVWYazaBuuhP2IE2VgGe6Dyjoi/6 CNfujA6gwt2KgSU6rQEYWlCNO2hZfOlW2UV/CONbSXK5SLKCKlfRLBa5cjGAMC71QvrKa+wSYhry i3Ugucr1pxg25yylCGMZgQiHriQXYcdKESphEEsK5IgPi0qLK8jyHdqhx6f0v6DNDcJgV5QKaqbN DduCUTUHJlWkMfoDLtjSEnCFoKQItmZYDbgeUVpyQGlZgy1AKYP1D4hBP3Qs10rR3ZoNtAHsa0wT l9fpC3gU0xl89lBhpJaGhEbG3AGG+wKN2U2hkL8wJ6elpSW7ISIhG0ohKSY+GBJbSYC4SCNpIiEi wOBtJxPhMxeGzKkkD64agEIgRUATIkF4BYhIbMRDsmBVT7xAnw1XWuKGXwHG9givILsT4VOEPSvh 3QGUd/IRSDWjsMGVBd698PROqghNhGIK8PbBOt6hFDejQ1kCmQZypoH2/+/sG0YSvrOFSPvtVrrY TrwKsRUHPEFLAmQ5rPmI8zvpg69KxtPDOAbh3QfPI/yb2DNRsa+RSfICP9QSeTnZUzEq0Q47UIdG WMtiuvmYll6238+4BRUJPuAagmcuuMNXo2KPXUE8wjPEtEBZPiZbttvO6DxAKXOPcEBqWXc3fNph p1fx6AMkjcyN8khjHsS9DvYZZHrZYY9NsU+AF640gxSR7cInEXyccOVmfkPOER37JWAcov4h0sIQ EZnEfkxwxQ/vPpDSzPTs18bBLAixmGuApyH2NCLjX0vIYn5D77phlyOKSQuLgyagbmb7EBkPW4u1 KMI/MCA2ZW2bGYZZMd7Baw/zZ8TXfqBqYLyDsDvrX9iRFbUzBzgF4C7IMs8d5e1SUB3o/W+3OoKc rK0/GtGhQVHXb1ELw8PznSREssEJNgRYtAbZnn6JDvaOMrLYJyKxDCjsjJ9MExvHaK+P+UX2kJ3J djCNXYqmhdEMtSo7bcDVx2pEvx9i61I/CndWBC/Qh5SMCA6gjeRLP2qxdSB2n8DstinealCQ6Y83 GREX22f7Fp8iZ7lmBFgU+RSUv6vHkaaV6etklQB5Z9+B1rftR1xaozZ4WBa6WE5HKhvqH1Kqn7wi a4u4OmJ8Hxt9suV+JkXGrBm42Ni+iFUOpi36zBuDSCPQoUVNylogppbaWBTJMRyRMRij4L+1KbbW OQZEmo356btrMFDOYDzupluW4nM32+f6lqoeUCqQyPTyDOAbWQlGozKSN4O7iKjUO3EA8i3MKgfb n3aX3pgWtXvwDqSPdN60QZEm545hUK9pYLnvi9G3WcmHiBdWwlPXXVATySqGtVfJaD/8yp3Mxqqr GN0R63tZ72/PmCZW7QX2GVR0FFk0/etYka27Wx3Hp82MaiDKd0NWiEEv1o//m5wNsioa6d39WRfJ KJwk3NFZJKDsGMjRzyJ7Obw3Kl6T+6OX4Tt4Dvn/UbX+tVUNSq6ElP7oHIBWGdExWSZihDuUZYI7 K6mBCdPMnulhTYDZzgxPquGuBFZLmH+07Ak+T2OZWQPXyNFEqhgvmYcZ3pH3AlhB3gK7x7t5QG8E XrhXR2qZDB1wszBKM+NdAasG+NQpdLijGFaq4B6vSwlOp7I8I+yyshzCfaiLrKkV1vulDtRKzyRG NKuAOzPwL1OeaoG3nvFD/bMYUnhtjOo5V9FUyzBCzsizGDQysDtcrYLPSqCzMDy1zGZZWyOzYS48 l23RMQ1kT8gaFcNnJchGilLQy8q0QElWhTKLWYj2lLD9KHUeW5U1Mylexut+LtkKlrIeiH91VLKF 2W+AX4HZb4UVK/ONFvhH+EZip5RxqIjGURWzT8twMDEJRewZooh4GqKU5hivFDO80G+oeQmTpGWI WO5qSYTbQO/cLToiEkqZfTqGlIFRWwBHHdDroytyPOqZrcUKtjJPOe7lmDDEoFvMbETPzgepOiWm tAy7gVbIGYL691she0CrvBfHYNbvfaPi3eKor00syu5EpYbloo5RaZmvLVEU5rL8rVA0r4qJsIgf q5T4NEU1G4hvJI8idN+ldsi8IrIHerCExZNB0dASRePf8+2vXzrocXZ2/glF6/fATh47SfZPqLGz aFZMzY2dDORqXMpoPYPo+lflOi33r/4zUOwsd7cuFjk5yzN+/yQcmUbkGi6flWInYQeb2eWZMBid UuQ+4otOKi3saX9/l0+HHkYRe/4LMrmyZc3KjsG85DnTxiYHlBa8C5rf1qkGnxj9rPfLUlrYdUiZ UtC+ZoUW1x8ZdEoODDpl/TsfRGz5d/gHmL/9yhnLxRDG+TJb4RsgkfNaPyaIgJM98wzyen/0IbdC MnguRQwaYzR3KB73sfkim52/QqBNIZxqcwAh/M2GeBhsQ7YyFf5frGhqXGVuZHN0cmVhbQplbmRv YmoKMzU0IDAgb2JqCjgxMjcKZW5kb2JqCjM1MiAwIG9iago8PCAvVHlwZSAvRm9udAovU3VidHlw ZSAvQ0lERm9udFR5cGUyCi9CYXNlRm9udCAvQml0c3RyZWFtVmVyYVNhbnMtUm9tYW4KL0NJRFN5 c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkgL1N1cHBs ZW1lbnQgMCA+PgovRm9udERlc2NyaXB0b3IgMzUwIDAgUgovQ0lEVG9HSURNYXAgL0lkZW50aXR5 Ci9XIFswIFs1OTUgNjA2IDYyOSAyNzYgNTE3IDMxNSA2MzAgNjEwIDU0NSAzNDkgNjA4IDM4OSA2 MDcgNjI5IDQwOCA1ODcgNjMwIDk2NiA4MTEgNTc0IDYyOSA3ODEgNjc5IDYzMSAzMTUgNjMxIDI3 NiA1MjEgNjMwIDU4NyA4NTYgMzE1IDc0MiA2MzAgMjkzIDM1OCA3NjQgNjgxIDY5MyA1OTggNjMx IDYzMSA2MzEgNjI3IDU3MSAzODcgMzg3IDMzNCAzMzQgNTg3IDUxNCA1MTQgMjkzIDYzMSA2MzEg Mjc2IDI3MyA1NTMgNjg5IDYzMCA2MzEgNzQ2IDMzNCA5ODEgNjMwIDcyNiA0NTYgNzgxIDYwNiAz ODcgMzg3IDY1MSA2MzEgNjMxIDQ5NiA0OTYgNzY5IDMzNCA4MzEgXQpdCj4+CmVuZG9iagozNTMg MCBvYmoKPDwgL0xlbmd0aCA5MTAgPj4Kc3RyZWFtCi9DSURJbml0IC9Qcm9jU2V0IGZpbmRyZXNv dXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAovQ0lEU3lzdGVtSW5mbyA8PCAvUmVn aXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBsZW1lbnQgMCA+PiBkZWYKL0NNYXBO YW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlwZSAyIGRlZgoxIGJlZ2luY29kZXNw YWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2VyYW5nZQoyIGJlZ2luYmZyYW5nZQo8 MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwNEU+IFs8MDA1ND4gPDAwNjg+IDwwMDY5PiA8 MDA3Mz4gPDAwMjA+IDwwMDcwPiA8MDA2NT4gPDAwNjM+IDwwMDY2PiA8MDA2MT4gPDAwNzQ+IDww MDZGPiA8MDA2RT4gPDAwNzI+IDwwMDc2PiA8MDA2ND4gPDAwNkQ+IDwwMDc3PiA8MDA2Qj4gPDAw NzU+IDwwMDRGPiA8MDA0MT4gPDAwMzI+IDwwMDJFPiA8MDAzMD4gPDAwNkM+IDwwMDdBPiA8MDA2 Nz4gPDAwNzk+IDwwMDREPiA8MDAyQz4gPDAwNEU+IDwwMDYyPiA8MDA0OT4gPDAwMkQ+IDwwMDQ0 PiA8MDA0Mj4gPDAwNDM+IDwwMDUwPiA8MDAzNz4gPDAwMzg+IDwwMDM5PiA8MDA0NT4gPDAwNDY+ IDwwMDI4PiA8MDAyOT4gPDAwM0E+IDwwMDJGPiA8MDA3OD4gPDIwMUM+IDwyMDFEPiA8MDA0QT4g PDAwMzE+IDwwMDMzPiA8MDA2QT4gPDAwMjc+IDwwMDRDPiA8MDA1Mj4gPDAwNTM+IDwwMDM0PiA8 MDA0OD4gPDAwM0I+IDwwMDU3PiA8MDA3MT4gPDAwNTU+IDwwMDIyPiA8MDA1MT4gPDAwNTk+IDww MDVCPiA8MDA1RD4gPDAwNEI+IDwwMDM2PiA8MDAzNT4gPDAwNUY+IDwwMDJBPiA8MDA0Nz4gPDAw N0M+IDwwMDNEPiBdCmVuZGJmcmFuZ2UKZW5kY21hcApDTWFwTmFtZSBjdXJyZW50ZGljdCAvQ01h cCBkZWZpbmVyZXNvdXJjZSBwb3AKZW5kCmVuZAplbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKPDwg L1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUwCi9CYXNlRm9udCAvQml0c3RyZWFtVmVyYVNhbnMt Um9tYW4KL0VuY29kaW5nIC9JZGVudGl0eS1ICi9EZXNjZW5kYW50Rm9udHMgWzM1MiAwIFJdCi9U b1VuaWNvZGUgMzUzIDAgUj4+CmVuZG9iagoyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyAK Wwo1IDAgUgoyMyAwIFIKNjQgMCBSCjgxIDAgUgo5MyAwIFIKMTA3IDAgUgoxMjIgMCBSCjE0MCAw IFIKMTU2IDAgUgoxNzAgMCBSCjE4MyAwIFIKMjAyIDAgUgoyMjEgMCBSCjI2NSAwIFIKMjc1IDAg UgpdCi9Db3VudCAxNQovUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUNdCj4+CmVu ZG9iagp4cmVmCjAgMzU1CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAwOSAwMDAwMCBuIAow MDAwMTY0MzU3IDAwMDAwIG4gCjAwMDAwMDAxOTkgMDAwMDAgbiAKMDAwMDAwMDI5NCAwMDAwMCBu IAowMDAwMDAxMzM5IDAwMDAwIG4gCjAwMDAxNDYwODIgMDAwMDAgbiAKMDAwMDE1NDA0NCAwMDAw MCBuIAowMDAwMTI2MzkwIDAwMDAwIG4gCjAwMDAxNjQyMDYgMDAwMDAgbiAKMDAwMDAwMDMzMSAw MDAwMCBuIAowMDAwMDAwMzgzIDAwMDAwIG4gCjAwMDAwMDA0MzUgMDAwMDAgbiAKMDAwMDAwMDQ4 NyAwMDAwMCBuIAowMDAwMDAwNTM5IDAwMDAwIG4gCjAwMDAwMDA1OTEgMDAwMDAgbiAKMDAwMDAw MDY0MyAwMDAwMCBuIAowMDAwMDAwODY5IDAwMDAwIG4gCjAwMDAwMDExMDAgMDAwMDAgbiAKMDAw MDAwMTY5NyAwMDAwMCBuIAowMDAwMDA1MzM2IDAwMDAwIG4gCjAwMDAwMDE0NjAgMDAwMDAgbiAK MDAwMDAwMTY1NiAwMDAwMCBuIAowMDAwMDEzMTUxIDAwMDAwIG4gCjAwMDAxMTk4MjAgMDAwMDAg biAKMDAwMDAwNTM1NyAwMDAwMCBuIAowMDAwMDA1NDA5IDAwMDAwIG4gCjAwMDAwMDU0NjEgMDAw MDAgbiAKMDAwMDAwNTY4NyAwMDAwMCBuIAowMDAwMDA1OTE5IDAwMDAwIG4gCjAwMDAwMDYxNTQg MDAwMDAgbiAKMDAwMDAwNjM4NyAwMDAwMCBuIAowMDAwMDA2NjE3IDAwMDAwIG4gCjAwMDAwMDY4 NTAgMDAwMDAgbiAKMDAwMDAwNzA3MyAwMDAwMCBuIAowMDAwMDA3MzEzIDAwMDAwIG4gCjAwMDAw MDc1NDMgMDAwMDAgbiAKMDAwMDAwNzc3MyAwMDAwMCBuIAowMDAwMDA4MDAzIDAwMDAwIG4gCjAw MDAwMDgyMzMgMDAwMDAgbiAKMDAwMDAwODQ2MyAwMDAwMCBuIAowMDAwMDA4NjkzIDAwMDAwIG4g CjAwMDAwMDg5MjMgMDAwMDAgbiAKMDAwMDAwOTE1NCAwMDAwMCBuIAowMDAwMDA5Mzg1IDAwMDAw IG4gCjAwMDAwMDk2MTYgMDAwMDAgbiAKMDAwMDAwOTg0NyAwMDAwMCBuIAowMDAwMDEwMDc4IDAw MDAwIG4gCjAwMDAwMTAzMDkgMDAwMDAgbiAKMDAwMDAxMDU0MCAwMDAwMCBuIAowMDAwMDEwNzcx IDAwMDAwIG4gCjAwMDAwMTEwMDkgMDAwMDAgbiAKMDAwMDAxMTI0NyAwMDAwMCBuIAowMDAwMDEx NDg1IDAwMDAwIG4gCjAwMDAwMTE3MTYgMDAwMDAgbiAKMDAwMDAxMTk0NyAwMDAwMCBuIAowMDAw MDEyMTgxIDAwMDAwIG4gCjAwMDAwMTI0MDcgMDAwMDAgbiAKMDAwMDAxMjYzNyAwMDAwMCBuIAow MDAwMDEyODk1IDAwMDAwIG4gCjAwMDAwMTM3MjIgMDAwMDAgbiAKMDAwMDAxODQxMSAwMDAwMCBu IAowMDAwMDEzMjczIDAwMDAwIG4gCjAwMDAwMTM0NzEgMDAwMDAgbiAKMDAwMDAyMDE1OSAwMDAw MCBuIAowMDAwMDE4NDMyIDAwMDAwIG4gCjAwMDAwMTg0NzcgMDAwMDAgbiAKMDAwMDAxODUyOSAw MDAwMCBuIAowMDAwMDE4NTgxIDAwMDAwIG4gCjAwMDAwMTg2MzMgMDAwMDAgbiAKMDAwMDAxODY4 NSAwMDAwMCBuIAowMDAwMDE4NzM3IDAwMDAwIG4gCjAwMDAwMTg5NjMgMDAwMDAgbiAKMDAwMDAx OTIyMSAwMDAwMCBuIAowMDAwMDE5NDc3IDAwMDAwIG4gCjAwMDAwMTk3MDMgMDAwMDAgbiAKMDAw MDAxOTkzMyAwMDAwMCBuIAowMDAwMDIwNTQxIDAwMDAwIG4gCjAwMDAwMjUxMTUgMDAwMDAgbiAK MDAwMDAyMDI4MSAwMDAwMCBuIAowMDAwMDIwNDc5IDAwMDAwIG4gCjAwMDAwMjU5NTQgMDAwMDAg biAKMDAwMDExNDQ3MiAwMDAwMCBuIAowMDAwMTM1ODAyIDAwMDAwIG4gCjAwMDAwMjUxMzYgMDAw MDAgbiAKMDAwMDAyNTE4OCAwMDAwMCBuIAowMDAwMDI1MjMzIDAwMDAwIG4gCjAwMDAwMjU0Nzkg MDAwMDAgbiAKMDAwMDAyNTcxOCAwMDAwMCBuIAowMDAwMDI2MzE3IDAwMDAwIG4gCjAwMDAwMjk0 MjEgMDAwMDAgbiAKMDAwMDAyNjA3NiAwMDAwMCBuIAowMDAwMDI2Mjc2IDAwMDAwIG4gCjAwMDAw MzA3ODggMDAwMDAgbiAKMDAwMDAyOTQ0MiAwMDAwMCBuIAowMDAwMDI5NDg3IDAwMDAwIG4gCjAw MDAwMjk1MzkgMDAwMDAgbiAKMDAwMDAyOTU5MSAwMDAwMCBuIAowMDAwMDI5NjQzIDAwMDAwIG4g CjAwMDAwMjk4NjkgMDAwMDAgbiAKMDAwMDAzMDA5OSAwMDAwMCBuIAowMDAwMDMwMzI2IDAwMDAw IG4gCjAwMDAwMzA1NTcgMDAwMDAgbiAKMDAwMDAzMTE1OSAwMDAwMCBuIAowMDAwMDM1MzQ2IDAw MDAwIG4gCjAwMDAwMzA5MTMgMDAwMDAgbiAKMDAwMDAzMTEwMCAwMDAwMCBuIAowMDAwMDM2OTU4 IDAwMDAwIG4gCjAwMDAwMzUzNjggMDAwMDAgbiAKMDAwMDAzNTQyMSAwMDAwMCBuIAowMDAwMDM1 NDc0IDAwMDAwIG4gCjAwMDAwMzU1MjcgMDAwMDAgbiAKMDAwMDAzNTU4MCAwMDAwMCBuIAowMDAw MDM1ODExIDAwMDAwIG4gCjAwMDAwMzYwMzggMDAwMDAgbiAKMDAwMDAzNjI2OSAwMDAwMCBuIAow MDAwMDM2NDk2IDAwMDAwIG4gCjAwMDAwMzY3MjcgMDAwMDAgbiAKMDAwMDAzNzM1MiAwMDAwMCBu IAowMDAwMDQxMjc0IDAwMDAwIG4gCjAwMDAwMzcwODQgMDAwMDAgbiAKMDAwMDAzNzI4MyAwMDAw MCBuIAowMDAwMDQzMjEyIDAwMDAwIG4gCjAwMDAwNDEyOTYgMDAwMDAgbiAKMDAwMDA0MTM0OSAw MDAwMCBuIAowMDAwMDQxNDAyIDAwMDAwIG4gCjAwMDAwNDE0NTUgMDAwMDAgbiAKMDAwMDA0MTUw OCAwMDAwMCBuIAowMDAwMDQxNTYxIDAwMDAwIG4gCjAwMDAwNDE2MTQgMDAwMDAgbiAKMDAwMDA0 MTg0NSAwMDAwMCBuIAowMDAwMDQyMDc2IDAwMDAwIG4gCjAwMDAwNDIzMDMgMDAwMDAgbiAKMDAw MDA0MjUyNyAwMDAwMCBuIAowMDAwMDQyNzU0IDAwMDAwIG4gCjAwMDAwNDI5ODUgMDAwMDAgbiAK MDAwMDA0MzYxNCAwMDAwMCBuIAowMDAwMDQ3MzU2IDAwMDAwIG4gCjAwMDAwNDMzMzggMDAwMDAg biAKMDAwMDA0MzUzNyAwMDAwMCBuIAowMDAwMDQ5MDMyIDAwMDAwIG4gCjAwMDAwNDczNzggMDAw MDAgbiAKMDAwMDA0NzQzMSAwMDAwMCBuIAowMDAwMDQ3NDg0IDAwMDAwIG4gCjAwMDAwNDc1Mzcg MDAwMDAgbiAKMDAwMDA0NzU5MCAwMDAwMCBuIAowMDAwMDQ3NjQzIDAwMDAwIG4gCjAwMDAwNDc4 NzQgMDAwMDAgbiAKMDAwMDA0ODEwMSAwMDAwMCBuIAowMDAwMDQ4MzI4IDAwMDAwIG4gCjAwMDAw NDg1NjQgMDAwMDAgbiAKMDAwMDA0ODgwNSAwMDAwMCBuIAowMDAwMDQ5NDI2IDAwMDAwIG4gCjAw MDAwNTQwMzAgMDAwMDAgbiAKMDAwMDA0OTE1OCAwMDAwMCBuIAowMDAwMDQ5MzU3IDAwMDAwIG4g CjAwMDAwNTU1OTkgMDAwMDAgbiAKMDAwMDA1NDA1MiAwMDAwMCBuIAowMDAwMDU0MTA1IDAwMDAw IG4gCjAwMDAwNTQxNTggMDAwMDAgbiAKMDAwMDA1NDIxMSAwMDAwMCBuIAowMDAwMDU0NDQ1IDAw MDAwIG4gCjAwMDAwNTQ2NzYgMDAwMDAgbiAKMDAwMDA1NDkwMyAwMDAwMCBuIAowMDAwMDU1MTM0 IDAwMDAwIG4gCjAwMDAwNTUzNjggMDAwMDAgbiAKMDAwMDA1NTk5MyAwMDAwMCBuIAowMDAwMDYw NzE3IDAwMDAwIG4gCjAwMDAwNTU3MjUgMDAwMDAgbiAKMDAwMDA1NTkyNCAwMDAwMCBuIAowMDAw MDYxODcwIDAwMDAwIG4gCjAwMDAwNjA3MzkgMDAwMDAgbiAKMDAwMDA2MDc5MiAwMDAwMCBuIAow MDAwMDYwODQ1IDAwMDAwIG4gCjAwMDAwNjA4OTggMDAwMDAgbiAKMDAwMDA2MDk1MSAwMDAwMCBu IAowMDAwMDYxMTc4IDAwMDAwIG4gCjAwMDAwNjE0MTIgMDAwMDAgbiAKMDAwMDA2MTY0MyAwMDAw MCBuIAowMDAwMDYyMjQ4IDAwMDAwIG4gCjAwMDAwNjY1NzEgMDAwMDAgbiAKMDAwMDA2MTk5NiAw MDAwMCBuIAowMDAwMDYyMTk1IDAwMDAwIG4gCjAwMDAwNjgzOTkgMDAwMDAgbiAKMDAwMDA2NjU5 MyAwMDAwMCBuIAowMDAwMDY2NjQ3IDAwMDAwIG4gCjAwMDAwNjY3MDEgMDAwMDAgbiAKMDAwMDA2 Njc1NSAwMDAwMCBuIAowMDAwMDY2ODA5IDAwMDAwIG4gCjAwMDAwNjY4NjMgMDAwMDAgbiAKMDAw MDA2NjkxNyAwMDAwMCBuIAowMDAwMDY2OTcxIDAwMDAwIG4gCjAwMDAwNjcwMjUgMDAwMDAgbiAK MDAwMDA2NzI1MiAwMDAwMCBuIAowMDAwMDY3NDg1IDAwMDAwIG4gCjAwMDAwNjc3MTggMDAwMDAg biAKMDAwMDA2Nzk0NSAwMDAwMCBuIAowMDAwMDY4MTcyIDAwMDAwIG4gCjAwMDAwNjg3ODEgMDAw MDAgbiAKMDAwMDA3MjY4OSAwMDAwMCBuIAowMDAwMDY4NTI1IDAwMDAwIG4gCjAwMDAwNjg3MTIg MDAwMDAgbiAKMDAwMDA3NDU0MiAwMDAwMCBuIAowMDAwMDcyNzExIDAwMDAwIG4gCjAwMDAwNzI3 NjUgMDAwMDAgbiAKMDAwMDA3MjgxOSAwMDAwMCBuIAowMDAwMDcyODczIDAwMDAwIG4gCjAwMDAw NzI5MjcgMDAwMDAgbiAKMDAwMDA3Mjk4MSAwMDAwMCBuIAowMDAwMDczMDM1IDAwMDAwIG4gCjAw MDAwNzMwODkgMDAwMDAgbiAKMDAwMDA3MzE0MyAwMDAwMCBuIAowMDAwMDczNDAzIDAwMDAwIG4g CjAwMDAwNzM2MzAgMDAwMDAgbiAKMDAwMDA3Mzg2MSAwMDAwMCBuIAowMDAwMDc0MDg4IDAwMDAw IG4gCjAwMDAwNzQzMTUgMDAwMDAgbiAKMDAwMDA3NDkzNiAwMDAwMCBuIAowMDAwMDc4OTc5IDAw MDAwIG4gCjAwMDAwNzQ2NjggMDAwMDAgbiAKMDAwMDA3NDg2NyAwMDAwMCBuIAowMDAwMDg0ODU1 IDAwMDAwIG4gCjAwMDAwNzkwMDEgMDAwMDAgbiAKMDAwMDA3OTA1NSAwMDAwMCBuIAowMDAwMDc5 MTA5IDAwMDAwIG4gCjAwMDAwNzkxNjMgMDAwMDAgbiAKMDAwMDA3OTIxNyAwMDAwMCBuIAowMDAw MDc5MjcxIDAwMDAwIG4gCjAwMDAwNzkzMjUgMDAwMDAgbiAKMDAwMDA3OTM3OSAwMDAwMCBuIAow MDAwMDc5NDMzIDAwMDAwIG4gCjAwMDAwNzk0ODcgMDAwMDAgbiAKMDAwMDA3OTU0MSAwMDAwMCBu IAowMDAwMDc5NTg4IDAwMDAwIG4gCjAwMDAwNzk2NDIgMDAwMDAgbiAKMDAwMDA3OTY5NiAwMDAw MCBuIAowMDAwMDc5NzUwIDAwMDAwIG4gCjAwMDAwNzk4MDQgMDAwMDAgbiAKMDAwMDA3OTg1OCAw MDAwMCBuIAowMDAwMDgwMDg1IDAwMDAwIG4gCjAwMDAwODAzMTIgMDAwMDAgbiAKMDAwMDA4MDUz OSAwMDAwMCBuIAowMDAwMDgwNzY2IDAwMDAwIG4gCjAwMDAwODA5OTMgMDAwMDAgbiAKMDAwMDA4 MTE3NyAwMDAwMCBuIAowMDAwMDgxMzczIDAwMDAwIG4gCjAwMDAwODE1NzYgMDAwMDAgbiAKMDAw MDA4MTc5MCAwMDAwMCBuIAowMDAwMDgyMDAyIDAwMDAwIG4gCjAwMDAwODIxOTggMDAwMDAgbiAK MDAwMDA4MjQwMSAwMDAwMCBuIAowMDAwMDgyNjI1IDAwMDAwIG4gCjAwMDAwODI4NjIgMDAwMDAg biAKMDAwMDA4MzA4MSAwMDAwMCBuIAowMDAwMDgzMzEzIDAwMDAwIG4gCjAwMDAwODM1NDUgMDAw MDAgbiAKMDAwMDA4Mzc2NiAwMDAwMCBuIAowMDAwMDg0MDAwIDAwMDAwIG4gCjAwMDAwODQyMzQg MDAwMDAgbiAKMDAwMDA4NDQ1NiAwMDAwMCBuIAowMDAwMDg0NjUyIDAwMDAwIG4gCjAwMDAwODUz NzMgMDAwMDAgbiAKMDAwMDA5MDI2OCAwMDAwMCBuIAowMDAwMDg0OTgxIDAwMDAwIG4gCjAwMDAw ODUxNjggMDAwMDAgbiAKMDAwMDA5MTAxNCAwMDAwMCBuIAowMDAwMDkwMjkwIDAwMDAwIG4gCjAw MDAwOTAzNDQgMDAwMDAgbiAKMDAwMDA5MDM5OCAwMDAwMCBuIAowMDAwMDkwNjI1IDAwMDAwIG4g CjAwMDAwOTA4MjAgMDAwMDAgbiAKMDAwMDA5MTM3MiAwMDAwMCBuIAowMDAwMDk1OTM0IDAwMDAw IG4gCjAwMDAwOTExNDAgMDAwMDAgbiAKMDAwMDA5MTMyNyAwMDAwMCBuIAowMDAwMTA4Mjg0IDAw MDAwIG4gCjAwMDAwOTU5NTYgMDAwMDAgbiAKMDAwMDA5NjE0MiAwMDAwMCBuIAowMDAwMTAyNzUz IDAwMDAwIG4gCjAwMDAxMDI1MDcgMDAwMDAgbiAKMDAwMDA5NjMzMSAwMDAwMCBuIAowMDAwMDk2 NDQ4IDAwMDAwIG4gCjAwMDAwOTY2MDMgMDAwMDAgbiAKMDAwMDA5Njc1MiAwMDAwMCBuIAowMDAw MDk2OTAzIDAwMDAwIG4gCjAwMDAwOTcwNTIgMDAwMDAgbiAKMDAwMDA5NzI0MyAwMDAwMCBuIAow MDAwMDk3MzkwIDAwMDAwIG4gCjAwMDAwOTc1MzMgMDAwMDAgbiAKMDAwMDA5NzcwNCAwMDAwMCBu IAowMDAwMDk3OTEzIDAwMDAwIG4gCjAwMDAwOTgwNzYgMDAwMDAgbiAKMDAwMDA5ODI4OSAwMDAw MCBuIAowMDAwMDk4NDUyIDAwMDAwIG4gCjAwMDAwOTg2NDEgMDAwMDAgbiAKMDAwMDA5ODgwOCAw MDAwMCBuIAowMDAwMDk5MDI3IDAwMDAwIG4gCjAwMDAwOTkyNDUgMDAwMDAgbiAKMDAwMDA5OTQx NyAwMDAwMCBuIAowMDAwMDk5NjEzIDAwMDAwIG4gCjAwMDAwOTk4MDkgMDAwMDAgbiAKMDAwMDEw MDAyNyAwMDAwMCBuIAowMDAwMTAwMTk5IDAwMDAwIG4gCjAwMDAxMDAzNjEgMDAwMDAgbiAKMDAw MDEwMDUyMyAwMDAwMCBuIAowMDAwMTAwNzQ3IDAwMDAwIG4gCjAwMDAxMDA5MTEgMDAwMDAgbiAK MDAwMDEwMTEwNSAwMDAwMCBuIAowMDAwMTAxMzEzIDAwMDAwIG4gCjAwMDAxMDE1MzEgMDAwMDAg biAKMDAwMDEwMTY3NyAwMDAwMCBuIAowMDAwMTAxODQ1IDAwMDAwIG4gCjAwMDAxMDIwMTcgMDAw MDAgbiAKMDAwMDEwMjE5MyAwMDAwMCBuIAowMDAwMTAyMzY5IDAwMDAwIG4gCjAwMDAxMDI4MTkg MDAwMDAgbiAKMDAwMDEwODYyNCAwMDAwMCBuIAowMDAwMTA5MjU5IDAwMDAwIG4gCjAwMDAxMDg0 MTAgMDAwMDAgbiAKMDAwMDEwODU4NyAwMDAwMCBuIAowMDAwMTA5MjgwIDAwMDAwIG4gCjAwMDAx MDk1NDIgMDAwMDAgbiAKMDAwMDExMzgzMiAwMDAwMCBuIAowMDAwMTE0MDUyIDAwMDAwIG4gCjAw MDAxMTM4MTAgMDAwMDAgbiAKMDAwMDExNDYxMSAwMDAwMCBuIAowMDAwMTE0ODc4IDAwMDAwIG4g CjAwMDAxMTkxNzUgMDAwMDAgbiAKMDAwMDExOTQwMCAwMDAwMCBuIAowMDAwMTE5MTUzIDAwMDAw IG4gCjAwMDAxMTk5NjQgMDAwMDAgbiAKMDAwMDEyMDE3NSAwMDAwMCBuIAowMDAwMTI1MTM3IDAw MDAwIG4gCjAwMDAxMjU1ODIgMDAwMDAgbiAKMDAwMDEyNTExNSAwMDAwMCBuIAowMDAwMTI2NTMz IDAwMDAwIG4gCjAwMDAxMjY3OTkgMDAwMDAgbiAKMDAwMDEzNDcxMSAwMDAwMCBuIAowMDAwMTM0 OTI0IDAwMDAwIG4gCjAwMDAxMzQ2ODkgMDAwMDAgbiAKMDAwMDEzNTk0NSAwMDAwMCBuIAowMDAw MTM2MjE5IDAwMDAwIG4gCjAwMDAxNDQ2NTUgMDAwMDAgbiAKMDAwMDE0NTE2OSAwMDAwMCBuIAow MDAwMTQ0NjMzIDAwMDAwIG4gCjAwMDAxNDYyMzIgMDAwMDAgbiAKMDAwMDE0NjQ5OCAwMDAwMCBu IAowMDAwMTUyOTAyIDAwMDAwIG4gCjAwMDAxNTMzMDYgMDAwMDAgbiAKMDAwMDE1Mjg4MCAwMDAw MCBuIAowMDAwMTU0MTg2IDAwMDAwIG4gCjAwMDAxNTQ0NjEgMDAwMDAgbiAKMDAwMDE2MjcwMyAw MDAwMCBuIAowMDAwMTYzMjQ0IDAwMDAwIG4gCjAwMDAxNjI2ODEgMDAwMDAgbiAKdHJhaWxlcgo8 PAovU2l6ZSAzNTUKL0luZm8gMSAwIFIKL1Jvb3QgMzE1IDAgUgo+PgpzdGFydHhyZWYKMTY0NTY0 CiUlRU9GCg== --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_ Content-Type: text/html; name="draft-ietf-oauth-assertions-10.html" Content-Description: draft-ietf-oauth-assertions-10.html Content-Disposition: attachment; filename="draft-ietf-oauth-assertions-10.html"; size=74202; creation-date="Fri, 18 Jan 2013 22:50:04 GMT"; modification-date="Fri, 18 Jan 2013 22:49:19 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+QXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wPC90aXRs ZT4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9dXRmLTgiPgo8bWV0YSBuYW1lPSJkZXNjcmlwdGlvbiIgY29udGVudD0iQXNzZXJ0aW9u IEZyYW1ld29yayBmb3IgT0F1dGggMi4wIj4KPG1ldGEgbmFtZT0ia2V5d29yZHMiIGNvbnRlbnQ9 Ik9BdXRoLCBTQU1MLCBKV1QsIEFzc2VydGlvbiI+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29u dGVudD0ieG1sMnJmYyB2MS4zNiAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvKSI+CjxzdHlsZSB0 eXBlPSd0ZXh0L2Nzcyc+PCEtLQogICAgICAgIGJvZHkgewogICAgICAgICAgICAgICAgZm9udC1m YW1pbHk6IHZlcmRhbmEsIGNoYXJjb2FsLCBoZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNlcmlmOwog ICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsgY29sb3I6ICMwMDA7IGJhY2tncm91bmQt Y29sb3I6ICNGRkY7CiAgICAgICAgICAgICAgICBtYXJnaW46IDJlbTsKICAgICAgICB9CiAgICAg ICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTog aGVsdmV0aWNhLCBtb25hY28sICJNUyBTYW5zIFNlcmlmIiwgYXJpYWwsIHNhbnMtc2VyaWY7CiAg ICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zdHlsZTogbm9ybWFsOwogICAg ICAgIH0KICAgICAgICBoMSB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3Bh cmVudDsgdGV4dC1hbGlnbjogcmlnaHQ7IH0KICAgICAgICBoMyB7IGNvbG9yOiAjMzMzOyBiYWNr Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICB0ZC5SRkNidWcgewogICAgICAg ICAgICAgICAgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7CiAgICAg ICAgICAgICAgICB3aWR0aDogMzBweDsgaGVpZ2h0OiAzMHB4OyBwYWRkaW5nLXRvcDogMnB4Owog ICAgICAgICAgICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVydGljYWwtYWxpZ246IG1pZGRs ZTsKICAgICAgICAgICAgICAgIGJhY2tncm91bmQtY29sb3I6ICMwMDA7CiAgICAgICAgfQogICAg ICAgIHRkLlJGQ2J1ZyBzcGFuLlJGQyB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9u YWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgdmVyZGFu YSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBjb2xvcjog IzY2NjsKICAgICAgICB9CiAgICAgICAgdGQuUkZDYnVnIHNwYW4uaG90VGV4dCB7CiAgICAgICAg ICAgICAgICBmb250LWZhbWlseTogY2hhcmNvYWwsIG1vbmFjbywgZ2VuZXZhLCAiTVMgU2FucyBT ZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZv bnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtYWxpZ246IGNlbnRlcjsgY29sb3I6ICNGRkY7CiAgICAg ICAgfQoKICAgICAgICB0YWJsZS5UT0NidWcgeyB3aWR0aDogMzBweDsgaGVpZ2h0OiAxNXB4OyB9 CiAgICAgICAgdGQuVE9DYnVnIHsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGNlbnRlcjsg d2lkdGg6IDMwcHg7IGhlaWdodDogMTVweDsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBi YWNrZ3JvdW5kLWNvbG9yOiAjOTAwOwogICAgICAgIH0KICAgICAgICB0ZC5UT0NidWcgYSB7CiAg ICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMg U2FucyBTZXJpZiIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQt d2VpZ2h0OiBib2xkOyBmb250LXNpemU6IHgtc21hbGw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsK ICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVu dDsKICAgICAgICB9CgogICAgICAgIHRkLmhlYWRlciB7CiAgICAgICAgICAgICAgICBmb250LWZh bWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiB4LXNtYWxsOwog ICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246IHRvcDsgd2lkdGg6IDMzJTsKICAgICAgICAg ICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjNjY2OwogICAgICAgIH0KICAg ICAgICB0ZC5hdXRob3IgeyBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyBt YXJnaW4tbGVmdDogNGVtOyB9CiAgICAgICAgdGQuYXV0aG9yLXRleHQgeyBmb250LXNpemU6IHgt c21hbGw7IH0KCiAgICAgICAgLyogaW5mbyBjb2RlIGZyb20gU2FudGFLbGF1c3MgYXQgaHR0cDov L3d3dy5tYWRhYm91dHN0eWxlLmNvbS90b29sdGlwMi5odG1sICovCiAgICAgICAgYS5pbmZvIHsK ICAgICAgICAgICAgICAgIC8qIFRoaXMgaXMgdGhlIGtleS4gKi8KICAgICAgICAgICAgICAgIHBv c2l0aW9uOiByZWxhdGl2ZTsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI0OwogICAgICAgICAg ICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgIH0KICAgICAgICBhLmluZm86aG92 ZXIgewogICAgICAgICAgICAgICAgei1pbmRleDogMjU7CiAgICAgICAgICAgICAgICBjb2xvcjog I0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgYS5pbmZvIHNw YW4geyBkaXNwbGF5OiBub25lOyB9CiAgICAgICAgYS5pbmZvOmhvdmVyIHNwYW4uaW5mbyB7CiAg ICAgICAgICAgICAgICAvKiBUaGUgc3BhbiB3aWxsIGRpc3BsYXkganVzdCBvbiA6aG92ZXIgc3Rh dGUuICovCiAgICAgICAgICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICAgICAgICAgIHBv c2l0aW9uOiBhYnNvbHV0ZTsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGxlcjsKICAg ICAgICAgICAgICAgIHRvcDogMmVtOyBsZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsKICAgICAgICAg ICAgICAgIHBhZGRpbmc6IDJweDsgYm9yZGVyOiAxcHggc29saWQgIzMzMzsKICAgICAgICAgICAg ICAgIGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOwogICAgICAgICAgICAgICAg dGV4dC1hbGlnbjogbGVmdDsKICAgICAgICB9CgogICAgICAgIGEgeyBmb250LXdlaWdodDogYm9s ZDsgfQogICAgICAgIGE6bGluayAgICB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgfQogICAgICAgIGE6dmlzaXRlZCB7IGNvbG9yOiAjNjMzOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgICAgIGE6YWN0aXZlICB7IGNvbG9yOiAjNjMzOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICBwIHsgbWFyZ2luLWxlZnQ6 IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBwLmNvcHlyaWdodCB7IGZvbnQtc2l6 ZTogeC1zbWFsbDsgfQogICAgICAgIHAudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWln aHQ6IGJvbGQ7IG1hcmdpbi1sZWZ0OiAzZW07IH0KICAgICAgICB0YWJsZS50b2MgeyBtYXJnaW46 IDAgMCAwIDNlbTsgcGFkZGluZzogMDsgYm9yZGVyOiAwOyB2ZXJ0aWNhbC1hbGlnbjogdGV4dC10 b3A7IH0KICAgICAgICB0ZC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdodDogYm9s ZDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9CgogICAgICAgIG9sLnRleHQgeyBtYXJnaW4t bGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIHVsLnRleHQgeyBtYXJnaW4t bGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIGxpICAgICAgeyBtYXJnaW4t bGVmdDogM2VtOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDxzcGFueD5zIGFuZCA8YXJ0d29yaz5z LiAqLwogICAgICAgIGVtICAgICB7IGZvbnQtc3R5bGU6IGl0YWxpYzsgfQogICAgICAgIHN0cm9u ZyB7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAgZGZuICAgIHsgZm9udC13ZWlnaHQ6IGJv bGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAgIGNpdGUgICB7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAgIHR0ICAgICB7IGNvbG9yOiAjMDM2 OyB9CiAgICAgICAgdHQsIHByZSwgcHJlIGRmbiwgcHJlIGVtLCBwcmUgY2l0ZSwgcHJlIHNwYW4g ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyIsIENvdXJpZXIsIG1v bm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsKICAgICAgICB9CiAgICAgICAgcHJlIHsKICAgICAg ICAgICAgICAgIHRleHQtYWxpZ246IGxlZnQ7IHBhZGRpbmc6IDRweDsKICAgICAgICAgICAgICAg IGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAgIH0KICAgICAgICBw cmUgZGZuICB7IGNvbG9yOiAjOTAwOyB9CiAgICAgICAgcHJlIGVtICAgeyBjb2xvcjogIzY2Rjsg YmFja2dyb3VuZC1jb2xvcjogI0ZGQzsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgfQogICAgICAgIHBy ZSAua2V5IHsgY29sb3I6ICMzM0M7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAgcHJlIC5p ZCAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSAuc3RyIHsgY29sb3I6ICMwMDA7IGJhY2tn cm91bmQtY29sb3I6ICNDRkY7IH0KICAgICAgICBwcmUgLnZhbCB7IGNvbG9yOiAjMDY2OyB9CiAg ICAgICAgcHJlIC5yZXAgeyBjb2xvcjogIzkwOTsgfQogICAgICAgIHByZSAub3RoIHsgY29sb3I6 ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNGQ0Y7IH0KICAgICAgICBwcmUgLmVyciB7IGJhY2tn cm91bmQtY29sb3I6ICNGQ0M7IH0KCiAgICAgICAgLyogUkZDLTI2MjkgPHRleHR0YWJsZT5zLiAq LwogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCwgdGFibGUuaGVhZGVycywgdGFibGUubm9u ZSB7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsOyB0ZXh0LWFsaWduOiBjZW50ZXI7 IGJvcmRlci13aWR0aDogMnB4OwogICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246IHRvcDsg Ym9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZTsKICAgICAgICB9CiAgICAgICAgdGFibGUuYWxsLCB0 YWJsZS5mdWxsIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsgYm9yZGVyLWNvbG9yOiBibGFjazsgfQog ICAgICAgIHRhYmxlLmhlYWRlcnMsIHRhYmxlLm5vbmUgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0K ICAgICAgICB0aCB7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgYm9yZGVyLWNv bG9yOiBibGFjazsKICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDogMnB4IDJweCAzcHggMnB4 OwogICAgICAgIH0KICAgICAgICB0YWJsZS5hbGwgdGgsIHRhYmxlLmZ1bGwgdGggeyBib3JkZXIt c3R5bGU6IHNvbGlkOyB9CiAgICAgICAgdGFibGUuaGVhZGVycyB0aCB7IGJvcmRlci1zdHlsZTog bm9uZSBub25lIHNvbGlkIG5vbmU7IH0KICAgICAgICB0YWJsZS5ub25lIHRoIHsgYm9yZGVyLXN0 eWxlOiBub25lOyB9CiAgICAgICAgdGFibGUuYWxsIHRkIHsKICAgICAgICAgICAgICAgIGJvcmRl ci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogIzMzMzsKICAgICAgICAgICAgICAgIGJvcmRl ci13aWR0aDogMXB4IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuZnVsbCB0ZCwgdGFibGUu aGVhZGVycyB0ZCwgdGFibGUubm9uZSB0ZCB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQoKICAgICAg ICBociB7IGhlaWdodDogMXB4OyB9CiAgICAgICAgaHIuaW5zZXJ0IHsKICAgICAgICAgICAgICAg IHdpZHRoOiA4MCU7IGJvcmRlci1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiAwOwogICAgICAg ICAgICAgICAgY29sb3I6ICNDQ0M7IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7CiAgICAgICAgfQot LT48L3N0eWxlPgo8L2hlYWQ+Cjxib2R5Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSI2NiUiIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkPjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxs c3BhY2luZz0iMSI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+T0F1dGggV29ya2luZyBHcm91cDwv dGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkIuIENhbXBiZWxsPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNz PSJoZWFkZXIiPkludGVybmV0LURyYWZ0PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+UGluZzwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjazwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkMuIE1vcnRpbW9yZTwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iaGVhZGVyIj5FeHBpcmVzOiBKdWx5IDIyLCAyMDEzPC90ZD48dGQgY2xhc3M9Imhl YWRlciI+U2FsZXNmb3JjZTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8 L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5NLiBKb25lczwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0i aGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ZLiBHb2xhbmQ8L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+TWlj cm9zb2Z0PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNs YXNzPSJoZWFkZXIiPkphbnVhcnkgMTgsIDIwMTM8L3RkPjwvdHI+CjwvdGFibGU+PC90ZD48L3Ry PjwvdGFibGU+CjxoMT48YnIgLz5Bc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjA8YnIg Lz5kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMTA8L2gxPgoKPGgzPkFic3RyYWN0PC9oMz4K CjxwPlRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhlIHVzZSBv ZgogICAgICBhc3NlcnRpb25zIHdpdGggT0F1dGggMi4wIGluIHRoZSBmb3JtIG9mIGEgbmV3IGNs aWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gYW5kIGEgbmV3IGF1dGhvcml6YXRpb24gZ3Jh bnQgdHlwZS4KCSAgICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yIHRyYW5zcG9ydGluZyBh c3NlcnRpb25zIGR1cmluZwogICAgICBpbnRlcmFjdGlvbnMgd2l0aCBhIHRva2VuIGVuZHBvaW50 LCBhcyB3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy4KPC9wPgo8cD5UaGUgaW50ZW50 IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29tbW9uIGZyYW1ld29yayBm b3IgT0F1dGggMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNp bmcgYXNzZXJ0aW9ucywgYW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbXMuCjwvcD4KPHA+Tm90ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBv bmx5IGRlZmluZXMgYWJzdHJhY3QgbWVzc2FnZSBmbG93cyBhbmQgcHJvY2Vzc2luZwoJICAgICAg cnVsZXMuICBJbiBvcmRlciB0byBiZSBpbXBsZW1lbnRhYmxlLCBjb21wYW5pb24gc3BlY2lmaWNh dGlvbnMgYXJlIG5lY2Vzc2FyeSB0byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5nCgkgICAgICBj b25jcmV0ZSBpbnN0YW50aWF0aW9ucy4KICAgICAgCjwvcD4KPGgzPlN0YXR1cyBvZiB0aGlzIE1l bW88L2gzPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgIGluIGZ1bGwKY29u Zm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AmbmJzcDs3OCBhbmQgQkNQJm5ic3A7 NzkuPC9wPgo8cD4KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcKVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt RHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudApJbnRlcm5ldC1EcmFmdHMgaXMgYXQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3A+CjxwPgpJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMKYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkgdGltZS4KSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlCnRoZW0gb3RoZXIgdGhhbiBh cyAmbGRxdW87d29yayBpbiBwcm9ncmVzcy4mcmRxdW87PC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBKdWx5IDIyLCAyMDEzLjwvcD4KCjxoMz5Db3B5cmlnaHQgTm90 aWNlPC9oMz4KPHA+CkNvcHlyaWdodCAoYykgMjAxMyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29u cyBpZGVudGlmaWVkIGFzIHRoZQpkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZl ZC48L3A+CjxwPgpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsClByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKKGh0 dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mCnB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50cwpjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3Ry aWN0aW9ucyB3aXRoIHJlc3BlY3QKdG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21wb25lbnRzIGV4 dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAppbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKdGhlIFRydXN0IExlZ2Fs IFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCmRlc2NyaWJl ZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3A+CjxhIG5hbWU9InRvYyI+PC9hPjxi ciAvPjxociAvPgo8aDM+VGFibGUgb2YgQ29udGVudHM8L2gzPgo8cCBjbGFzcz0idG9jIj4KPGEg aHJlZj0iI292ZXJ2aWV3Ij4xLjwvYT4mbmJzcDsKSW50cm9kdWN0aW9uPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNJbnRlcm9wZXJhYmlsaXR5Ij4xLjEuPC9hPiZuYnNw OwpJbnRlcm9wZXJhYmlsaXR5IENvbnNpZGVyYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNybmMiPjIu PC9hPiZuYnNwOwpUZXJtaW5vbG9neTxiciAvPgo8YSBocmVmPSIjZnJhbWV3b3JrIj4zLjwvYT4m bmJzcDsKRnJhbWV3b3JrPGJyIC8+CjxhIGhyZWY9IiN0cmFuc3BvcnRpbmciPjQuPC9hPiZuYnNw OwpUcmFuc3BvcnRpbmcgQXNzZXJ0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjYXV0aGdyYW50cyI+NC4xLjwvYT4mbmJzcDsKVXNpbmcgQXNzZXJ0aW9ucyBhcyBB dXRob3JpemF0aW9uIEdyYW50czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMSI+NC4xLjEuPC9hPiZuYnNwOwpFcnJv ciBSZXNwb25zZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NsaWVu dGF1dGgiPjQuMi48L2E+Jm5ic3A7ClVzaW5nIEFzc2VydGlvbnMgZm9yIENsaWVudCBBdXRoZW50 aWNhdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSIjYW5jaG9yMiI+NC4yLjEuPC9hPiZuYnNwOwpFcnJvciBSZXNwb25zZXM8 YnIgLz4KPGEgaHJlZj0iI2NvbnRlbnRwcm9jZXNzaW5nIj41LjwvYT4mbmJzcDsKQXNzZXJ0aW9u IENvbnRlbnQgYW5kIFByb2Nlc3Npbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjMiPjUuMS48L2E+Jm5ic3A7CkFzc2VydGlvbiBNZXRhbW9kZWw8YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjUuMi48L2E+Jm5ic3A7 CkdlbmVyYWwgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSdWxlczxiciAvPgo8YSBo cmVmPSIjYW5jaG9yNSI+Ni48L2E+Jm5ic3A7ClNwZWNpZmljIEFzc2VydGlvbiBGb3JtYXQgYW5k IFByb2Nlc3NpbmcgUnVsZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i I2FuY2hvcjYiPjYuMS48L2E+Jm5ic3A7CkNsaWVudCBBdXRoZW50aWNhdGlvbjxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNyI+Ni4yLjwvYT4mbmJzcDsKQ2xp ZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgSXRzZWxmPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3I4Ij42LjMuPC9hPiZuYnNwOwpDbGllbnQgQWN0aW5nIG9uIEJl aGFsZiBvZiBhIFVzZXI8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Fu Y2hvcjkiPjYuNC48L2E+Jm5ic3A7CkNsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGFuIEFub255 bW91cyBVc2VyPGJyIC8+CjxhIGhyZWY9IiNTZWN1cml0eSI+Ny48L2E+Jm5ic3A7ClNlY3VyaXR5 IENvbnNpZGVyYXRpb25zPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3IxMCI+Ny4xLjwvYT4mbmJzcDsKRm9yZ2VkIEFzc2VydGlvbjxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTEiPjcuMi48L2E+Jm5ic3A7ClN0b2xlbiBB c3NlcnRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjEy Ij43LjMuPC9hPiZuYnNwOwpVbmF1dGhvcml6ZWQgRGlzY2xvc3VyZSBvZiBQZXJzb25hbCBJbmZv cm1hdGlvbjxiciAvPgo8YSBocmVmPSIjYW5jaG9yMTMiPjguPC9hPiZuYnNwOwpJQU5BIENvbnNp ZGVyYXRpb25zPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3Ix NCI+OC4xLjwvYT4mbmJzcDsKYXNzZXJ0aW9uIFBhcmFtZXRlciBSZWdpc3RyYXRpb248YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE1Ij44LjIuPC9hPiZuYnNw OwpjbGllbnRfYXNzZXJ0aW9uIFBhcmFtZXRlciBSZWdpc3RyYXRpb248YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE2Ij44LjMuPC9hPiZuYnNwOwpjbGllbnRf YXNzZXJ0aW9uX3R5cGUgUGFyYW1ldGVyIFJlZ2lzdHJhdGlvbjxiciAvPgo8YSBocmVmPSIjcmZj LnJlZmVyZW5jZXMxIj45LjwvYT4mbmJzcDsKUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj45LjEuPC9hPiZuYnNwOwpOb3Jt YXRpdmUgUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj cmZjLnJlZmVyZW5jZXMyIj45LjIuPC9hPiZuYnNwOwpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJy IC8+CjxhIGhyZWY9IiNhbmNob3IxOSI+QXBwZW5kaXgmbmJzcDtBLjwvYT4mbmJzcDsKQWNrbm93 bGVkZ2VtZW50czxiciAvPgo8YSBocmVmPSIjYW5jaG9yMjAiPkFwcGVuZGl4Jm5ic3A7Qi48L2E+ Jm5ic3A7CkRvY3VtZW50IEhpc3Rvcnk8YnIgLz4KPGEgaHJlZj0iI3JmYy5hdXRob3JzIj4mIzE2 Nzs8L2E+Jm5ic3A7CkF1dGhvcnMnIEFkZHJlc3NlczxiciAvPgo8L3A+CjxiciBjbGVhcj0iYWxs IiAvPgoKPGEgbmFtZT0ib3ZlcnZpZXciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xIj48 L2E+PGgzPjEuJm5ic3A7CkludHJvZHVjdGlvbjwvaDM+Cgo8cD5PQXV0aCAyLjAgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNSRkM2NzQ5Jz5bUkZDNjc0OV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZy YW1ld29yaywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4gaXMgYW4gYXV0aG9yaXphdGlvbiBmcmFtZXdvcmsgdGhhdCBlbmFibGVzIGEgdGhpcmQtcGFy dHkKICAgICAgICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8gYSBwcm90 ZWN0ZWQgSFRUUCByZXNvdXJjZS4gSW4gT0F1dGgsIHRob3NlIHRoaXJkLXBhcnR5CiAgICAgICAg YXBwbGljYXRpb25zIGFyZSBjYWxsZWQgY2xpZW50czsgdGhleSBhY2Nlc3MgcHJvdGVjdGVkIHJl c291cmNlcyBieSBwcmVzZW50aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgSFRUUCByZXNvdXJj ZS4KICAgICAgICBBY2Nlc3MgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gY2xpZW50cyBieSBhbgogICAg ICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggdGhlIChzb21ldGltZXMgaW1wbGljaXQpIGFw cHJvdmFsIG9mIHRoZQogICAgICAgIHJlc291cmNlIG93bmVyLiBUaGVzZSBhY2Nlc3MgdG9rZW5z IGFyZSB0eXBpY2FsbHkgb2J0YWluZWQgYnkKICAgICAgICBleGNoYW5naW5nIGFuIGF1dGhvcml6 YXRpb24gZ3JhbnQsIHdoaWNoIHJlcHJlc2VudHMgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnRlZCBi eSB0aGUKICAgICAgICByZXNvdXJjZSBvd25lciAob3IgYnkgYSBwcml2aWxlZ2VkIGFkbWluaXN0 cmF0b3IpLiBTZXZlcmFsIGF1dGhvcml6YXRpb24KICAgICAgICBncmFudCB0eXBlcyBhcmUgZGVm aW5lZCB0byBzdXBwb3J0IGEgd2lkZSByYW5nZSBvZiBjbGllbnQgdHlwZXMgYW5kCiAgICAgICAg dXNlciBleHBlcmllbmNlcy4gT0F1dGggYWxzbyBwcm92aWRlcyBhbiBleHRlbnNpYmlsaXR5IG1l Y2hhbmlzbSBmb3IgZGVmaW5pbmcgYWRkaXRpb25hbAogICAgICAgIGdyYW50IHR5cGVzLCB3aGlj aCBjYW4gc2VydmUgYXMgYSBicmlkZ2UgYmV0d2VlbiBPQXV0aCBhbmQgb3RoZXIgcHJvdG9jb2wg ZnJhbWV3b3Jrcy4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIHBy b3ZpZGVzIGEgZ2VuZXJhbCBmcmFtZXdvcmsgZm9yIHRoZSB1c2Ugb2YKICAgICAgICBhc3NlcnRp b25zIGFzIGF1dGhvcml6YXRpb24gZ3JhbnRzIHdpdGggT0F1dGggMi4wLiBJdCBhbHNvIHByb3Zp ZGVzIGEgZnJhbWV3b3JrIGZvciBhc3NlcnRpb25zIHRvCiAgICAgICAgYmUgdXNlZCBmb3IgY2xp ZW50IGF1dGhlbnRpY2F0aW9uLgogICAgICAgIEl0IHByb3ZpZGVzIGdlbmVyaWMgbWVjaGFuaXNt cyBmb3IgdHJhbnNwb3J0aW5nCiAgICAgICAgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25z IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyB0b2tlbiBlbmRwb2ludCwgYXMgd2VsbCBh cyBnZW5lcmFsCiAgICAgICAgcnVsZXMgZm9yIHRoZSBjb250ZW50IGFuZCBwcm9jZXNzaW5nIG9m IHRob3NlIGFzc2VydGlvbnMuIFRoZSBpbnRlbnQKICAgICAgICBpcyB0byBwcm92aWRlIGFuIGFs dGVybmF0aXZlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gKG9uZSB0aGF0IGRvZXNu J3Qgc2VuZCBjbGllbnQgc2VjcmV0cyksCiAgICAgICAgYXMgd2VsbCBhcyB0byBmYWNpbGl0YXRl IHRoZSB1c2Ugb2YgT0F1dGgKICAgICAgICAyLjAgaW4gY2xpZW50LXNlcnZlciBpbnRlZ3JhdGlv biBzY2VuYXJpb3MsIHdoZXJlIHRoZSBlbmQtdXNlciBtYXkgbm90IGJlIHByZXNlbnQuCiAgICAg IAo8L3A+CjxwPgogICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMgYWJzdHJh Y3QgbWVzc2FnZSBmbG93cyBhbmQgcHJvY2Vzc2luZwoJICAgICAgcnVsZXMuICBJbiBvcmRlciB0 byBiZSBpbXBsZW1lbnRhYmxlLCBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2Fy eSB0byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5nCgkgICAgICBjb25jcmV0ZSBpbnN0YW50aWF0 aW9ucy4KICAgICAgRm9yIGluc3RhbmNlLAogICAgICBTQU1MIDIuMCBCZWFyZXIgQXNzZXJ0aW9u IFByb2ZpbGVzIGZvciBPQXV0aCAyLjAKICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQu aWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXInPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtvYXV0aCYjODIw OTtzYW1sMiYjODIwOTtiZWFyZXJdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNh bXBiZWxsLCBCLiBhbmQgQy4gTW9ydGltb3JlLCAmbGRxdW87U0FNTCAyLjAgQmVhcmVyIEFzc2Vy dGlvbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wLCZyZHF1bzsgTm92ZW1iZXImbmJzcDsyMDEyLjwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4KICAgICAgZGVmaW5lcyBhIGNvbmNyZXRlIGluc3RhbnRp YXRpb24gZm9yIFNBTUwgMi4wIHRva2VucyBhbmQgCiAgICAgIEpTT04gV2ViIFRva2VuIChKV1Qp IEJlYXJlciBUb2tlbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wCiAgICAgIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjSS1ELmlldGYtb2F1dGgtand0LWJlYXJlcic+W0kmIzgyMDk7RC5pZXRmJiM4MjA5 O29hdXRoJiM4MjA5O2p3dCYjODIwOTtiZWFyZXJdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkpvbmVzLCBNLiwgQ2FtcGJlbGwsIEIuLCBhbmQgQy4gTW9ydGltb3JlLCAmbGRxdW87 SlNPTiBXZWIgVG9rZW4gKEpXVCkgQmVhcmVyIFRva2VuIFByb2ZpbGVzIGZvciBPQXV0aCAyLjAs JnJkcXVvOyBEZWNlbWJlciZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPgogICAg ICBkZWZpbmVzIGEgY29uY3JldGUgaW5zdGFudGlhdGlvbiBmb3IgSldUIHRva2Vucy4KICAgICAg CjwvcD4KPHA+CiAgICAgICAgTm90ZTogVGhlIHVzZSBvZiBhc3NlcnRpb25zIGZvciBjbGllbnQK ICAgICAgICBhdXRoZW50aWNhdGlvbiBpcyBvcnRob2dvbmFsIHRvIGFuZCBzZXBhcmFibGUgZnJv bSB1c2luZyBhc3NlcnRpb25zIGFzIGFuCiAgICAgICAgYXV0aG9yaXphdGlvbiBncmFudC4gIFRo ZXkgY2FuIGJlIHVzZWQgZWl0aGVyIGluIGNvbWJpbmF0aW9uIG9yIHNlcGFyYXRlbHkuCiAgICAg ICAgQ2xpZW50IGFzc2VydGlvbiBhdXRoZW50aWNhdGlvbiBpcyBub3RoaW5nIG1vcmUgdGhhbiBh biBhbHRlcm5hdGl2ZSB3YXkgZm9yIGEgY2xpZW50IHRvIGF1dGhlbnRpY2F0ZQogICAgICAgIHRv IHRoZSB0b2tlbiBlbmRwb2ludCBhbmQgbXVzdCBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGgg c29tZSBncmFudCB0eXBlIHRvIGZvcm0gYSBjb21wbGV0ZSBhbmQKICAgICAgICBtZWFuaW5nZnVs IHByb3RvY29sIHJlcXVlc3QuIEFzc2VydGlvbiBhdXRob3JpemF0aW9uIGdyYW50cyBtYXkgYmUg dXNlZCB3aXRoIG9yIHdpdGhvdXQgY2xpZW50IGF1dGhlbnRpY2F0aW9uCiAgICAgICAgb3IgaWRl bnRpZmljYXRpb24uIFdoZXRoZXIgb3Igbm90IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBuZWVk ZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhbiBhc3NlcnRpb24gYXV0aG9yaXphdGlvbgogICAgICAg IGdyYW50LCBhcyB3ZWxsIGFzIHRoZSBzdXBwb3J0ZWQgdHlwZXMgb2YgY2xpZW50IGF1dGhlbnRp Y2F0aW9uLCBhcmUgcG9saWN5IGRlY2lzaW9ucyBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgIAo8L3A+CjxhIG5hbWU9IkludGVyb3BlcmFiaWxpdHki PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjEiPjwvYT48aDM+MS4xLiZuYnNwOwpJbnRl cm9wZXJhYmlsaXR5IENvbnNpZGVyYXRpb25zPC9oMz4KCjxwPgoJICBUaGlzIHNwZWNpZmljYXRp b24gZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgdXNpbmcgYXNzZXJ0aW9ucwoJICB3aXRoIE9BdXRo IDIuMC4gIEhvd2V2ZXIsIGFzIGFuIGFic3RyYWN0IGZyYW1ld29yayBpbiB3aGljaAoJICB0aGUg ZGF0YSBmb3JtYXRzIHVzZWQgZm9yIHJlcHJlc2VudGluZyBtYW55IHZhbHVlcyBhcmUgbm90Cgkg IGRlZmluZWQsIG9uIGl0cyBvd24sIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBub3Qgc3VmZmljaWVu dCB0bwoJICBwcm9kdWNlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLgoJCjwvcD4KPHA+ CgkgIFR3byBvdGhlciBzcGVjaWZpY2F0aW9ucyB0aGF0IHByb2ZpbGUgdGhpcyBmcmFtZXdvcmsg Zm9yCgkgIHNwZWNpZmljIGFzc2VydGlvbiBoYXZlIGJlZW4gZGV2ZWxvcGVkOgoJICBvbmUgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXInPltJJiM4MjA5 O0QuaWV0ZiYjODIwOTtvYXV0aCYjODIwOTtzYW1sMiYjODIwOTtiZWFyZXJdPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbXBiZWxsLCBCLiBhbmQgQy4gTW9ydGltb3JlLCAmbGRx dW87U0FNTCAyLjAgQmVhcmVyIEFzc2VydGlvbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wLCZyZHF1 bzsgTm92ZW1iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4KCSAgdXNlcyBT QU1MIDIuMC1iYXNlZCBhc3NlcnRpb25zIGFuZAoJICB0aGUgb3RoZXIgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC1qd3QtYmVhcmVyJz5bSSYjODIwOTtELmlldGYmIzgyMDk7 b2F1dGgmIzgyMDk7and0JiM4MjA5O2JlYXJlcl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+Sm9uZXMsIE0uLCBDYW1wYmVsbCwgQi4sIGFuZCBDLiBNb3J0aW1vcmUsICZsZHF1bztK U09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9rZW4gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMCwm cmRxdW87IERlY2VtYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CgkgIHVz ZXMgSlNPTiBXZWIgVG9rZW5zIChKV1RzKS4gIFRoZXNlIHR3byBpbnN0YW50aWF0aW9ucyBvZgoJ ICB0aGlzIGZyYW1ld29yayBzcGVjaWZ5IGFkZGl0aW9uYWwgZGV0YWlscyBhYm91dCB0aGUKCSAg YXNzZXJ0aW9uIGVuY29kaW5nIGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGZvciB1c2luZyB0aG9zZQoJ ICBraW5kcyBvZiBhc3NlcnRpb25zIHdpdGggT0F1dGggMi4wLgoJCjwvcD4KPHA+CgkgIEhvd2V2 ZXIsIGV2ZW4gd2hlbiBwcm9maWxlZCBmb3Igc3BlY2lmaWMgYXNzZXJ0aW9uIHR5cGVzLAoJICBh ZGRpdGlvbmFsIHByb2ZpbGluZyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpbGwgYmUgcmVxdWly ZWQKCSAgdG8gYWNoaWV2ZSBmdWxsIGludGVyb3BlcmFiaWxpdHkuICBEZXBsb3ltZW50cyBmb3IK CSAgcGFydGljdWxhciB0cnVzdCBmcmFtZXdvcmtzLCBjaXJjbGVzIG9mIHRydXN0LCBvciBvdGhl ciB1c2VzCgkgIGNhc2VzIHdpbGwgbmVlZCB0byBhZ3JlZSBhbW9uZyB0aGUgcGFydGljaXBhbnRz IG9uIHRoZSBraW5kcwoJICBvZiB2YWx1ZXMgdG8gYmUgdXNlZCBmb3Igc29tZSBhYnN0cmFjdCBm aWVsZHMgZGVmaW5lZCBieQoJICB0aGlzIHNwZWNpZmljYXRpb24uICBGb3IgZXhhbXBsZSB0aGUg dmFsdWVzIG9mIElzc3VlciwKCSAgU3ViamVjdCwgYW5kIEF1ZGllbmNlIGZpZWxkcyBtaWdodCBi ZSBVUkxzLCBVUklzLCBmdWxseQoJICBxdWFsaWZpZWQgZG9tYWluIG5hbWVzLCBPQXV0aCBjbGll bnQgSURzLCBJUCBhZGRyZXNzZXMsIG9yCgkgIG90aGVyIHZhbHVlcywgZGVwZW5kaW5nIHVwb24g dGhlIHJlcXVpcmVtZW50cyBvZiB0aGUKCSAgcGFydGljdWxhciB1c2UgY2FzZS4gIFRoZSB2ZXJp ZmljYXRpb24gcnVsZXMgZm9yIHNvbWUgdmFsdWVzCgkgIHdpbGwgYWxzbyBiZSB1c2UgY2FzZSBz cGVjaWZpYy4KCQo8L3A+CjxwPgoJICBUaGlzIGZyYW1ld29yayB3YXMgZGVzaWduZWQgd2l0aCB0 aGUgY2xlYXIgZXhwZWN0YXRpb24gdGhhdAoJICBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHdp bGwgZGVmaW5lIHByZXNjcmlwdGl2ZSBwcm9maWxlcwoJICBhbmQgZXh0ZW5zaW9ucyBuZWNlc3Nh cnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2FsZQoJICBpbnRlcm9wZXJhYmlsaXR5IGZvciBwYXJ0 aWN1bGFyIHVzZSBjYXNlcy4KCQo8L3A+CjxhIG5hbWU9InJuYyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjIiPjwvYT48aDM+Mi4mbmJzcDsKVGVybWlub2xvZ3k8L2gzPgoKPHA+VGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLAogICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcwogICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjExOSc+W1JGQzIx MTldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJyYWRuZXIsIFMuLCAmbGRxdW87 S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMs JnJkcXVvOyBNYXJjaCZuYnNwOzE5OTcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiAuCjwvcD4K PHA+VGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LCB2YWx1ZXMgYXJlIHF1b3RlZCB0byBpbmRpY2F0 ZSB0aGF0IHRoZXkgYXJlCiAgICAgIHRvIGJlIHRha2VuIGxpdGVyYWxseS4gV2hlbiB1c2luZyB0 aGVzZSB2YWx1ZXMgaW4gcHJvdG9jb2wgbWVzc2FnZXMsIHRoZSAgICAgICAgICAKICAgICAgcXVv dGVzIG11c3Qgbm90IGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgdmFsdWUuCjwvcD4KPGEgbmFtZT0i ZnJhbWV3b3JrIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMyI+PC9hPjxoMz4zLiZuYnNw OwpGcmFtZXdvcms8L2gzPgoKPHA+CiAgICBBbiBhc3NlcnRpb24gaXMgYSBwYWNrYWdlIG9mIGlu Zm9ybWF0aW9uIHRoYXQgYWxsb3dzCiAgICBpZGVudGl0eSBhbmQgc2VjdXJpdHkgaW5mb3JtYXRp b24gdG8gYmUgc2hhcmVkIGFjcm9zcyBzZWN1cml0eQogICAgZG9tYWlucy4gQW4gYXNzZXJ0aW9u IHR5cGljYWxseSBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCBhIHN1YmplY3Qgb3IgcHJpbmNp cGFsLAogICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBhcnR5IHRoYXQgaXNzdWVkIHRoZSBhc3Nl cnRpb24gYW5kIHdoZW4gd2FzIGl0IGlzc3VlZCwgYXMgd2VsbCBhcyB0aGUgY29uZGl0aW9ucwog ICAgdW5kZXIgd2hpY2ggdGhlIGFzc2VydGlvbiBpcyB0bwogICAgYmUgY29uc2lkZXJlZCB2YWxp ZCwgc3VjaCBhcyB3aGVuIGFuZCB3aGVyZSBpdCBjYW4gYmUgdXNlZC4gCiAgCjwvcD4KPHA+CiAg ICBUaGUgZW50aXR5IHRoYXQgY3JlYXRlcyBhbmQgc2lnbnMgdGhlIGFzc2VydGlvbiBpcyB0eXBp Y2FsbHkga25vd24gYXMgdGhlICJJc3N1ZXIiIGFuZCB0aGUgZW50aXR5IHRoYXQKICAgIGNvbnN1 bWVzIHRoZSBhc3NlcnRpb24gYW5kIHJlbGllcyBvbiBpdHMgaW5mb3JtYXRpb24gaXMgdHlwaWNh bGx5IGtub3duIGFzIHRoZSAiUmVseWluZyBQYXJ0eSIuICBJbiB0aGUgY29udGV4dCBvZgogICAg dGhpcyBkb2N1bWVudCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFjdHMgYXMgYSByZWx5aW5n IHBhcnR5LgogIAo8L3A+CjxwPgogICAgQXNzZXJ0aW9ucyB1c2VkIGluIHRoZSBwcm90b2NvbCBl eGNoYW5nZXMgZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24KICAgIE1VU1QgYWx3YXlzIGJl IHByb3RlY3RlZCBhZ2FpbnN0IHRhbXBlcmluZwogICAgdXNpbmcgYSBkaWdpdGFsIHNpZ25hdHVy ZSBvciBhIGtleWVkIG1lc3NhZ2UgZGlnZXN0IGFwcGxpZWQgYnkgdGhlIGlzc3Vlci4KICAgIEFu IGFzc2VydGlvbiBNQVkgYWRkaXRpb25hbGx5IGJlIGVuY3J5cHRlZCwgcHJldmVudGluZyB1bmF1 dGhvcml6ZWQgcGFydGllcwogICAgZnJvbSBpbnNwZWN0aW5nIHRoZSBjb250ZW50LgogIAo8L3A+ CjxwPgogICAgQWx0aG91Z2ggdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgdGhlIHByb2Nl c3NlcyBieSB3aGljaCB0aGUgY2xpZW50CiAgICBvYnRhaW5zIHRoZSBhc3NlcnRpb24gKHByaW9y IHRvIHNlbmRpbmcgaXQgdG8gdGhlIGF1dGhvcml6YXRpb24KICAgIHNlcnZlciksIHRoZXJlIGFy ZSB0d28gY29tbW9uIHBhdHRlcm5zIGRlc2NyaWJlZCBiZWxvdy4KICAKPC9wPgo8cD4KICAgIElu IHRoZSBmaXJzdCBwYXR0ZXJuLAogICAgZGVwaWN0ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0aGlyZC1wYXJ0eS1jcmVhdGVkJz5GaWd1cmUmbmJzcDsxPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPlRoaXJkIFBhcnR5IENyZWF0ZWQgQXNzZXJ0aW9uPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiwgdGhlIGNsaWVudCBvYnRhaW5zCiAgICBhbiBhc3NlcnRpb24gZnJvbSBhIHRo aXJkIHBhcnR5IGVudGl0eSBjYXBhYmxlIG9mIGlzc3VpbmcsIHJlbmV3aW5nLCB0cmFuc2Zvcm1p bmcsIGFuZCB2YWxpZGF0aW5nIHNlY3VyaXR5IHRva2Vucy4KICAgIFR5cGljYWxseSBzdWNoIGFu IGVudGl0eSBpcyBrbm93biBhcyBhICJTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIiAoU1RTKSBvciBq dXN0ICJUb2tlbiBTZXJ2aWNlIiBhbmQKICAgIGEgdHJ1c3QgcmVsYXRpb25zaGlwICh1c3VhbGx5 IG1hbmlmZXN0ZWQgaW4gdGhlIGV4Y2hhbmdlIG9mIHNvbWUga2luZCBvZiBrZXkgbWF0ZXJpYWwp CiAgICBleGlzdHMgYmV0d2VlbiB0aGUgdG9rZW4gc2VydmljZSBhbmQgdGhlIHJlbHlpbmcgcGFy dHkuCiAgICBUaGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlcjsgaXRzIHJv bGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQgdmFy aW91cyBjcmVkZW50aWFscywgYW5kCiAgICBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVzdGVkLCBm aWxsIHRoZW0gd2l0aCBhcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4KICAg IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjT0FTSVMuV1MtVHJ1c3QnPldTLVRydXN0PHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5hZGFsaW4sIEEuLCBFZC4sIEdvb2RuZXIsIE0uLCBF ZC4sIEd1ZGdpbiwgTS4sIEVkLiwgQmFyYmlyLCBBLiwgRWQuLCBhbmQgSC4gR3JhbnF2aXN0LCBF ZC4sICZsZHF1bztXUy1UcnVzdCwmcmRxdW87IEZlYiZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiBbT0FTSVMuV1MmIzgyMDk7VHJ1c3RdIGlzIG9uZSBhdmFpbGFibGUgc3RhbmRh cmQgZm9yIHJlcXVlc3Rpbmcgc2VjdXJpdHkgdG9rZW5zIChhc3NlcnRpb25zKS4KICAKPC9wPgo8 cD4KCSA8YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0idGhpcmQtcGFydHktY3Jl YXRlZCI+PC9hPgo8L3A+CjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIFJlbHlpbmcKICBQYXJ0 eSAgICAgICAgICAgICAgICAgICAgIENsaWVudCAgICAgICAgICAgICAgICAgICBUb2tlbiBTZXJ2 aWNlCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEpIFJlcXVlc3QgQXNzZXJ0 aW9uICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSZndDt8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDIpIEFzc2Vy dGlvbiAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICB8ICAgIDMpIEFzc2VydGlvbiAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgIDQpIE9LIG9yIEZhaWx1cmUg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3wgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwKPC9wcmU+PC9kaXY+PHA+ Cjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249 ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNh bnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzE6IFRoaXJkIFBhcnR5IENy ZWF0ZWQgQXNzZXJ0aW9uJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48 aHIgY2xhc3M9Imluc2VydCIgLz4KCgkJCjwvcD4KPHA+CiAgICBJbiB0aGUgc2Vjb25kIHBhdHRl cm4sIGRlcGljdGVkIGluICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3NlbGYtaXNzdWVkJz5GaWd1 cmUmbmJzcDsyPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlNlbGYtSXNzdWVkIEFz c2VydGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIHRoZSBjbGllbnQgY3JlYXRlcyBhc3Nl cnRpb25zCiAgICBsb2NhbGx5LiAgVG8gc2lnbiB0aGUgYXNzZXJ0aW9ucywgaXQgaGFzIHRvIG9i dGFpbiBrZXkgbWF0ZXJpYWw6CiAgICBlaXRoZXIgc3ltbWV0cmljIGtleXMgb3IgYXN5bW1ldHJp YyBrZXkgcGFpcnMuCiAgICBUaGUgbWVjaGFuaXNtcyBmb3Igb2J0YWluaW5nIHRoaXMga2V5IG1h dGVyaWFsIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAKPC9w Pgo8cD4KICAgIEFsdGhvdWdoIGFzc2VydGlvbnMgYXJlIHVzdWFsbHkgdXNlZCB0byBjb252ZXkg aWRlbnRpdHkgYW5kIHNlY3VyaXR5IGluZm9ybWF0aW9uLAogICAgc2VsZi1pc3N1ZWQgYXNzZXJ0 aW9ucyBjYW4gYWxzbyBzZXJ2ZSBhIGRpZmZlcmVudCBwdXJwb3NlLiBUaGV5IGNhbiBiZSB1c2Vk IHRvIGRlbW9uc3RyYXRlIGtub3dsZWRnZSBvZiBzb21lIHNlY3JldCwgc3VjaCBhcyBhIGNsaWVu dCBzZWNyZXQsIHdpdGhvdXQgYWN0dWFsbHkKICAgIGNvbW11bmljYXRpbmcgdGhlIHNlY3JldCBk aXJlY3RseSBpbiB0aGUgdHJhbnNhY3Rpb24uIEluIHRoYXQgY2FzZSwgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBpbmNsdWRlZCBpbiB0aGUKICAgIGFzc2VydGlvbiBieSB0aGUgY2xpZW50IGl0c2Vs ZiB3aWxsIGJlIG9mIGxpbWl0ZWQgdmFsdWUgdG8gdGhlIHJlbHlpbmcgcGFydHkKICAgIGFuZCwg Zm9yIHRoaXMgcmVhc29uLCBvbmx5IGEgYmFyZSBtaW5pbXVtIG9mIGluZm9ybWF0aW9uIGlzIHR5 cGljYWxseSBpbmNsdWRlZCBpbiBzdWNoIGFuIGFzc2VydGlvbiwgc3VjaCBhcyBpbmZvcm1hdGlv biBhYm91dCBpc3N1aW5nIGFuZCB1c2FnZSBjb25kaXRpb25zLgo8L3A+CjxwPgoJIDxiciAvPjxo ciBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJzZWxmLWlzc3VlZCI+PC9hPgo8L3A+CjxkaXYg c3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2lu LXJpZ2h0OiBhdXRvJz48cHJlPgogIFJlbHlpbmcKICBQYXJ0eSAgICAgICAgICAgICAgICAgICAg IENsaWVudAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAxKSBDcmVhdGUKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgQXNzZXJ0aW9uCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0t LS0tLS0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8CiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8IDIpIEFzc2VydGlvbiB8CiAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0rCiAgICB8ICAgIDMpIEFzc2Vy dGlvbiAgICAgICAgICB8CiAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgIDQpIE9LIG9yIEZhaWx1cmUgICAg ICB8CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8CiAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CjwvcHJlPjwv ZGl2PjxwPgo8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNv LCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDsyOiBTZWxmLUlz c3VlZCBBc3NlcnRpb24mbmJzcDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48L3RhYmxlPjxo ciBjbGFzcz0iaW5zZXJ0IiAvPgoKCQkKPC9wPgo8cD5EZXBsb3ltZW50cyBuZWVkIHRvCiAgICBk ZXRlcm1pbmUgdGhlIGFwcHJvcHJpYXRlIHZhcmlhbnQgdG8gdXNlIGJhc2VkIG9uIHRoZSByZXF1 aXJlZCBsZXZlbCBvZiBzZWN1cml0eSwgdGhlIHRydXN0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZSBlbnRpdGllcywgYW5kIG90aGVyIGZhY3RvcnMuCiAgCjwvcD4KPHA+CiAgICBGcm9tIHRoZSBw ZXJzcGVjdGl2ZSBvZiB3aGF0IG11c3QgYmUgZG9uZSBieSB0aGUgZW50aXR5IHByZXNlbnRpbmcg dGhlIGFzc2VydGlvbiwgdGhlcmUgYXJlIHR3byBnZW5lcmFsIHR5cGVzIG9mIGFzc2VydGlvbnM6 CiAgICA8L3A+CjxvbCBjbGFzcz0idGV4dCI+CjxsaT5CZWFyZXIgQXNzZXJ0aW9uczogIEFueSBl bnRpdHkgaW4KICAgICAgIHBvc3Nlc3Npb24gb2YgYSBiZWFyZXIgYXNzZXJ0aW9uIChlLmcuIHRo ZSBiZWFyZXIpIGNhbiB1c2UgaXQgdG8gZ2V0IGFjY2VzcyB0bwogICAgICAgdGhlIGFzc29jaWF0 ZWQgcmVzb3VyY2VzICh3aXRob3V0IGRlbW9uc3RyYXRpbmcgcG9zc2Vzc2lvbiBvZiBhCiAgICAg ICBjcnlwdG9ncmFwaGljIGtleSkuICBUbyBwcmV2ZW50IG1pc3VzZSwgYmVhcmVyIGFzc2VydGlv bnMgbmVlZCB0byBiZQogICAgICAgcHJvdGVjdGVkIGZyb20gZGlzY2xvc3VyZSBpbiBzdG9yYWdl IGFuZCBpbiB0cmFuc3BvcnQuIEEgc2VjdXJlIGNvbW11bmljYXRpb24gY2hhbm5lbCBpcyByZXF1 aXJlZAogICAgICAgIGJldHdlZW4gYWxsIGVudGl0aWVzIHRvIGF2b2lkIGxlYWtpbmcgdGhlIGFz c2VydGlvbiB0byB1bmF1dGhvcml6ZWQgcGFydGllcy4KPC9saT4KPGxpPkhvbGRlci1vZi1LZXkg QXNzZXJ0aW9uczoKICAgICAgVG8gYWNjZXNzIHRoZSBhc3NvY2lhdGVkIHJlc291cmNlcywgdGhl IGVudGl0eSBwcmVzZW50aW5nIHRoZSBhc3NlcnRpb24gbXVzdCBkZW1vbnN0cmF0ZSBwb3NzZXNz aW9uIG9mIGFkZGl0aW9uYWwgY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbC4KICAgICAgVGhlIHRva2Vu IHNlcnZpY2UgdGhlcmVieSBiaW5kcyBhIGtleSBpZGVudGlmaWVyIHRvIHRoZSBhc3NlcnRpb24K ICAgICAgYW5kIHRoZSBjbGllbnQgaGFzIHRvIGRlbW9uc3RyYXRlIHRvIHRoZSByZWx5aW5nIHBh cnR5IHRoYXQgaXQga25vd3MgdGhlIGtleSBjb3JyZXNwb25kaW5nIHRvIHRoYXQKICAgICAgaWRl bnRpZmllciB3aGVuIHByZXNlbnRpbmcgdGhlIGFzc2VydGlvbi4gVGhpcyBtZWNoYW5pc20gcHJv dmlkZXMgYWRkaXRpb25hbCBzZWN1cml0eSBwcm9wZXJ0aWVzLgo8L2xpPgo8L29sPjxwPgoKICAg IFRoZSBwcm90b2NvbCBwYXJhbWV0ZXJzIGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudCBhcmUgaW50ZW5kZWQgdG8gc3VwcG9ydAogICAgYSBjbGllbnQgcHJlc2Vu dGluZyBhIGJlYXJlciBhc3NlcnRpb24gdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB1 c2Ugb2YgaG9sZGVyLW9mLWtleSBhc3NlcnRpb25zIGFyZSBub3QgcHJlY2x1ZGVkIGJ5IHRoaXMg ZG9jdW1lbnQsIGJ1dAogICAgYWRkaXRpb25hbCBwcm90b2NvbCBkZXRhaWxzIHdvdWxkIG5lZWQg dG8gYmUgc3BlY2lmaWVkLgogIAo8L3A+CjxhIG5hbWU9InRyYW5zcG9ydGluZyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjQiPjwvYT48aDM+NC4mbmJzcDsKVHJhbnNwb3J0aW5nIEFzc2Vy dGlvbnM8L2gzPgoKPHA+CiAgICAgICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgSFRUUCBwYXJhbWV0 ZXJzIGZvciB0cmFuc3BvcnRpbmcKICAgICAgICBhc3NlcnRpb25zIGR1cmluZyBpbnRlcmFjdGlv bnMgd2l0aCBhIHRva2VuIGVuZHBvaW50IG9mIGFuIE9BdXRoIGF1dGhvcml6YXRpb24gc2VydmVy LgogICAgICAgIEJlY2F1c2UgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBp biB0aGUgdHJhbnNtaXNzaW9uIG9mCiAgICAgICAgY2xlYXItdGV4dCBjcmVkZW50aWFscyAoaW4g Ym90aCB0aGUgSFRUUCByZXF1ZXN0IGFuZCByZXNwb25zZSksIGFsbCByZXF1ZXN0cyB0byB0aGUK ICAgICAgICB0b2tlbiBlbmRwb2ludCBNVVNUIHVzZSBUTFMsIGFzIG1hbmRhdGVkIGluIFNlY3Rp b24gMy4yIG9mIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAy LjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmssJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM2NzQ5XS4KCSAgCjwvcD4KPGEgbmFtZT0iYXV0aGdy YW50cyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMSI+PC9hPjxoMz40LjEuJm5ic3A7 ClVzaW5nIEFzc2VydGlvbnMgYXMgQXV0aG9yaXphdGlvbiBHcmFudHM8L2gzPgoKPHA+VGhpcyBz ZWN0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiBhc3NlcnRpb25zIGFzIGF1dGhvcml6YXRpb24gZ3Jh bnRzLAogICAgICAgIGJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIHByb3ZpZGVkIGluIFNlY3Rpb24g NC41IG9mIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAg QXV0aG9yaXphdGlvbiBGcmFtZXdvcmssJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM2NzQ5XS4KCQkgICAgV2hlbiB1c2luZyBhc3NlcnRpb25z IGFzIGF1dGhvcml6YXRpb24gZ3JhbnRzLCB0aGUgY2xpZW50CiAgICAgICAgaW5jbHVkZXMgdGhl IGFzc2VydGlvbiBhbmQgcmVsYXRlZCBpbmZvcm1hdGlvbiB1c2luZyB0aGUgZm9sbG93aW5nIEhU VFAgcmVxdWVzdAogICAgICAgIHBhcmFtZXRlcnM6CjwvcD4KPHA+PC9wPgo8YmxvY2txdW90ZSBj bGFzcz0idGV4dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD5SRVFVSVJFRC4gVGhlIGZv cm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzCiAgICAgICAgICAgIGRlZmluZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZQogICAgICAgICAg ICBVUkkuCjwvZGQ+CjxkdD5hc3NlcnRpb248L2R0Pgo8ZGQ+UkVRVUlSRUQuIFRoZSBhc3NlcnRp b24gYmVpbmcgdXNlZCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGdyYW50LiBTcGVj aWZpYyBzZXJpYWxpemF0aW9uIG9mIHRoZSBhc3NlcnRpb24gaXMKICAgICAgICAgICAgZGVmaW5l ZCBieSBwcm9maWxlIGRvY3VtZW50cy4gVGhlIHNlcmlhbGl6YXRpb24gTVVTVCBiZSBlbmNvZGVk CiAgICAgICAgICAgIGZvciB0cmFuc3BvcnQgd2l0aGluIEhUVFAgZm9ybXMuIEl0IGlzIFJFQ09N TUVOREVEIHRoYXQgYmFzZTY0dXJsCiAgICAgICAgICAgIGJlIHVzZWQuCjwvZGQ+CjxkdD5zY29w ZTwvZHQ+CjxkZD5PUFRJT05BTC4gVGhlIHJlcXVlc3RlZCBzY29wZSBhcwogICAgICAgICAgICBk ZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMgb2YgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM2NzQ5 Jz5PQXV0aAogICAgICAgICAgICAyLjA8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yaywm cmRxdW87IE9jdG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzY3 NDldLiBXaGVuCiAgICAgICAgICAgIGV4Y2hhbmdpbmcgYXNzZXJ0aW9ucyBmb3IgYWNjZXNzIHRv a2VucywgdGhlIGF1dGhvcml6YXRpb24gZm9yIHRoZQogICAgICAgICAgICB0b2tlbiBoYXMgYmVl biBwcmV2aW91c2x5IGdyYW50ZWQgdGhyb3VnaCBzb21lIG91dC1vZi1iYW5kIG1lY2hhbmlzbS4g QXMKICAgICAgICAgICAgc3VjaCwgdGhlIHJlcXVlc3RlZCBzY29wZSBNVVNUIGJlIGVxdWFsIG9y IGxlc3NlciB0aGFuIHRoZSBzY29wZQogICAgICAgICAgICBvcmlnaW5hbGx5IGdyYW50ZWQgdG8g dGhlIGF1dGhvcml6ZWQgYWNjZXNzb3IuIElmIHRoZSBzY29wZQogICAgICAgICAgICBwYXJhbWV0 ZXIgYW5kL29yIHZhbHVlIGFyZSBvbWl0dGVkLCB0aGUgc2NvcGUgTVVTVCBiZSB0cmVhdGVkIGFz CiAgICAgICAgICAgIGVxdWFsIHRvIHRoZSBzY29wZSBvcmlnaW5hbGx5IGdyYW50ZWQgdG8gdGhl IGF1dGhvcml6ZWQgYWNjZXNzb3IuCiAgICAgICAgICAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZl ciBNVVNUIGxpbWl0IHRoZSBzY29wZSBvZiB0aGUgaXNzdWVkCiAgICAgICAgICAgIGFjY2VzcyB0 b2tlbiB0byBiZSBlcXVhbCBvciBsZXNzZXIgdGhhbiB0aGUgc2NvcGUgb3JpZ2luYWxseQogICAg ICAgICAgICBncmFudGVkIHRvIHRoZSBhdXRob3JpemVkIGFjY2Vzc29yLgo8L2RkPgo8L2RsPjwv YmxvY2txdW90ZT4KCjxwPlRoZSBmb2xsb3dpbmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9u c3RyYXRlcyBhbiBhc3NlcnRpb24gYmVpbmcKICAgICAgICB1c2VkIGFzIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQKCSh3aXRoIGV4dHJhIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVm dDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEK ICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gt d3d3LWZvcm0tdXJsZW5jb2RlZAoKICBjbGllbnRfaWQ9czZCaGRSa3F0MyZhbXA7CiAgZ3JhbnRf dHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGglM0FncmFudC10eXBlJTNBc2FtbDItYmVh cmVyJmFtcDsKICBhc3NlcnRpb249UEhOaGJXeHdPbC4uLltvbWl0dGVkIGZvciBicmV2aXR5XS4u LlpUNAo8L3ByZT48L2Rpdj4KPHA+QW4gYXNzZXJ0aW9uIHVzZWQgaW4gdGhpcyBjb250ZXh0IGlz IGdlbmVyYWxseSBhIHNob3J0IGxpdmVkIHJlcHJlc2VudGF0aW9uCiAgICAgICAgICBvZiB0aGUg YXV0aG9yaXphdGlvbiBncmFudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIFNIT1VMRCBOT1Qg aXNzdWUgYWNjZXNzIHRva2VucyB3aXRoIGEgbGlmZXRpbWUKICAgICAgICAgIHRoYXQgZXhjZWVk cyB0aGUgdmFsaWRpdHkgcGVyaW9kIG9mIHRoZSBhc3NlcnRpb24gYnkgYSBzaWduaWZpY2FudCBw ZXJpb2QuIEluIHByYWN0aWNlLCB0aGF0IHdpbGwKICAgICAgICAgIHVzdWFsbHkgbWVhbiB0aGF0 IHJlZnJlc2ggdG9rZW5zIGFyZSBub3QgaXNzdWVkIGluIHJlc3BvbnNlIHRvIGFzc2VydGlvbgog ICAgICAgICAgZ3JhbnQgcmVxdWVzdHMgYW5kIGFjY2VzcyB0b2tlbnMgd2lsbCBiZSBpc3N1ZWQg d2l0aCBhIHJlYXNvbmFibHkgc2hvcnQgbGlmZXRpbWUuCiAgICAgICAgICBDbGllbnRzIGNhbiBy ZWZyZXNoIGFuIGV4cGlyZWQgYWNjZXNzIHRva2VuIGJ5IHJlcXVlc3RpbmcgYSBuZXcgb25lIHVz aW5nIHRoZSBzYW1lCiAgICAgICAgICBhc3NlcnRpb24sIGlmIGl0IGlzIHN0aWxsIHZhbGlkLCBv ciB3aXRoIGEgbmV3IGFzc2VydGlvbi4KICAgICAgICAKPC9wPgo8cD5BbiBJRUZUIFVSTiBmb3Ig dXNlIGFzIHRoZSA8dHQ+Z3JhbnRfdHlwZTwvdHQ+IHZhbHVlIGNhbiBiZSByZXF1ZXN0ZWQKICAg ICAgICAgIHVzaW5nIHRoZSB0ZW1wbGF0ZSBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzY3 NTUnPkFuIElFVEYgVVJOIFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkNhbXBiZWxsLCBCLiBhbmQgSC4gVHNjaG9mZW5pZywgJmxkcXVvO0Fu IElFVEYgVVJOIFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIw MTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNjc1NV0uCiAgICAgICAgICBBIFVSTiBv ZiB0aGUgZm9ybSB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnRfdHlwZToqIGlzIHN1Z2dlc3Rl ZC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uNC4xLjEiPjwvYT48aDM+NC4xLjEuJm5ic3A7CkVycm9yIFJlc3BvbnNlczwvaDM+Cgo8 cD5JZiBhbiBhc3NlcnRpb24gaXMgbm90IHZhbGlkIG9yIGhhcyBleHBpcmVkLCB0aGUgQXV0aG9y aXphdGlvbiBTZXJ2ZXIKICAgICAgICAgIE1VU1QgY29uc3RydWN0IGFuIGVycm9yIHJlc3BvbnNl IGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM2NzQ5Jz5PQXV0aCAyLjA8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9B dXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yaywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDEy Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzY3NDldLiBUaGUgdmFsdWUgb2YgdGhlIDx0 dD5lcnJvcjwvdHQ+CiAgICAgICAgICBwYXJhbWV0ZXIgTVVTVCBiZSB0aGUgPHR0PmludmFsaWRf Z3JhbnQ8L3R0PiBlcnJvciBjb2RlLiBUaGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgc2VydmVy IE1BWSBpbmNsdWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSByZWFzb25z IHRoZQogICAgICAgICAgYXNzZXJ0aW9uIHdhcyBjb25zaWRlcmVkIGludmFsaWQgdXNpbmcgdGhl IDx0dD5lcnJvcl9kZXNjcmlwdGlvbjwvdHQ+IG9yCiAgICAgICAgICA8dHQ+ZXJyb3JfdXJpPC90 dD4gcGFyYW1ldGVycy4KPC9wPgo8cD5Gb3IgZXhhbXBsZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3Bs YXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRv Jz48cHJlPgogIEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdAogIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24vanNvbgogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCgogIHsKICAgICJlcnJvciI6Imlu dmFsaWRfZ3JhbnQiLAogICAgImVycm9yX2Rlc2NyaXB0aW9uIjoiQXVkaWVuY2UgdmFsaWRhdGlv biBmYWlsZWQiCiAgfQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iY2xpZW50YXV0aCI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjQuMiI+PC9hPjxoMz40LjIuJm5ic3A7ClVzaW5nIEFzc2VydGlv bnMgZm9yIENsaWVudCBBdXRoZW50aWNhdGlvbjwvaDM+Cgo8cD5UaGUgZm9sbG93aW5nIHNlY3Rp b24gZGVmaW5lcyB0aGUgdXNlIG9mIGFzc2VydGlvbnMgYXMgY2xpZW50CiAgICAgICAgY3JlZGVu dGlhbHMgYXMgYW4gZXh0ZW5zaW9uIG9mIFNlY3Rpb24gMi4zIG9mIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjUkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkhhcmR0LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmss JnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM2 NzQ5XS4gV2hlbiB1c2luZwogICAgICAgIGFzc2VydGlvbnMgYXMgY2xpZW50IGNyZWRlbnRpYWxz LCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBhc3NlcnRpb24KICAgICAgICBhbmQgcmVsYXRlZCBp bmZvcm1hdGlvbiB1c2luZyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCBwYXJhbWV0ZXJzOgo8 L3A+CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNsaWVudF9pZDwv ZHQ+CjxkZD5PUFRJT05BTC4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGFzCiAgICAgICAgICAgIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDIuMiBvZiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzY3NDkn Pk9BdXRoCiAgICAgICAgICAgIDIuMDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5I YXJkdCwgRC4sICZsZHF1bztUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrLCZy ZHF1bzsgT2N0b2JlciZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNjc0 OV0uIFdoZW4gcHJlc2VudCwgdGhlIDx0dD5jbGllbnRfaWQ8L3R0PiBNVVNUIGlkZW50aWZ5IHRo ZSBjbGllbnQgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgo8L2RkPgo8ZHQ+Y2xpZW50X2Fz c2VydGlvbl90eXBlPC9kdD4KPGRkPlJFUVVJUkVELiBUaGUgZm9ybWF0IG9mIHRoZQogICAgICAg ICAgICBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRo ZSB2YWx1ZSBNVVNUCiAgICAgICAgICAgIGJlIGFuIGFic29sdXRlIFVSSS4gCjwvZGQ+CjxkdD5j bGllbnRfYXNzZXJ0aW9uPC9kdD4KPGRkPlJFUVVJUkVELiBUaGUgYXNzZXJ0aW9uIGJlaW5nIHVz ZWQKICAgICAgICAgICAgdG8gYXV0aGVudGljYXRlIHRoZSBjbGllbnQuIFNwZWNpZmljIHNlcmlh bGl6YXRpb24gb2YgdGhlCiAgICAgICAgICAgIGFzc2VydGlvbiBpcyBkZWZpbmVkIGJ5IHByb2Zp bGUgZG9jdW1lbnRzLiBUaGUgc2VyaWFsaXphdGlvbiBNVVNUCiAgICAgICAgICAgIGJlIGVuY29k ZWQgZm9yIHRyYW5zcG9ydCB3aXRoaW4gSFRUUCBmb3Jtcy4gSXQgaXMgUkVDT01NRU5ERUQgdGhh dAogICAgICAgICAgICBiYXNlNjR1cmwgYmUgdXNlZC4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+ Cgo8cD5UaGUgZm9sbG93aW5nIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSBkZW1vbnN0cmF0ZXMgYSBj bGllbnQKICAgICAgICBhdXRoZW50aWNhdGluZyB1c2luZyBhbiBhc3NlcnRpb24gZHVyaW5nIGFu CglBY2Nlc3MgVG9rZW4gUmVxdWVzdCwgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4zIG9mCgk8 YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzY3NDknPk9BdXRoIDIuMDxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5IYXJkdCwgRC4sICZsZHF1bztUaGUgT0F1dGggMi4wIEF1dGhvcml6 YXRpb24gRnJhbWV3b3JrLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiBbUkZDNjc0OV0KCSh3aXRoIGV4dHJhIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5 IHB1cnBvc2VzIG9ubHkpOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CiAgUE9TVCAvdG9r ZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50LVR5cGU6IGFw cGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZAoKICBncmFudF90eXBlPWF1dGhvcml6YXRp b25fY29kZSZhbXA7CiAgY29kZT1pMVdzUm4xdUIxJmFtcDsKICBjbGllbnRfaWQ9czZCaGRSa3F0 MyZhbXA7CiAgY2xpZW50X2Fzc2VydGlvbl90eXBlPXVybiUzQWlldGYlM0FwYXJhbXMlM0FvYXV0 aAogICUzQWNsaWVudC1hc3NlcnRpb24tdHlwZSUzQXNhbWwyLWJlYXJlciZhbXA7CiAgY2xpZW50 X2Fzc2VydGlvbj1QSE5oYlcuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5aVAo8L3ByZT48L2Rp dj4KPHA+VG9rZW4gZW5kcG9pbnRzIGNhbiBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYXNzZXJ0aW9u IGJhc2VkCiAgICAgIGNyZWRlbnRpYWxzIGFuZCBvdGhlciBjbGllbnQgY3JlZGVudGlhbCB0eXBl cyBieSBsb29raW5nIGZvciB0aGUKICAgICAgcHJlc2VuY2Ugb2YgdGhlIDx0dD5jbGllbnRfYXNz ZXJ0aW9uPC90dD4gYW5kCiAgICAgIDx0dD5jbGllbnRfYXNzZXJ0aW9uX3R5cGU8L3R0PiBwYXJh bWV0ZXJzLAogICAgICB3aGljaCB3aWxsIG9ubHkgYmUgcHJlc2VudCB3aGVuIHVzaW5nIGFzc2Vy dGlvbnMgZm9yIGNsaWVudAogICAgICBhdXRoZW50aWNhdGlvbi4KPC9wPgo8cD5BbiBJRUZUIFVS TiBmb3IgdXNlIGFzIHRoZSA8dHQ+Y2xpZW50X2Fzc2VydGlvbl90eXBlPC90dD4gdmFsdWUgbWF5 IGJlIHJlcXVlc3RlZAogICAgICAgIHVzaW5nIHRoZSB0ZW1wbGF0ZSBpbiA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1JGQzY3NTUnPkFuIElFVEYgVVJOIFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbXBiZWxsLCBCLiBhbmQgSC4gVHNjaG9m ZW5pZywgJmxkcXVvO0FuIElFVEYgVVJOIFN1Yi1OYW1lc3BhY2UgZm9yIE9BdXRoLCZyZHF1bzsg T2N0b2JlciZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNjc1NV0uCiAg ICAgICAgQSBVUk4gb2YgdGhlIGZvcm0gdXJuOmlldGY6cGFyYW1zOm9hdXRoOmNsaWVudC1hc3Nl cnRpb24tdHlwZToqIGlzIHN1Z2dlc3RlZC4KICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMiI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMi4xIj48L2E+PGgzPjQuMi4xLiZuYnNwOwpF cnJvciBSZXNwb25zZXM8L2gzPgoKPHA+SWYgYW4gYXNzZXJ0aW9uIGlzIGludmFsaWQgZm9yIGFu eSByZWFzb24gb3IgaWYgbW9yZSB0aGFuIG9uZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtIGlzIHVzZWQsIHRoZSBBdXRob3JpemF0aW9uCiAgICAgIFNlcnZlciBNVVNUIGNvbnN0cnVj dCBhbiBlcnJvciByZXNwb25zZSBhcyBkZWZpbmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj UkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0 LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmssJnJkcXVv OyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM2NzQ5XS4g VGhlIHZhbHVlIG9mIHRoZSA8dHQ+ZXJyb3I8L3R0PgogICAgICBwYXJhbWV0ZXIgTVVTVCBiZSB0 aGUgPHR0PmludmFsaWRfY2xpZW50PC90dD4gZXJyb3IgY29kZS4gVGhlCiAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyIE1BWSBpbmNsdWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5n IHRoZQogICAgICByZWFzb25zIHRoZSBjbGllbnQgYXNzZXJ0aW9uIHdhcyBjb25zaWRlcmVkIGlu dmFsaWQgdXNpbmcgdGhlIDx0dD5lcnJvcl9kZXNjcmlwdGlvbjwvdHQ+CiAgICAgIG9yIDx0dD5l cnJvcl91cmk8L3R0PiBwYXJhbWV0ZXJzLgo8L3A+CjxwPkZvciBleGFtcGxlOgo8L3A+PGRpdiBz dHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4t cmlnaHQ6IGF1dG8nPjxwcmU+CiAgSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0CiAgQ29udGVudC1U eXBlOiBhcHBsaWNhdGlvbi9qc29uCiAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKCiAgewogICAg ImVycm9yIjoiaW52YWxpZF9jbGllbnQiCiAgICAiZXJyb3JfZGVzY3JpcHRpb24iOiJhc3NlcnRp b24gaGFzIGV4cGlyZWQiCiAgfQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iY29udGVudHByb2Nlc3Np bmciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41Ij48L2E+PGgzPjUuJm5ic3A7CkFzc2Vy dGlvbiBDb250ZW50IGFuZCBQcm9jZXNzaW5nPC9oMz4KCjxwPlRoaXMgc2VjdGlvbiBwcm92aWRl cyBhIGdlbmVyYWwgY29udGVudCBhbmQgcHJvY2Vzc2luZyBtb2RlbCBmb3IgdGhlCiAgICAgIHVz ZSBvZiBhc3NlcnRpb25zIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNjc0OSc+T0F1dGgK ICAgICAgMi4wPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0LCBELiwgJmxk cXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmssJnJkcXVvOyBPY3RvYmVy Jm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM2NzQ5XS4KPC9wPgo8YSBu YW1lPSJhbmNob3IzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNS4xIj48L2E+PGgzPjUu MS4mbmJzcDsKQXNzZXJ0aW9uIE1ldGFtb2RlbDwvaDM+Cgo8cD5UaGUgZm9sbG93aW5nIGFyZSBl bnRpdGllcyBhbmQgbWV0YWRhdGEgaW52b2x2ZWQgaW4gdGhlIGlzc3VhbmNlLAogICAgICAgIGV4 Y2hhbmdlLCBhbmQgcHJvY2Vzc2luZyBvZiBhc3NlcnRpb25zIGluIE9BdXRoIDIuMC4gVGhlc2Ug YXJlIGdlbmVyYWwKICAgICAgICB0ZXJtcywgYWJzdHJhY3QgZnJvbSBhbnkgcGFydGljdWxhciBh c3NlcnRpb24gZm9ybWF0LiBNYXBwaW5ncyBvZgogICAgICAgIHRoZXNlIHRlcm1zIGludG8gc3Bl Y2lmaWMgcmVwcmVzZW50YXRpb25zIGFyZSBwcm92aWRlZCBieSBwcm9maWxlcyBvZgogICAgICAg IHRoaXMgc3BlY2lmaWNhdGlvbi4KPC9wPgo8cD48L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0 Ij48ZGw+CjxkdD5Jc3N1ZXI8L2R0Pgo8ZGQ+VGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUg ZW50aXR5IHRoYXQKICAgICAgICAgICAgaXNzdWVkIHRoZSBhc3NlcnRpb24uIEdlbmVyYWxseSB0 aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUKICAgICAgICAgICAga2V5IG1hdGVyaWFs IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4KCSAgICBFeGFtcGxlcyBvZiBpc3N1ZXJz IGFyZSBPQXV0aCBjbGllbnRzICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKQoJICAg IGFuZCB0aGlyZCBwYXJ0eSBzZWN1cml0eSB0b2tlbiBzZXJ2aWNlcy4KPC9kZD4KPGR0PlN1Ympl Y3Q8L2R0Pgo8ZGQ+QSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIHN1YmplY3Qgb2YgdGhlCiAg ICAgICAgICAgIGFzc2VydGlvbi4gV2hlbiB1c2luZyBhc3NlcnRpb25zIGZvciBjbGllbnQgYXV0 aGVudGljYXRpb24sIHRoZQogICAgICAgICAgICBTdWJqZWN0IFNIT1VMRCBiZSB0aGUgPHR0PmNs aWVudF9pZDwvdHQ+IG9mIHRoZSBPQXV0aCBjbGllbnQuIFdoZW4gdXNpbmcKICAgICAgICAgICAg YXNzZXJ0aW9ucyBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50LCB0aGUgU3ViamVjdCBNVVNUIGlk ZW50aWZ5CiAgICAgICAgICAgIGFuIGF1dGhvcml6ZWQgYWNjZXNzb3IgZm9yIHdoaWNoIHRoZSBh Y2Nlc3MgdG9rZW4gaXMgYmVpbmcKICAgICAgICAgICAgcmVxdWVzdGVkICh0eXBpY2FsbHkgdGhl IHJlc291cmNlIG93bmVyLCBvciBhbiBhdXRob3JpemVkCiAgICAgICAgICAgIGRlbGVnYXRlKS4K PC9kZD4KPGR0PkF1ZGllbmNlPC9kdD4KPGRkPkEgdmFsdWUgdGhhdCBpZGVudGlmaWVzIHRoZSBw YXJ0aWVzIGludGVuZGVkIHRvCgkgICAgcHJvY2VzcyB0aGUgYXNzZXJ0aW9uLiAgQW4gYXVkaWVu Y2UgdmFsdWUgTUFZIGJlIHRoZSBVUkwgb2YKICAgICAgICAgICAgdGhlIFRva2VuIEVuZHBvaW50 IGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIgb2YgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM2 NzQ5Jz5PQXV0aCAyLjA8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SGFyZHQsIEQu LCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yaywmcmRxdW87IE9j dG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzY3NDldLgo8L2Rk Pgo8ZHQ+SXNzdWVkIEF0IDwvZHQ+CjxkZD5UaGUgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0aW9u IHdhcwogICAgICAgICAgICBpc3N1ZWQuIFdoaWxlIHRoZSBzZXJpYWxpemF0aW9uIG1heSBkaWZm ZXIgYnkgYXNzZXJ0aW9uIGZvcm1hdCwKICAgICAgICAgICAgdGhpcyBpcyBhbHdheXMgZXhwcmVz c2VkIGluIFVUQyB3aXRoIG5vIHRpbWUgem9uZSBjb21wb25lbnQuCjwvZGQ+CjxkdD5FeHBpcmVz IEF0IDwvZHQ+CjxkZD5UaGUgdGltZSBhdCB3aGljaCB0aGUgYXNzZXJ0aW9uIGV4cGlyZXMuCiAg ICAgICAgICAgIFdoaWxlIHRoZSBzZXJpYWxpemF0aW9uIG1heSBkaWZmZXIgYnkgYXNzZXJ0aW9u IGZvcm1hdCwgdGhpcyBpcwogICAgICAgICAgICBhbHdheXMgZXhwcmVzc2VkIGluIFVUQyB3aXRo IG5vIHRpbWUgem9uZSBjb21wb25lbnQuCjwvZGQ+CjxkdD5Bc3NlcnRpb24gSUQ8L2R0Pgo8ZGQ+ QSBub25jZSBvciB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlCiAgICAgICAgICAgIGFzc2VydGlv bi4gVGhlIEFzc2VydGlvbiBJRCBtYXkgYmUgdXNlZCBieSBpbXBsZW1lbnRhdGlvbnMKICAgICAg ICAgICAgcmVxdWlyaW5nIG1lc3NhZ2UgZGUtZHVwbGljYXRpb24gZm9yIG9uZS10aW1lIHVzZSBh c3NlcnRpb25zLiBBbnkKICAgICAgICAgICAgZW50aXR5IHRoYXQgYXNzaWducyBhbiBpZGVudGlm aWVyIE1VU1QgZW5zdXJlIHRoYXQgdGhlcmUgaXMKICAgICAgICAgICAgbmVnbGlnaWJsZSBwcm9i YWJpbGl0eSB0aGF0IHRoYXQgZW50aXR5IG9yIGFueSBvdGhlciBlbnRpdHkgd2lsbAogICAgICAg ICAgICBhY2NpZGVudGFsbHkgYXNzaWduIHRoZSBzYW1lIGlkZW50aWZpZXIgdG8gYSBkaWZmZXJl bnQgZGF0YQogICAgICAgICAgICBvYmplY3QuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPGEg bmFtZT0iYW5jaG9yNCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMiI+PC9hPjxoMz41 LjIuJm5ic3A7CkdlbmVyYWwgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSdWxlczwv aDM+Cgo8cD5UaGUgZm9sbG93aW5nIGFyZSBnZW5lcmFsIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBy dWxlcyBmb3IgdGhlIHVzZQogICAgICAgIG9mIGFzc2VydGlvbnMgaW4gT0F1dGg6CjwvcD4KPHA+ PC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+VGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4gYW4g SXNzdWVyLiBUaGUgSXNzdWVyIE1VU1QgaWRlbnRpZnkKICAgICAgICAgICAgdGhlIGVudGl0eSB0 aGF0IGlzc3VlZCB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlCiAgICAgICAgICAg IEF1dGhvcml6YXRpb24gU2VydmVyLiBJZiBhbiBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRo ZSBJc3N1ZXIKICAgICAgICAgICAgU0hPVUxEIGJlIHRoZSA8dHQ+Y2xpZW50X2lkPC90dD4uCjwv bGk+CjxsaT5UaGUgYXNzZXJ0aW9uIFNIT1VMRCBjb250YWluIGEgU3ViamVjdC4gVGhlIFN1Ympl Y3QgTVVTVAogICAgICAgICAgICBpZGVudGlmeSBhbiBhdXRob3JpemVkIGFjY2Vzc29yIGZvciB3 aGljaCB0aGUgYWNjZXNzIHRva2VuIGlzIGJlaW5nCiAgICAgICAgICAgIHJlcXVlc3RlZCAodHlw aWNhbGx5IHRoZSByZXNvdXJjZSBvd25lciwgb3IgYW4gYXV0aG9yaXplZAogICAgICAgICAgICBk ZWxlZ2F0ZSkuICBXaGVuIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBpdHNlbGYs IHRoZQogICAgICAgICAgICBTdWJqZWN0IFNIT1VMRCBiZSB0aGUgPHR0PmNsaWVudF9pZDwvdHQ+ Lgo8L2xpPgo8bGk+VGhlIGFzc2VydGlvbiBNVVNUIGNvbnRhaW4gYW4gQXVkaWVuY2UgdGhhdCBp ZGVudGlmaWVzIHRoZQogICAgICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBhcyB0aGUgaW50 ZW5kZWQgYXVkaWVuY2UuIFRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgICAgIFNlcnZlciBNVVNU IHZlcmlmeSB0aGF0IGl0IGlzIGFuIGludGVuZGVkIGF1ZGllbmNlIGZvciB0aGUKICAgICAgICAg ICAgYXNzZXJ0aW9uLiBUaGUgQXVkaWVuY2UgU0hPVUxEIGJlIHRoZSBVUkwgb2YgdGhlIEF1dGhv cml6YXRpb24KICAgICAgICAgICAgU2VydmVyJ3MgVG9rZW4gRW5kcG9pbnQuCjwvbGk+CjxsaT5U aGUgYXNzZXJ0aW9uIE1VU1QgY29udGFpbiBhbiBFeHBpcmVzIEF0IGVudGl0eSB0aGF0IGxpbWl0 cyB0aGUKICAgICAgICAgICAgdGltZSB3aW5kb3cgZHVyaW5nIHdoaWNoIHRoZSBhc3NlcnRpb24g Y2FuIGJlIHVzZWQuIFRoZQogICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZl cmlmeSB0aGF0IHRoZSBleHBpcmF0aW9uIHRpbWUgaGFzIG5vdAogICAgICAgICAgICBwYXNzZWQs IHN1YmplY3QgdG8gYWxsb3dhYmxlIGNsb2NrIHNrZXcgYmV0d2VlbiBzeXN0ZW1zLiBUaGUKICAg ICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlamVjdCBhc3NlcnRpb25zIHdp dGggYW4gRXhwaXJlcyBBdAogICAgICAgICAgICBhdHRyaWJ1dGUgdmFsdWUgdGhhdCBpcyB1bnJl YXNvbmFibHkgZmFyIGluIHRoZSBmdXR1cmUuCjwvbGk+CjxsaT5UaGUgYXNzZXJ0aW9uIE1BWSBj b250YWluIGFuIElzc3VlZCBBdCBlbnRpdHkgY29udGFpbmluZyB0aGUKICAgICAgICAgICAgVVRD IHRpbWUgYXQgd2hpY2ggdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkLgo8L2xpPgo8bGk+VGhlIGFz c2VydGlvbiBNQVkgY29udGFpbiBhbiBBc3NlcnRpb24gSUQuIEFuIEF1dGhvcml6YXRpb24KICAg ICAgICAgICAgU2VydmVyIE1BWSBkaWN0YXRlIHRoYXQgQXNzZXJ0aW9uIElEIGlzIG1hbmRhdG9y eS4KPC9saT4KPGxpPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBh c3NlcnRpb24ncyBzaWduYXR1cmUKICAgICAgICAgICAgdG8gdmVyaWZ5IHRoZSBJc3N1ZXIgb2Yg dGhlIGFzc2VydGlvbi4gVGhlIGFsZ29yaXRobSB1c2VkIHRvIHZhbGlkYXRlIHRoZQogICAgICAg ICAgICBzaWduYXR1cmUsIGFuZCB0aGUgbWVjaGFuaXNtIGZvciBkZXNpZ25hdGluZyB0aGUgc2Vj cmV0IHVzZWQgdG8KICAgICAgICAgICAgZ2VuZXJhdGUgdGhlIGFzc2VydGlvbiwgYXJlIGJleW9u ZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgo8L2xpPgo8L3VsPgoKPGEgbmFtZT0i YW5jaG9yNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYiPjwvYT48aDM+Ni4mbmJzcDsK U3BlY2lmaWMgQXNzZXJ0aW9uIEZvcm1hdCBhbmQgUHJvY2Vzc2luZyBSdWxlczwvaDM+Cgo8cD5U aGUgZm9sbG93aW5nIGNsYXJpZmllcyB0aGUgZm9ybWF0IGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGRl ZmluZWQgaW4KICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0cmFuc3BvcnRpbmcnPlNlY3Rp b24mbmJzcDs0PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRyYW5zcG9ydGluZyBB c3NlcnRpb25zPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBhbmQgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNjb250ZW50cHJvY2Vzc2luZyc+U2VjdGlvbiZuYnNwOzU8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QXNzZXJ0aW9uIENvbnRlbnQgYW5kIFByb2Nlc3Npbmc8L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+CiAgICAgIGZvciBhIG51bWJlciBvZiBjb21tb24gdXNlIGNhc2VzOgo8 L3A+CjxhIG5hbWU9ImFuY2hvcjYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjEiPjwv YT48aDM+Ni4xLiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248L2gzPgoKPHA+V2hlbiBhIGNs aWVudCB1c2VzIGFuIGFzc2VydGlvbiBmb3IgYXV0aGVudGljYXRpb24sIGl0IFNIT1VMRCBkbyBz byBhY2NvcmRpbmcgdG8gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnRhdXRoJz5TZWN0aW9u Jm5ic3A7NC4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlVzaW5nIEFzc2VydGlv bnMgZm9yIENsaWVudCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRo ZSBmb2xsb3dpbmcgZm9ybWF0IGFuZAogICAgICAgIHByb2Nlc3NpbmcgcnVsZXMgYXBwbHk6Cgk8 L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5UaGUgPHR0PmNsaWVudF9hc3NlcnRpb25fdHlwZTwv dHQ+IEhUVFAgcGFyYW1ldGVyIE1VU1QgaWRlbnRpZnkgdGhlCiAgICAgICAgICAgIGFzc2VydGlv biBmb3JtYXQgYmVpbmcgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uCjwvbGk+CjxsaT5UaGUgPHR0 PmNsaWVudF9hc3NlcnRpb248L3R0PiBIVFRQIHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gdGhlIHNl cmlhbGl6ZWQKICAgICAgICAgICAgYXNzZXJ0aW9uIGluIGEgZm9ybWF0IGluZGljYXRlZCBieSB0 aGUgPHR0PmNsaWVudF9hc3NlcnRpb25fdHlwZTwvdHQ+CiAgICAgICAgICAgIHBhcmFtZXRlci4K PC9saT4KPGxpPlRoZSBTdWJqZWN0IFNIT1VMRCBiZSB0aGUgPHR0PmNsaWVudF9pZDwvdHQ+Lgo8 L2xpPgo8bGk+VGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVu dGl0eSB0aGF0IGlzc3VlZAogICAgICAgICAgICAgICB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6 ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgSWYgdGhlCiAgICAgICAgICAgICAgIGFz c2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlIDx0dD5jbGll bnRfaWQ8L3R0Pi4KPC9saT4KPGxpPlRoZSBBdWRpZW5jZSBvZiB0aGUgYXNzZXJ0aW9uIE1VU1Qg aWRlbnRpZnkgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICAgICAgU2VydmVyIGFuZCBTSE9VTEQg YmUgdGhlIFVSTCBvZiB0aGUgVG9rZW4gRW5kcG9pbnQuCjwvbGk+CjxsaT5UaGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIGFzc2VydGlvbidzIHNpZ25hdHVyZSBvciBrZXll ZCBtZXNzYWdlIGRpZ2VzdCB0byBkZXRlcm1pbmUgdGhlIHZhbGlkaXR5IG9mIHRoZSBpc3N1ZXIg YW5kIHRoZSBjb250ZW50IG9mIHRoZSBhc3NlcnRpb24uCjwvbGk+CjwvdWw+Cgo8cD5UaGUgZm9s bG93aW5nIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSBkZW1vbnN0cmF0ZXMgYQogICAgICAgIGNsaWVu dCBhdXRoZW50aWNhdGlvbiB1c2luZyBhbiBhc3NlcnRpb24gZHVyaW5nIGFuCiAgICAgICAgQWNj ZXNzIFRva2VuIFJlcXVlc3QsIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEuMyBvZgoJPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNSRkM2NzQ5Jz5PQXV0aCAyLjA8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9u IEZyYW1ld29yaywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4gW1JGQzY3NDldCgkod2l0aCBleHRyYSBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheSBwdXJw b3NlcyBvbmx5KToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFy Z2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIFBPU1QgL3Rva2VuIEhU VFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBhcHBsaWNh dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQKCiAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2Nv ZGUmYW1wOwogIGNvZGU9aTFXc1JuMXVCMSZhbXA7CiAgY2xpZW50X2lkPXM2QmhkUmtxdDMmYW1w OwogIGNsaWVudF9hc3NlcnRpb25fdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGgKICAl M0FjbGllbnQtYXNzZXJ0aW9uLXR5cGUlM0FzYW1sMi1iZWFyZXImYW1wOwogIGNsaWVudF9hc3Nl cnRpb249UEhOaGIuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5aVDQKPC9wcmU+PC9kaXY+Cjxh IG5hbWU9ImFuY2hvcjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjIiPjwvYT48aDM+ Ni4yLiZuYnNwOwpDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBJdHNlbGY8L2gzPgoKPHA+V2hl biBhIGNsaWVudCBpcyBhY2Nlc3NpbmcgcmVzb3VyY2VzIG9uIGJlaGFsZiBvZiBpdHNlbGYsIGl0 IFNIT1VMRAogICAgICAgIGRvIHNvIGluIGEgbWFubmVyIGFuYWxvZ291cyB0byB0aGUgQ2xpZW50 IENyZWRlbnRpYWxzIGZsb3cgZGVmaW5lZCBpbgogICAgICAgIFNlY3Rpb24gNC40IG9mIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjUkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkhhcmR0LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlv biBGcmFtZXdvcmssJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+IFtSRkM2NzQ5XS4gVGhpcwogICAgICAgIGlzIGEgc3BlY2lhbCBjYXNlIHRoYXQgY29t YmluZXMgYm90aCB0aGUgYXV0aGVudGljYXRpb24gYW5kCiAgICAgICAgYXV0aG9yaXphdGlvbiBn cmFudCB1c2FnZSBwYXR0ZXJucy4gSW4gdGhpcyBjYXNlLCB0aGUgaW50ZXJhY3Rpb25zCiAgICAg ICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgdXNp bmcgYW4gYXNzZXJ0aW9uCiAgICAgICAgZm9yIENsaWVudCBBdXRoZW50aWNhdGlvbiBhY2NvcmRp bmcgdG8gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnRhdXRoJz5TZWN0aW9uJm5ic3A7NC4y PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlVzaW5nIEFzc2VydGlvbnMgZm9yIENs aWVudCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIHdpdGggdGhlIGFk ZGl0aW9uCiAgICAgICAgb2YgYSBncmFudF90eXBlIHBhcmFtZXRlci4gVGhlIGZvbGxvd2luZyBm b3JtYXQgYW5kIHByb2Nlc3NpbmcgcnVsZXMKICAgICAgICBhcHBseToKCTwvcD4KPHVsIGNsYXNz PSJ0ZXh0Ij4KPGxpPlRoZSBncmFudF90eXBlIEhUVFAgcmVxdWVzdCBwYXJhbWV0ZXIgTVVTVCBi ZQogICAgICAgICAgICA8dHQ+Y2xpZW50X2NyZWRlbnRpYWxzPC90dD4uCjwvbGk+CjxsaT5UaGUg PHR0PmNsaWVudF9hc3NlcnRpb25fdHlwZTwvdHQ+IEhUVFAgcGFyYW1ldGVyIE1VU1QgaWRlbnRp ZnkgdGhlCiAgICAgICAgICAgIGFzc2VydGlvbiBmb3JtYXQuCjwvbGk+CjxsaT5UaGUgPHR0PmNs aWVudF9hc3NlcnRpb248L3R0PiBIVFRQIHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gdGhlIHNlcmlh bGl6ZWQKICAgICAgICAgICAgYXNzZXJ0aW9uIGFzIGluIGEgZm9ybWF0IGluZGljYXRlZCBieSB0 aGUgPHR0PmNsaWVudF9hc3NlcnRpb25fdHlwZTwvdHQ+CiAgICAgICAgICAgIHBhcmFtZXRlci4K PC9saT4KPGxpPlRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBl bnRpdHkgdGhhdAogICAgICAgICAgICBpc3N1ZWQgdGhlIGFzc2VydGlvbiBhcyByZWNvZ25pemVk IGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gSWYKICAgICAgICAgICAgdGhlIGFzc2VydGlv biBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlCiAgICAgICAgICAgIDx0 dD5jbGllbnRfaWQ8L3R0Pi4gSWYgdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJp dHkgVG9rZW4KICAgICAgICAgICAgU2VydmljZSAoU1RTKSwgdGhlIElzc3VlciBTSE9VTEQgaWRl bnRpZnkgdGhlIFNUUyBhcyByZWNvZ25pemVkIGJ5IHRoZQogICAgICAgICAgICBBdXRob3JpemF0 aW9uIFNlcnZlci4KPC9saT4KPGxpPlRoZSBTdWJqZWN0IFNIT1VMRCBiZSB0aGUgPHR0PmNsaWVu dF9pZDwvdHQ+Lgo8L2xpPgo8bGk+VGhlIEF1ZGllbmNlIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBp ZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICAgICAgICBTZXJ2ZXIgYW5kIFNIT1VMRCBi ZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KPC9saT4KPGxpPlRoZSBBdXRob3JpemF0 aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24ncyBzaWduYXR1cmUgdG8gdmVy aWZ5IHRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbi4KPC9saT4KPC91bD4KCjxwPlRoZSBmb2xs b3dpbmcgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIGRlbW9uc3RyYXRlcwogICAgICAgIGFuIGFzc2Vy dGlvbiBiZWluZyB1c2VkIGZvciBhIENsaWVudCBDcmVkZW50aWFscyBBY2Nlc3MgVG9rZW4KICAg ICAgICBSZXF1ZXN0LCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC40LjIgb2YKCTxhIGNsYXNzPSdp bmZvJyBocmVmPScjUkZDNjc0OSc+T0F1dGggMi4wPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkhhcmR0LCBELiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFt ZXdvcmssJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ IFtSRkM2NzQ5XQoJKHdpdGggZXh0cmEgbGluZSBicmVha3MgZm9yIGRpc3BsYXkgcHVycG9zZXMg b25seSk6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICBQT1NUIC90b2tlbiBIVFRQLzEu MQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v eC13d3ctZm9ybS11cmxlbmNvZGVkCgogIGNsaWVudF9pZD1zNkJoZFJrcXQzJmFtcDsKICBncmFu dF90eXBlPWNsaWVudF9jcmVkZW50aWFscyZhbXA7CiAgY2xpZW50X2Fzc2VydGlvbl90eXBlPXVy biUzQWlldGYlM0FwYXJhbXMlM0FvYXV0aAogICUzQWNsaWVudC1hc3NlcnRpb24tdHlwZSUzQXNh bWwyLWJlYXJlciZhbXA7CiAgY2xpZW50X2Fzc2VydGlvbj1QSE5oYlcuLi5bb21pdHRlZCBmb3Ig YnJldml0eV0uLi5aVAo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yOCI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjYuMyI+PC9hPjxoMz42LjMuJm5ic3A7CkNsaWVudCBBY3Rpbmcgb24g QmVoYWxmIG9mIGEgVXNlcjwvaDM+Cgo8cD5XaGVuIGEgY2xpZW50IGlzIGFjY2Vzc2luZyByZXNv dXJjZXMgb24gYmVoYWxmIG9mIGEgdXNlciwgaXQgU0hPVUxECiAgICAgICAgYmUgdHJlYXRlZCBh cyB1c2luZyBhbiBhc3NlcnRpb24gYXMgYW4gQXV0aG9yaXphdGlvbiBHcmFudCBhY2NvcmRpbmcK ICAgICAgICB0byA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2F1dGhncmFudHMnPlNlY3Rpb24mbmJz cDs0LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VXNpbmcgQXNzZXJ0aW9ucyBh cyBBdXRob3JpemF0aW9uIEdyYW50czwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZSBmb2xs b3dpbmcgZm9ybWF0IGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGFwcGx5OgoJPC9wPgo8dWwgY2xhc3M9 InRleHQiPgo8bGk+VGhlIGdyYW50X3R5cGUgSFRUUCByZXF1ZXN0IHBhcmFtZXRlciBNVVNUIGlu ZGljYXRlIHRoZQogICAgICAgICAgICBhc3NlcnRpb24gZm9ybWF0Lgo8L2xpPgo8bGk+VGhlIGFz c2VydGlvbiBIVFRQIHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gdGhlIHNlcmlhbGl6ZWQKICAgICAg ICAgICAgYXNzZXJ0aW9uIGFzIGluIGEgZm9ybWF0IGluZGljYXRlZCBieSB0aGUgZ3JhbnRfdHlw ZQogICAgICAgICAgICBwYXJhbWV0ZXIuCjwvbGk+CjxsaT5UaGUgSXNzdWVyIG9mIHRoZSBhc3Nl cnRpb24gTVVTVCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQKICAgICAgICAgICAgaXNzdWVkIHRo ZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIElm CiAgICAgICAgICAgIHRoZSBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hP VUxEIGJlIHRoZQogICAgICAgICAgICA8dHQ+Y2xpZW50X2lkPC90dD4uIElmIHRoZSBhc3NlcnRp b24gd2FzIGlzc3VlZCBieSBhCgkgICAgICAgICAgU2VjdXJpdHkgVG9rZW4gU2VydmljZSAoU1RT KSwgdGhlIElzc3VlciBTSE9VTEQKICAgICAgICAgICAgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNv Z25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9saT4KPGxpPlRoZSBTdWJqZWN0 IE1VU1QgaWRlbnRpZnkgYW4gYXV0aG9yaXplZCBhY2Nlc3NvciBmb3Igd2hpY2ggdGhlCiAgICAg ICAgICAgIGFjY2VzcyB0b2tlbiBpcyBiZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseSB0aGUgcmVz b3VyY2Ugb3duZXIsIG9yCiAgICAgICAgICAgIGFuIGF1dGhvcml6ZWQgZGVsZWdhdGUpLgo8L2xp Pgo8bGk+VGhlIEF1ZGllbmNlIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUgQXV0 aG9yaXphdGlvbgogICAgICAgICAgICBTZXJ2ZXIgYW5kIE1BWSBiZSB0aGUgVVJMIG9mIHRoZSBU b2tlbiBFbmRwb2ludC4KPC9saT4KPGxpPlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZh bGlkYXRlIHRoZSBhc3NlcnRpb24ncyBzaWduYXR1cmUgdG8gdmVyaWZ5IHRoZSBJc3N1ZXIgb2Yg dGhlIGFzc2VydGlvbi4KPC9saT4KPC91bD4KCjxwPlRoZSBmb2xsb3dpbmcgbm9uLW5vcm1hdGl2 ZSBleGFtcGxlIGRlbW9uc3RyYXRlcyBhCiAgICAgICAgY2xpZW50IHVzaW5nIGFuIGFzc2VydGlv biBhcyBhbiBBdXRob3JpemF0aW9uIEdyYW50IGR1cmluZyBhbgogICAgICAgIEFjY2VzcyBUb2tl biBSZXF1ZXN0LCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjMgb2YgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNSRkM2NzQ5Jz5PQXV0aCAyLjA8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29y aywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JG QzY3NDldCgkod2l0aCBleHRyYSBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5 KToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAg SG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3 dy1mb3JtLXVybGVuY29kZWQKCiAgY2xpZW50X2lkPXM2QmhkUmtxdDMmYW1wOwogIGdyYW50X3R5 cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoJTNBZ3JhbnQtdHlwZSUzQXNhbWwyLWJlYXJl ciZhbXA7CiAgYXNzZXJ0aW9uPVBITmhiV3h3T2wuLi5bb21pdHRlZCBmb3IgYnJldml0eV0uLi5a VAo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yOSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjYuNCI+PC9hPjxoMz42LjQuJm5ic3A7CkNsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGFu IEFub255bW91cyBVc2VyPC9oMz4KCjxwPldoZW4gYSBjbGllbnQgaXMgYWNjZXNzaW5nIHJlc291 cmNlcyBvbiBiZWhhbGYgb2YgYW4gYW5vbnltb3VzCiAgICAgICAgdXNlciwgdGhlIGZvbGxvd2lu ZyBmb3JtYXQgYW5kIHByb2Nlc3NpbmcgcnVsZXMgYXBwbHk6Cgk8L3A+Cjx1bCBjbGFzcz0idGV4 dCI+CjxsaT5UaGUgZ3JhbnRfdHlwZSBIVFRQIHJlcXVlc3QgcGFyYW1ldGVyIE1VU1QgaW5kaWNh dGUgdGhlCiAgICAgICAgICAgIGFzc2VydGlvbiBmb3JtYXQuCjwvbGk+CjxsaT5UaGUgYXNzZXJ0 aW9uIEhUVFAgcGFyYW1ldGVyIE1VU1QgY29udGFpbiB0aGUgc2VyaWFsaXplZAogICAgICAgICAg ICBhc3NlcnRpb24gYXMgaW4gYSBmb3JtYXQgaW5kaWNhdGVkIGJ5IHRoZSBncmFudF90eXBlCiAg ICAgICAgICAgIHBhcmFtZXRlci4KPC9saT4KPGxpPlRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlv biBNVVNUIGlkZW50aWZ5IHRoZSBlbnRpdHkgdGhhdAogICAgICAgICAgICBpc3N1ZWQgdGhlIGFz c2VydGlvbiBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gSWYKICAg ICAgICAgICAgdGhlIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQg YmUgdGhlCiAgICAgICAgICAgIDx0dD5jbGllbnRfaWQ8L3R0Pi4gSWYgdGhlIGFzc2VydGlvbiB3 YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4KICAgICAgICAgICAgU2VydmljZSAoU1RTKSwg dGhlIElzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25pemVkIGJ5IHRoZQog ICAgICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlci4KPC9saT4KPGxpPlRoZSBTdWJqZWN0IFNI T1VMRCBpbmRpY2F0ZSB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGhhdAogICAgICAgICAg ICB0aGUgY2xpZW50IGlzIGFjdGluZyBvbi1iZWhhbGYgb2YgYW4gYW5vbnltb3VzIHVzZXIgYXMg ZGVmaW5lZCBieQogICAgICAgICAgICB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIEl0IGlzIGlt cGxpZWQgdGhhdCBhdXRob3JpemF0aW9uIGlzIGJhc2VkCiAgICAgICAgICAgIHVwb24gYWRkaXRp b25hbCBjcml0ZXJpYSwgc3VjaCBhcyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb3IgY2xhaW1zCiAg ICAgICAgICAgIHByb3ZpZGVkIGluIHRoZSBhc3NlcnRpb24uIEZvciBleGFtcGxlLCBhIGNsaWVu dCBtYXkgcHJlc2VudCBhbgogICAgICAgICAgICBhc3NlcnRpb24gZnJvbSBhIHRydXN0ZWQgaXNz dWVyIGFzc2VydGluZyB0aGF0IHRoZSBiZWFyZXIgaXMgb3ZlcgogICAgICAgICAgICAxOCB2aWEg YW4gaW5jbHVkZWQgY2xhaW0uIEluIHRoaXMgY2FzZSwgbm8gYWRkaXRpb25hbCBpbmZvcm1hdGlv bgogICAgICAgICAgICBhYm91dCB0aGUgdXNlcidzIGlkZW50aXR5IGlzIGluY2x1ZGVkIHlldCBh bGwgdGhlIGRhdGEgbmVlZGVkIHRvCiAgICAgICAgICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBp cyBwcmVzZW50Lgo8L2xpPgo8bGk+VGhlIEF1ZGllbmNlIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBp ZGVudGlmeSB0aGUgQXV0aG9yaXphdGlvbgogICAgICAgICAgICBTZXJ2ZXIgYW5kIE1BWSBiZSB0 aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KPC9saT4KPGxpPlRoZSBBdXRob3JpemF0aW9u IFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhc3NlcnRpb24ncyBzaWduYXR1cmUgdG8gdmVyaWZ5 IHRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbi4KPC9saT4KPC91bD4KCjxhIG5hbWU9IlNlY3Vy aXR5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNyI+PC9hPjxoMz43LiZuYnNwOwpTZWN1 cml0eSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD5UaGlzIHNlY3Rpb24gZGlzY3Vzc2VzIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHRoYXQgYXBwbHkgd2hlbiB1c2luZyBhc3NlcnRpb25zIHdpdGgg T0F1dGggMi4wIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgogICAgICBBcyBkaXNjdXNz ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNmcmFtZXdvcmsnPlNlY3Rpb24mbmJzcDszPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZyYW1ld29yazwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4sIHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IHdheXMgdG8gb2J0YWluIGFzc2VydGlv bnM6ICBlaXRoZXIgYXMgc2VsZi1pc3N1ZWQgb3IKICAgICAgICAgb2J0YWluZWQgZnJvbSBhIHRo aXJkIHBhcnR5IHRva2VuIHNlcnZpY2UuCiAgICAgICAgV2hpbGUgdGhlIGFjdHVhbCBpbnRlcmFj dGlvbnMgZm9yIG9idGFpbmluZyBhbiBhc3NlcnRpb24gYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMgZG9jdW1lbnQsCiAgICAgICAgdGhlIGRldGFpbHMgYXJlIGltcG9ydGFudCBmcm9tIGEg c2VjdXJpdHkgcGVyc3BlY3RpdmUuCiAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNmcmFt ZXdvcmsnPlNlY3Rpb24mbmJzcDszPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZy YW1ld29yazwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZGlzY3Vzc2VzIHRoZSBoaWdoIGxldmVs IGFyY2hpdGVjdHVyYWwgYXNwZWN0cy4gIE1hbnkgb2YgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGRpc2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24gYXJlIGFwcGxpY2FibGUgdG8gYm90aCB0aGUg T0F1dGggZXhjaGFuZ2UgYXMgd2VsbCBhcyB0aGUgY2xpZW50IG9idGFpbmluZyB0aGUgYXNzZXJ0 aW9uLiAKPC9wPgo8cD5UaGUgcmVtYWluZGVyIG9mIHRoaXMgc2VjdGlvbiBmb2N1c2VzIG9uIHRo ZSBleGNoYW5nZXMgdGhhdCBjb25jZXJuIHByZXNlbnRpbmcgYW4gYXNzZXJ0aW9uIGZvciBjbGll bnQgYXV0aGVudGljYXRpb24gYW5kIGZvciB0aGUgYXV0aG9yaXphdGlvbiBncmFudC4gCjwvcD4K PGEgbmFtZT0iYW5jaG9yMTAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43LjEiPjwvYT48 aDM+Ny4xLiZuYnNwOwpGb3JnZWQgQXNzZXJ0aW9uPC9oMz4KCjxwPgo8L3A+CjxibG9ja3F1b3Rl IGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5UaHJlYXQ6PC9kdD4KPGRkPgoKICAgICAgQW4gYWR2ZXJz YXJ5IGNvdWxkIGZvcmdlIG9yIGFsdGVyIGFuIGFzc2VydGlvbiBpbiBvcmRlciB0bwogICAgICBv YnRhaW4gYW4gYWNjZXNzIHRva2VuIChpbiBjYXNlIG9mIHRoZSBhdXRob3JpemF0aW9uIGdyYW50 KSBvciB0bwoJICBpbXBlcnNvbmF0ZSBhIGNsaWVudCAoaW4gY2FzZSBvZiB0aGUgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSkuCiAgICAgIDxiciAvPgo8YnIgLz4KCjwvZGQ+CjxkdD5D b3VudGVybWVhc3VyZXM6PC9kdD4KPGRkPgoKICAgICAgVG8gYXZvaWQgdGhpcyBraW5kIG9mIGF0 dGFjaywgdGhlIGVudGl0aWVzIG11c3QgYXNzdXJlIHRoYXQgcHJvcGVyCiAgICAgIG1lY2hhbmlz bXMgZm9yIHByb3RlY3RpbmcgdGhlIGludGVncml0eSBvZiB0aGUgYXNzZXJ0aW9uIGFyZSBlbXBs b3llZC4gVGhpcyBpbmNsdWRlcwoJICB0aGUgaXNzdWVyIGRpZ2l0YWxseSBzaWduaW5nIHRoZSBh c3NlcnRpb24gb3IgY29tcHV0aW5nIGEga2V5ZWQKCSAgbWVzc2FnZSBkaWdlc3Qgb3ZlciB0aGUg YXNzZXJ0aW9uLgoKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+Cgo8L3A+CjxhIG5hbWU9ImFu Y2hvcjExIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNy4yIj48L2E+PGgzPjcuMi4mbmJz cDsKU3RvbGVuIEFzc2VydGlvbjwvaDM+Cgo8cD4KPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4 dCI+PGRsPgo8ZHQ+VGhyZWF0OjwvZHQ+CjxkZD4KCiAgICAgIEFuIGFkdmVyc2FyeSBtYXkgYmUg YWJsZSBvYnRhaW4gYW4gYXNzZXJ0aW9uIChlLmcuLCBieSBlYXZlc2Ryb3BwaW5nKQoJICBhbmQg dGhlbiByZXVzZSBpdCAocmVwbGF5IGl0KSBhdCBhIGxhdGVyIHBvaW50IGluIHRpbWUuCiAgICAg IDxiciAvPgo8YnIgLz4KCjwvZGQ+CjxkdD5Db3VudGVybWVhc3VyZXM6PC9kdD4KPGRkPgogICAg ICAgICAgICBUaGUgcHJpbWFyeSBtaXRpZ2F0aW9uIGZvciB0aGlzIHRocmVhdCBpcyB0aGUgdXNl IG9mIGEgc2VjdXJlIGNvbW11bmljYXRpb24KICAgICAgY2hhbm5lbCB3aXRoIHNlcnZlciBhdXRo ZW50aWNhdGlvbiBmb3IgYWxsIG5ldHdvcmsgZXhjaGFuZ2VzLgogICAgICAgIDxiciAvPgo8YnIg Lz4KCgogICAgICBBbiBhc3NlcnRpb24gbWF5IGFsc28gY29udGFpbiBzZXZlcmFsIGVsZW1lbnRz IHRvIHByZXZlbnQgcmVwbGF5CiAgICAgIGF0dGFja3MuICBUaGVyZSBpcywgaG93ZXZlciwgYSBj bGVhciB0cmFkZW9mZiBiZXR3ZWVuCgkgIHJldXNpbmcgYW4gYXNzZXJ0aW9uIGZvciBtdWx0aXBs ZSBleGNoYW5nZXMgYW5kIG9idGFpbmluZyBhbmQgY3JlYXRpbmcKCSAgbmV3IGZyZXNoIGFzc2Vy dGlvbnMuCgkgIDxiciAvPgo8YnIgLz4KCgoJICBBdXRob3JpemF0aW9uIFNlcnZlcnMgYW5kIFJl c291cmNlIFNlcnZlcnMgbWF5IHVzZSBhIGNvbWJpbmF0aW9uIG9mIHRoZQogICBBc3NlcnRpb24g SUQgYW5kIElzc3VlZCBBdC9FeHBpcmVzIEF0IGF0dHJpYnV0ZXMgZm9yIHJlcGxheSBwcm90ZWN0 aW9uLiAgUHJldmlvdXNseQogICBwcm9jZXNzZWQgYXNzZXJ0aW9ucyBtYXkgYmUgcmVqZWN0ZWQg YmFzZWQgb24gdGhlCiAgIEFzc2VydGlvbiBJRC4gIFRoZSBhZGRpdGlvbiBvZiB0aGUgdmFsaWRp dHkgd2luZG93IHJlbGlldmVzIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBmcm9tIG1haW50 YWluaW5nIGFuIGluZmluaXRlIHN0YXRlIHRhYmxlIG9mCiAgIHByb2Nlc3NlZCBhc3NlcnRpb24g SURzLgoKCiAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KCjwvcD4KPGEgbmFtZT0iYW5j aG9yMTIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43LjMiPjwvYT48aDM+Ny4zLiZuYnNw OwpVbmF1dGhvcml6ZWQgRGlzY2xvc3VyZSBvZiBQZXJzb25hbCBJbmZvcm1hdGlvbjwvaDM+Cgo8 cD4KPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+VGhyZWF0OjwvZHQ+Cjxk ZD4KICAgICAgVGhlIGFiaWxpdHkgZm9yIG90aGVyIGVudGl0aWVzIHRvIG9idGFpbiBpbmZvcm1h dGlvbgogICAgICBhYm91dCBhbiBpbmRpdmlkdWFsLCBzdWNoIGFzIGF1dGhlbnRpY2F0aW9uIGlu Zm9ybWF0aW9uLCByb2xlIGluIGFuIG9yZ2FuaXphdGlvbiwgb3Igb3RoZXIKICAgICAgYXV0aG9y aXphdGlvbiByZWxldmFudCBpbmZvcm1hdGlvbiwgcmFpc2VzIHByaXZhY3kgY29uY2VybnMuCiAg ICAgIDxiciAvPgo8YnIgLz4KCjwvZGQ+CjxkdD5Db3VudGVybWVhc3VyZXM6PC9kdD4KPGRkPgog ICAgICBUbyBhZGRyZXNzIHRoZSB0aHJlYXRzLCB0d28gY2FzZXMgbmVlZCB0byBiZSBkaWZmZXJl bnRpYXRlZDoKCSAgPGJyIC8+CjxiciAvPgoKCiAgICAgIEZpcnN0LCBhIHRoaXJkIHBhcnR5IHRo YXQgZGlkIG5vdCBwYXJ0aWNpcGF0ZSBpbiBhbnkgb2YgdGhlCiAgICAgIGV4Y2hhbmdlIGlzIHBy ZXZlbnRlZCBmcm9tIGVhdmVzZHJvcHBpbmcgb24gdGhlIGNvbnRlbnQgb2YgdGhlCiAgICAgIGFz c2VydGlvbiBieSBlbXBsb3lpbmcgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gb2YgdGhlCiAg ICAgIGV4Y2hhbmdlIHVzaW5nIFRMUy4gIFRoaXMgZW5zdXJlcwogICAgICB0aGF0IGFuIGVhdmVz ZHJvcHBlciBvbiB0aGUgd2lyZSBpcyB1bmFibGUgdG8gb2J0YWluIGluZm9ybWF0aW9uLgogICAg ICBIb3dldmVyLCB0aGlzIGRvZXMgbm90IHByZXZlbnQgbGVnaXRpbWF0ZSBwcm90b2NvbCBlbnRp dGllcwogICAgICBmcm9tIG9idGFpbmluZyBpbmZvcm1hdGlvbiBmcm9tIGFuIGFzc2VydGlvbiB0 aGV5IG1heSBub3QgaGF2ZSBiZWVuCgkgICAgYWxsb3dlZCB0byBvYnRhaW4uIFNvbWUgYXNzZXJ0 aW9uIGZvcm1hdHMgYWxsb3cgZm9yIHRoZSBhc3NlcnRpb24KICAgICAgdG8gYmUgZW5jcnlwdGVk LCBwcmV2ZW50aW5nIHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZyb20gaW5zcGVjdGluZyB0aGUgY29u dGVudC4KCSAgPGJyIC8+CjxiciAvPgoKCgkgIFNlY29uZCwgYW4gQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgbWF5IG9idGFpbiBhbgoJICBhc3NlcnRpb24gdGhhdCB3YXMgY3JlYXRlZCBieSBhIHRoaXJk IHBhcnR5IHRva2VuIHNlcnZpY2UgYW5kIHRoYXQKCSAgdG9rZW4gc2VydmljZSBtYXkgaGF2ZSBw bGFjZWQgYXR0cmlidXRlcyBpbnRvIHRoZSBhc3NlcnRpb24uIFRvCm1pdGlnYXRlIHBvdGVudGlh bCBwcml2YWN5IHByb2JsZW1zLCBwcmlvciBjb25zZW50IGZyb20gdGhlIHJlc291cmNlIG93bmVy CmhhcyB0byBiZSBvYnRhaW5lZC4gIE9BdXRoIGl0c2VsZiBkb2VzIG5vdCBkaXJlY3RseSBwcm92 aWRlIHN1Y2ggY2FwYWJpbGl0aWVzLCBidXQgdGhpcwpjb25zZW50IGFwcHJvdmFsIG1heSBiZSBv YnRhaW5lZCB1c2luZyBvdGhlciBpZGVudGl0eSBtYW5hZ2VtZW50IHByb3RvY29scywKdXNlciBj b25zZW50IGludGVyYWN0aW9ucywKb3IgaW4gYW4gb3V0LW9mLWJhbmQgZmFzaGlvbi4KPGJyIC8+ CjxiciAvPgoKCiAgICAgIEZvciB0aGUgY2FzZXMgd2hlcmUgYSB0aGlyZCBwYXJ0eSB0b2tlbiBz ZXJ2aWNlIGNyZWF0ZXMgYXNzZXJ0aW9ucwp0byBiZSB1c2VkIGZvciBjbGllbnQgYXV0aGVudGlj YXRpb24sIHByaXZhY3kgY29uY2VybnMgYXJlIHR5cGljYWxseSBsb3dlciwKc2luY2UgbWFueSBv ZiB0aGVzZSBjbGllbnRzIGFyZSBXZWIgc2VydmVycyByYXRoZXIgdGhhbiBpbmRpdmlkdWFsIGRl dmljZXMKb3BlcmF0ZWQgYnkgaHVtYW5zLiBJZiB0aGUgYXNzZXJ0aW9ucyBhcmUgdXNlZCBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG9mCmRldmljZXMgb3Igc29mdHdhcmUgdGhhdCBjYW4gYmUg Y2xvc2VseSBsaW5rZWQgdG8gZW5kIHVzZXJzLCB0aGVuIHByaXZhY3kKcHJvdGVjdGlvbiBzYWZl Z3VhcmRzIG5lZWQgdG8gYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLgo8YnIgLz4KPGJyIC8+ CgoKRnVydGhlciBndWlkYW5jZSBvbiBwcml2YWN5IGZyaWVuZGx5IHByb3RvY29sIGRlc2lnbiBj YW4gYmUgZm91bmQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWFiLXByaXZhY3ktY29u c2lkZXJhdGlvbnMnPltJJiM4MjA5O0QuaWFiJiM4MjA5O3ByaXZhY3kmIzgyMDk7Y29uc2lkZXJh dGlvbnNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNvb3BlciwgQS4sIFRzY2hv ZmVuaWcsIEguLCBBYm9iYSwgQi4sIFBldGVyc29uLCBKLiwgTW9ycmlzLCBKLiwgSGFuc2VuLCBN LiwgYW5kIFIuIFNtaXRoLCAmbGRxdW87UHJpdmFjeSBDb25zaWRlcmF0aW9ucyBmb3IgSW50ZXJu ZXQgUHJvdG9jb2xzLCZyZHF1bzsgSnVseSZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPi4KIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KCjwvcD4KPGEgbmFtZT0iYW5jaG9y MTMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44Ij48L2E+PGgzPjguJm5ic3A7CklBTkEg Q29uc2lkZXJhdGlvbnM8L2gzPgoKPHA+VGhpcyBpcyBhIHJlcXVlc3QgdG8gYWRkIHRocmVlIHZh bHVlcywgYXMgbGlzdGVkIGluIHRoZSBzdWItc2VjdGlvbnMgYmVsb3csCiAgICAgICAgICAgICAg dG8gdGhlICJPQXV0aCBQYXJhbWV0ZXJzIiByZWdpc3RyeSBlc3RhYmxpc2hlZCBieSA8YSBjbGFz cz0naW5mbycgaHJlZj0nI1JGQzY3NDknPlJGQyA2NzQ5LjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5IYXJkdCwgRC4sICZsZHF1bztUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24g RnJhbWV3b3JrLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiBbUkZDNjc0OV0KPC9wPgo8YSBuYW1lPSJhbmNob3IxNCI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjguMSI+PC9hPjxoMz44LjEuJm5ic3A7CmFzc2VydGlvbiBQYXJhbWV0ZXIgUmVn aXN0cmF0aW9uPC9oMz4KCjxwPgoJICAgICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+ CjxsaT5QYXJhbWV0ZXIgbmFtZTogYXNzZXJ0aW9uCjwvbGk+CjxsaT5QYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246IHRva2VuIHJlcXVlc3QKCSAgICAgICAgICAgICAgICAKPC9saT4KPGxpPkNoYW5n ZSBjb250cm9sbGVyOiBJRVRGCjwvbGk+CjxsaT5TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBb W3RoaXMgZG9jdW1lbnRdXQo8L2xpPgo8L3VsPjxwPgoJICAgICAgICAgICAgCjwvcD4KPGEgbmFt ZT0iYW5jaG9yMTUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjIiPjwvYT48aDM+OC4y LiZuYnNwOwpjbGllbnRfYXNzZXJ0aW9uIFBhcmFtZXRlciBSZWdpc3RyYXRpb248L2gzPgoKPHA+ CgkgICAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPlBhcmFtZXRlciBuYW1l OiBjbGllbnRfYXNzZXJ0aW9uCjwvbGk+CjxsaT5QYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRv a2VuIHJlcXVlc3QKCSAgICAgICAgICAgICAgICAKPC9saT4KPGxpPkNoYW5nZSBjb250cm9sbGVy OiBJRVRGCjwvbGk+CjxsaT5TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbW3RoaXMgZG9jdW1l bnRdXQo8L2xpPgo8L3VsPjxwPgoJICAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTYi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjMiPjwvYT48aDM+OC4zLiZuYnNwOwpjbGll bnRfYXNzZXJ0aW9uX3R5cGUgUGFyYW1ldGVyIFJlZ2lzdHJhdGlvbjwvaDM+Cgo8cD4KCSAgICAg ICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+UGFyYW1ldGVyIG5hbWU6IGNsaWVu dF9hc3NlcnRpb25fdHlwZQo8L2xpPgo8bGk+UGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tl biByZXF1ZXN0CgkgICAgICAgICAgICAgICAgCjwvbGk+CjxsaT5DaGFuZ2UgY29udHJvbGxlcjog SUVURgo8L2xpPgo8bGk+U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1t0aGlzIGRvY3VtZW50 XV0KPC9saT4KPC91bD48cD4KCSAgICAgICAgICAgIAo8L3A+CjxhIG5hbWU9InJmYy5yZWZlcmVu Y2VzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOSI+PC9hPjxoMz45LiZuYnNwOwpSZWZl cmVuY2VzPC9oMz4KCjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzMSI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxoMz45LjEuJm5i c3A7Tm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gzPgo8dGFibGUgd2lkdGg9Ijk5JSIgYm9yZGVyPSIw Ij4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkMy MTE5Ij5bUkZDMjExOV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+PGEgaHJlZj0i bWFpbHRvOnNvYkBoYXJ2YXJkLmVkdSI+QnJhZG5lciwgUy48L2E+LCAmbGRxdW87PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjExOSI+S2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHM8L2E+LCZyZHF1bzsgQkNQJm5ic3A7 MTQsIFJGQyZuYnNwOzIxMTksIE1hcmNoJm5ic3A7MTk5NyAoPGEgaHJlZj0iaHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjExOS50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMyMTE5Lmh0bWwiPkhUTUw8L2E+LCA8 YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMyMTE5Lnht bCI+WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzY3NDkiPltSRkM2NzQ5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5IYXJkdCwgRC4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5Ij5UaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrPC9h PiwmcmRxdW87IFJGQyZuYnNwOzY3NDksIE9jdG9iZXImbmJzcDsyMDEyICg8YSBocmVmPSJodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2NzQ5LnR4dCI+VFhUPC9hPikuPC90ZD48L3Ry Pgo8L3RhYmxlPgoKPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjkuMi4mbmJz cDtJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0i MCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1E LmlhYi1wcml2YWN5LWNvbnNpZGVyYXRpb25zIj5bSS1ELmlhYi1wcml2YWN5LWNvbnNpZGVyYXRp b25zXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Db29wZXIsIEEuLCBUc2Nob2Zl bmlnLCBILiwgQWJvYmEsIEIuLCBQZXRlcnNvbiwgSi4sIE1vcnJpcywgSi4sIEhhbnNlbiwgTS4s IGFuZCBSLiBTbWl0aCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlhYi1wcml2YWN5LWNvbnNpZGVyYXRpb25zLTAzIj5Qcml2YWN5IENvbnNpZGVyYXRp b25zIGZvciBJbnRlcm5ldCBQcm90b2NvbHM8L2E+LCZyZHF1bzsgZHJhZnQtaWFiLXByaXZhY3kt Y29uc2lkZXJhdGlvbnMtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdWx5Jm5ic3A7MjAxMiAoPGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWFiLXByaXZh Y3ktY29uc2lkZXJhdGlvbnMtMDMudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtb2F1dGgtand0 LWJlYXJlciI+W0ktRC5pZXRmLW9hdXRoLWp3dC1iZWFyZXJdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPkpvbmVzLCBNLiwgQ2FtcGJlbGwsIEIuLCBhbmQgQy4gTW9ydGltb3JlLCAm bGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1qd3QtYmVhcmVyLTA0Ij5KU09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgVG9rZW4gUHJvZmls ZXMgZm9yIE9BdXRoIDIuMDwvYT4sJnJkcXVvOyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIt MDQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBEZWNlbWJlciZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJl ci0wNC50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wNC5wZGYiPlBERjwvYT4pLjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJJ LUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXIiPltJLUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXJd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNhbXBiZWxsLCBCLiBhbmQgQy4gTW9y dGltb3JlLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTUiPlNBTUwgMi4wIEJlYXJlciBBc3NlcnRpb24gUHJv ZmlsZXMgZm9yIE9BdXRoIDIuMDwvYT4sJnJkcXVvOyBkcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJl YXJlci0xNSAod29yayBpbiBwcm9ncmVzcyksIE5vdmVtYmVyJm5ic3A7MjAxMiAoPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC1zYW1s Mi1iZWFyZXItMTUudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xNS5wZGYiPlBERjwv YT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48 YSBuYW1lPSJPQVNJUy5XUy1UcnVzdCI+W09BU0lTLldTLVRydXN0XTwvYT48L3RkPgo8dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij5OYWRhbGluLCBBLiwgRWQuLCBHb29kbmVyLCBNLiwgRWQuLCBHdWRn aW4sIE0uLCBFZC4sIEJhcmJpciwgQS4sIEVkLiwgYW5kIEguIEdyYW5xdmlzdCwgRWQuLCAmbGRx dW87PGEgaHJlZj0iaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvd3Mtc3gvd3MtdHJ1c3QvdjEu NC93cy10cnVzdC5odG1sIj5XUy1UcnVzdDwvYT4sJnJkcXVvOyBGZWImbmJzcDsyMDA5LjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJS RkM2NzU1Ij5bUkZDNjc1NV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Q2FtcGJl bGwsIEIuIGFuZCBILiBUc2Nob2ZlbmlnLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjc1NSI+QW4gSUVURiBVUk4gU3ViLU5hbWVzcGFjZSBmb3IgT0F1dGg8 L2E+LCZyZHF1bzsgUkZDJm5ic3A7Njc1NSwgT2N0b2JlciZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzY3NTUudHh0Ij5UWFQ8L2E+KS48L3RkPjwv dHI+CjwvdGFibGU+Cgo8YSBuYW1lPSJhbmNob3IxOSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLkEiPjwvYT48aDM+QXBwZW5kaXggQS4mbmJzcDsKQWNrbm93bGVkZ2VtZW50czwvaDM+Cgo8 cD5UaGUgYXV0aG9ycyB3aXNoIHRvIHRoYW5rIHRoZSBmb2xsb3dpbmcgcGVvcGxlIHRoYXQgaGF2 ZSBpbmZsdWVuY2VkCiAgICAgIG9yIGNvbnRyaWJ1dGVkIHRoaXMgc3BlY2lmaWNhdGlvbjogUGF1 bCBNYWRzZW4sIEVyaWMgU2FjaHMsIEppYW4gQ2FpLAogICAgICBUb255IE5hZGFsaW4sIEhhbm5l cyBUc2Nob2ZlbmlnLCB0aGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggV1JBUCBzcGVjaWZpY2F0aW9u LAogICAgICBhbmQgdGhlIG1lbWJlcnMgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuCjwvcD4K PGEgbmFtZT0iYW5jaG9yMjAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5CIj48L2E+PGgz PkFwcGVuZGl4IEIuJm5ic3A7CkRvY3VtZW50IEhpc3Rvcnk8L2gzPgoKPHA+CglbWyB0byBiZSBy ZW1vdmVkIGJ5IHRoZSBSRkMgZWRpdG9yIGJlZm9yZSBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgXV0K ICAgICAgCjwvcD4KPHA+CiAgICAgICAgLTEwCiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQi Pgo8bGk+CgkgICAgQ2hhbmdlIHRlcm0gIlByaW5jaXBhbCIgdG8gIlN1YmplY3QiLgoJICAKPC9s aT4KPGxpPgoJICAgIEFkZGVkIEludGVyb3BlcmFiaWxpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv bi4KCSAgCjwvbGk+CjwvdWw+PHA+CiAgICAgIAo8L3A+CjxwPgogICAgICAgIC0wOQogICAgICAg IDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgoJICAgIEFsbG93IGF1ZGllbmNlIHZhbHVlcyB0 byBub3QgYmUgVVJJcy4KCSAgCjwvbGk+CjxsaT4KCSAgICBBZGRlZCBpbmZvcm1hdGl2ZSByZWZl cmVuY2VzIHRvIGRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyCgkgICAgYW5kIGRyYWZ0LWll dGYtb2F1dGgtand0LWJlYXJlci4KCSAgCjwvbGk+CjxsaT4KCSAgICBDbGFyaWZpZWQgdGhhdCB0 aGUgc3RhdGVtZW50cyBhYm91dCBwb3NzaWJsZSBpc3N1ZXJzIGFyZSBub24tbm9ybWF0aXZlCgkg ICAgYnkgdXNpbmcgdGhlIGxhbmd1YWdlICJFeGFtcGxlcyBvZiBpc3N1ZXJzIi4KCSAgCjwvbGk+ CjwvdWw+PHA+CiAgICAgIAo8L3A+CjxwPgogICAgICAgIC0wOAogICAgICAgIDwvcD4KPHVsIGNs YXNzPSJ0ZXh0Ij4KPGxpPlVwZGF0ZSByZWZlcmVuY2UgdG8gUkZDIDY3NTUgZnJvbSBkcmFmdC1p ZXRmLW9hdXRoLXVybi1zdWItbnMKPC9saT4KPGxpPlRpZHkgdXAgSUFOQSBjb25zaWRlcmF0aW9u IHNlY3Rpb24KPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgZHJhZnQtaWV0 Zi1vYXV0aC1hc3NlcnRpb25zLTA3CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+ UmVmZXJlbmNlIFJGQyA2NzQ5Lgo8L2xpPgo8bGk+UmVtb3ZlIGV4dHJhbmVvdXMgd29yZCBwZXIg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAw MjkuaHRtbAo8L2xpPgo8L3VsPjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICBkcmFmdC1pZXRm LW9hdXRoLWFzc2VydGlvbnMtMDYKICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5B ZGQgbW9yZSB0ZXh0IHRvIGludHJvIGV4cGxhaW5pbmcgdGhhdCBhbiBhc3NlcnRpb24gZ3JhbnQg dHlwZSBjYW4gYmUgdXNlZCB3aXRoIG9yIHdpdGhvdXQgY2xpZW50CiAgICAgICAgICAgIGF1dGhl bnRpY2F0aW9uL2lkZW50aWZpY2F0aW9uIGFuZCB0aGF0IGNsaWVudCBhc3NlcnRpb24gYXV0aGVu dGljYXRpb24gaXMgbm90aGluZyBtb3JlIHRoYW4gYW4gYWx0ZXJuYXRpdmUgd2F5IGZvciBhIGNs aWVudCB0byBhdXRoZW50aWNhdGUgdG8gdGhlIHRva2VuIGVuZHBvaW50CjwvbGk+CjwvdWw+PHA+ CiAgICAgIAo8L3A+CjxwPgogICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wNQog ICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPk5vbi1ub3JtYXRpdmUgZWRpdG9yaWFs IGNsZWFudXBzCjwvbGk+CjwvdWw+PHA+CiAgICAgIAo8L3A+CjxwPgogICAgICAgIGRyYWZ0LWll dGYtb2F1dGgtYXNzZXJ0aW9ucy0wNAogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxp PlVwZGF0ZWQgZG9jdW1lbnQgdG8gaW5jb3Jwb3JhdGUgdGhlIHJldmlldyBjb21tZW50cyBmcm9t IHRoZSBzaGVwaGVyZCAtIHRocmVhZCBhbmQgYWx0ZXJuYXRpdmUgZHJhZnQgYXQgaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDk0MzcuaHRtbAo8 L2xpPgo8bGk+QWRkZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtb2F1dGgtdXJuLXN1Yi1ucyBh bmQgaW5jbHVkZSBzdWdnZXN0aW9ucyBvbiB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6W2dyYW50LXR5 cGV8Y2xpZW50LWFzc2VydGlvbi10eXBlXToqIFVSTnMKPC9saT4KPC91bD48cD4KICAgICAgCjwv cD4KPHA+CiAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTAzCiAgICAgICAgPC9w Pgo8dWwgY2xhc3M9InRleHQiPgo8bGk+dXBkYXRlZCByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1v YXV0aC12MiBmcm9tIC0yNSB0byAtMjYKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+Cglk cmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDIKCTwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxp PkFkZGVkIHRleHQgYWJvdXQgbGltaXRlZCBsaWZldGltZSBBVHMgYW5kIFJUcyBwZXIgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDgyOTguaHRt bC4KPC9saT4KPGxpPkNoYW5nZWQgdGhlIGxpbmUgYnJlYWtzIGluIHNvbWUgZXhhbXBsZXMgdG8g YXZvaWQgYXdrd2FyZCByZW5kZXJpbmcgdG8gdGV4dCBmb3JtYXQuIEFsc28gcmVtb3ZlZCBlbmNv ZGVkICc9JyBwYWRkaW5nIGZyb20gYSBmZXcgZXhhbXBsZXMgYmVjYXVzZSBib3RoIGtub3duIGRl cml2YXRpdmUgc3BlY3MsIFNBTUwgYW5kIEpXVCwgb21pdCB0aGUgcGFkZGluZyBjaGFyIGluIHNl cmlhbGl6YXRpb24vZW5jb2RpbmcuCjwvbGk+CjxsaT5SZW1vdmUgc2VjdGlvbiA3IG9uIGVycm9y IHJlc3BvbnNlcyBhbmQgbW92ZSB0aGF0IChzb21ld2hhdCBtb2RpZmllZCkgY29udGVudCBpbnRv IHN1YnNlY3Rpb25zIG9mIHNlY3Rpb24gNCBicm9rZW4gdXAgYnkgYXV0aG4vYXV0aHogcGVyIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA4NzM1 Lmh0bWwuCjwvbGk+CjxsaT5SZXdvcmsgdGhlIHRleHQgYWJvdXQgIk1VU1QgdmFsaWRhdGUgLi4u IGluIG9yZGVyIHRvIGVzdGFibGlzaCBhIG1hcHBpbmcgYmV0d2VlbiAuLi4iIHBlciBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwODg3Mi5odG1s IGFuZCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cwODc0OS5odG1sLgo8L2xpPgo8bGk+Q2hhbmdlICJUaGUgUHJpbmNpcGFsIE1VU1QgaWRlbnRp ZnkgYW4gYXV0aG9yaXplZCBhY2Nlc3Nvci4gIElmIHRoZQoJICBhc3NlcnRpb24gaXMgc2VsZi1p c3N1ZWQsIHRoZSBQcmluY2lwYWwgU0hPVUxEIGJlIHRoZSBjbGllbnRfaWQiIGluIDYuMSBwZXIg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4 NzMuaHRtbC4KPC9saT4KPGxpPlVwZGF0ZSByZWZlcmVuY2UgaW4gNC4xIHRvIHBvaW50IHRvIDIu MyAocmF0aGVyIHRoYW4gMy4yKSBvZiBvYXV0aC12MiAocmF0aGVyIHRoYW4gc2VsZikgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4NzQuaHRt bC4KPC9saT4KPGxpPk1vdmUgdGhlICJTZWN0aW9uIDMgb2YiIG91dCBvZiB0aGUgeHJlZiB0byBo b3BlZnVsbHkgZml4IHRoZSBsaW5rIGluIDQuMSBhbmQgcmVtb3ZlIHRoZSBjbGllbnRfaWQgYnVs bGV0IGZyb20gNC4yIHBlciBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1 dGgvY3VycmVudC9tc2cwODg3NS5odG1sLgo8L2xpPgo8bGk+QWRkIHJlZiB0byBTZWN0aW9uIDMu MyBvZiBvYXV0aC12MiBmb3Igc2NvcGUgZGVmaW5pdGlvbiBhbmQgcmVtb3ZlIHNvbWUgdGhlbiBy ZWR1bmRhbnQgdGV4dCBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMDg4OTAuaHRtbC4KPC9saT4KPGxpPkNoYW5nZSAiVGhlIGZvbGxvd2lu ZyBmb3JtYXQgYW5kIHByb2Nlc3NpbmcgcnVsZXMgU0hPVUxEIGJlIGFwcGxpZWQiIHRvICJUaGUg Zm9sbG93aW5nIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBhcHBseSIgaW4gc2VjdGlvbnMg Ni54IHRvIHJlbW92ZSBjb25mbGljdGluZyBub3JtYXRpdmUgcXVhbGlmaWNhdGlvbiBvZiBvdGhl ciBub3JtYXRpdmUgc3RhdGVtZW50cyBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4OTIuaHRtbC4KPC9saT4KPGxpPkFkZCB0ZXh0IHRo ZSBjbGllbnRfaWQgbXVzdCBpZCB0aGUgY2xpZW50IHRvIDQuMSBhbmQgcmVtb3ZlIHNpbWlsYXIg dGV4dCBmcm9tIG90aGVyIHBsYWNlcyBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDg4OTMuaHRtbC4KPC9saT4KPGxpPlJlbW92ZSB0aGUg TVVTVCBmcm9tIHRoZSB0ZXh0IHByaW9yIHRvIHRoZSBIVFRQIHBhcmFtZXRlciBkZWZpbml0aW9u cyBwZXIgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMDg5MjAuaHRtbC4KPC9saT4KPGxpPlVwZGF0ZWQgZXhhbXBsZXMgdG8gdXNlIGdyYW50X3R5 cGUgYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB2YWx1ZXMgZnJvbSB0aGUgT0F1dGggU0FNTCBB c3NlcnRpb24gUHJvZmlsZXMgc3BlYy4KPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPGEgbmFt ZT0icmZjLmF1dGhvcnMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+QXV0aG9ycycgQWRkcmVzc2VzPC9oMz4KPHRhYmxl IHdpZHRoPSI5OSUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4K PHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPkJyaWFuIENhbXBiZWxsPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+UGluZyBJZGVudGl0eSBDb3Jw LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZu YnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpicmlhbi5k LmNhbXBiZWxsQGdtYWlsLmNvbSI+YnJpYW4uZC5jYW1wYmVsbEBnbWFpbC5jb208L2E+PC90ZD48 L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0ZD4mbmJzcDs8L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5DaHVjayBNb3J0aW1vcmU8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5TYWxlc2ZvcmNlLmNv bTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZu YnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpjbW9ydGlt b3JlQHNhbGVzZm9yY2UuY29tIj5jbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPC9hPjwvdGQ+PC90 cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+TWljaGFlbCBCLiBKb25lczwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk1pY3Jvc29mdDwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzptYmpAbWljcm9zb2Z0 LmNvbSI+bWJqQG1pY3Jvc29mdC5jb208L2E+PC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMi Pjx0ZD4mbmJzcDs8L3RkPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5ZYXJvbiBZLiBHb2xh bmQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQg Y2xhc3M9ImF1dGhvci10ZXh0Ij5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10 ZXh0Ij48YSBocmVmPSJtYWlsdG86eWFyb25nQG1pY3Jvc29mdC5jb20iPnlhcm9uZ0BtaWNyb3Nv ZnQuY29tPC9hPjwvdGQ+PC90cj4KPC90YWJsZT4KPC9ib2R5PjwvaHRtbD4K --_005_4E1F6AAD24975D4BA5B168042967394366A50570TK5EX14MBXC284r_-- From bcampbell@pingidentity.com Fri Jan 18 15:33:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7309321F85AC for ; Fri, 18 Jan 2013 15:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.826 X-Spam-Level: X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1m8J42HfwMz for ; Fri, 18 Jan 2013 15:33:15 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id A21DC21F856D for ; Fri, 18 Jan 2013 15:33:14 -0800 (PST) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUPnbuvBCAO8hm5DsTxolW92QMo1S2O/P@postini.com; Fri, 18 Jan 2013 15:33:14 PST Received: by mail-oa0-f71.google.com with SMTP id n12so20757673oag.6 for ; Fri, 18 Jan 2013 15:33:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=gP1xf6+sfnLM8CL4NFuG0rBUUKSaNUp33fM9gt2k3LQ=; b=oAqEAqx0S7C8wHeehAbyHHZadbz5xLigbqxFFPmmX5gzHWBhva0Rb4q9FcVLfXQGyk RiGxOwNOvHsvgjBM2imfDlk7Gc1Q/DjiNz78sz9FNfx413UCIkBT08q/27uBNKtPE6d4 H2HVc1VV8++ZpWWEmEtIvMz/RqF8jjn+1/ZeTYm2GtCj85CdiC5HxmxRxCX1ewXXSq58 YhckYY3ZPqhxt/7o0eZNmqQHKVACYV7YOEj49o0ZGz8vF1ZAZDeNThyYa2f7VqMWoUZh Vn1vy8XIFxEliwLC1dnWRkpDZk1AHe7a0U+ELiLBrvKjIpXbkReg4tZL2+lS/52gS8D/ UZ9g== X-Received: by 10.50.161.232 with SMTP id xv8mr3491063igb.22.1358551993779; Fri, 18 Jan 2013 15:33:13 -0800 (PST) X-Received: by 10.50.161.232 with SMTP id xv8mr3491060igb.22.1358551993676; Fri, 18 Jan 2013 15:33:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.17.134 with HTTP; Fri, 18 Jan 2013 15:32:43 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 18 Jan 2013 16:32:43 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=14dae93409a9fdf54a04d398887a X-Gm-Message-State: ALoCoQlR+qs8kL/44T/pM4nVy0ZF/U3BU/yPK0XUeh4VyKRmvwXonqvzV2fjj8Kcdk0WZYYQrbOz4DcRB5XmixJ5J+seWMRSuvpe/HZI0l/QunKpIzojiQaC9Y2gvicHvP2/9yMHBJkE Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 23:33:16 -0000 --14dae93409a9fdf54a04d398887a Content-Type: text/plain; charset=ISO-8859-1 I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work. I would, however, like to voice my support in favor of the version of the text that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones wrote: > To make the proposed changes concrete, I've made them in a proposed draft > 10 (attached). This contains no normative changes from draft 9. People > should look at Section 1.1 (Interoperability Considerations) and review the > new text there. The only other change was renaming "Principal" to > "Subject" to align terminology with the SAML and JWT specs, as discussed on > the list. > > I will wait for OK from one of the chairs or Stephen before checking this > in. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Friday, January 18, 2013 2:31 PM > To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- > Today > > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification > that the syntax and verification rules of some fields is intentionally left > open for profiles to specify (even while the semantics of them is defined > by the Assertions spec). I propose that instead, we go with the revised > version at the end of this message, which I believe incorporates Hannes' > ideas while keeping the editorial tone positive. > > Second, I believe that we should proceed with the non-normative > terminology change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the > interoperability text). > > Finally, I believe that it would be beneficial to all to have the > Assertions and SAML Profile specs be discussed on the same telechat, as > both are useful for understanding the other. Frankly, I think they should > go to the IETF Editor together as "related specifications", with the goal > being consecutively numbered RFCs referencing one another. Is there any > reason we can't schedule both for the February 7th telechat? (I don't > actually understand how they failed to proceed in lock-step in the first > place. Chairs - any insights?) > > ==== > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific > assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses > SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses > JSON Web Tokens (JWTs). These two instantiations of this framework specify > additional details about the assertion encoding and processing rules for > using those kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be > use case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary > to achieve full web-scale interoperability for particular use cases. > > ==== > > Thanks all, > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- > Today > > > Hiya, > > So I'll take the lack of further discussion about this an meaning that the > wg want this to shoot ahead. I'll put this in as an RFC editor note for the > draft. > > Cheers, > S. > > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi all, > > > > As you have seen on the list (see > > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I > > had a chat with Mike about how to address my comment for the assertion > > draft and Mike kindly provided his text proposal (see > > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > > have used his text as input and extended it a bit. Here is the updated > > text. > > > > ---- > > > > Operational Considerations and Interoperability Expectations > > > > This specification defines a framework for using assertions with OAuth > > 2.0. However, as an abstract framework on its own, this specification > > is not sufficient to produce interoperable implementations. Two other > > specifications that instantiate this framework have been developed, > > one uses SAML 2.0-based assertions and is described in > > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > > instantiations provide additional details about the assertion encoding > > and processing rules for those interested to implement and deploy > > assertions with OAuth 2.0. > > > > However, even with these instance documents an interoperable > > implementation is not possible since for a specific deployment > > environment (within a trust framework or circle of trust, as it is > > sometimes called) agreements about acceptable values for various > > fields in the specification have to be agreed upon. For example, the > > audience field needs to be populated by the entity that generates the > > assertion with a specific value and that value may hold identifiers of > > different types (for example, a URL, an IP address, an FQDN) and the > > entity receiving and verifying the assertion must compare the value in > > the audience field with other information it may obtain from the > > request and/or with locally available information. Since the abstract > > framework nor the instance documents provide sufficient information > > about the syntax, the semantic and the comparison operation of the > > audience field additional profiling in further specifications is > > needed for an interoperable implementation. This additional profiling > > is not only needed for the audience field but also for other fields as > well. > > > > This framework was designed with the expectation that additional > > specifications will fill this gap for deployment-specific environments. > > > > ---- > > > > You have the choice: > > > > 1. take this as-is if you want the assertion draft > > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is > > no normative text in the writeup; it is rather a clarification. > > > > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on > > the Feb 7 > > telechat (if the discussion is done by Feb 1) > > > > 1 or 2 needs to be chosen today. > > > > > > Ciao > > Hannes > > > > PS: FYI - draft-ietf-oauth-saml2-bearer and > > draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae93409a9fdf54a04d398887a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I apologize for not participating in much of the disc= ussion around this - I've been otherwise occupied this week with a myri= ad of other priorities at work.

I would, however, like to voic= e my support in favor of the version of the text that Mike proposed.


On Fri,= Jan 18, 2013 at 3:59 PM, Mike Jones <Michael.Jones@microsoft.co= m> wrote:
To make the proposed changes concrete, I'= ;ve made them in a proposed draft 10 (attached). =A0This contains no normat= ive changes from draft 9. =A0People should look at Section 1.1 (Interoperab= ility Considerations) and review the new text there. =A0The only other chan= ge was renaming "Principal" to "Subject" to align termi= nology with the SAML and JWT specs, as discussed on the list.

I will wait for OK from one of the chairs or Stephen before checking this i= n.

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

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, January 18, 2013 2:31 PM
To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay

I can't agree with proceeding with Hannes' rewrite of the interoper= ability text, as editorially, it reads like it is apologizing for a defect = in the specification, whereas it is an intentional feature of the specifica= tion that the syntax and verification rules of some fields is intentionally= left open for profiles to specify (even while the semantics of them is def= ined by the Assertions spec). =A0I propose that instead, we go with the rev= ised version at the end of this message, which I believe incorporates Hanne= s' ideas while keeping the editorial tone positive.

Second, I believe that we should proceed with the non-normative terminology= change of "Principal" to "Subject", which was proposed= in http://www.ietf.org/mail-archive/web/oauth/current/= msg10530.html and supported by Justin and Torsten, with no one opposed.= =A0This should go into the version being discussed on the telechat (as wel= l as the interoperability text).

Finally, I believe that it would be beneficial to all to have the Assertion= s and SAML Profile specs be discussed on the same telechat, as both are use= ful for understanding the other. =A0Frankly, I think they should go to the = IETF Editor together as "related specifications", with the goal b= eing consecutively numbered RFCs referencing one another. =A0Is there any r= eason we can't schedule both for the February 7th telechat? =A0(I don&#= 39;t actually understand how they failed to proceed in lock-step in the fir= st place. =A0Chairs - any insights?)

=3D=3D=3D=3D

Interoperability Considerations

This specification defines a framework for using assertions with OAuth 2.0.= However, as an abstract framework in which the data formats used for repre= senting many values are not defined, on its own, this specification is not = sufficient to produce interoperable implementations.

Two other specifications that profile this framework for specific assertion= have been developed: =A0one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-= based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web = Tokens (JWTs). =A0These two instantiations of this framework specify additi= onal details about the assertion encoding and processing rules for using th= ose kinds of assertions with OAuth 2.0.

However, even when profiled for specific assertion types, additional profil= ing for specific use cases will be required to achieve full interoperabilit= y. =A0Deployments for particular trust frameworks, circles of trust, or oth= er uses cases will need to agree among the participants on the kinds of val= ues to be used for some abstract fields defined by this specification. =A0F= or example the values of Issuer, Subject, and Audience fields might be URLs= , URIs, fully qualified domain names, OAuth client IDs, IP addresses, or ot= her values, depending upon the requirements of the particular use case. =A0= The verification rules for some values will also be use case specific.

This framework was designed with the clear expectation that additional spec= ifications will define prescriptive profiles and extensions necessary to ac= hieve full web-scale interoperability for particular use cases.

=3D=3D=3D=3D

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks all,=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, January 18, 2013 9:47 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay


Hiya,

So I'll take the lack of further discussion about this an meaning that = the wg want this to shoot ahead. I'll put this in as an RFC editor note= for the draft.

Cheers,
S.

On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi all,
>
> As you have seen on the list (see
> http://www.ietf.org/mail-archive/web/oauth/current= /msg10526.html) I
> had a chat with Mike about how to address my comment for the assertion=
> draft and Mike kindly provided his text proposal (see
> http://www.ietf.org/mail-archive/web/oauth/current= /msg10529.html). I
> have used his text as input and extended it a bit. Here is the updated=
> text.
>
> ----
>
> Operational Considerations and Interoperability Expectations
>
> This specification defines a framework for using assertions with OAuth=
> 2.0. However, as an abstract framework on its own, this specification<= br> > is not sufficient to produce interoperable implementations. Two other<= br> > specifications that instantiate this framework have been developed, > one uses SAML 2.0-based assertions and is described in
> [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens=
> (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two
> instantiations provide additional details about the assertion encoding=
> and processing rules for those interested to implement and deploy
> assertions with OAuth 2.0.
>
> However, even with these instance documents an interoperable
> implementation is not possible since for a specific deployment
> environment (within a trust framework or circle of trust, as it is
> sometimes called) agreements about acceptable values for various
> fields in the specification have to be agreed upon. For example, the > audience field needs to be populated by the entity that generates the<= br> > assertion with a specific value and that value may hold identifiers of=
> different types (for example, a URL, an IP address, an FQDN) and the > entity receiving and verifying the assertion must compare the value in=
> the audience field with other information it may obtain from the
> request and/or with locally available information. Since the abstract<= br> > framework nor the instance documents provide sufficient information > about the syntax, the semantic and the comparison operation of the
> audience field additional profiling in further specifications is
> needed for an interoperable implementation. This additional profiling<= br> > is not only needed for the audience field but also for other fields as= well.
>
> This framework was designed with the expectation that additional
> specifications will fill this gap for deployment-specific environments= .
>
> ----
>
> You have the choice:
>
> 1. take this as-is if you want the assertion draft
> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is > no normative text in the writeup; it is rather a clarification.
>
> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on > the Feb 7
> =A0 =A0telechat (if the discussion is done by Feb 1)
>
> 1 or 2 needs to be chosen today.
>
>
> Ciao
> Hannes
>
> PS: FYI - draft-ietf-oauth-saml2-bearer and
> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

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


--14dae93409a9fdf54a04d398887a-- From cmortimore@salesforce.com Fri Jan 18 16:39:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707F21F86D2 for ; Fri, 18 Jan 2013 16:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shhdZuwcrr43 for ; Fri, 18 Jan 2013 16:39:43 -0800 (PST) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by ietfa.amsl.com (Postfix) with SMTP id 82A4021F869C for ; Fri, 18 Jan 2013 16:39:28 -0800 (PST) Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKUPnrQPmwwweYaWAsFfnrELpWFwv1S7jS@postini.com; Fri, 18 Jan 2013 16:39:28 PST Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Fri, 18 Jan 2013 16:39:28 -0800 From: Chuck Mortimore To: Brian Campbell Date: Fri, 18 Jan 2013 16:39:27 -0800 Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Thread-Index: Ac313W+b07WcaXplTXCnqorjTxcHCw== Message-ID: <29D9514D-88ED-4433-BC48-58B08BB37716@salesforce.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366A50570@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_29D9514D88ED4433BC4858B08BB37716salesforcecom_" MIME-Version: 1.0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:39:45 -0000 --_000_29D9514D88ED4433BC4858B08BB37716salesforcecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same comment as Brian. I support Mike's proposed text. -cmort On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote: I apologize for not participating in much of the discussion around this - I= 've been otherwise occupied this week with a myriad of other priorities at = work. I would, however, like to voice my support in favor of the version of the t= ext that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones > wrote: To make the proposed changes concrete, I've made them in a proposed draft 1= 0 (attached). This contains no normative changes from draft 9. People sho= uld look at Section 1.1 (Interoperability Considerations) and review the ne= w text there. The only other change was renaming "Principal" to "Subject" = to align terminology with the SAML and JWT specs, as discussed on the list. I will wait for OK from one of the chairs or Stephen before checking this i= n. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, January 18, 2013 2:31 PM To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay I can't agree with proceeding with Hannes' rewrite of the interoperability = text, as editorially, it reads like it is apologizing for a defect in the s= pecification, whereas it is an intentional feature of the specification tha= t the syntax and verification rules of some fields is intentionally left op= en for profiles to specify (even while the semantics of them is defined by = the Assertions spec). I propose that instead, we go with the revised versi= on at the end of this message, which I believe incorporates Hannes' ideas w= hile keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology= change of "Principal" to "Subject", which was proposed in http://www.ietf.= org/mail-archive/web/oauth/current/msg10530.html and supported by Justin an= d Torsten, with no one opposed. This should go into the version being disc= ussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertion= s and SAML Profile specs be discussed on the same telechat, as both are use= ful for understanding the other. Frankly, I think they should go to the IE= TF Editor together as "related specifications", with the goal being consecu= tively numbered RFCs referencing one another. Is there any reason we can't= schedule both for the February 7th telechat? (I don't actually understand= how they failed to proceed in lock-step in the first place. Chairs - any = insights?) =3D=3D=3D=3D Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0.= However, as an abstract framework in which the data formats used for repre= senting many values are not defined, on its own, this specification is not = sufficient to produce interoperable implementations. Two other specifications that profile this framework for specific assertion= have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-ba= sed assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web To= kens (JWTs). These two instantiations of this framework specify additional= details about the assertion encoding and processing rules for using those = kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profil= ing for specific use cases will be required to achieve full interoperabilit= y. Deployments for particular trust frameworks, circles of trust, or other= uses cases will need to agree among the participants on the kinds of value= s to be used for some abstract fields defined by this specification. For e= xample the values of Issuer, Subject, and Audience fields might be URLs, UR= Is, fully qualified domain names, OAuth client IDs, IP addresses, or other = values, depending upon the requirements of the particular use case. The ve= rification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional spec= ifications will define prescriptive profiles and extensions necessary to ac= hieve full web-scale interoperability for particular use cases. =3D=3D=3D=3D Thanks all, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Stephen Farrel= l Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay Hiya, So I'll take the lack of further discussion about this an meaning that the = wg want this to shoot ahead. I'll put this in as an RFC editor note for the= draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I > had a chat with Mike about how to address my comment for the assertion > draft and Mike kindly provided his text proposal (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > have used his text as input and extended it a bit. Here is the updated > text. > > ---- > > Operational Considerations and Interoperability Expectations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework on its own, this specification > is not sufficient to produce interoperable implementations. Two other > specifications that instantiate this framework have been developed, > one uses SAML 2.0-based assertions and is described in > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > instantiations provide additional details about the assertion encoding > and processing rules for those interested to implement and deploy > assertions with OAuth 2.0. > > However, even with these instance documents an interoperable > implementation is not possible since for a specific deployment > environment (within a trust framework or circle of trust, as it is > sometimes called) agreements about acceptable values for various > fields in the specification have to be agreed upon. For example, the > audience field needs to be populated by the entity that generates the > assertion with a specific value and that value may hold identifiers of > different types (for example, a URL, an IP address, an FQDN) and the > entity receiving and verifying the assertion must compare the value in > the audience field with other information it may obtain from the > request and/or with locally available information. Since the abstract > framework nor the instance documents provide sufficient information > about the syntax, the semantic and the comparison operation of the > audience field additional profiling in further specifications is > needed for an interoperable implementation. This additional profiling > is not only needed for the audience field but also for other fields as we= ll. > > This framework was designed with the expectation that additional > specifications will fill this gap for deployment-specific environments. > > ---- > > You have the choice: > > 1. take this as-is if you want the assertion draft > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is > no normative text in the writeup; it is rather a clarification. > > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on > the Feb 7 > telechat (if the discussion is done by Feb 1) > > 1 or 2 needs to be chosen today. > > > Ciao > Hannes > > PS: FYI - draft-ietf-oauth-saml2-bearer and > draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_29D9514D88ED4433BC4858B08BB37716salesforcecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same comment as Brian. &nb= sp;  I support Mike's proposed text.

-cmort

On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote:
I apologize for not participating in much of the discussion arou= nd this - I've been otherwise occupied this week with a myriad of other pri= orities at work.

I would, however, like to voice my support in= favor of the version of the text that Mike proposed.


On Fri,= Jan 18, 2013 at 3:59 PM, Mike Jones <Michael.Jones@microsoft.co= m> wrote:
To make the proposed changes concrete, I've = made them in a proposed draft 10 (attached).  This contains no normati= ve changes from draft 9.  People should look at Section 1.1 (Interoper= ability Considerations) and review the new text there.  The only other= change was renaming "Principal" to "Subject" to align terminology with the= SAML and JWT specs, as discussed on the list.

I will wait for OK from one of the chairs or Stephen before checking this i= n.

                     = ;           -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, January 18, 2013 2:31 PM
To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay

I can't agree with proceeding with Hannes' rewrite of the interoperability = text, as editorially, it reads like it is apologizing for a defect in the s= pecification, whereas it is an intentional feature of the specification tha= t the syntax and verification rules of some fields is intentionally left op= en for profiles to specify (even while the semantics of them is defined by = the Assertions spec).  I propose that instead, we go with the revised = version at the end of this message, which I believe incorporates Hannes' id= eas while keeping the editorial tone positive.

Second, I believe that we should proceed with the non-normative terminology= change of "Principal" to "Subject", which was proposed in http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html an= d supported by Justin and Torsten, with no one opposed.  This should g= o into the version being discussed on the telechat (as well as the interope= rability text).

Finally, I believe that it would be beneficial to all to have the Assertion= s and SAML Profile specs be discussed on the same telechat, as both are use= ful for understanding the other.  Frankly, I think they should go to t= he IETF Editor together as "related specifications", with the goal being co= nsecutively numbered RFCs referencing one another.  Is there any reaso= n we can't schedule both for the February 7th telechat?  (I don't actu= ally understand how they failed to proceed in lock-step in the first place.=  Chairs - any insights?)

=3D=3D=3D=3D

Interoperability Considerations

This specification defines a framework for using assertions with OAuth 2.0.= However, as an abstract framework in which the data formats used for repre= senting many values are not defined, on its own, this specification is not = sufficient to produce interoperable implementations.

Two other specifications that profile this framework for specific assertion= have been developed:  one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2= .0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON W= eb Tokens (JWTs).  These two instantiations of this framework specify = additional details about the assertion encoding and processing rules for us= ing those kinds of assertions with OAuth 2.0.

However, even when profiled for specific assertion types, additional profil= ing for specific use cases will be required to achieve full interoperabilit= y.  Deployments for particular trust frameworks, circles of trust, or = other uses cases will need to agree among the participants on the kinds of = values to be used for some abstract fields defined by this specification. &= nbsp;For example the values of Issuer, Subject, and Audience fields might b= e URLs, URIs, fully qualified domain names, OAuth client IDs, IP addresses,= or other values, depending upon the requirements of the particular use cas= e.  The verification rules for some values will also be use case speci= fic.

This framework was designed with the clear expectation that additional spec= ifications will define prescriptive profiles and extensions necessary to ac= hieve full web-scale interoperability for particular use cases.

=3D=3D=3D=3D

                     = ;           Thanks all,
                     = ;           -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, January 18, 2013 9:47 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay


Hiya,

So I'll take the lack of further discussion about this an meaning that the = wg want this to shoot ahead. I'll put this in as an RFC editor note for the= draft.

Cheers,
S.

On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi all,
>
> As you have seen on the list (see
> http://www.ietf.org/mail-archive/web/oauth/current= /msg10526.html) I
> had a chat with Mike about how to address my comment for the assertion=
> draft and Mike kindly provided his text proposal (see
> http://www.ietf.org/mail-archive/web/oauth/current= /msg10529.html). I
> have used his text as input and extended it a bit. Here is the updated=
> text.
>
> ----
>
> Operational Considerations and Interoperability Expectations
>
> This specification defines a framework for using assertions with OAuth=
> 2.0. However, as an abstract framework on its own, this specification<= br> > is not sufficient to produce interoperable implementations. Two other<= br> > specifications that instantiate this framework have been developed, > one uses SAML 2.0-based assertions and is described in
> [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens=
> (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two
> instantiations provide additional details about the assertion encoding=
> and processing rules for those interested to implement and deploy
> assertions with OAuth 2.0.
>
> However, even with these instance documents an interoperable
> implementation is not possible since for a specific deployment
> environment (within a trust framework or circle of trust, as it is
> sometimes called) agreements about acceptable values for various
> fields in the specification have to be agreed upon. For example, the > audience field needs to be populated by the entity that generates the<= br> > assertion with a specific value and that value may hold identifiers of=
> different types (for example, a URL, an IP address, an FQDN) and the > entity receiving and verifying the assertion must compare the value in=
> the audience field with other information it may obtain from the
> request and/or with locally available information. Since the abstract<= br> > framework nor the instance documents provide sufficient information > about the syntax, the semantic and the comparison operation of the
> audience field additional profiling in further specifications is
> needed for an interoperable implementation. This additional profiling<= br> > is not only needed for the audience field but also for other fields as= well.
>
> This framework was designed with the expectation that additional
> specifications will fill this gap for deployment-specific environments= .
>
> ----
>
> You have the choice:
>
> 1. take this as-is if you want the assertion draft
> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is > no normative text in the writeup; it is rather a clarification.
>
> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on > the Feb 7
>    telechat (if the discussion is done by Feb 1)
>
> 1 or 2 needs to be chosen today.
>
>
> Ciao
> Hannes
>
> PS: FYI - draft-ietf-oauth-saml2-bearer and
> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
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

= --_000_29D9514D88ED4433BC4858B08BB37716salesforcecom_-- From bcampbell@pingidentity.com Fri Jan 18 17:14:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06F821F86A9 for ; Fri, 18 Jan 2013 17:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxg5f1lDYREU for ; Fri, 18 Jan 2013 17:14:46 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0121F8698 for ; Fri, 18 Jan 2013 17:14:23 -0800 (PST) Received: from mail-ie0-f197.google.com ([209.85.223.197]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUPnzb1rvdG3L4pjdPnyE/lxzRoAchuN2@postini.com; Fri, 18 Jan 2013 17:14:23 PST Received: by mail-ie0-f197.google.com with SMTP id 16so20414506iea.4 for ; Fri, 18 Jan 2013 17:14:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=aDguvFchZWDUmC9+DnBtRyJIsux4vwccUl9CfiJOtM8=; b=fJZMY3+fIEaVUmqCMalkCKwTes/4mK2hxJsNsXO8rTa5cMxWVIkEgzZHf8SZ/3bq08 H+vm8DhfPff0BQ7dkWxTF2Zo1a14xic9GSyID0l16PHEYQt2StnHQASJ8U4lsPKNBczJ xiQZWojLyxkMrLcEnFQlMO/dhsUHub7IuSpreIZtPtFPqDkTp6fxV/PkwvA347falE27 DNPQf7R7OYYljRq7CsIUxCWkNvyh2dDaXeCc7gBUeG2lARjY1UQaIIqPlEAqSPRPppmV tvjX2ETXyh6gZ8Gv8PwV8JaQjaj3vUppfspa2ULUGocwmtoPckuzLLXWLerEUkpfI2Sh xYpQ== X-Received: by 10.50.108.161 with SMTP id hl1mr3523139igb.101.1358558062812; Fri, 18 Jan 2013 17:14:22 -0800 (PST) X-Received: by 10.50.108.161 with SMTP id hl1mr3523130igb.101.1358558062508; Fri, 18 Jan 2013 17:14:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.17.134 with HTTP; Fri, 18 Jan 2013 17:13:52 -0800 (PST) From: Brian Campbell Date: Fri, 18 Jan 2013 18:13:52 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=f46d0402a9afb8fc3804d399f2b9 X-Gm-Message-State: ALoCoQnjcMcD6tgu/B8uVh7vjQxOwbjt16XvfH/qW6MDYBMgtjHCXAdYsHhDdC0oDWhqDRrtye8dbfqrxmMB7SnYG/cslvB3TE1YMMITfVz4c154Ha1ApiNPIuNVqpC5Vp1sczhBh5X9 Cc: shawn.emery@oracle.com Subject: [OAUTH-WG] Missed comments on the assertion framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 01:14:46 -0000 --f46d0402a9afb8fc3804d399f2b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There were some comments on the document made by Shawn Emery as part of a security directorate's review http://www.ietf.org/mail-archive/web/secdir/current/msg03679.html that seem to have gotten lost in the shuffle. His editorial comments are spot on and I believe the changes he suggests should all be made. I'm not sure if a new draft or a RFC editor's note is more appropriate at this stage? The question about providing more guidance on the Assertion ID is a little less straightforward. The JWT and SAML instances of the framework both inherit some guidance from their respective token format definitions - http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.1.7= and =A71.3.4 ID and ID Reference Values of saml-core-2.0-os. Perhaps that is sufficient. If we were to add something to draft-ietf-oauth-assertions, I'd probably look to borrow some text from one or both of those locations. --f46d0402a9afb8fc3804d399f2b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There were some comments on the document made by= Shawn Emery as part of a security directorate's review http://www.ietf.org/mail-archive/web/secdir/current/msg03679.html= that seem to have gotten lost in the shuffle.=A0

His editorial comments are spot on and I believe the changes he s= uggests should all be made. I'm not sure if a new draft or a RFC editor= 's note is more appropriate at this stage?

The question ab= out providing more guidance on the Assertion ID is a little less straightfo= rward. The JWT and SAML instances of the framework both inherit some guidan= ce from their respective token format definitions - http://too= ls.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.1.7 and = =A71.3.4 ID and ID Reference Values of saml-core-2.0-os. Perhaps that is su= fficient. If we were to add something to draft-ietf-oauth-assertions, I'= ;d probably look to borrow some text from one or both of those locations.


--f46d0402a9afb8fc3804d399f2b9-- From ve7jtb@ve7jtb.com Fri Jan 18 17:33:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDF921F84F8 for ; Fri, 18 Jan 2013 17:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PggoDVQv2nnf for ; Fri, 18 Jan 2013 17:33:35 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id C19AD21F84F2 for ; Fri, 18 Jan 2013 17:33:35 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so7295442iea.29 for ; Fri, 18 Jan 2013 17:33:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=M1YzLwMuHiwHoaLmoOhmchG9O6hqE2qS7B2Nv7FmdWE=; b=Z1YGjHLx2kGgQpWTCNZ7lYjnv5dkyCHcWoXC09XWtklJaS+lYv6nDjdzKb6hQOTXQg IXO0VMZgfgxYR9BmNgF9TGP2tljCHl+k9aFyTcrvLJiQ3kNKs0HXx/n/R/EBgk2VNNdc k7WxRtyj047+Sr8SGAtmzq4addFRssSKM8UfigxVYXR9beOkn1pfE4XrRiwhlJDsaX2u F+4zy3eR7mZkoS2RrTVtAabxuKDQMeTOwe3yrhKECF9KylDgHxai/o1fT3pmd9G4iUuJ fA6Kfb7dYOl1hmWrtw2QFi0E3kSur58absfuGm1MD/teZEoZr+ZIvw1ZJEy9bqAu56zy i83A== X-Received: by 10.50.89.165 with SMTP id bp5mr3688076igb.70.1358559215322; Fri, 18 Jan 2013 17:33:35 -0800 (PST) Received: from [10.111.113.32] ([38.109.210.2]) by mx.google.com with ESMTPS id dc8sm3437365igb.15.2013.01.18.17.33.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 17:33:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 18 Jan 2013 18:33:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B0E60D3-A9CC-44F2-B588-CAFBA0B56746@ve7jtb.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm6WNNMSWvvJVDPCYGGdN269tyb2sWj85eaSxqNvSWrI7kb6mexpMRacPbSg/JMvXscZKpX Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 01:33:37 -0000 I prefer Mike's wording over Hannes's rewrite. =20 This is a design feature to leave it to specs like openID Connect to = profile what the values are. We did that in the context of what made = sense for the spec using the assertion profile. I thought I also supported changing Principal to Subject on this list = but it could have been one of the other places, that I agreed to the = change:) John B. On 2013-01-18, at 3:30 PM, Mike Jones = wrote: > I can't agree with proceeding with Hannes' rewrite of the = interoperability text, as editorially, it reads like it is apologizing = for a defect in the specification, whereas it is an intentional feature = of the specification that the syntax and verification rules of some = fields is intentionally left open for profiles to specify (even while = the semantics of them is defined by the Assertions spec). I propose = that instead, we go with the revised version at the end of this message, = which I believe incorporates Hannes' ideas while keeping the editorial = tone positive. >=20 > Second, I believe that we should proceed with the non-normative = terminology change of "Principal" to "Subject", which was proposed in = http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and = supported by Justin and Torsten, with no one opposed. This should go = into the version being discussed on the telechat (as well as the = interoperability text). >=20 > Finally, I believe that it would be beneficial to all to have the = Assertions and SAML Profile specs be discussed on the same telechat, as = both are useful for understanding the other. Frankly, I think they = should go to the IETF Editor together as "related specifications", with = the goal being consecutively numbered RFCs referencing one another. Is = there any reason we can't schedule both for the February 7th telechat? = (I don't actually understand how they failed to proceed in lock-step in = the first place. Chairs - any insights?) >=20 > =3D=3D=3D=3D >=20 > Interoperability Considerations >=20 > This specification defines a framework for using assertions with OAuth = 2.0. However, as an abstract framework in which the data formats used = for representing many values are not defined, on its own, this = specification is not sufficient to produce interoperable = implementations.=20 >=20 > Two other specifications that profile this framework for specific = assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses = SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) = uses JSON Web Tokens (JWTs). These two instantiations of this framework = specify additional details about the assertion encoding and processing = rules for using those kinds of assertions with OAuth 2.0. >=20 > However, even when profiled for specific assertion types, additional = profiling for specific use cases will be required to achieve full = interoperability. Deployments for particular trust frameworks, circles = of trust, or other uses cases will need to agree among the participants = on the kinds of values to be used for some abstract fields defined by = this specification. For example the values of Issuer, Subject, and = Audience fields might be URLs, URIs, fully qualified domain names, OAuth = client IDs, IP addresses, or other values, depending upon the = requirements of the particular use case. The verification rules for = some values will also be use case specific. >=20 > This framework was designed with the clear expectation that additional = specifications will define prescriptive profiles and extensions = necessary to achieve full web-scale interoperability for particular use = cases. >=20 > =3D=3D=3D=3D >=20 > Thanks all, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability = -- Today >=20 >=20 > Hiya, >=20 > So I'll take the lack of further discussion about this an meaning that = the wg want this to shoot ahead. I'll put this in as an RFC editor note = for the draft. >=20 > Cheers, > S. >=20 > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >>=20 >> As you have seen on the list (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20= >> had a chat with Mike about how to address my comment for the = assertion=20 >> draft and Mike kindly provided his text proposal (see=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20= >> have used his text as input and extended it a bit. Here is the = updated=20 >> text. >>=20 >> ---- >>=20 >> Operational Considerations and Interoperability Expectations >>=20 >> This specification defines a framework for using assertions with = OAuth=20 >> 2.0. However, as an abstract framework on its own, this specification=20= >> is not sufficient to produce interoperable implementations. Two other=20= >> specifications that instantiate this framework have been developed,=20= >> one uses SAML 2.0-based assertions and is described in=20 >> [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web = Tokens >> (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two=20 >> instantiations provide additional details about the assertion = encoding=20 >> and processing rules for those interested to implement and deploy=20 >> assertions with OAuth 2.0. >>=20 >> However, even with these instance documents an interoperable=20 >> implementation is not possible since for a specific deployment=20 >> environment (within a trust framework or circle of trust, as it is=20 >> sometimes called) agreements about acceptable values for various=20 >> fields in the specification have to be agreed upon. For example, the=20= >> audience field needs to be populated by the entity that generates the=20= >> assertion with a specific value and that value may hold identifiers = of=20 >> different types (for example, a URL, an IP address, an FQDN) and the=20= >> entity receiving and verifying the assertion must compare the value = in=20 >> the audience field with other information it may obtain from the=20 >> request and/or with locally available information. Since the abstract=20= >> framework nor the instance documents provide sufficient information=20= >> about the syntax, the semantic and the comparison operation of the=20 >> audience field additional profiling in further specifications is=20 >> needed for an interoperable implementation. This additional profiling=20= >> is not only needed for the audience field but also for other fields = as well. >>=20 >> This framework was designed with the expectation that additional=20 >> specifications will fill this gap for deployment-specific = environments. >>=20 >> ---- >>=20 >> You have the choice: >>=20 >> 1. take this as-is if you want the assertion draft=20 >> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20= >> no normative text in the writeup; it is rather a clarification. >>=20 >> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20= >> the Feb 7 >> telechat (if the discussion is done by Feb 1) >>=20 >> 1 or 2 needs to be chosen today. >>=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: FYI - draft-ietf-oauth-saml2-bearer and=20 >> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. >>=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 From hannes.tschofenig@gmx.net Sat Jan 19 08:19:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66421F85F7 for ; Sat, 19 Jan 2013 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX2Oi4au5tP1 for ; Sat, 19 Jan 2013 08:19:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 730CC21F85DB for ; Sat, 19 Jan 2013 08:19:08 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LxIqi-1Sphib1CSA-016sp3 for ; Sat, 19 Jan 2013 17:19:07 +0100 Received: (qmail invoked by alias); 19 Jan 2013 16:19:06 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 19 Jan 2013 17:19:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19iradeIclieX/Y5P7bDtuavJemOQkuTk8poZR1jf pzJwY/L126YN9O Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 19 Jan 2013 18:19:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <788A2E1F-4D54-426B-BFCA-23CC07857CF8@gmx.net> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:19:14 -0000 Hi Mike, Hi all,=20 Thanks for the feedback. I see that a couple of you have decided to go = with option 2. Regarding the comments below.=20 On Jan 19, 2013, at 12:30 AM, Mike Jones wrote: > I can't agree with proceeding with Hannes' rewrite of the = interoperability text, as editorially, it reads like it is apologizing = for a defect in the specification, whereas it is an intentional feature = of the specification that the syntax and verification rules of some = fields is intentionally left open for profiles to specify (even while = the semantics of them is defined by the Assertions spec). I propose = that instead, we go with the revised version at the end of this message, = which I believe incorporates Hannes' ideas while keeping the editorial = tone positive. I tried to provide an honest assessment of the situation with my = writeup.=20 >=20 > Second, I believe that we should proceed with the non-normative = terminology change of "Principal" to "Subject", which was proposed in = http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and = supported by Justin and Torsten, with no one opposed. This should go = into the version being discussed on the telechat (as well as the = interoperability text). It would certainly make sense to re-submit a new version with this = change and then we see how it reads. Now, since we have a bit more time = that should not be an issue at all.=20 >=20 > Finally, I believe that it would be beneficial to all to have the = Assertions and SAML Profile specs be discussed on the same telechat, as = both are useful for understanding the other. Frankly, I think they = should go to the IETF Editor together as "related specifications", with = the goal being consecutively numbered RFCs referencing one another. Is = there any reason we can't schedule both for the February 7th telechat? = (I don't actually understand how they failed to proceed in lock-step in = the first place. Chairs - any insights?) It might be beneficial to have the two discussed together but the IESG = has not done the reviews of the SAML assertion draft yet and therefore = it is not on the agenda yet.=20 Ciao Hannes >=20 > =3D=3D=3D=3D >=20 > Interoperability Considerations >=20 > This specification defines a framework for using assertions with OAuth = 2.0. However, as an abstract framework in which the data formats used = for representing many values are not defined, on its own, this = specification is not sufficient to produce interoperable = implementations.=20 >=20 > Two other specifications that profile this framework for specific = assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses = SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) = uses JSON Web Tokens (JWTs). These two instantiations of this framework = specify additional details about the assertion encoding and processing = rules for using those kinds of assertions with OAuth 2.0. >=20 > However, even when profiled for specific assertion types, additional = profiling for specific use cases will be required to achieve full = interoperability. Deployments for particular trust frameworks, circles = of trust, or other uses cases will need to agree among the participants = on the kinds of values to be used for some abstract fields defined by = this specification. For example the values of Issuer, Subject, and = Audience fields might be URLs, URIs, fully qualified domain names, OAuth = client IDs, IP addresses, or other values, depending upon the = requirements of the particular use case. The verification rules for = some values will also be use case specific. >=20 > This framework was designed with the clear expectation that additional = specifications will define prescriptive profiles and extensions = necessary to achieve full web-scale interoperability for particular use = cases. >=20 > =3D=3D=3D=3D >=20 > Thanks all, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability = -- Today >=20 >=20 > Hiya, >=20 > So I'll take the lack of further discussion about this an meaning that = the wg want this to shoot ahead. I'll put this in as an RFC editor note = for the draft. >=20 > Cheers, > S. >=20 > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >>=20 >> As you have seen on the list (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20= >> had a chat with Mike about how to address my comment for the = assertion=20 >> draft and Mike kindly provided his text proposal (see=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20= >> have used his text as input and extended it a bit. Here is the = updated=20 >> text. >>=20 >> ---- >>=20 >> Operational Considerations and Interoperability Expectations >>=20 >> This specification defines a framework for using assertions with = OAuth=20 >> 2.0. However, as an abstract framework on its own, this specification=20= >> is not sufficient to produce interoperable implementations. Two other=20= >> specifications that instantiate this framework have been developed,=20= >> one uses SAML 2.0-based assertions and is described in=20 >> [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web = Tokens >> (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two=20 >> instantiations provide additional details about the assertion = encoding=20 >> and processing rules for those interested to implement and deploy=20 >> assertions with OAuth 2.0. >>=20 >> However, even with these instance documents an interoperable=20 >> implementation is not possible since for a specific deployment=20 >> environment (within a trust framework or circle of trust, as it is=20 >> sometimes called) agreements about acceptable values for various=20 >> fields in the specification have to be agreed upon. For example, the=20= >> audience field needs to be populated by the entity that generates the=20= >> assertion with a specific value and that value may hold identifiers = of=20 >> different types (for example, a URL, an IP address, an FQDN) and the=20= >> entity receiving and verifying the assertion must compare the value = in=20 >> the audience field with other information it may obtain from the=20 >> request and/or with locally available information. Since the abstract=20= >> framework nor the instance documents provide sufficient information=20= >> about the syntax, the semantic and the comparison operation of the=20 >> audience field additional profiling in further specifications is=20 >> needed for an interoperable implementation. This additional profiling=20= >> is not only needed for the audience field but also for other fields = as well. >>=20 >> This framework was designed with the expectation that additional=20 >> specifications will fill this gap for deployment-specific = environments. >>=20 >> ---- >>=20 >> You have the choice: >>=20 >> 1. take this as-is if you want the assertion draft=20 >> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20= >> no normative text in the writeup; it is rather a clarification. >>=20 >> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20= >> the Feb 7 >> telechat (if the discussion is done by Feb 1) >>=20 >> 1 or 2 needs to be chosen today. >>=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: FYI - draft-ietf-oauth-saml2-bearer and=20 >> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. >>=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 From hannes.tschofenig@gmx.net Sat Jan 19 08:19:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A743221F85DB for ; Sat, 19 Jan 2013 08:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrrcNf8VIKyD for ; Sat, 19 Jan 2013 08:19:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D221F8610 for ; Sat, 19 Jan 2013 08:19:45 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MgJFg-1Tb5ks1S3q-00Nk3y for ; Sat, 19 Jan 2013 17:19:44 +0100 Received: (qmail invoked by alias); 19 Jan 2013 16:19:44 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 19 Jan 2013 17:19:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18MOJgV/8sMjFtLQwpa2kVnZA+zRZP+CmJXjdanZB D6mD7FB8y9DGV5 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Jan 2013 18:19:43 +0200 Message-Id: <20D098C4-46EB-483F-B656-C9D7236F843A@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Minutes from the Conference Call (11th Jan. 2013) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:19:52 -0000 Hi all,=20 here are the minutes from the recent conference call: ----- OAuth Conference Call - 11th Jan 2013 Participants: - Bill Mills - Hannes Tschofenig - Justin Richer - Phil Hunt=20 - Prateek Mishra - Derek Atkins - Mike Jones - George Fletcher - John Bradley Notes: The slides for the meeting, which are based on the requirements in = http://tools.ietf.org/html/draft-tschofenig-oauth-security-01#section-5, = can be found here: http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt The discussion started with the requirement for "Cryptographic Algorithm = Independence" (or also called crypto agility), which states that "The = key management protocol MUST be cryptographic algorithm independent.". = There are at least two types of algorithms in the OAuth framework, = namely:=20 1) The access token must be cryptographically protected against = modifications and may contain the session key encrypted with a key only = known to the resource server and the authorization server. The = authorization server needs to use an algorithm that is also supported by = the resource server to perform the cryptographic computations.=20 =20 2) When the client interacts with the resource server and provides the = access token it needs to demonstrate the possession of a key by using a = keyed message digest or a digital signature computed over the request. = Different algorithms may be used by the client and the algorithm = selected must be supported by the resource server. For example, a client = may be using a HMAC-SHA1-160 keyed message digest computed over selected = header fields of the request and the resource server needs to support = the same cryptographic algorithm. The notion of an algorithm may, = however, also refer to a different credential being supported = (asymmetric keys vs. symmetric keys), or an entirely different = specification (HOTK vs. the MAC token, for example). The participants discussed whether the requirement implies a run-time = algorithm negotiation or rather an indication of the algorithms as part = of the discovery procedure / dynamic client registration.=20 In case of the discovery exchange, which happens prior to the protocol = exchange between the client and the authorization server, the client = learns (for example via WebFinger) what algorithms the resource server = supports. For the case of dynamic client registration it was suggested = that the client id is used to associate the supported algorithms to a = specific client and that any indication of the algorithms during the = OAuth protocol exchange are therefore not needed. In that case the = client-supported algorithms are implicitly known to the authorization = server based on the client id.=20 There was also the recommendation to support cases where the AS does not = know anything about the resource server. It was not clear how the = resource server would be able to obtain the required session key in this = case. It was also noted that the current OAuth base specification does = not allow the client to convey information about what resource server it = wants to interact with. This information would, however, be needed by = the authorization server to determine the algorithms supported by the = resource server and to encrypt a session key.=20 =20 No conclusion was reached on how much flexibility is needed nor at what = part of the exchange the algorithm indication / negotiation should be = take place. Justin even suggested that the topic of crypto-agility is = orthogonal to the discussion of enhanced bearer token security.=20 ----- Feedback on my notes are appreciated. Maybe someone was able to take = more detailed notes during the call.=20 I have also uploaded them to the meeting materials page:=20 = http://www.ietf.org/proceedings/interim/2013/01/11/oauth/minutes/minutes-i= nterim-2013-oauth-1 Ciao Hannes From stephen.farrell@cs.tcd.ie Sat Jan 19 08:37:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8A521F85E8 for ; Sat, 19 Jan 2013 08:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLKAkt3iOOcC for ; Sat, 19 Jan 2013 08:37:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 044B121F85DA for ; Sat, 19 Jan 2013 08:37:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C607BE5F; Sat, 19 Jan 2013 16:36:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMD4BSlp3nfB; Sat, 19 Jan 2013 16:36:50 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.16.247]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 74E74BE3C; Sat, 19 Jan 2013 16:36:50 +0000 (GMT) Message-ID: <50FACBA2.5030201@cs.tcd.ie> Date: Sat, 19 Jan 2013 16:36:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hannes Tschofenig References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <788A2E1F-4D54-426B-BFCA-23CC07857CF8@gmx.net> In-Reply-To: <788A2E1F-4D54-426B-BFCA-23CC07857CF8@gmx.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:37:13 -0000 Hi Hannes, On 01/19/2013 04:19 PM, Hannes Tschofenig wrote: > > Thanks for the feedback. I see that a couple of you have decided to go with option 2. Yep, looks like it. I've moved this back to Feb 7 so the discussion doesn't need to be rushed. S. From Michael.Jones@microsoft.com Sat Jan 19 12:18:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FF821F8230 for ; Sat, 19 Jan 2013 12:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2rc9LSmXl4i for ; Sat, 19 Jan 2013 12:18:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 027BA21F886D for ; Sat, 19 Jan 2013 12:18:08 -0800 (PST) Received: from BY2FFO11FD008.protection.gbl (10.1.15.201) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sat, 19 Jan 2013 20:18:02 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sat, 19 Jan 2013 20:18:02 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Sat, 19 Jan 2013 20:17:47 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Thread-Index: Ac31c/ey/0oPxcEZTU2GjVm1VBYpaAAL9XQAAAkriSAAJg2ggAAIRWHA Date: Sat, 19 Jan 2013 20:17:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A5339F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <999913AB42CC9341B05A99BBF358718D02513229@FIESEXC035.nsn-intra.net> <50F98A8E.7090701@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394366A5043B@TK5EX14MBXC284.redmond.corp.microsoft.com> <788A2E1F-4D54-426B-BFCA-23CC07857CF8@gmx.net> In-Reply-To: <788A2E1F-4D54-426B-BFCA-23CC07857CF8@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(51704002)(377454001)(24454001)(69234002)(479174001)(13464002)(47776002)(23726001)(44976002)(47446002)(47736001)(74502001)(50986001)(15202345001)(74662001)(31966008)(4396001)(16406001)(46102001)(49866001)(79102001)(50466001)(53806001)(54356001)(56816002)(47976001)(77982001)(51856001)(59766001)(550184003)(5343655001)(46406002)(55846006)(76482001)(54316002)(56776001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB022; H:TK5EX14MLTC103.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0731AA2DE6 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 20:18:10 -0000 When can we get the IESG to review the SAML Assertions draft? It would be = good to get the Assertions draft and the SAML Assertions draft back in sync= , from a schedule and process perspective, as comments on one may also refl= ect on the other. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Saturday, January 19, 2013 8:19 AM To: Mike Jones Cc: Hannes Tschofenig; Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)= ; oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Tod= ay Hi Mike, Hi all,=20 Thanks for the feedback. I see that a couple of you have decided to go with= option 2. Regarding the comments below.=20 On Jan 19, 2013, at 12:30 AM, Mike Jones wrote: > I can't agree with proceeding with Hannes' rewrite of the interoperabilit= y text, as editorially, it reads like it is apologizing for a defect in the= specification, whereas it is an intentional feature of the specification t= hat the syntax and verification rules of some fields is intentionally left = open for profiles to specify (even while the semantics of them is defined b= y the Assertions spec). I propose that instead, we go with the revised ver= sion at the end of this message, which I believe incorporates Hannes' ideas= while keeping the editorial tone positive. I tried to provide an honest assessment of the situation with my writeup.=20 >=20 > Second, I believe that we should proceed with the non-normative terminolo= gy change of "Principal" to "Subject", which was proposed in http://www.iet= f.org/mail-archive/web/oauth/current/msg10530.html and supported by Justin = and Torsten, with no one opposed. This should go into the version being di= scussed on the telechat (as well as the interoperability text). It would certainly make sense to re-submit a new version with this change a= nd then we see how it reads. Now, since we have a bit more time that should= not be an issue at all.=20 >=20 > Finally, I believe that it would be beneficial to all to have the=20 > Assertions and SAML Profile specs be discussed on the same telechat,=20 > as both are useful for understanding the other. Frankly, I think they=20 > should go to the IETF Editor together as "related specifications",=20 > with the goal being consecutively numbered RFCs referencing one=20 > another. Is there any reason we can't schedule both for the February=20 > 7th telechat? (I don't actually understand how they failed to proceed=20 > in lock-step in the first place. Chairs - any insights?) It might be beneficial to have the two discussed together but the IESG has = not done the reviews of the SAML assertion draft yet and therefore it is no= t on the agenda yet.=20 Ciao Hannes >=20 > =3D=3D=3D=3D >=20 > Interoperability Considerations >=20 > This specification defines a framework for using assertions with OAuth 2.= 0. However, as an abstract framework in which the data formats used for rep= resenting many values are not defined, on its own, this specification is no= t sufficient to produce interoperable implementations.=20 >=20 > Two other specifications that profile this framework for specific asserti= on have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-= based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web = Tokens (JWTs). These two instantiations of this framework specify addition= al details about the assertion encoding and processing rules for using thos= e kinds of assertions with OAuth 2.0. >=20 > However, even when profiled for specific assertion types, additional prof= iling for specific use cases will be required to achieve full interoperabil= ity. Deployments for particular trust frameworks, circles of trust, or oth= er uses cases will need to agree among the participants on the kinds of val= ues to be used for some abstract fields defined by this specification. For= example the values of Issuer, Subject, and Audience fields might be URLs, = URIs, fully qualified domain names, OAuth client IDs, IP addresses, or othe= r values, depending upon the requirements of the particular use case. The = verification rules for some values will also be use case specific. >=20 > This framework was designed with the clear expectation that additional sp= ecifications will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability for particular use cases. >=20 > =3D=3D=3D=3D >=20 > Thanks all, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability=20 > -- Today >=20 >=20 > Hiya, >=20 > So I'll take the lack of further discussion about this an meaning that th= e wg want this to shoot ahead. I'll put this in as an RFC editor note for t= he draft. >=20 > Cheers, > S. >=20 > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >>=20 >> As you have seen on the list (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I=20 >> had a chat with Mike about how to address my comment for the=20 >> assertion draft and Mike kindly provided his text proposal (see=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I=20 >> have used his text as input and extended it a bit. Here is the=20 >> updated text. >>=20 >> ---- >>=20 >> Operational Considerations and Interoperability Expectations >>=20 >> This specification defines a framework for using assertions with=20 >> OAuth 2.0. However, as an abstract framework on its own, this=20 >> specification is not sufficient to produce interoperable=20 >> implementations. Two other specifications that instantiate this=20 >> framework have been developed, one uses SAML 2.0-based assertions and=20 >> is described in [I-D.ietf-oauth-saml2-bearer] and the second builds=20 >> on JSON Web Tokens >> (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two=20 >> instantiations provide additional details about the assertion=20 >> encoding and processing rules for those interested to implement and=20 >> deploy assertions with OAuth 2.0. >>=20 >> However, even with these instance documents an interoperable=20 >> implementation is not possible since for a specific deployment=20 >> environment (within a trust framework or circle of trust, as it is=20 >> sometimes called) agreements about acceptable values for various=20 >> fields in the specification have to be agreed upon. For example, the=20 >> audience field needs to be populated by the entity that generates the=20 >> assertion with a specific value and that value may hold identifiers=20 >> of different types (for example, a URL, an IP address, an FQDN) and=20 >> the entity receiving and verifying the assertion must compare the=20 >> value in the audience field with other information it may obtain from=20 >> the request and/or with locally available information. Since the=20 >> abstract framework nor the instance documents provide sufficient=20 >> information about the syntax, the semantic and the comparison=20 >> operation of the audience field additional profiling in further=20 >> specifications is needed for an interoperable implementation. This=20 >> additional profiling is not only needed for the audience field but also = for other fields as well. >>=20 >> This framework was designed with the expectation that additional=20 >> specifications will fill this gap for deployment-specific environments. >>=20 >> ---- >>=20 >> You have the choice: >>=20 >> 1. take this as-is if you want the assertion draft=20 >> (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is=20 >> no normative text in the writeup; it is rather a clarification. >>=20 >> 2. discuss it if need be, and draft-ietf-oauth-assertions will be on=20 >> the Feb 7 >> telechat (if the discussion is done by Feb 1) >>=20 >> 1 or 2 needs to be chosen today. >>=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: FYI - draft-ietf-oauth-saml2-bearer and=20 >> draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. >>=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 From internet-drafts@ietf.org Sat Jan 19 13:55:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42E21F85A0; Sat, 19 Jan 2013 13:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMHABvmFMpGK; Sat, 19 Jan 2013 13:55:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AFD21F854F; Sat, 19 Jan 2013 13:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130119215535.3930.66197.idtracker@ietfa.amsl.com> Date: Sat, 19 Jan 2013 13:55:35 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:55:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Assertion Framework for OAuth 2.0 Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-10.txt Pages : 23 Date : 2013-01-19 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Sat Jan 19 13:57:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71A21F85E8 for ; Sat, 19 Jan 2013 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WJRcQouK4r2 for ; Sat, 19 Jan 2013 13:57:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC6121F8613 for ; Sat, 19 Jan 2013 13:57:17 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.201) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sat, 19 Jan 2013 21:57:14 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sat, 19 Jan 2013 21:57:14 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 19 Jan 2013 21:57:07 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Assertion Framework draft -10 Thread-Index: Ac32j+vih4ObEJonQH27WK7pRPCRQg== Date: Sat, 19 Jan 2013 21:57:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A53BBC@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A53BBCTK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(54316002)(44976002)(56776001)(31966008)(51856001)(74502001)(5343635001)(5343655001)(55846006)(79102001)(4396001)(54356001)(33656001)(5343665001)(16406001)(56816002)(16236675001)(47446002)(49866001)(59766001)(512954001)(74662001)(53806001)(77982001)(50986001)(47976001)(15202345001)(47736001)(46102001)(76482001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14HUBC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0731AA2DE6 Cc: "shawn.emery@oracle.com" Subject: [OAUTH-WG] OAuth Assertion Framework draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:57:19 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A53BBCTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 10 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normati= ve changes that add the "Interoperability Considerations" section that has = been discussed on the mailing list, rename "Principal" to "Subject" to use = the same terminology as the SAML Assertion Profile and JWT Assertion Profile specs, and apply Shawn Emery's com= ments from the security directorate review. The draft is available at: * http://tools.ietf.org/html/draft-ietf-oauth-assertions-10 An HTML formatted version is available at: * http://self-issued.info/docs/draft-ietf-oauth-assertions-10.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366A53BBCTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 10 of the Assertion Framework for OAuth 2.0 has been published.  It contains= non-normative changes that add the “Interoperability Considerations&= #8221; section that has been discussed on the mailing list, rename “P= rincipal” to “Subject” to use the same terminology as the SAML A= ssertion Profile and JWT Asse= rtion Profile specs, and apply Shawn Emery’s comments from the se= curity directorate review.

 

The draft is available at:

·        http://tools.ietf.org/html/draft-ietf-oauth-asser= tions-10

 

An HTML formatted version is available at:

·        http://self-issued.info/docs/draft-ietf-oa= uth-assertions-10.html

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366A53BBCTK5EX14MBXC284r_-- From sberyozkin@gmail.com Sun Jan 20 13:28:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3621F86D4 for ; Sun, 20 Jan 2013 13:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Voj+b0JntZf for ; Sun, 20 Jan 2013 13:28:37 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8B21F84E6 for ; Sun, 20 Jan 2013 13:28:37 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so1371483eaa.10 for ; Sun, 20 Jan 2013 13:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sAwMdczy8JUfR2h6Vhwk85+/9t/TIZisdwx+3+ijXfU=; b=MkTA63mkL/kpraSa7xrfChEXICJgg8t8D9hqDtDUwuSQ5WIWZ2cCxy/ceBQjzZH7u7 jv2OxA832aj2UPIe94yYbPJZJayYezuLSVMW2AXexya/3oPk7KS5w4OamtGXfrKxZBub sP4CETFdTWiPps48nmG4FzOaDBHO35c1N4JLxOz5lXawgK1AXJgUHtcBuPuorSBmZJGZ FwqYLfq6ss4VAqLAhy9p3cwjJGFy4jQIx3IIe6ent69KaRa9q2T+SKnhw2sZSXTKQzIG 1+XgKlZhRlLC8UBiLj0Yi/qSu3GB1NprEp2ILLFC6X8qw1J9B8nYciR/4X542k8WPN4I zXzQ== X-Received: by 10.14.173.69 with SMTP id u45mr52961034eel.21.1358717316391; Sun, 20 Jan 2013 13:28:36 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id k4sm19319558eep.15.2013.01.20.13.28.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 13:28:35 -0800 (PST) Message-ID: <50FC6166.8010807@gmail.com> Date: Sun, 20 Jan 2013 21:28:06 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <50E609F6.3080904@mitre.org> In-Reply-To: <50E609F6.3080904@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Use Cases for Signed Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 21:28:39 -0000 Hi, On 03/01/13 22:45, Justin Richer wrote: > I'd like to present two use cases for signed tokens, for input into the > ongoing MAC/HoK/higher-security discussion. Both of these are actual > cases that I've done in the past, and we've used either OAuth 1 or JW* > to solve them. I think that with the right tooling, a MAC-token-like > thing could be used here. I'll note to the crypto nerds in the group > (ahem, John) that I'm going to be using terms like "signing" and "MAC" > in a somewhat loose sense, so please don't get hung up on that because I > think you actually know what I mean. > > So: > > 1) Message-level signing. > > In this, you protect the content of the HTTP message by signing it with > the secret part of the token, effectively what was done in OpenID 2, > OAuth1, and the MAC draft. You pick some subset of the HTTP components, > add them to your signing base in a predictable and repeatable fashion, > and sign it with your secret. You then send the signature along with all > of the bare HTTP elements across the wire, and the far side does the > same signature generation magic and you're good to go. > > The driving use case to this is security in depth. Yes, you probably > still do want everything to go over TLS, but that only protects things > in transit between endpoints. It won't protect anything as it gets > chewed through an application platform or handed around a server farm. > It's also considered "best practice" in many cases. In my experience in > the health care space, you almost always want to have multiple layers > protecting you. > > An alternative approach here is to use a JW* container like a JWS or JWE > to hold all of your parameters (as claims) and sign/encrypt over that. > But if you do that, you're not really using HTTP anymore, except as a > dumb transport. This is the approach of SOAP, and I doubt that many will > come to its defense. (At least, those that don't want to sell you > something to process SOAP messages.) We've done this ourselves with a > prototype, and losing all of the processing capability that comes with > HTTP is a huge programmatic hit. > > 2) Signed URL as an authorized artifact. > > In this, you have party A generate a URL with parameters in it, > protected by a signature. That URL points to party B, who can validate > the signature. Party A then hands that fully baked URL to a third party, > C, who can't do anything to the parameters in the URL without messing up > the signature. From party B's perspective, so long as that signature is > valid, all the parameters in the URL can be trusted and the request can > proceed. With a timestamp and nonce parameter (built in to OAuth1), > you've even got really nice replay and timeout protection. TLS doesn't > do you any good here, because there's a party in the middle who has the > full right to hold and view the artifact (URL), but does not have the > right to modify it. We've solved this in the past using OAuth1's > signature mechanism without tokens (aka, 2-legged OAuth1). We can't > currently do this with OAuth2. If we had a generalizable HTTP components > signing mechanism (which MAC *almost* is, and could become), then we could. > > Again, you could simply cram everything into a JW* container and send > *that* as the sole parameter to a URL and get almost the same result. > But then you've got to unpack that JW* container to get all of your > parameters, and you're back in SOAP land. And again I posit: nerds hate > SOAP. > > > > Hopefully both of these will help inform the discussion and shed some > light onto why I think that: > * MAC tokens (or equivalent) are still a good idea for the WG to pursue > * Channel-binding and TLS don't solve all security problems > * Abusing JOSE leads to breaking good HTTP designs IMHO it's a very good summary - and a good read. While this is off-topic, it might also make sense to consider MAC as a light weight alternative to JW*, with both token styles nicely complementing each other and covering the signed tokens space completely, as opposed to prioritizing on a single token only which IMHO may not be ideal, which is also highlighted above by Justin Thanks, Sergey > > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From prabath@wso2.com Sun Jan 20 19:28:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE1C21F843C for ; Sun, 20 Jan 2013 19:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ISTrgQt7JB for ; Sun, 20 Jan 2013 19:28:28 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB521F843B for ; Sun, 20 Jan 2013 19:28:27 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so1431178eaa.10 for ; Sun, 20 Jan 2013 19:28:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=1ItvekzkNm8U6xVbc0PKQs0IQajZL6+ADhhATdqzBRk=; b=lpYXIVrXxK9eiBxS8mQBE9cqAlEhu+86gWzJhnsnfA8baqxHtwZJ7jGHiZN4hhG15t dQe5wzcItHReb/r71jz2+8Y7B/BceVoAbiQp1SKdSNeT9ARBzlgu7cWUW/PywXx1Et9K Rj1jEkqZV7+DgJfq8pJYcJJplfnnj6MCMJr7ow9fLWZz7TfyK8sg9OmPpCqK+2pA5YZ8 1QTM8mI+CinxAEDbvhjv8allJeIiga2LQwPdLg/z4TNTgO5Cqb5DQisf8zTSD9UYNPbw cfLoHI8a2a9jTYIstQttByL8xJc26kgGz3N1m/8GjScFEtQGwwaMoczpNKrOXNt+ETDh 0Kyw== MIME-Version: 1.0 X-Received: by 10.14.205.198 with SMTP id j46mr55823138eeo.27.1358738906875; Sun, 20 Jan 2013 19:28:26 -0800 (PST) Received: by 10.223.194.4 with HTTP; Sun, 20 Jan 2013 19:28:26 -0800 (PST) Date: Mon, 21 Jan 2013 08:58:26 +0530 Message-ID: From: Prabath Siriwardena To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7b3438eae307fa04d3c40d3a X-Gm-Message-State: ALoCoQncsF7XF7IDMAqQ80tLUfhjXDiNoMexuet3FqVrjK+X16mEqOsKyCWpxSi89F9C0vbwVz2l Subject: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 03:28:29 -0000 --047d7b3438eae307fa04d3c40d3a Content-Type: text/plain; charset=ISO-8859-1 Although token type is extensible according to the OAuth core specification - it is fully governed by the Authorization Server. There can be a case where a single AS supports multiple token types based on client request. But currently we don't have a way the client can specify (or at least suggest) which token type it needs in the OAuth access token request ? Is this behavior intentional ? or am I missing something... Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b3438eae307fa04d3c40d3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Although token type is extensible according to the OAuth core specification= - it is fully governed by the Authorization Server.

The= re can be a case where a single AS supports multiple token types based on c= lient request.

But currently we don't have a way the client can sp= ecify (or at least suggest) which token type it needs in the OAuth access t= oken request ?

Is this behavior intentional ? or a= m I missing something...


Thanks & Regards,
Prabath
--047d7b3438eae307fa04d3c40d3a-- From wmills_92105@yahoo.com Sun Jan 20 21:08:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA221F8800 for ; Sun, 20 Jan 2013 21:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0zc9yzz2ARW for ; Sun, 20 Jan 2013 21:08:45 -0800 (PST) Received: from nm22-vm0.bullet.mail.ne1.yahoo.com (nm22-vm0.bullet.mail.ne1.yahoo.com [98.138.91.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6A121F8620 for ; Sun, 20 Jan 2013 21:08:44 -0800 (PST) Received: from [98.138.226.177] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2013 05:08:40 -0000 Received: from [98.138.87.7] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2013 05:08:40 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 21 Jan 2013 05:08:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 285021.32258.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 57029 invoked by uid 60001); 21 Jan 2013 05:08:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358744919; bh=8FmLJP+q3B7XyrKUxAoOz3ultDKbDtShTECW7YV8ats=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Fz3vTFYe3xZKUfDNaQDPuUpFNJQnJ7PhicvaLsAjMQzCNpZ2gI7eFkEZA7hJ7itIZHuPxw+aOwrZhiS4D/yMTyPuRfg0Sh/6e8zAJaNNxqTD8m/TKD8EZzVxwiGYMjdVuqYFRRIDrLE8ryEw4TVPA9o07Pii8FR1O9KFW/kS9fs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CSEdYXq1nCmn+URvbz89Aw9fLV0yp2LVYvxYBpOc+vIlMUQxg2FgryF7xyh1liMcF0/b3Y3AWw9D5ha31dUPu2L1cY9IVQSo0bUB+6kSe5QjzpTrFY1SRYB/7V2XYIKfhtCU1rI0mN6tsxcqkQOlJqI4gZxHkf9QXFRkzsDVX2k=; X-YMail-OSG: BOtc7pAVM1mowEGlVIkJyAxlProzFRa2BLPkWLW4FnNKv0M Me9F2UJ6uwRwuMP2JteOuqdJuLtcEQTX.btXRr4ZBnPo7Qsr3GKV2BJxE0Pb fN9brDrNLHhzZfTD7gmSOEQtoH5EZ2Zxelk5g_YzWFnlvgLhCdELPcdsYmCA 3qfSjuPFwAFsC3KltjWJtBX_TrcpUJNaDTLukDbWU.PhjnJs6IKaNwsIw.ij 9hvwWKdRudMnW_y2alf1z7zkQ1evf2GsE0JnM2.Rzj749sDt1VfY.EPOtyHS SjwTo9pC1SsGlqme0GT9HoJwEShqodQTgsoipXi8qrfWshmJZA43koF9rv5W XvBve0FVlUMmDXh4.eBHl9FIDOyMQfM.uX8_xX1i9WE3E6OI_UVAsumgoQjQ bY2XdvFPYl96xOBirz_wKxNJOrHPsVT73RBTDTy1tRwK2cMRgRUmwq5m8d9n aeJMKFK18s5lLYQZHQhxKN1Sczkex2cz3dsCYRsXCFMrvgUPyfWfpGnt66WD .RC2P48JhWSpBPUlCyimxqW9BQYelzeTCBGSOWC79qpxo5zixPnQL4oQuAdw F7AJOrWwT457YXrHPW.7m19Z6_BL1fsHn4n.syA1v9T8Z6Oo7HF.BsnCPJBz M_.qt_MnHOCU0ihZA_EOM Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Sun, 20 Jan 2013 21:08:39 PST X-Rocket-MIMEInfo: 001.001, VGhpcyBpcyB0cnVlLiDCoEl0J3MgcG9zc2libGUgZm9yIHRoZSBBUyB0byB2YXJ5IGl0J3MgYmVoYXZpb3Igb24gc2NvcGUgbmFtZSwgYnV0IGl0J3MgcHJlc3VtZWQgdGhlIEFTIGFuZCBSUyBoYXZlIGFuIGFncmVlbWVudCBvZiB3aGF0IHRva2VuIHR5cGUgaXMgaW4gcGxheS4gwqBMaWtlbHkgYSBnb29kIGV4dGVuc2lvbiB0byB0aGUgc3BlYy4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4KVG86ICJvYXV0aEABMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.496 References: Message-ID: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sun, 20 Jan 2013 21:08:39 -0800 (PST) From: William Mills To: Prabath Siriwardena , "oauth@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1492950284-1358744919=:12881" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 05:08:46 -0000 --764183289-1492950284-1358744919=:12881 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is true. =A0It's possible for the AS to vary it's behavior on scope na= me, but it's presumed the AS and RS have an agreement of what token type is= in play. =A0Likely a good extension to the spec.=0A=0A=0A_________________= _______________=0A From: Prabath Siriwardena =0ATo: "oaut= h@ietf.org WG" =0ASent: Sunday, January 20, 2013 7:28 PM= =0ASubject: [OAUTH-WG] Client cannot specify the token type it needs=0A =0A= =0AAlthough token type is extensible according to the OAuth core specificat= ion - it is fully governed by the Authorization Server.=0A=0AThere can be a= case where a single AS supports multiple token types based on client reque= st.=0A=0ABut currently we don't have a way the client can specify (or at le= ast suggest) which token type it needs in the OAuth access token request ?= =0A=0AIs this behavior intentional ? or am I missing something...=0A=0A=0AT= hanks & Regards,=0APrabath=0A=0AMobile : +94 71 809 6732=A0=0A=0Ahttp://blo= g.facilelogin.com=0Ahttp://RampartFAQ.com=0A_______________________________= ________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.o= rg/mailman/listinfo/oauth --764183289-1492950284-1358744919=:12881 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This is true.  It's possible for the AS to vary it's behavior on sco= pe name, but it's presumed the AS and RS have an agreement of what token ty= pe is in play.  Likely a good extension to the spec.
=
From: Prabath Siriwardena <prabath@wso2.com>
= To: "oauth@ietf.org WG" &l= t;oauth@ietf.org>
Sent: Sunday, January 20, 2013 7:28 PM
Subject: [OAUTH-WG] Client cannot specify the token type= it needs

=0A
Although toke= n type is extensible according to the OAuth core specification - it is full= y governed by the Authorization Server.

There can be a c= ase where a single AS supports multiple token types based on client request= .
=0A

But currently we don't have a way the client = can specify (or at least suggest) which token type it needs in the OAuth ac= cess token request ?

Is this behavior intentional = ? or am I missing something...
=0A


T= hanks & Regards,
Prabath

Mobile : +94 71 809 6732=  

http://blog.facilelogin.com
http://RampartFAQ.com
=0A= =0A
=0A

_______________________________________________
OA= uth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th


--764183289-1492950284-1358744919=:12881-- From zhou.sujing@zte.com.cn Sun Jan 20 21:18:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515BA21F8518; Sun, 20 Jan 2013 21:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8O2u1vBgpWS; Sun, 20 Jan 2013 21:18:49 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D421F850F; Sun, 20 Jan 2013 21:18:48 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id CC77D1261C34; Mon, 21 Jan 2013 13:21:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0L5IP59015238; Mon, 21 Jan 2013 13:18:25 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> To: William Mills MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 21 Jan 2013 13:18:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-21 13:18:28, Serialize complete at 2013-01-21 13:18:28 Content-Type: multipart/alternative; boundary="=_alternative 001D2C4D48257AFA_=" X-MAIL: mse01.zte.com.cn r0L5IP59015238 Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 05:18:50 -0000 This is a multipart message in MIME format. --=_alternative 001D2C4D48257AFA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHRva2VuIHR5cGUgc2hvdWxiZSBkZWNpZGVkIGJ5IHJlc291cmNlIHNlcnZlciwgd2hpY2gg Y29uc3VtZXMgYWNjZXNzIA0KdG9rZW4uDQpDbGllbnQganVzdCByZS10ZWxsIHRoZSByZXF1ZXN0 ZWQgdG9rZW4gdHlwZSB0byBBUy4gDQpDbGllbnQgc2hvdWxkIG5vdCBzcGVjaWZ5IHRoZSB0b2tl biB0eXBlLg0KDQoNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTIxIDEzOjA4 OjM5Og0KDQo+IFRoaXMgaXMgdHJ1ZS4gIEl0J3MgcG9zc2libGUgZm9yIHRoZSBBUyB0byB2YXJ5 IGl0J3MgYmVoYXZpb3Igb24gDQo+IHNjb3BlIG5hbWUsIGJ1dCBpdCdzIHByZXN1bWVkIHRoZSBB UyBhbmQgUlMgaGF2ZSBhbiBhZ3JlZW1lbnQgb2YgDQo+IHdoYXQgdG9rZW4gdHlwZSBpcyBpbiBw bGF5LiAgTGlrZWx5IGEgZ29vZCBleHRlbnNpb24gdG8gdGhlIHNwZWMuDQo+IA0KPiBGcm9tOiBQ cmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPg0KPiBUbzogIm9hdXRoQGlldGYu b3JnIFdHIiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiBTZW50OiBTdW5kYXksIEphbnVhcnkgMjAsIDIw MTMgNzoyOCBQTQ0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0 aGUgdG9rZW4gdHlwZSBpdCBuZWVkcw0KPiANCj4gQWx0aG91Z2ggdG9rZW4gdHlwZSBpcyBleHRl bnNpYmxlIGFjY29yZGluZyB0byB0aGUgT0F1dGggY29yZSANCj4gc3BlY2lmaWNhdGlvbiAtIGl0 IGlzIGZ1bGx5IGdvdmVybmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4NCj4gDQo+IFRo ZXJlIGNhbiBiZSBhIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMgbXVsdGlwbGUgdG9r ZW4gdHlwZXMgDQo+IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0Lg0KPiANCj4gQnV0IGN1cnJlbnRs eSB3ZSBkb24ndCBoYXZlIGEgd2F5IHRoZSBjbGllbnQgY2FuIHNwZWNpZnkgKG9yIGF0IA0KPiBs ZWFzdCBzdWdnZXN0KSB3aGljaCB0b2tlbiB0eXBlIGl0IG5lZWRzIGluIHRoZSBPQXV0aCBhY2Nl c3MgdG9rZW4gDQpyZXF1ZXN0ID8NCj4gDQo+IElzIHRoaXMgYmVoYXZpb3IgaW50ZW50aW9uYWwg PyBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nLi4uDQo+IA0KPiBUaGFua3MgJiBSZWdhcmRzLA0K PiBQcmFiYXRoDQo+IA0KPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+IA0KPiBodHRwOi8v YmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gaHR0cDovL1JhbXBhcnRGQVEuY29tDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWls aW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --=_alternative 001D2C4D48257AFA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSB0b2tlbiB0eXBlIHNob3Vs YmUgZGVjaWRlZCBieSByZXNvdXJjZQ0Kc2VydmVyLCB3aGljaCBjb25zdW1lcyBhY2Nlc3MgdG9r ZW4uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5DbGllbnQganVz dCByZS10ZWxsIHRoZSByZXF1ZXN0ZWQgdG9rZW4NCnR5cGUgdG8gQVMuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2xpZW50IHNob3VsZCBub3Qgc3BlY2lmeSB0 aGUgdG9rZW4NCnR5cGUuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ b2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDEtMjEgMTM6MDg6Mzk6PGJyPg0KPGJy Pg0KJmd0OyBUaGlzIGlzIHRydWUuICZuYnNwO0l0J3MgcG9zc2libGUgZm9yIHRoZSBBUyB0byB2 YXJ5IGl0J3MgYmVoYXZpb3INCm9uIDxicj4NCiZndDsgc2NvcGUgbmFtZSwgYnV0IGl0J3MgcHJl c3VtZWQgdGhlIEFTIGFuZCBSUyBoYXZlIGFuIGFncmVlbWVudCBvZiA8YnI+DQomZ3Q7IHdoYXQg dG9rZW4gdHlwZSBpcyBpbiBwbGF5LiAmbmJzcDtMaWtlbHkgYSBnb29kIGV4dGVuc2lvbiB0byB0 aGUgc3BlYy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyBGcm9tOiBQcmFiYXRoIFNpcml3YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0Ozxicj4N CiZndDsgVG86ICZxdW90O29hdXRoQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9y ZyZndDsgPGJyPg0KJmd0OyBTZW50OiBTdW5kYXksIEphbnVhcnkgMjAsIDIwMTMgNzoyOCBQTTxi cj4NCiZndDsgU3ViamVjdDogW09BVVRILVdHXSBDbGllbnQgY2Fubm90IHNwZWNpZnkgdGhlIHRv a2VuIHR5cGUgaXQgbmVlZHM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBBbHRob3VnaCB0b2tlbiB0eXBlIGlzIGV4dGVuc2libGUgYWNjb3JkaW5nIHRv IHRoZSBPQXV0aCBjb3JlIDxicj4NCiZndDsgc3BlY2lmaWNhdGlvbiAtIGl0IGlzIGZ1bGx5IGdv dmVybmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGVyZSBjYW4gYmUgYSBjYXNlIHdoZXJlIGEg c2luZ2xlIEFTIHN1cHBvcnRzIG11bHRpcGxlIHRva2VuIHR5cGVzDQo8YnI+DQomZ3Q7IGJhc2Vk IG9uIGNsaWVudCByZXF1ZXN0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IEJ1dCBjdXJyZW50bHkgd2UgZG9uJ3QgaGF2ZSBhIHdheSB0aGUgY2xpZW50 IGNhbiBzcGVjaWZ5IChvciBhdCA8YnI+DQomZ3Q7IGxlYXN0IHN1Z2dlc3QpIHdoaWNoIHRva2Vu IHR5cGUgaXQgbmVlZHMgaW4gdGhlIE9BdXRoIGFjY2VzcyB0b2tlbg0KcmVxdWVzdCA/PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSXMgdGhpcyBiZWhh dmlvciBpbnRlbnRpb25hbCA/IG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmcuLi48L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgUmVn YXJkcyw8YnI+DQomZ3Q7IFByYWJhdGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgPGJyPg0KJmd0OyBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgaHR0cDovL1JhbXBh cnRGQVEuY29tPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7IDxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+ DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQo8 L2ZvbnQ+PC90dD4NCg== --=_alternative 001D2C4D48257AFA_=-- From prabath@wso2.com Sun Jan 20 21:29:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF921F8584 for ; Sun, 20 Jan 2013 21:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzET8OJdXPYH for ; Sun, 20 Jan 2013 21:29:07 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB121F857A for ; Sun, 20 Jan 2013 21:29:06 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so2611960eek.11 for ; Sun, 20 Jan 2013 21:29:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Et3q1qDpB0o7W6SQr8Dt9X/8cuCJzZUHhZzVw9ez7Uk=; b=pVV/YzxYDyt/1Mb9D5MQ0qWzXOZ5zA/+haD1ZLWSxNPocrXOOoOLqtYCm2OMYIJ2gL +TJS5cerin8Ats13SDvl3IYVIUEle5cEzy+Mo9B4KgNzIjba3lS29vX6bw/4ztRP59PJ JBGHFS4FE0HAG3ZH9flflsK0jxUILp3uz4iZ0/lHACaEaxzjc5VgiHv5zKnOV9eMsOXa Ol6hjfpiKdM6bXWrFSrjQ1ukRiXv3PXDUiHQEgEvzYXc7rMXvFlkfkNj3LBoiHsRoP6B 99CtIFAKZuGx6rc6jmSMtrd1spzysrDyVmXVBE8xKxbbYGnwdLNp2wYey91ODOPR26Gv cjHw== MIME-Version: 1.0 X-Received: by 10.14.205.198 with SMTP id j46mr56737729eeo.27.1358746145907; Sun, 20 Jan 2013 21:29:05 -0800 (PST) Received: by 10.223.194.4 with HTTP; Sun, 20 Jan 2013 21:29:05 -0800 (PST) In-Reply-To: References: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Mon, 21 Jan 2013 10:59:05 +0530 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b3438ea5de55f04d3c5bd41 X-Gm-Message-State: ALoCoQkEkZ3KVd/EQWwHz1SnzW79TzlhszctnDVrpmGjTylvauyqTGYTS0uMFJWh0L04UNcmnES5 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 05:29:08 -0000 --047d7b3438ea5de55f04d3c5bd41 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Think about a distributed setup. You have single Authorization Server and multiple Resource Servers. Although OAuth nicely decouples AS from RS - AFAIK there is no standard established for communication betweens AS and RS - how to declare metadata between those. Also there can be Resource Servers which support multiple token types. It could vary on APIs hosted in a given RS. Thanks & regards, -Prabath On Mon, Jan 21, 2013 at 10:48 AM, wrote: > > The token type shoulbe decided by resource server, which consumes access > token. > Client just re-tell the requested token type to AS. > Client should not specify the token type. > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39: > > > > This is true. It's possible for the AS to vary it's behavior on > > scope name, but it's presumed the AS and RS have an agreement of > > what token type is in play. Likely a good extension to the spec. > > > > > From: Prabath Siriwardena > > To: "oauth@ietf.org WG" > > Sent: Sunday, January 20, 2013 7:28 PM > > Subject: [OAUTH-WG] Client cannot specify the token type it needs > > > > > Although token type is extensible according to the OAuth core > > specification - it is fully governed by the Authorization Server. > > > > There can be a case where a single AS supports multiple token types > > based on client request. > > > > But currently we don't have a way the client can specify (or at > > least suggest) which token type it needs in the OAuth access token > request ? > > > > Is this behavior intentional ? or am I missing something... > > > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b3438ea5de55f04d3c5bd41 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Think about a distributed setup. You have single Authorization Server and m= ultiple Resource Servers.

Although OAuth nicely decouple= s AS from RS - AFAIK there is no standard established for communication bet= weens AS and RS - how to declare metadata between those.

Also there can be Resource Servers which support multip= le token types. It could vary on APIs hosted in a given RS.

<= /div>
Thanks & regards,
-Prabath


On Mon, Jan 21, 2013 at 10:48 AM, <zhou.sujing@zte.com.cn> wrote:

The token type shoulbe decided by resource server, which consumes access token.
Client just re-tell the requested token type to AS.
Client should not specify the token type.


o= auth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39:


> This is true.  It's possible for the AS to vary it's beha= vior on
> scope name, but it's presumed the AS and RS have an agreement of <= br> > what token type is in play.  Likely a good extension to the spec.=

>
> From: Prabath Siriwardena <prabath@wso2.com>
> To: "oauth@ie= tf.org WG" <oauth@ietf.org>
> Sent: Sunday, January 20, 2013 7:28 PM
> Subject: [OAUTH-WG] Client cannot specify the token type it needs
>
> Although token type is extensible according to the OAuth core
> specification - it is fully governed by the Authorization Server.
>
> There can be a case where a single AS supports multiple token types
> based on client request.
>
> But currently we don't have a way the client can specify (or at > least suggest) which token type it needs in the OAuth access token request ?
>
> Is this behavior intentional ? or am I missing something...
>
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.= facilelogin.com
> http://RampartFAQ.= com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



--
= Thanks & Regards,
Prabath

--047d7b3438ea5de55f04d3c5bd41-- From zhou.sujing@zte.com.cn Sun Jan 20 21:39:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065A721F881E for ; Sun, 20 Jan 2013 21:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0Lj8-tiKdoC for ; Sun, 20 Jan 2013 21:39:10 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CC7A721F881C for ; Sun, 20 Jan 2013 21:39:01 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A2A81126200E; Mon, 21 Jan 2013 13:41:35 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id ABDDEDF5343; Mon, 21 Jan 2013 13:42:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r0L5cf0u003105; Mon, 21 Jan 2013 13:38:41 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 21 Jan 2013 13:38:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-21 13:38:44, Serialize complete at 2013-01-21 13:38:44 Content-Type: multipart/alternative; boundary="=_alternative 001F07AC48257AFA_=" X-MAIL: mse02.zte.com.cn r0L5cf0u003105 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 05:39:11 -0000 This is a multipart message in MIME format. --=_alternative 001F07AC48257AFA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2VsbCwgaWYgUlMgY291bGQgc3BlY2lmeSB0b2tlbiB0eXBlLCB0aGVuIENsaWVudCBjb3VsZCB0 cmFuc2ZlciBpdCB0byBBUywgDQoNCkkgdGhpbmssIGJ1dCBpdCBpcyBub3QgYSBnb29kIGlkZWEg Zm9yIGNsaWVudCBpdHNlbGYgdG8gc3BlY2lmeSB0aGUgdG9rZW4gDQp0eXBlLiANCg0KDQpQcmFi YXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiDQtNPaIDIwMTMtMDEtMjEgMTM6Mjk6 MDU6DQoNCj4gVGhpbmsgYWJvdXQgYSBkaXN0cmlidXRlZCBzZXR1cC4gWW91IGhhdmUgc2luZ2xl IEF1dGhvcml6YXRpb24gDQo+IFNlcnZlciBhbmQgbXVsdGlwbGUgUmVzb3VyY2UgU2VydmVycy4N Cj4gDQo+IEFsdGhvdWdoIE9BdXRoIG5pY2VseSBkZWNvdXBsZXMgQVMgZnJvbSBSUyAtIEFGQUlL IHRoZXJlIGlzIG5vIA0KPiBzdGFuZGFyZCBlc3RhYmxpc2hlZCBmb3IgY29tbXVuaWNhdGlvbiBi ZXR3ZWVucyBBUyBhbmQgUlMgLSBob3cgdG8gDQo+IGRlY2xhcmUgbWV0YWRhdGEgYmV0d2VlbiB0 aG9zZS4NCj4gDQo+IEFsc28gdGhlcmUgY2FuIGJlIFJlc291cmNlIFNlcnZlcnMgd2hpY2ggc3Vw cG9ydCBtdWx0aXBsZSB0b2tlbiANCj4gdHlwZXMuIEl0IGNvdWxkIHZhcnkgb24gQVBJcyBob3N0 ZWQgaW4gYSBnaXZlbiBSUy4NCj4gDQo+IFRoYW5rcyAmIHJlZ2FyZHMsDQo+IC1QcmFiYXRoDQo+ IA0KPiBPbiBNb24sIEphbiAyMSwgMjAxMyBhdCAxMDo0OCBBTSwgPHpob3Uuc3VqaW5nQHp0ZS5j b20uY24+IHdyb3RlOg0KPiANCj4gVGhlIHRva2VuIHR5cGUgc2hvdWxiZSBkZWNpZGVkIGJ5IHJl c291cmNlIHNlcnZlciwgd2hpY2ggY29uc3VtZXMgDQo+IGFjY2VzcyB0b2tlbi4gDQo+IENsaWVu dCBqdXN0IHJlLXRlbGwgdGhlIHJlcXVlc3RlZCB0b2tlbiB0eXBlIHRvIEFTLiANCj4gQ2xpZW50 IHNob3VsZCBub3Qgc3BlY2lmeSB0aGUgdG9rZW4gdHlwZS4gDQo+IA0KPiANCj4gb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDEtMjEgMTM6MDg6Mzk6DQo+IA0KPiANCj4gPiBUaGlz IGlzIHRydWUuICBJdCdzIHBvc3NpYmxlIGZvciB0aGUgQVMgdG8gdmFyeSBpdCdzIGJlaGF2aW9y IG9uIA0KPiA+IHNjb3BlIG5hbWUsIGJ1dCBpdCdzIHByZXN1bWVkIHRoZSBBUyBhbmQgUlMgaGF2 ZSBhbiBhZ3JlZW1lbnQgb2YgDQo+ID4gd2hhdCB0b2tlbiB0eXBlIGlzIGluIHBsYXkuICBMaWtl bHkgYSBnb29kIGV4dGVuc2lvbiB0byB0aGUgc3BlYy4NCj4gDQo+ID4gDQo+ID4gRnJvbTogUHJh YmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4NCj4gPiBUbzogIm9hdXRoQGlldGYu b3JnIFdHIiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiA+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAyMCwg MjAxMyA3OjI4IFBNDQo+ID4gU3ViamVjdDogW09BVVRILVdHXSBDbGllbnQgY2Fubm90IHNwZWNp ZnkgdGhlIHRva2VuIHR5cGUgaXQgbmVlZHMNCj4gDQo+ID4gDQo+ID4gQWx0aG91Z2ggdG9rZW4g dHlwZSBpcyBleHRlbnNpYmxlIGFjY29yZGluZyB0byB0aGUgT0F1dGggY29yZSANCj4gPiBzcGVj aWZpY2F0aW9uIC0gaXQgaXMgZnVsbHkgZ292ZXJuZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2Vy dmVyLiANCj4gPiANCj4gPiBUaGVyZSBjYW4gYmUgYSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1 cHBvcnRzIG11bHRpcGxlIHRva2VuIHR5cGVzIA0KPiA+IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0 LiANCj4gPiANCj4gPiBCdXQgY3VycmVudGx5IHdlIGRvbid0IGhhdmUgYSB3YXkgdGhlIGNsaWVu dCBjYW4gc3BlY2lmeSAob3IgYXQgDQo+ID4gbGVhc3Qgc3VnZ2VzdCkgd2hpY2ggdG9rZW4gdHlw ZSBpdCBuZWVkcyBpbiB0aGUgT0F1dGggYWNjZXNzIA0KdG9rZW5yZXF1ZXN0ID8NCj4gPiANCj4g PiBJcyB0aGlzIGJlaGF2aW9yIGludGVudGlvbmFsID8gb3IgYW0gSSBtaXNzaW5nIHNvbWV0aGlu Zy4uLiANCj4gPiANCj4gPiBUaGFua3MgJiBSZWdhcmRzLA0KPiA+IFByYWJhdGggDQo+ID4gDQo+ ID4gTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KPiA+IA0KPiA+IGh0dHA6Ly9ibG9nLmZhY2ls ZWxvZ2luLmNvbQ0KPiA+IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbSANCj4gPiANCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxp bmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo+IA0KDQo+IA0KPiAtLSANCj4gVGhhbmtzICYgUmVnYXJkcywNCj4gUHJhYmF0aA0KPiANCj4g TW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KPiANCj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4u Y29tDQo+IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbQ0K --=_alternative 001F07AC48257AFA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlbGwsIGlmIFJTIGNvdWxkIHNw ZWNpZnkgdG9rZW4gdHlwZSwNCnRoZW4gQ2xpZW50IGNvdWxkIHRyYW5zZmVyIGl0IHRvIEFTLCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmssIGJ1dCBp dCBpcyBub3QgYSBnb29kIGlkZWEgZm9yDQpjbGllbnQgaXRzZWxmIHRvIHNwZWNpZnkgdGhlIHRv a2VuIHR5cGUuIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlByYWJh dGggU2lyaXdhcmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7INC009oNCjIwMTMtMDEtMjEg MTM6Mjk6MDU6PGJyPg0KPGJyPg0KJmd0OyBUaGluayBhYm91dCBhIGRpc3RyaWJ1dGVkIHNldHVw LiBZb3UgaGF2ZSBzaW5nbGUgQXV0aG9yaXphdGlvbiA8YnI+DQomZ3Q7IFNlcnZlciBhbmQgbXVs dGlwbGUgUmVzb3VyY2UgU2VydmVycy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgPGJyPg0KJmd0OyBBbHRob3VnaCBPQXV0aCBuaWNlbHkgZGVjb3VwbGVzIEFTIGZyb20g UlMgLSBBRkFJSyB0aGVyZSBpcyBubyA8YnI+DQomZ3Q7IHN0YW5kYXJkIGVzdGFibGlzaGVkIGZv ciBjb21tdW5pY2F0aW9uIGJldHdlZW5zIEFTIGFuZCBSUyAtIGhvdyB0bw0KPGJyPg0KJmd0OyBk ZWNsYXJlIG1ldGFkYXRhIGJldHdlZW4gdGhvc2UuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQWxzbyB0aGVyZSBjYW4gYmUgUmVzb3VyY2UgU2VydmVy cyB3aGljaCBzdXBwb3J0IG11bHRpcGxlIHRva2VuIDxicj4NCiZndDsgdHlwZXMuIEl0IGNvdWxk IHZhcnkgb24gQVBJcyBob3N0ZWQgaW4gYSBnaXZlbiBSUy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcyw8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLVByYWJhdGg8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIEphbiAyMSwgMjAxMyBh dCAxMDo0OCBBTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7IHdyb3RlOjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoZSB0b2tlbiB0eXBl IHNob3VsYmUgZGVjaWRlZCBieSByZXNvdXJjZSBzZXJ2ZXIsIHdoaWNoIGNvbnN1bWVzDQo8YnI+ DQomZ3Q7IGFjY2VzcyB0b2tlbi4gPGJyPg0KJmd0OyBDbGllbnQganVzdCByZS10ZWxsIHRoZSBy ZXF1ZXN0ZWQgdG9rZW4gdHlwZSB0byBBUy4gPGJyPg0KJmd0OyBDbGllbnQgc2hvdWxkIG5vdCBz cGVjaWZ5IHRoZSB0b2tlbiB0eXBlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBv YXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0yMSAxMzowODozOTo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg VGhpcyBpcyB0cnVlLiAmbmJzcDtJdCdzIHBvc3NpYmxlIGZvciB0aGUgQVMgdG8gdmFyeSBpdCdz IGJlaGF2aW9yDQpvbiA8YnI+DQomZ3Q7ICZndDsgc2NvcGUgbmFtZSwgYnV0IGl0J3MgcHJlc3Vt ZWQgdGhlIEFTIGFuZCBSUyBoYXZlIGFuIGFncmVlbWVudA0Kb2YgPGJyPg0KJmd0OyAmZ3Q7IHdo YXQgdG9rZW4gdHlwZSBpcyBpbiBwbGF5LiAmbmJzcDtMaWtlbHkgYSBnb29kIGV4dGVuc2lvbiB0 bw0KdGhlIHNwZWMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsgJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBG cm9tOiBQcmFiYXRoIFNpcml3YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0Ozxicj4NCiZn dDsgJmd0OyBUbzogJnF1b3Q7b2F1dGhAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0O29hdXRoQGlldGYu b3JnJmd0OyA8YnI+DQomZ3Q7ICZndDsgU2VudDogU3VuZGF5LCBKYW51YXJ5IDIwLCAyMDEzIDc6 MjggUE08YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogW09BVVRILVdHXSBDbGllbnQgY2Fubm90IHNw ZWNpZnkgdGhlIHRva2VuIHR5cGUgaXQgbmVlZHM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbHRob3VnaCB0b2tl biB0eXBlIGlzIGV4dGVuc2libGUgYWNjb3JkaW5nIHRvIHRoZSBPQXV0aCBjb3JlDQo8YnI+DQom Z3Q7ICZndDsgc3BlY2lmaWNhdGlvbiAtIGl0IGlzIGZ1bGx5IGdvdmVybmVkIGJ5IHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlci4NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUg Y2FuIGJlIGEgY2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBtdWx0aXBsZSB0b2tlbg0K dHlwZXMgPGJyPg0KJmd0OyAmZ3Q7IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0LiA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJ1dCBjdXJyZW50bHkgd2UgZG9uJ3QgaGF2ZSBhIHdheSB0 aGUgY2xpZW50IGNhbiBzcGVjaWZ5IChvcg0KYXQgPGJyPg0KJmd0OyAmZ3Q7IGxlYXN0IHN1Z2dl c3QpIHdoaWNoIHRva2VuIHR5cGUgaXQgbmVlZHMgaW4gdGhlIE9BdXRoIGFjY2Vzcw0KdG9rZW5y ZXF1ZXN0ID88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IElzIHRoaXMgYmVoYXZpb3Ig aW50ZW50aW9uYWwgPyBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nLi4uIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IFBy YWJhdGggPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBNb2JpbGUgOiArOTQgNzEgODA5 IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVs b2dpbi5jb208YnI+DQomZ3Q7ICZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZn dDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgVGhhbmtzICZh bXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyBQcmFiYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIDxicj4NCiZn dDsgPGJyPg0KJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208YnI+DQomZ3Q7IGh0dHA6 Ly9SYW1wYXJ0RkFRLmNvbTwvZm9udD48L3R0Pg0K --=_alternative 001F07AC48257AFA_=-- From wmills_92105@yahoo.com Sun Jan 20 21:45:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA72521F8777 for ; Sun, 20 Jan 2013 21:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F+dJ3ddLGg8 for ; Sun, 20 Jan 2013 21:45:02 -0800 (PST) Received: from nm13.bullet.mail.bf1.yahoo.com (nm13.bullet.mail.bf1.yahoo.com [98.139.212.172]) by ietfa.amsl.com (Postfix) with SMTP id 867F521F8620 for ; Sun, 20 Jan 2013 21:44:47 -0800 (PST) Received: from [98.139.212.146] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 05:44:46 -0000 Received: from [98.139.215.228] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 05:44:46 -0000 Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 05:44:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 940504.5786.bm@omp1068.mail.bf1.yahoo.com Received: (qmail 46794 invoked by uid 60001); 21 Jan 2013 05:44:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358747086; bh=QkXGGRj1HYyNwGwAGu04uz2RrbBsi8B8g0PprPuNLw4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kgOPKWyqsa1bl6UENt89Znhc6lHtF9aDgInx88z8Z2AOSNEIQwe5BlhLwS2vQ+jmLhp6L7lYknl26yEqOYsjvGyabYBfel4qxWofM2szWJrP+Xm1idJiuHPM1QgOMYvxM028hbEvpEU2fd3T8ehAPX0F16Y0qJxKJsAJ2RL6dls= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SFziQAWcDcTpthrLEcGQlVOoM0eLQmpMydOmZmS75R1KtDcv74MHtUKxpWJ7M0WurP5A7ivnc+WoXbTEsurWi3Y/jF2n2q9nu7pQAxiCckkEM49XSupi67+dQ5r1u3bfYeFtARcCWu580TMjAv/ufwDTiCs8wC2aWB+wzd5Jnhc=; X-YMail-OSG: bindHnkVM1lvGSqMavgrlazJXFO1ygXZBwFm6pawzWMNk5A T9fdbcjf.9W2wzUQzOqxwZ63wqI44pCO_mxYcraOG6R8b8EQSCogJ20prvzK MzqvVfFnLHm6WIadJ_8gzL25ORRRUjQndU._sRisszZS2GPt3BF1z.v7POh1 2eYPRwCU7gX_7A2YpzLC0PsIKYusaDJpS72xfSFPP9ubBL4_UdaQJ2foT6H6 EWhu3jg_bhoPysQSC9fdnCXs1Gf8aeVwudIZ8LJudq5QDI5qwVh7Fejnp6u_ m1j7VMWJQS.pIGzjeiRs8DIeAWhC5.M1Uv51YXCEGlc5P1ttfBc1vp7B2L9i VsaopOQFFZfhoVrk9N0vc.RCIWGOICnvOs2pHzXZf4X_Wo03s917FatA1ePJ vhCcP64iAp0JZYuwqGEYjyFvXshmw9usHjRZEb4L1mMHcYuKKxGvYfaWSAPz 8dBSKobrFxSW4nNxONZWujMnmp8VmeBivtbgN5V4BBrY0tL4h7JGfCBc4NAu ubEYnM8HREwER1nyLASzbVO.tdOTaDScATivmh35cf5kbe9FIOt4gJ9iWZNg lrmQ6dAzjGD4ZuIAVgpWXDmu9b7r3vzWgYrKZhZwQUjQNFPRhajxlcBGJ9Qu hlTV5d2M87L26xC8qtsu. Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Sun, 20 Jan 2013 21:44:45 PST X-Rocket-MIMEInfo: 001.001, Tm90IGEgcHJvYmxlbSBmb3IgdGhlIGNsaWVudCB0byByZXF1ZXN0IGEgdHlwZSwgYnV0IGl0IG1heSBub3QgZ2V0IGl0LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiAiemhvdS5zdWppbmdAenRlLmNvbS5jbiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24.ClRvOiBQcmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiAKQ2M6ICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPjsgV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gClMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.496 References: Message-ID: <1358747085.35324.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Sun, 20 Jan 2013 21:44:45 -0800 (PST) From: William Mills To: "zhou.sujing@zte.com.cn" , Prabath Siriwardena In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-211105913-1358747085=:35324" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 05:45:12 -0000 ---1395015409-211105913-1358747085=:35324 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not a problem for the client to request a type, but it may not get it.=0A= =0A=0A________________________________=0A From: "zhou.sujing@zte.com.cn" =0ATo: Prabath Siriwardena =0ACc: = "oauth@ietf.org WG" ; William Mills =0ASent: Sunday, January 20, 2013 9:38 PM=0ASubject: Re: Re: Re: [OAUTH-W= G] Client cannot specify the token type it needs=0A =0A=0A=0AWell, if RS co= uld specify token type,=0Athen Client could transfer it to AS, =0AI think,= but it is not a good idea for=0Aclient itself to specify the token type. = =0A=0A=0APrabath Siriwardena =E5=86=99=E4=BA=8E=0A2013-0= 1-21 13:29:05:=0A=0A> Think about a distributed setup. You have single Auth= orization =0A> Server and multiple Resource Servers. =0A> =0A> Although OAu= th nicely decouples AS from RS - AFAIK there is no =0A> standard establishe= d for communication betweens AS and RS - how to =0A> declare metadata betwe= en those. =0A> =0A> Also there can be Resource Servers which support multip= le token =0A> types. It could vary on APIs hosted in a given RS. =0A> =0A> = Thanks & regards, =0A> -Prabath =0A> =0A> On Mon, Jan 21, 2013 at 10:48 AM,= wrote: =0A> =0A> The token type shoulbe decided b= y resource server, which consumes =0A> access token. =0A> Client just re-te= ll the requested token type to AS. =0A> Client should not specify the token= type. =0A> =0A> =0A> oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-01-21 = 13:08:39: =0A> =0A> =0A> > This is true. =C2=A0It's possible for the AS to = vary it's behavior=0Aon =0A> > scope name, but it's presumed the AS and RS = have an agreement=0Aof =0A> > what token type is in play. =C2=A0Likely a go= od extension to=0Athe spec. =0A> =0A> > =0A> > From: Prabath Siriwardena <= prabath@wso2.com>=0A> > To: "oauth@ietf.org WG" =0A> > Sen= t: Sunday, January 20, 2013 7:28 PM=0A> > Subject: [OAUTH-WG] Client cannot= specify the token type it needs =0A> =0A> > =0A> > Although token type is = extensible according to the OAuth core =0A> > specification - it is fully g= overned by the Authorization Server. =0A> > =0A> > There can be a case wher= e a single AS supports multiple token=0Atypes =0A> > based on client reques= t. =0A> > =0A> > But currently we don't have a way the client can specify (= or=0Aat =0A> > least suggest) which token type it needs in the OAuth access= =0Atokenrequest ?=0A> > =0A> > Is this behavior intentional ? or am I missi= ng something... =0A> > =0A> > Thanks & Regards,=0A> > Prabath =0A> > =0A> >= Mobile : +94 71 809 6732 =0A> > =0A> > http://blog.facilelogin.com=0A> > h= ttp://RampartFAQ.com =0A> > =0A> > ________________________________________= _______=0A> > OAuth mailing list=0A> > OAuth@ietf.org=0A> > https://www.iet= f.org/mailman/listinfo/oauth=0A> > =0A> > _________________________________= ______________=0A> > OAuth mailing list=0A> > OAuth@ietf.org=0A> > https://= www.ietf.org/mailman/listinfo/oauth =0A> =0A =0A> =0A> -- =0A> Thanks & Reg= ards,=0A> Prabath =0A> =0A> Mobile : +94 71 809 6732 =0A> =0A> http://blog.= facilelogin.com=0A> http://RampartFAQ.com ---1395015409-211105913-1358747085=:35324 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable ---1395015409-211105913-1358747085=:35324-- From zhou.sujing@zte.com.cn Sun Jan 20 23:14:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A2C21F882A for ; Sun, 20 Jan 2013 23:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKcmof1AMsld for ; Sun, 20 Jan 2013 23:14:22 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 96FAC21F882D for ; Sun, 20 Jan 2013 23:14:21 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 9596B12719BC; Mon, 21 Jan 2013 15:16:54 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A3821DF5A18; Mon, 21 Jan 2013 15:18:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0L7DmSF011318; Mon, 21 Jan 2013 15:13:55 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <1358747085.35324.YahooMailNeo@web31809.mail.mud.yahoo.com> To: William Mills MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 21 Jan 2013 15:13:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-21 15:13:58, Serialize complete at 2013-01-21 15:13:58 Content-Type: multipart/alternative; boundary="=_alternative 0027BC3448257AFA_=" X-MAIL: mse01.zte.com.cn r0L7DmSF011318 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:14:23 -0000 This is a multipart message in MIME format. --=_alternative 0027BC3448257AFA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4g0LTT2iAyMDEzLTAxLTIxIDEz OjQ0OjQ1Og0KDQo+IE5vdCBhIHByb2JsZW0gZm9yIHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhIHR5 cGUsIGJ1dCBpdCBtYXkgbm90IGdldCBpdC4NCkkgZG9uJ3Qgb2JqZWN0IGNsaWVudCByZXF1ZXN0 aW5nIGEgdHlwZSwgYnV0IEkgdGhpbmsgaXQgaXMgbWVhbmluZ2Z1bCBvbmx5IA0Kd2hlbiB0aGUg cmVxdWVzdGVkIHR5cGUgaXMgc3BlY2lmaWVkIGJ5IGEgUlMsDQphbmQgY2xpZW50IGp1c3QgcmVs YXkgdGhhdCByZXF1ZXN0IHRvIEFTLg0KDQo+IA0KPiBGcm9tOiAiemhvdS5zdWppbmdAenRlLmNv bS5jbiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+DQo+IFRvOiBQcmFiYXRoIFNpcml3YXJkZW5h IDxwcmFiYXRoQHdzbzIuY29tPiANCj4gQ2M6ICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGll dGYub3JnPjsgV2lsbGlhbSBNaWxscyANCj4gPHdtaWxsc185MjEwNUB5YWhvby5jb20+IA0KPiBT ZW50OiBTdW5kYXksIEphbnVhcnkgMjAsIDIwMTMgOTozOCBQTQ0KPiBTdWJqZWN0OiBSZTogUmU6 IFJlOiBbT0FVVEgtV0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9rZW4gdHlwZSBpdCAN Cm5lZWRzDQo+IA0KPiANCj4gV2VsbCwgaWYgUlMgY291bGQgc3BlY2lmeSB0b2tlbiB0eXBlLCB0 aGVuIENsaWVudCBjb3VsZCB0cmFuc2ZlciBpdCB0byANCkFTLCANCj4gSSB0aGluaywgYnV0IGl0 IGlzIG5vdCBhIGdvb2QgaWRlYSBmb3IgY2xpZW50IGl0c2VsZiB0byBzcGVjaWZ5IHRoZSANCj4g dG9rZW4gdHlwZS4gDQo+IA0KPiANCj4gUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28y LmNvbT4g0LTT2iAyMDEzLTAxLTIxIDEzOjI5OjA1Og0KPiANCj4gPiBUaGluayBhYm91dCBhIGRp c3RyaWJ1dGVkIHNldHVwLiBZb3UgaGF2ZSBzaW5nbGUgQXV0aG9yaXphdGlvbiANCj4gPiBTZXJ2 ZXIgYW5kIG11bHRpcGxlIFJlc291cmNlIFNlcnZlcnMuIA0KPiA+IA0KPiA+IEFsdGhvdWdoIE9B dXRoIG5pY2VseSBkZWNvdXBsZXMgQVMgZnJvbSBSUyAtIEFGQUlLIHRoZXJlIGlzIG5vIA0KPiA+ IHN0YW5kYXJkIGVzdGFibGlzaGVkIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW5zIEFTIGFuZCBS UyAtIGhvdyB0byANCj4gPiBkZWNsYXJlIG1ldGFkYXRhIGJldHdlZW4gdGhvc2UuIA0KPiA+IA0K PiA+IEFsc28gdGhlcmUgY2FuIGJlIFJlc291cmNlIFNlcnZlcnMgd2hpY2ggc3VwcG9ydCBtdWx0 aXBsZSB0b2tlbiANCj4gPiB0eXBlcy4gSXQgY291bGQgdmFyeSBvbiBBUElzIGhvc3RlZCBpbiBh IGdpdmVuIFJTLiANCj4gPiANCj4gPiBUaGFua3MgJiByZWdhcmRzLCANCj4gPiAtUHJhYmF0aCAN Cj4gPiANCj4gPiBPbiBNb24sIEphbiAyMSwgMjAxMyBhdCAxMDo0OCBBTSwgPHpob3Uuc3VqaW5n QHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiANCj4gPiBUaGUgdG9rZW4gdHlwZSBzaG91bGJlIGRl Y2lkZWQgYnkgcmVzb3VyY2Ugc2VydmVyLCB3aGljaCBjb25zdW1lcyANCj4gPiBhY2Nlc3MgdG9r ZW4uIA0KPiA+IENsaWVudCBqdXN0IHJlLXRlbGwgdGhlIHJlcXVlc3RlZCB0b2tlbiB0eXBlIHRv IEFTLiANCj4gPiBDbGllbnQgc2hvdWxkIG5vdCBzcGVjaWZ5IHRoZSB0b2tlbiB0eXBlLiANCj4g PiANCj4gPiANCj4gPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0yMSAxMzow ODozOTogDQo+ID4gDQo+ID4gDQo+ID4gPiBUaGlzIGlzIHRydWUuICBJdCdzIHBvc3NpYmxlIGZv ciB0aGUgQVMgdG8gdmFyeSBpdCdzIGJlaGF2aW9yIG9uIA0KPiA+ID4gc2NvcGUgbmFtZSwgYnV0 IGl0J3MgcHJlc3VtZWQgdGhlIEFTIGFuZCBSUyBoYXZlIGFuIGFncmVlbWVudCBvZiANCj4gPiA+ IHdoYXQgdG9rZW4gdHlwZSBpcyBpbiBwbGF5LiAgTGlrZWx5IGEgZ29vZCBleHRlbnNpb24gdG8g dGhlIHNwZWMuIA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBGcm9tOiBQcmFiYXRoIFNpcml3YXJkZW5h IDxwcmFiYXRoQHdzbzIuY29tPg0KPiA+ID4gVG86ICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRo QGlldGYub3JnPiANCj4gPiA+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAyMCwgMjAxMyA3OjI4IFBN DQo+ID4gPiBTdWJqZWN0OiBbT0FVVEgtV0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9r ZW4gdHlwZSBpdCBuZWVkcyANCj4gPiANCj4gPiA+IA0KPiA+ID4gQWx0aG91Z2ggdG9rZW4gdHlw ZSBpcyBleHRlbnNpYmxlIGFjY29yZGluZyB0byB0aGUgT0F1dGggY29yZSANCj4gPiA+IHNwZWNp ZmljYXRpb24gLSBpdCBpcyBmdWxseSBnb3Zlcm5lZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIuIA0KPiA+ID4gDQo+ID4gPiBUaGVyZSBjYW4gYmUgYSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFT IHN1cHBvcnRzIG11bHRpcGxlIHRva2VuIHR5cGVzIA0KPiA+ID4gYmFzZWQgb24gY2xpZW50IHJl cXVlc3QuIA0KPiA+ID4gDQo+ID4gPiBCdXQgY3VycmVudGx5IHdlIGRvbid0IGhhdmUgYSB3YXkg dGhlIGNsaWVudCBjYW4gc3BlY2lmeSAob3IgYXQgDQo+ID4gPiBsZWFzdCBzdWdnZXN0KSB3aGlj aCB0b2tlbiB0eXBlIGl0IG5lZWRzIGluIHRoZSBPQXV0aCBhY2Nlc3MgDQo+IHRva2VucmVxdWVz dCA/DQo+ID4gPiANCj4gPiA+IElzIHRoaXMgYmVoYXZpb3IgaW50ZW50aW9uYWwgPyBvciBhbSBJ IG1pc3Npbmcgc29tZXRoaW5nLi4uIA0KPiA+ID4gDQo+ID4gPiBUaGFua3MgJiBSZWdhcmRzLA0K PiA+ID4gUHJhYmF0aCANCj4gPiA+IA0KPiA+ID4gTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0K PiA+ID4gDQo+ID4gPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gPiA+IGh0dHA6Ly9S YW1wYXJ0RkFRLmNvbSANCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1 dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5v cmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggDQo+ ID4gDQo+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4gUHJhYmF0 aCANCj4gPiANCj4gPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+ID4gDQo+ID4gaHR0cDov L2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiANCg0K --=_alternative 0027BC3448257AFA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XaWxsaWFtIE1pbGxzICZsdDt3bWlsbHNfOTIxMDVAeWFo b28uY29tJmd0OyDQtNPaDQoyMDEzLTAxLTIxIDEzOjQ0OjQ1Ojxicj4NCjxicj4NCiZndDsgTm90 IGEgcHJvYmxlbSBmb3IgdGhlIGNsaWVudCB0byByZXF1ZXN0IGEgdHlwZSwgYnV0IGl0IG1heSBu b3QgZ2V0DQppdC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgZG9uJ3Qgb2Jq ZWN0IGNsaWVudCByZXF1ZXN0aW5nIGEgdHlwZSwgYnV0IEkgdGhpbmsNCml0IGlzIG1lYW5pbmdm dWwgb25seSB3aGVuIHRoZSByZXF1ZXN0ZWQgdHlwZSBpcyBzcGVjaWZpZWQgYnkgYSBSUyw8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmFuZCBjbGllbnQganVzdCByZWxheSB0aGF0 IHJlcXVlc3QgdG8gQVMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IDxicj4NCiZndDsgRnJvbTogJnF1b3Q7emhvdS5zdWppbmdAenRlLmNvbS5jbiZxdW90OyAm bHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7IFRvOiBQcmFiYXRoIFNpcml3 YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0OyA8YnI+DQomZ3Q7IENjOiAmcXVvdDtvYXV0 aEBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7OyBXaWxsaWFtDQpNaWxs cyA8YnI+DQomZ3Q7ICZsdDt3bWlsbHNfOTIxMDVAeWFob28uY29tJmd0OyA8YnI+DQomZ3Q7IFNl bnQ6IFN1bmRheSwgSmFudWFyeSAyMCwgMjAxMyA5OjM4IFBNPGJyPg0KJmd0OyBTdWJqZWN0OiBS ZTogUmU6IFJlOiBbT0FVVEgtV0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9rZW4gdHlw ZQ0KaXQgbmVlZHM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFdlbGwsIGlmIFJTIGNvdWxkIHNwZWNpZnkgdG9rZW4gdHlwZSwgdGhl biBDbGllbnQgY291bGQgdHJhbnNmZXIgaXQNCnRvIEFTLCA8YnI+DQomZ3Q7IEkgdGhpbmssIGJ1 dCBpdCBpcyBub3QgYSBnb29kIGlkZWEgZm9yIGNsaWVudCBpdHNlbGYgdG8gc3BlY2lmeSB0aGUN Cjxicj4NCiZndDsgdG9rZW4gdHlwZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7cHJhYmF0aEB3c28yLmNvbSZndDsg0LTT2iAyMDEzLTAx LTIxIDEzOjI5OjA1Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaW5rIGFib3V0IGEgZGlz dHJpYnV0ZWQgc2V0dXAuIFlvdSBoYXZlIHNpbmdsZSBBdXRob3JpemF0aW9uDQo8YnI+DQomZ3Q7 ICZndDsgU2VydmVyIGFuZCBtdWx0aXBsZSBSZXNvdXJjZSBTZXJ2ZXJzLiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEFsdGhvdWdoIE9BdXRoIG5pY2VseSBkZWNvdXBsZXMgQVMgZnJv bSBSUyAtIEFGQUlLIHRoZXJlIGlzIG5vDQo8YnI+DQomZ3Q7ICZndDsgc3RhbmRhcmQgZXN0YWJs aXNoZWQgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbnMgQVMgYW5kIFJTIC0gaG93DQp0byA8YnI+ DQomZ3Q7ICZndDsgZGVjbGFyZSBtZXRhZGF0YSBiZXR3ZWVuIHRob3NlLiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEFsc28gdGhlcmUgY2FuIGJlIFJlc291cmNlIFNlcnZlcnMgd2hp Y2ggc3VwcG9ydCBtdWx0aXBsZSB0b2tlbg0KPGJyPg0KJmd0OyAmZ3Q7IHR5cGVzLiBJdCBjb3Vs ZCB2YXJ5IG9uIEFQSXMgaG9zdGVkIGluIGEgZ2l2ZW4gUlMuIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsIDxicj4NCiZndDsgJmd0OyAtUHJhYmF0 aCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIE1vbiwgSmFuIDIxLCAyMDEzIGF0 IDEwOjQ4IEFNLCAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSB0b2tlbiB0eXBlIHNob3VsYmUgZGVjaWRlZCBi eSByZXNvdXJjZSBzZXJ2ZXIsIHdoaWNoIGNvbnN1bWVzDQo8YnI+DQomZ3Q7ICZndDsgYWNjZXNz IHRva2VuLiA8YnI+DQomZ3Q7ICZndDsgQ2xpZW50IGp1c3QgcmUtdGVsbCB0aGUgcmVxdWVzdGVk IHRva2VuIHR5cGUgdG8gQVMuIDxicj4NCiZndDsgJmd0OyBDbGllbnQgc2hvdWxkIG5vdCBzcGVj aWZ5IHRoZSB0b2tlbiB0eXBlLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0yMSAxMzowODoz OTogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBU aGlzIGlzIHRydWUuICZuYnNwO0l0J3MgcG9zc2libGUgZm9yIHRoZSBBUyB0byB2YXJ5IGl0J3MN CmJlaGF2aW9yIG9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNjb3BlIG5hbWUsIGJ1dCBpdCdzIHBy ZXN1bWVkIHRoZSBBUyBhbmQgUlMgaGF2ZSBhbiBhZ3JlZW1lbnQNCm9mIDxicj4NCiZndDsgJmd0 OyAmZ3Q7IHdoYXQgdG9rZW4gdHlwZSBpcyBpbiBwbGF5LiAmbmJzcDtMaWtlbHkgYSBnb29kIGV4 dGVuc2lvbg0KdG8gdGhlIHNwZWMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBGcm9tOiBQcmFiYXRoIFNpcml3YXJkZW5hICZsdDtwcmFi YXRoQHdzbzIuY29tJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiAmcXVvdDtvYXV0aEBpZXRm Lm9yZyBXRyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0 OyBTZW50OiBTdW5kYXksIEphbnVhcnkgMjAsIDIwMTMgNzoyOCBQTTxicj4NCiZndDsgJmd0OyAm Z3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10gQ2xpZW50IGNhbm5vdCBzcGVjaWZ5IHRoZSB0b2tlbiB0 eXBlDQppdCBuZWVkcyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgQWx0aG91Z2ggdG9rZW4gdHlwZSBpcyBleHRlbnNpYmxlIGFjY29yZGlu ZyB0byB0aGUgT0F1dGgNCmNvcmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWNhdGlvbiAt IGl0IGlzIGZ1bGx5IGdvdmVybmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQpTZXJ2ZXIuIDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZXJlIGNhbiBiZSBhIGNhc2Ug d2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMgbXVsdGlwbGUNCnRva2VuIHR5cGVzIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0LiA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBCdXQgY3VycmVudGx5IHdlIGRvbid0IGhhdmUgYSB3YXkg dGhlIGNsaWVudCBjYW4gc3BlY2lmeQ0KKG9yIGF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGxlYXN0 IHN1Z2dlc3QpIHdoaWNoIHRva2VuIHR5cGUgaXQgbmVlZHMgaW4gdGhlIE9BdXRoIGFjY2Vzcw0K PGJyPg0KJmd0OyB0b2tlbnJlcXVlc3QgPzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7IElzIHRoaXMgYmVoYXZpb3IgaW50ZW50aW9uYWwgPyBvciBhbSBJIG1pc3Npbmcg c29tZXRoaW5nLi4uDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBU aGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBQcmFiYXRoIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjcz MiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwOi8vYmxvZy5m YWNpbGVsb2dpbi5jb208YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb20g PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZn dDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRo IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IC0tIDxicj4NCiZndDsgJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsg UHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4 MDkgNjczMiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2ls ZWxvZ2luLmNvbTxicj4NCiZndDsgJmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb20gPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0027BC3448257AFA_=-- From prabath@wso2.com Sun Jan 20 23:28:02 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AF521F8783 for ; Sun, 20 Jan 2013 23:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc16PwW8VSOl for ; Sun, 20 Jan 2013 23:28:01 -0800 (PST) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21F21F8775 for ; Sun, 20 Jan 2013 23:27:58 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id c13so1711150eaa.16 for ; Sun, 20 Jan 2013 23:27:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yAkMNpAzRAW1RjFS557VIiAjjePXHWsbOC77Sj7Fi7s=; b=YjYlRtGHfxeHp1eyxNcWecnuANL+UH+imBa2defXqxxsMIYVgh7+r9WSlk8ry9NCmE rKvgvV/GyBxqldMkhL6RgPog+aGYBVBDDKvmRRsHYVzcJjIfvkri5wEYfFBw9Okin0Af /8dwayH8LPfdGW6wTGddN8zYx5BY2eLrXcuMjECDSCjhPAHfOVV7VTbEdUjTaq2jIn63 iL1F5nypdiSynsY+2rcJIgpzM35sVizyXFiFOV0DSbynOyOuAeiApJx3hcNfyaTPYkvz 0d2Qj/57GUKXtO5+ehLWNIw5XmB5LuSfaPvL9tc131wr9qtHa+XEyx78vDH4oX10JEkN 630g== MIME-Version: 1.0 X-Received: by 10.14.3.195 with SMTP id 43mr57228786eeh.36.1358753277161; Sun, 20 Jan 2013 23:27:57 -0800 (PST) Received: by 10.223.194.4 with HTTP; Sun, 20 Jan 2013 23:27:57 -0800 (PST) In-Reply-To: References: <1358747085.35324.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Mon, 21 Jan 2013 12:57:57 +0530 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b66f2396c31b204d3c76688 X-Gm-Message-State: ALoCoQmAPTX/5toqGKnGD7+MABygxLPPpTTbTVMtDFFEIl/J84fi8BKycy7cew75M9yo/tc70RrB Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:28:02 -0000 --047d7b66f2396c31b204d3c76688 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I guess that is a pattern used many scenarios. Requesting client can suggest - but its up to the AS to honor it or not... Thanks & regards, -prabath On Mon, Jan 21, 2013 at 12:43 PM, wrote: > > William Mills =D0=B4=D3=DA 2013-01-21 13:44:45: > > > > Not a problem for the client to request a type, but it may not get it. > > I don't object client requesting a type, but I think it is meaningful onl= y > when the requested type is specified by a RS, > and client just relay that request to AS. > > > > > From: "zhou.sujing@zte.com.cn" > > To: Prabath Siriwardena > > Cc: "oauth@ietf.org WG" ; William Mills > > > > Sent: Sunday, January 20, 2013 9:38 PM > > Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token type it > needs > > > > > > Well, if RS could specify token type, then Client could transfer it to > AS, > > I think, but it is not a good idea for client itself to specify the > > token type. > > > > > > Prabath Siriwardena =D0=B4=D3=DA 2013-01-21 13:29:05= : > > > > > Think about a distributed setup. You have single Authorization > > > Server and multiple Resource Servers. > > > > > > Although OAuth nicely decouples AS from RS - AFAIK there is no > > > standard established for communication betweens AS and RS - how to > > > declare metadata between those. > > > > > > Also there can be Resource Servers which support multiple token > > > types. It could vary on APIs hosted in a given RS. > > > > > > Thanks & regards, > > > -Prabath > > > > > > On Mon, Jan 21, 2013 at 10:48 AM, wrote: > > > > > > The token type shoulbe decided by resource server, which consumes > > > access token. > > > Client just re-tell the requested token type to AS. > > > Client should not specify the token type. > > > > > > > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39: > > > > > > > > > > This is true. It's possible for the AS to vary it's behavior on > > > > scope name, but it's presumed the AS and RS have an agreement of > > > > what token type is in play. Likely a good extension to the spec. > > > > > > > > > > > From: Prabath Siriwardena > > > > To: "oauth@ietf.org WG" > > > > Sent: Sunday, January 20, 2013 7:28 PM > > > > Subject: [OAUTH-WG] Client cannot specify the token type it needs > > > > > > > > > > > Although token type is extensible according to the OAuth core > > > > specification - it is fully governed by the Authorization Server. > > > > > > > > There can be a case where a single AS supports multiple token types > > > > based on client request. > > > > > > > > But currently we don't have a way the client can specify (or at > > > > least suggest) which token type it needs in the OAuth access > > tokenrequest ? > > > > > > > > Is this behavior intentional ? or am I missing something... > > > > > > > > Thanks & Regards, > > > > Prabath > > > > > > > > Mobile : +94 71 809 6732 > > > > > > > > http://blog.facilelogin.com > > > > http://RampartFAQ.com > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Mobile : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com > > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b66f2396c31b204d3c76688 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I guess that is a pattern used many scenarios. Requesting client can sugges= t - but its up to the AS to honor it or not...

Thanks &a= mp; regards,
-prabath

On Mon, J= an 21, 2013 at 12:43 PM, <zhou.sujing@zte.com.cn> wrot= e:

William Mills <wmills_92105@yahoo.com> =D0=B4=D3=DA 2013-01-21 13:44:45:


> Not a problem for the client to request a type, but it may not get it.
I don't object client requesting a type, but I think it is meaningful only when the requested type is specified by a RS,<= /tt>
and client just relay that request to AS.

>
> From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
> To: Prabath Siriwardena <prabath@wso2.com>
> Cc: "oauth@ie= tf.org WG" <oauth@ietf.org>; William Mills
> <wmills= _92105@yahoo.com>
> Sent: Sunday, January 20, 2013 9:38 PM
> Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token type it needs
>
>
> Well, if RS could specify token type, then Client could transfer it to AS,
> I think, but it is not a good idea for client itself to specify the
> token type.
>
>
> Prabath Siriwardena <prabath@wso2.com> =D0=B4=D3=DA 2013-01-21 13:29:05:
>
> > Think about a distributed setup. You have single Authorization
> > Server and multiple Resource Servers.
> >
> > Although OAuth nicely decouples AS from RS - AFAIK there is no
> > standard established for communication betweens AS and RS - how to
> > declare metadata between those.
> >
> > Also there can be Resource Servers which support multiple token
> > types. It could vary on APIs hosted in a given RS.
> >
> > Thanks & regards,
> > -Prabath
> >
> > On Mon, Jan 21, 2013 at 10:48 AM, <zhou.sujing@zte.com.cn> wrote:
> >
> > The token type shoulbe decided by resource server, which consumes
> > access token.
> > Client just re-tell the requested token type to AS.
> > Client should not specify the token type.
> >
> >
> > oauth= -bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39:
> >
> >
> > > This is true.  It's possible for the AS to vary it&= #39;s behavior on
> > > scope name, but it's presumed the AS and RS have an agre= ement of
> > > what token type is in play.  Likely a good extension to the spec.
> >
> > >
> > > From: Prabath Siriwardena <prabath@wso2.com>
> > > To: "oauth@ietf.org WG" <oauth@ietf.org>
> > > Sent: Sunday, January 20, 2013 7:28 PM
> > > Subject: [OAUTH-WG] Client cannot specify the token type it needs
> >
> > >
> > > Although token type is extensible according to the OAuth core
> > > specification - it is fully governed by the Authorization Server.
> > >
> > > There can be a case where a single AS supports multiple token types
> > > based on client request.
> > >
> > > But currently we don't have a way the client can specify (or at
> > > least suggest) which token type it needs in the OAuth access
> tokenrequest ?
> > >
> > > Is this behavior intentional ? or am I missing something...
> > >
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > ht= tp://blog.facilelogin.com
> > > http://R= ampartFAQ.com
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://= blog.facilelogin.com
> > http://Rampar= tFAQ.com
>



--
= Thanks & Regards,
Prabath

--047d7b66f2396c31b204d3c76688-- From zhou.sujing@zte.com.cn Sun Jan 20 23:38:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF021F882F for ; Sun, 20 Jan 2013 23:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEl0zwYNsIM5 for ; Sun, 20 Jan 2013 23:37:59 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49521F881C for ; Sun, 20 Jan 2013 23:37:54 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 873CD1271DBB; Mon, 21 Jan 2013 15:40:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r0L7bYOS023926; Mon, 21 Jan 2013 15:37:34 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 21 Jan 2013 15:37:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-21 15:37:38, Serialize complete at 2013-01-21 15:37:38 Content-Type: multipart/alternative; boundary="=_alternative 0029EA3648257AFA_=" X-MAIL: mse02.zte.com.cn r0L7bYOS023926 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:38:00 -0000 This is a multipart message in MIME format. --=_alternative 0029EA3648257AFA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4g0LTT2iAyMDEzLTAxLTIxIDE1 OjI3OjU3Og0KDQo+IEkgZ3Vlc3MgdGhhdCBpcyBhIHBhdHRlcm4gdXNlZCBtYW55IHNjZW5hcmlv cy4gUmVxdWVzdGluZyBjbGllbnQgY2FuDQo+IHN1Z2dlc3QgLSBidXQgaXRzIHVwIHRvIHRoZSBB UyB0byBob25vciBpdCBvciBub3QuLi4NCg0KTm90IGV4YWN0bHkuIEZvciBleGFtcGxlLCBSUyBz dXBwb3J0cyB0d28gdG9rZW4gdHlwZXMsIG9uZSBpcyBiZWFyIHRva2VuLCANCmFub3RoZXIgaXMg aG9sZXItb2Yta2V5IHdoaWNoIGlzIGFzc3VtZWQgbW9yZSBzZWN1cmUgdGhhbiB0aGUgZmlyc3Qg b25lLg0KUlMgcmVhbHkgd2FudHMgdGhlIHNlY29uZGUgdHlwZSwgYnV0IKOoYSBkaXNob25lc3Sj qSBjbGllbnQsIGFsd2F5cyANCmNob29zaW5nIHRoZSB3ZWFrZXN0LCByZXF1ZXN0cyB0aGUgZmly c3Qgb25lLiANCndoYXQgaXMgdGhlIG1lYW5pbmcgZm9yIGNsaWVudCB0byBzcGVjaWZ5IHRoZSB0 b2tlbiB0eXBlPyANCg0KPiANCj4gVGhhbmtzICYgcmVnYXJkcywNCj4gLXByYWJhdGgNCg0KPiBP biBNb24sIEphbiAyMSwgMjAxMyBhdCAxMjo0MyBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+ IHdyb3RlOg0KPiANCj4gV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4g0LTT 2iAyMDEzLTAxLTIxIDEzOjQ0OjQ1Og0KPiANCj4gDQo+ID4gTm90IGEgcHJvYmxlbSBmb3IgdGhl IGNsaWVudCB0byByZXF1ZXN0IGEgdHlwZSwgYnV0IGl0IG1heSBub3QgZ2V0IGl0Lg0KPiANCj4g SSBkb24ndCBvYmplY3QgY2xpZW50IHJlcXVlc3RpbmcgYSB0eXBlLCBidXQgSSB0aGluayBpdCBp cyANCj4gbWVhbmluZ2Z1bCBvbmx5IHdoZW4gdGhlIHJlcXVlc3RlZCB0eXBlIGlzIHNwZWNpZmll ZCBieSBhIFJTLCANCj4gYW5kIGNsaWVudCBqdXN0IHJlbGF5IHRoYXQgcmVxdWVzdCB0byBBUy4g DQo+IA0KPiA+IA0KPiA+IEZyb206ICJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS5zdWpp bmdAenRlLmNvbS5jbj4NCj4gPiBUbzogUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28y LmNvbT4gDQo+ID4gQ2M6ICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPjsgV2ls bGlhbSBNaWxscyANCj4gPiA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gDQo+ID4gU2VudDogU3Vu ZGF5LCBKYW51YXJ5IDIwLCAyMDEzIDk6MzggUE0NCj4gPiBTdWJqZWN0OiBSZTogUmU6IFJlOiBb T0FVVEgtV0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9rZW4gDQo+IHR5cGUgaXQgbmVl ZHMgDQo+ID4gDQo+ID4gDQo+ID4gV2VsbCwgaWYgUlMgY291bGQgc3BlY2lmeSB0b2tlbiB0eXBl LCB0aGVuIENsaWVudCBjb3VsZCB0cmFuc2ZlciBpdCB0byANCkFTLCANCj4gPiBJIHRoaW5rLCBi dXQgaXQgaXMgbm90IGEgZ29vZCBpZGVhIGZvciBjbGllbnQgaXRzZWxmIHRvIHNwZWNpZnkgdGhl IA0KPiA+IHRva2VuIHR5cGUuIA0KPiA+IA0KPiA+IA0KPiA+IFByYWJhdGggU2lyaXdhcmRlbmEg PHByYWJhdGhAd3NvMi5jb20+INC009ogMjAxMy0wMS0yMSAxMzoyOTowNToNCj4gPiANCj4gPiA+ IFRoaW5rIGFib3V0IGEgZGlzdHJpYnV0ZWQgc2V0dXAuIFlvdSBoYXZlIHNpbmdsZSBBdXRob3Jp emF0aW9uIA0KPiA+ID4gU2VydmVyIGFuZCBtdWx0aXBsZSBSZXNvdXJjZSBTZXJ2ZXJzLiANCj4g PiA+IA0KPiA+ID4gQWx0aG91Z2ggT0F1dGggbmljZWx5IGRlY291cGxlcyBBUyBmcm9tIFJTIC0g QUZBSUsgdGhlcmUgaXMgbm8gDQo+ID4gPiBzdGFuZGFyZCBlc3RhYmxpc2hlZCBmb3IgY29tbXVu aWNhdGlvbiBiZXR3ZWVucyBBUyBhbmQgUlMgLSBob3cgdG8gDQo+ID4gPiBkZWNsYXJlIG1ldGFk YXRhIGJldHdlZW4gdGhvc2UuIA0KPiA+ID4gDQo+ID4gPiBBbHNvIHRoZXJlIGNhbiBiZSBSZXNv dXJjZSBTZXJ2ZXJzIHdoaWNoIHN1cHBvcnQgbXVsdGlwbGUgdG9rZW4gDQo+ID4gPiB0eXBlcy4g SXQgY291bGQgdmFyeSBvbiBBUElzIGhvc3RlZCBpbiBhIGdpdmVuIFJTLiANCj4gPiA+IA0KPiA+ ID4gVGhhbmtzICYgcmVnYXJkcywgDQo+ID4gPiAtUHJhYmF0aCANCj4gPiA+IA0KPiA+ID4gT24g TW9uLCBKYW4gMjEsIDIwMTMgYXQgMTA6NDggQU0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3 cm90ZTogDQo+ID4gPiANCj4gPiA+IFRoZSB0b2tlbiB0eXBlIHNob3VsYmUgZGVjaWRlZCBieSBy ZXNvdXJjZSBzZXJ2ZXIsIHdoaWNoIGNvbnN1bWVzIA0KPiA+ID4gYWNjZXNzIHRva2VuLiANCj4g PiA+IENsaWVudCBqdXN0IHJlLXRlbGwgdGhlIHJlcXVlc3RlZCB0b2tlbiB0eXBlIHRvIEFTLiAN Cj4gPiA+IENsaWVudCBzaG91bGQgbm90IHNwZWNpZnkgdGhlIHRva2VuIHR5cGUuIA0KPiA+ID4g DQo+ID4gPiANCj4gPiA+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTIxIDEz OjA4OjM5OiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IFRoaXMgaXMgdHJ1ZS4gIEl0J3MgcG9z c2libGUgZm9yIHRoZSBBUyB0byB2YXJ5IGl0J3MgYmVoYXZpb3Igb24gDQo+ID4gPiA+IHNjb3Bl IG5hbWUsIGJ1dCBpdCdzIHByZXN1bWVkIHRoZSBBUyBhbmQgUlMgaGF2ZSBhbiBhZ3JlZW1lbnQg b2YgDQo+ID4gPiA+IHdoYXQgdG9rZW4gdHlwZSBpcyBpbiBwbGF5LiAgTGlrZWx5IGEgZ29vZCBl eHRlbnNpb24gdG8gdGhlIHNwZWMuIA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBGcm9tOiBQ cmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPg0KPiA+ID4gPiBUbzogIm9hdXRo QGlldGYub3JnIFdHIiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiA+ID4gPiBTZW50OiBTdW5kYXksIEph bnVhcnkgMjAsIDIwMTMgNzoyOCBQTQ0KPiA+ID4gPiBTdWJqZWN0OiBbT0FVVEgtV0ddIENsaWVu dCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9rZW4gdHlwZSBpdCBuZWVkcyANCj4gPiA+IA0KPiA+ID4g PiANCj4gPiA+ID4gQWx0aG91Z2ggdG9rZW4gdHlwZSBpcyBleHRlbnNpYmxlIGFjY29yZGluZyB0 byB0aGUgT0F1dGggY29yZSANCj4gPiA+ID4gc3BlY2lmaWNhdGlvbiAtIGl0IGlzIGZ1bGx5IGdv dmVybmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gDQo+ID4gPiA+IA0KPiA+ID4gPiBU aGVyZSBjYW4gYmUgYSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIG11bHRpcGxlIHRv a2VuIA0KdHlwZXMgDQo+ID4gPiA+IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0LiANCj4gPiA+ID4g DQo+ID4gPiA+IEJ1dCBjdXJyZW50bHkgd2UgZG9uJ3QgaGF2ZSBhIHdheSB0aGUgY2xpZW50IGNh biBzcGVjaWZ5IChvciBhdCANCj4gPiA+ID4gbGVhc3Qgc3VnZ2VzdCkgd2hpY2ggdG9rZW4gdHlw ZSBpdCBuZWVkcyBpbiB0aGUgT0F1dGggYWNjZXNzIA0KPiA+IHRva2VucmVxdWVzdCA/DQo+ID4g PiA+IA0KPiA+ID4gPiBJcyB0aGlzIGJlaGF2aW9yIGludGVudGlvbmFsID8gb3IgYW0gSSBtaXNz aW5nIHNvbWV0aGluZy4uLiANCj4gPiA+ID4gDQo+ID4gPiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ ID4gPiA+IFByYWJhdGggDQo+ID4gPiA+IA0KPiA+ID4gPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3 MzIgDQo+ID4gPiA+IA0KPiA+ID4gPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gPiA+ ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiA+ID4gPiANCj4gPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IE9BdXRoIG1haWxp bmcgbGlzdA0KPiA+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0KPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+ IC0tIA0KPiA+ID4gVGhhbmtzICYgUmVnYXJkcywNCj4gPiA+IFByYWJhdGggDQo+ID4gPiANCj4g PiA+IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiANCj4gPiA+IA0KPiA+ID4gaHR0cDovL2Jsb2cu ZmFjaWxlbG9naW4uY29tDQo+ID4gPiBodHRwOi8vUmFtcGFydEZBUS5jb20gDQo+ID4gDQo+IA0K DQo+IA0KPiAtLSANCj4gVGhhbmtzICYgUmVnYXJkcywNCj4gUHJhYmF0aA0KPiANCj4gTW9iaWxl IDogKzk0IDcxIDgwOSA2NzMyIA0KPiANCj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+ IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbQ0K --=_alternative 0029EA3648257AFA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5QcmFiYXRoIFNpcml3YXJkZW5hICZsdDtwcmFiYXRoQHdz bzIuY29tJmd0OyDQtNPaDQoyMDEzLTAxLTIxIDE1OjI3OjU3Ojxicj4NCjxicj4NCiZndDsgSSBn dWVzcyB0aGF0IGlzIGEgcGF0dGVybiB1c2VkIG1hbnkgc2NlbmFyaW9zLiBSZXF1ZXN0aW5nIGNs aWVudCBjYW48YnI+DQomZ3Q7IHN1Z2dlc3QgLSBidXQgaXRzIHVwIHRvIHRoZSBBUyB0byBob25v ciBpdCBvciBub3QuLi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk5v dCBleGFjdGx5LiBGb3IgZXhhbXBsZSwgUlMgc3VwcG9ydHMgdHdvIHRva2VuIHR5cGVzLA0Kb25l IGlzIGJlYXIgdG9rZW4sIGFub3RoZXIgaXMgaG9sZXItb2Yta2V5IHdoaWNoIGlzIGFzc3VtZWQg bW9yZSBzZWN1cmUNCnRoYW4gdGhlIGZpcnN0IG9uZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPlJTIHJlYWx5IHdhbnRzIHRoZSBzZWNvbmRlIHR5cGUsIGJ1dCCjqGEgZGlzaG9u ZXN0o6kNCmNsaWVudCwgYWx3YXlzIGNob29zaW5nIHRoZSB3ZWFrZXN0LCByZXF1ZXN0cyB0aGUg Zmlyc3Qgb25lLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPndoYXQgaXMgdGhl IG1lYW5pbmcgZm9yIGNsaWVudCB0byBzcGVjaWZ5IHRoZSB0b2tlbg0KdHlwZT8gPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzICZh bXA7IHJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC1wcmFi YXRoPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIE1vbiwg SmFuIDIxLCAyMDEzIGF0IDEyOjQzIFBNLCAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsN Cndyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IFdpbGxpYW0gTWlsbHMgJmx0O3dtaWxsc185MjEwNUB5YWhvby5jb20mZ3Q7INC009ogMjAxMy0w MS0yMSAxMzo0NDo0NTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgTm90IGEgcHJvYmxlbSBmb3IgdGhlIGNsaWVudCB0byBy ZXF1ZXN0IGEgdHlwZSwgYnV0IGl0IG1heSBub3QNCmdldCBpdC48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJIGRvbid0IG9iamVjdCBjbGllbnQgcmVx dWVzdGluZyBhIHR5cGUsIGJ1dCBJIHRoaW5rIGl0IGlzIDxicj4NCiZndDsgbWVhbmluZ2Z1bCBv bmx5IHdoZW4gdGhlIHJlcXVlc3RlZCB0eXBlIGlzIHNwZWNpZmllZCBieSBhIFJTLCA8YnI+DQom Z3Q7IGFuZCBjbGllbnQganVzdCByZWxheSB0aGF0IHJlcXVlc3QgdG8gQVMuIDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEZyb206ICZxdW90O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsgJmx0O3pob3Uuc3Vq aW5nQHp0ZS5jb20uY24mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRvOiBQcmFiYXRoIFNpcml3YXJkZW5h ICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90O29hdXRo QGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs7IFdpbGxpYW0NCk1pbGxz IDxicj4NCiZndDsgJmd0OyAmbHQ7d21pbGxzXzkyMTA1QHlhaG9vLmNvbSZndDsgPGJyPg0KJmd0 OyAmZ3Q7IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAyMCwgMjAxMyA5OjM4IFBNPGJyPg0KJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBSZTogUmU6IFtPQVVUSC1XR10gQ2xpZW50IGNhbm5vdCBzcGVjaWZ5 IHRoZSB0b2tlbg0KPGJyPg0KJmd0OyB0eXBlIGl0IG5lZWRzIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFdlbGwsIGlmIFJTIGNvdWxkIHNwZWNpZnkgdG9r ZW4gdHlwZSwgdGhlbiBDbGllbnQgY291bGQgdHJhbnNmZXINCml0IHRvIEFTLCA8YnI+DQomZ3Q7 ICZndDsgSSB0aGluaywgYnV0IGl0IGlzIG5vdCBhIGdvb2QgaWRlYSBmb3IgY2xpZW50IGl0c2Vs ZiB0byBzcGVjaWZ5DQp0aGUgPGJyPg0KJmd0OyAmZ3Q7IHRva2VuIHR5cGUuIDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFByYWJhdGggU2lyaXdhcmRlbmEg Jmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7INC009ogMjAxMy0wMS0yMQ0KMTM6Mjk6MDU6PGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoaW5rIGFib3V0IGEgZGlzdHJpYnV0ZWQg c2V0dXAuIFlvdSBoYXZlIHNpbmdsZSBBdXRob3JpemF0aW9uDQo8YnI+DQomZ3Q7ICZndDsgJmd0 OyBTZXJ2ZXIgYW5kIG11bHRpcGxlIFJlc291cmNlIFNlcnZlcnMuIDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFsdGhvdWdoIE9BdXRoIG5pY2VseSBkZWNvdXBsZXMg QVMgZnJvbSBSUyAtIEFGQUlLIHRoZXJlDQppcyBubyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdGFu ZGFyZCBlc3RhYmxpc2hlZCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVucyBBUyBhbmQgUlMNCi0g aG93IHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRlY2xhcmUgbWV0YWRhdGEgYmV0d2VlbiB0aG9z ZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWxzbyB0aGVyZSBj YW4gYmUgUmVzb3VyY2UgU2VydmVycyB3aGljaCBzdXBwb3J0IG11bHRpcGxlDQp0b2tlbiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0eXBlcy4gSXQgY291bGQgdmFyeSBvbiBBUElzIGhvc3RlZCBpbiBh IGdpdmVuIFJTLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGFu a3MgJmFtcDsgcmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLVByYWJhdGggPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gTW9uLCBKYW4gMjEsIDIwMTMgYXQg MTA6NDggQU0sICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSB0b2tlbiB0eXBlIHNob3VsYmUg ZGVjaWRlZCBieSByZXNvdXJjZSBzZXJ2ZXIsIHdoaWNoDQpjb25zdW1lcyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBhY2Nlc3MgdG9rZW4uIDxicj4NCiZndDsgJmd0OyAmZ3Q7IENsaWVudCBqdXN0IHJl LXRlbGwgdGhlIHJlcXVlc3RlZCB0b2tlbiB0eXBlIHRvIEFTLiA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBDbGllbnQgc2hvdWxkIG5vdCBzcGVjaWZ5IHRoZSB0b2tlbiB0eXBlLiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBvYXV0aC1i b3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMS0yMSAxMzowODozOTogPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGlz IGlzIHRydWUuICZuYnNwO0l0J3MgcG9zc2libGUgZm9yIHRoZSBBUyB0byB2YXJ5DQppdCdzIGJl aGF2aW9yIG9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2NvcGUgbmFtZSwgYnV0IGl0J3Mg cHJlc3VtZWQgdGhlIEFTIGFuZCBSUyBoYXZlIGFuDQphZ3JlZW1lbnQgb2YgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyB3aGF0IHRva2VuIHR5cGUgaXMgaW4gcGxheS4gJm5ic3A7TGlrZWx5IGEg Z29vZCBleHRlbnNpb24NCnRvIHRoZSBzcGVjLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogUHJhYmF0 aCBTaXJpd2FyZGVuYSAmbHQ7cHJhYmF0aEB3c28yLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IFRvOiAmcXVvdDtvYXV0aEBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5v cmcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAy MCwgMjAxMyA3OjI4IFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBbT0FVVEgt V0ddIENsaWVudCBjYW5ub3Qgc3BlY2lmeSB0aGUgdG9rZW4NCnR5cGUgaXQgbmVlZHMgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEFsdGhvdWdoIHRva2VuIHR5cGUgaXMgZXh0ZW5zaWJsZSBhY2NvcmRpbmcgdG8g dGhlDQpPQXV0aCBjb3JlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWNhdGlvbiAt IGl0IGlzIGZ1bGx5IGdvdmVybmVkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQpTZXJ2ZXIuIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBjYW4g YmUgYSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIG11bHRpcGxlDQp0b2tlbiB0eXBl cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJhc2VkIG9uIGNsaWVudCByZXF1ZXN0LiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQnV0IGN1cnJl bnRseSB3ZSBkb24ndCBoYXZlIGEgd2F5IHRoZSBjbGllbnQgY2FuIHNwZWNpZnkNCihvciBhdCA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxlYXN0IHN1Z2dlc3QpIHdoaWNoIHRva2VuIHR5cGUg aXQgbmVlZHMgaW4gdGhlIE9BdXRoDQphY2Nlc3MgPGJyPg0KJmd0OyAmZ3Q7IHRva2VucmVxdWVz dCA/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElz IHRoaXMgYmVoYXZpb3IgaW50ZW50aW9uYWwgPyBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nLi4u DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhh bmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBQcmFiYXRoIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNb2JpbGUgOiAr OTQgNzEgODA5IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aEBp ZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAm Z3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUHJhYmF0 aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNb2JpbGUgOiArOTQg NzEgODA5IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0 cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL1JhbXBh cnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgLS0gPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7IFBy YWJhdGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBN b2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly9ibG9n LmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tPC9mb250Pjwv dHQ+DQo= --=_alternative 0029EA3648257AFA_=-- From prabath@wso2.com Sun Jan 20 23:57:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346DE21F8842 for ; Sun, 20 Jan 2013 23:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD5Fr32ybvAz for ; Sun, 20 Jan 2013 23:57:27 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9421F8841 for ; Sun, 20 Jan 2013 23:57:26 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so2279391eaa.1 for ; Sun, 20 Jan 2013 23:57:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=1XRKZ/MPiuRkxM6YLbYgWK3b0zv/XVdoe5KZoz2/dCw=; b=Penq6GauWl+d2fx8IN7TfEuPT5W+lnZHIrFPuC0ofcK57v06qgUlehGWAqluxI7G/C R5hZUagHi2tcuJ3uYuFQ3YLPDq1w8HLqD7b97yqwCjWfLu3JtkKYW53chGaCVj+o3isM N69JAwxF5SGzIFpbZHwZmsBH03qSMnrsGA1iVMNwHCW/KD0cmeq2OySbKMWONNPn2VrJ nAj0i/Lf7+2fBVHH1M8/976V8R/GfHh/+pjXF8Ztv4VaszOLVVuKGlgVlJsL6ypAHxc6 D1WvfNg2GyuqeAPubPEHJAxzcu8hvrfC4V3OcNT8ihd7sfq+iOwN8tztOi5mgJNz/kgl P0aQ== MIME-Version: 1.0 X-Received: by 10.14.0.133 with SMTP id 5mr57417989eeb.29.1358755045406; Sun, 20 Jan 2013 23:57:25 -0800 (PST) Received: by 10.223.194.4 with HTTP; Sun, 20 Jan 2013 23:57:25 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 13:27:25 +0530 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b66fef3d1780004d3c7cf77 X-Gm-Message-State: ALoCoQkt4wfpNbGqvjCnMcEh3cyKJQMZEQmPofKHBXUSFgvH+yh1K6Z6UR3RVGvMGJPCqJRjUMMs Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:57:28 -0000 --047d7b66fef3d1780004d3c7cf77 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I am not objecting that RS should define it's requirements... and RS should be able to do it by each resource... So ideally RS may have away to express that in a WADL and we need to have a standard mechanism established for communication between RS and AS. In WS-Trust - SP can declare it's token requirements via WS-SecurityPolicy, in WSDL. And client reads the WSDL and identify the token requirements. Then based on those requirements, client talks to the STS and gets the token. Thanks & regards, -Prabath On Mon, Jan 21, 2013 at 1:07 PM, wrote: > > Prabath Siriwardena =D0=B4=D3=DA 2013-01-21 15:27:57: > > > > I guess that is a pattern used many scenarios. Requesting client can > > suggest - but its up to the AS to honor it or not... > > > Not exactly. For example, RS supports two token types, one is bear token, > another is holer-of-key which is assumed more secure than the first one. > RS realy wants the seconde type, but =A3=A8a dishonest=A3=A9 client, alwa= ys choosing > the weakest, requests the first one. > what is the meaning for client to specify the token type? > > > > > Thanks & regards, > > -prabath > > > On Mon, Jan 21, 2013 at 12:43 PM, wrote: > > > > William Mills =D0=B4=D3=DA 2013-01-21 13:44:45= : > > > > > > > Not a problem for the client to request a type, but it may not get it= . > > > > I don't object client requesting a type, but I think it is > > meaningful only when the requested type is specified by a RS, > > and client just relay that request to AS. > > > > > > > > From: "zhou.sujing@zte.com.cn" > > > To: Prabath Siriwardena > > > Cc: "oauth@ietf.org WG" ; William Mills > > > > > > Sent: Sunday, January 20, 2013 9:38 PM > > > Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token > > type it needs > > > > > > > > > Well, if RS could specify token type, then Client could transfer it t= o > AS, > > > I think, but it is not a good idea for client itself to specify the > > > token type. > > > > > > > > > Prabath Siriwardena =D0=B4=D3=DA 2013-01-21 13:29:= 05: > > > > > > > Think about a distributed setup. You have single Authorization > > > > Server and multiple Resource Servers. > > > > > > > > Although OAuth nicely decouples AS from RS - AFAIK there is no > > > > standard established for communication betweens AS and RS - how to > > > > declare metadata between those. > > > > > > > > Also there can be Resource Servers which support multiple token > > > > types. It could vary on APIs hosted in a given RS. > > > > > > > > Thanks & regards, > > > > -Prabath > > > > > > > > On Mon, Jan 21, 2013 at 10:48 AM, wrote: > > > > > > > > The token type shoulbe decided by resource server, which consumes > > > > access token. > > > > Client just re-tell the requested token type to AS. > > > > Client should not specify the token type. > > > > > > > > > > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39: > > > > > > > > > > > > > This is true. It's possible for the AS to vary it's behavior on > > > > > scope name, but it's presumed the AS and RS have an agreement of > > > > > what token type is in play. Likely a good extension to the spec. > > > > > > > > > > > > > > From: Prabath Siriwardena > > > > > To: "oauth@ietf.org WG" > > > > > Sent: Sunday, January 20, 2013 7:28 PM > > > > > Subject: [OAUTH-WG] Client cannot specify the token type it needs > > > > > > > > > > > > > > Although token type is extensible according to the OAuth core > > > > > specification - it is fully governed by the Authorization Server. > > > > > > > > > > There can be a case where a single AS supports multiple token > types > > > > > based on client request. > > > > > > > > > > But currently we don't have a way the client can specify (or at > > > > > least suggest) which token type it needs in the OAuth access > > > tokenrequest ? > > > > > > > > > > Is this behavior intentional ? or am I missing something... > > > > > > > > > > Thanks & Regards, > > > > > Prabath > > > > > > > > > > Mobile : +94 71 809 6732 > > > > > > > > > > http://blog.facilelogin.com > > > > > http://RampartFAQ.com > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > -- > > > > Thanks & Regards, > > > > Prabath > > > > > > > > Mobile : +94 71 809 6732 > > > > > > > > http://blog.facilelogin.com > > > > http://RampartFAQ.com > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b66fef3d1780004d3c7cf77 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I am not objecting that RS should define it's requirements...  and= RS should be able to do it by each resource... So ideally RS may have &nbs= p;away to express that in a WADL and we need to have a standard mechanism e= stablished for communication between RS and AS.

In WS-Trust - SP can declare it's token requirements via= WS-SecurityPolicy, in WSDL. And client reads the WSDL and identify the tok= en requirements. Then based on those requirements, client talks to the STS = and gets the token.

Thanks & regards,
-Prabath 

=
On Mon, Jan 21, 2013 at 1:07 PM, <zhou.su= jing@zte.com.cn> wrote:

Prabath Siriwardena <prabath@wso2.com> =D0=B4=D3=DA 2013-01-21 15:27:57:


> I guess that is a pattern used many scenarios. Requesting client can > suggest - but its up to the AS to honor it or not...

Not exactly. For example, RS supports two token types, one is bear token, another is holer-of-key which is assumed more secure than the first one.
RS realy wants the seconde type, but =A3=A8a dishonest=A3=A9 client, always choosing the weakest, requests the first one.
what is the meaning for client to specify the token type?

>
> Thanks & regards,
> -prabath
> On Mon, Jan 21, 2013 at 12:43 PM, <zhou.sujing@zte.com.cn> wrote:
>
> William Mills <wmills_92105@yahoo.com> =D0=B4=D3=DA 2013-01-21 13:44:45:
>
>
> > Not a problem for the client to request a type, but it may not get it.
>
> I don't object client requesting a type, but I think it is
> meaningful only when the requested type is specified by a RS,
> and client just relay that request to AS.
>
> >
> > From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
> > To: Prabath Siriwardena <prabath@wso2.com>
> > Cc: "oau= th@ietf.org WG" <oauth@ietf.org>; William Mills
> > <w= mills_92105@yahoo.com>
> > Sent: Sunday, January 20, 2013 9:38 PM
> > Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token
> type it needs
> >
> >
> > Well, if RS could specify token type, then Client could transfer it to AS,
> > I think, but it is not a good idea for client itself to specify the
> > token type.
> >
> >
> > Prabath Siriwardena <prabath@wso2.com> =D0=B4=D3=DA 2013-01-21 13:29:05:
> >
> > > Think about a distributed setup. You have single Authorizati= on
> > > Server and multiple Resource Servers.
> > >
> > > Although OAuth nicely decouples AS from RS - AFAIK there is no
> > > standard established for communication betweens AS and RS - how to
> > > declare metadata between those.
> > >
> > > Also there can be Resource Servers which support multiple token
> > > types. It could vary on APIs hosted in a given RS.
> > >
> > > Thanks & regards,
> > > -Prabath
> > >
> > > On Mon, Jan 21, 2013 at 10:48 AM, <zhou.sujing@zte.com.cn> wrote:
> > >
> > > The token type shoulbe decided by resource server, which consumes
> > > access token.
> > > Client just re-tell the requested token type to AS.
> > > Client should not specify the token type.
> > >
> > >
> > > = oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39:
> > >
> > >
> > > > This is true.  It's possible for the AS to var= y it's behavior on
> > > > scope name, but it's presumed the AS and RS have an agreement of
> > > > what token type is in play.  Likely a good extensi= on to the spec.
> > >
> > > >
> > > > From: Prabath Siriwardena <prabath@wso2.com>
> > > > To: "oauth@ietf.org WG" <oauth@ietf.org>
> > > > Sent: Sunday, January 20, 2013 7:28 PM
> > > > Subject: [OAUTH-WG] Client cannot specify the token type it needs
> > >
> > > >
> > > > Although token type is extensible according to the OAuth core
> > > > specification - it is fully governed by the Authorizati= on Server.
> > > >
> > > > There can be a case where a single AS supports multiple token types
> > > > based on client request.
> > > >
> > > > But currently we don't have a way the client can sp= ecify (or at
> > > > least suggest) which token type it needs in the OAuth access
> > tokenrequest ?
> > > >
> > > > Is this behavior intentional ? or am I missing somethin= g...
> > > >
> > > > Thanks & Regards,
> > > > Prabath
> > > >
> > > > Mobile : +94 71 809 6732
> > > >
> > > > http://blog.facilelogin.com
> > > > htt= p://RampartFAQ.com
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAu= th@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAu= th@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > ht= tp://blog.facilelogin.com
> > > http://R= ampartFAQ.com
> >
>

>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.= facilelogin.com
> http://RampartFAQ.= com



--
= Thanks & Regards,
Prabath

--047d7b66fef3d1780004d3c7cf77-- From jricher@mitre.org Tue Jan 22 11:00:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CE21F8A3E for ; Tue, 22 Jan 2013 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ9TMnM+1wKv for ; Tue, 22 Jan 2013 11:00:36 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0979921F8A3D for ; Tue, 22 Jan 2013 11:00:36 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 610E153106F3; Tue, 22 Jan 2013 14:00:35 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4027953106E0; Tue, 22 Jan 2013 14:00:35 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 22 Jan 2013 14:00:34 -0500 Message-ID: <50FEE1BF.5050200@mitre.org> Date: Tue, 22 Jan 2013 14:00:15 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Shiu Fun Poon , "oauth@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020408060301040407090605" X-Originating-IP: [129.83.31.58] Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:00:37 -0000 --------------020408060301040407090605 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit (CC'ing the working group) I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. -- Justin On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: > Justin, > > This spec is looking good.. > > One thing I would like to recommend is to add "action"/"operation" to > the request. (and potentially add client_id and client_secret) > > So the request will be like : > token REQUIRED > operation (wording to be determine) OPTIONAL inquire (default) | > revoke ... > resource_id OPTIONAL > client_id OPTIONAL > client_secret OPTIONAL > > And for the OAuth client information, it should be an optional > parameter (in case it is a public client or client is authenticated > with SSL mutual authentication). > > Please consider. > > ShiuFun --------------020408060301040407090605 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit (CC'ing the working group)

I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

 -- Justin

On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
Justin,

This spec is looking good..

One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)

So the request will be like :
token                                             REQUIRED
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
resource_id                                    OPTIONAL
client_id                                         OPTIONAL
client_secret                                   OPTIONAL

And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

Please consider.

ShiuFun

--------------020408060301040407090605-- From sakimura@gmail.com Tue Jan 22 17:05:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3321F874F for ; Tue, 22 Jan 2013 17:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3xKrevXhFYa for ; Tue, 22 Jan 2013 17:05:35 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id A590221F8830 for ; Tue, 22 Jan 2013 17:05:35 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so3660772eek.26 for ; Tue, 22 Jan 2013 17:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=VavsTOljQ6ahLYy3erngqv0BLJhoISZbbNbjy4ytfKA=; b=MRHTI0f+u7Lre8fLxd7Hl+XY0Kl2vcK0R9sW60mIVyTHgCgpTctVRmD2tTMsc+O7xN 7RabRFy2mfKygyvM13vM6G5NSC+PiSDc56w/PadJUb0VJGsTGhpOPv5o4ZhpoE3pUg9t GqPi2Cz1KXmOat5Ir31+npOKzR25icGb9qJ28Th/rIcxnKkJCfVnR8hRye0CkNF85j94 bfTZGr+ZInLlQC065VQGq1MTuDvtPVGjlsjC0i7PgbGZRCL5R02hzP0jqivHu4codNBE phlLyP31xdHWv/iS4UZ3OMKhjtyawlnoCueR5Vr2ZQRjEogaL7SFQG7FP8vPBL+B9U3C EuZQ== X-Received: by 10.14.3.195 with SMTP id 43mr78331917eeh.36.1358903134677; Tue, 22 Jan 2013 17:05:34 -0800 (PST) References: <50FEE1BF.5050200@mitre.org> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <50FEE1BF.5050200@mitre.org> Date: Wed, 23 Jan 2013 10:05:32 +0900 Message-ID: <-6134323107835063788@unknownmsgid> To: Justin Richer Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: base64 Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 01:05:36 -0000 IkFjdGlvbiIgZ29lcyBhZ2FpbnN0IFJFU1QgcHJpbmNpcGxlLgpJIGRvIG5vdCB0aGluayBpdCBp cyBhIGdvb2QgaWRlYS4KCj1uYXQgdmlhIGlQaG9uZQoKSmFuIDIzLCAyMDEzIDQ6MDAbJEIhIhso Qkp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiAbJEIkTiVhJUMlOyE8JTgbKEI6Cgo+ IChDQydpbmcgdGhlIHdvcmtpbmcgZ3JvdXApCj4KPiBJJ20gbm90IHN1cmUgd2hhdCB0aGUgImFj dGlvbi9vcGVyYXRpb24iIGZsYWcgd291bGQgYWNjb21wbGlzaC4gVGhlIGlkZWEgYmVoaW5kIGhh dmluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGluIE9BdXRoIGlzIHRoYXQgdGhleSBlYWNoIGRvIGRp ZmZlcmVudCBraW5kcyBvZiB0aGluZ3MuIFRoZSBvbmx5ICJhY3Rpb24vb3BlcmF0aW9uIiB0aGF0 IEkgaGFkIGVudmlzaW9uZWQgZm9yIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGlzIGludHJv c3BlY3Rpb24gaXRzZWxmOiAiSSBoYXZlIGEgdG9rZW4sIHdoYXQgZG9lcyBpdCBtZWFuPyIKPgo+ IE5vdGUgdGhhdCBjbGllbnRfaWQgYW5kIGNsaWVudF9zZWNyZXQgKmNhbiogYWxyZWFkeSBiZSB1 c2VkIGF0IHRoaXMgZW5kcG9pbnQgaWYgdGhlIHNlcnZlciBzdXBwb3J0cyB0aGF0IGFzIHBhcnQg b2YgdGhlaXIgY2xpZW50IGNyZWRlbnRpYWxzIHNldHVwLiBUaGUgZXhhbXBsZXMgdXNlIEhUVFAg QmFzaWMgd2l0aCBjbGllbnQgaWQgYW5kIHNlY3JldCByaWdodCBub3cuIEJhc2ljYWxseSwgdGhl IGNsaWVudCBjYW4gYXV0aGVudGljYXRlIGhvd2V2ZXIgaXQgd2FudHMsIGluY2x1ZGluZyBhbnkg b2YgdGhlIG1ldGhvZHMgdGhhdCBPQXV0aDIgYWxsb3dzIG9uIHRoZSB0b2tlbiBlbmRwb2ludC4g SXQgY291bGQgYWxzbyBhdXRoZW50aWNhdGUgd2l0aCBhbiBhY2Nlc3MgdG9rZW4uIEF0IGxlYXN0 LCB0aGF0J3MgdGhlIGludGVudCBvZiB0aGUgaW50cm9zcGVjdGlvbiBkcmFmdCAtLSBpZiB0aGF0 J3MgdW5jbGVhciwgSSdkIGJlIGhhcHB5IHRvIGFjY2VwdCBzdWdnZXN0ZWQgY2hhbmdlcyB0byBj bGFyaWZ5IHRoaXMgdGV4dC4KPgo+ICAtLSBKdXN0aW4KPgo+IE9uIDAxLzIyLzIwMTMgMDE6MDAg UE0sIFNoaXUgRnVuIFBvb24gd3JvdGU6Cj4+IEp1c3RpbiwKPj4KPj4gVGhpcyBzcGVjIGlzIGxv b2tpbmcgZ29vZC4uCj4+Cj4+IE9uZSB0aGluZyBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIGlz IHRvIGFkZCAiYWN0aW9uIi8ib3BlcmF0aW9uIiB0byB0aGUgcmVxdWVzdC4gIChhbmQgcG90ZW50 aWFsbHkgYWRkIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCkKPj4KPj4gU28gdGhlIHJlcXVl c3Qgd2lsbCBiZSBsaWtlIDoKPj4gdG9rZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSRVFVSVJFRAo+PiBvcGVyYXRpb24gKHdvcmRpbmcgdG8gYmUgZGV0ZXJt aW5lKSAgT1BUSU9OQUwgaW5xdWlyZSAoZGVmYXVsdCkgfCByZXZva2UgLi4uCj4+IHJlc291cmNl X2lkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT1BUSU9OQUwKPj4gY2xpZW50 X2lkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPUFRJT05BTAo+PiBj bGllbnRfc2VjcmV0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPUFRJT05BTAo+ Pgo+PiBBbmQgZm9yIHRoZSBPQXV0aCBjbGllbnQgaW5mb3JtYXRpb24sIGl0IHNob3VsZCBiZSBh biBvcHRpb25hbCBwYXJhbWV0ZXIgKGluIGNhc2UgaXQgaXMgYSBwdWJsaWMgY2xpZW50IG9yIGNs aWVudCBpcyBhdXRoZW50aWNhdGVkIHdpdGggU1NMIG11dHVhbCBhdXRoZW50aWNhdGlvbikuCj4+ Cj4+IFBsZWFzZSBjb25zaWRlci4KPj4KPj4gU2hpdUZ1bgo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBPQXV0aCBtYWlsaW5nIGxpc3QKPiBPQXV0 aEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK From jricher@mitre.org Wed Jan 23 07:19:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DC721F86D2 for ; Wed, 23 Jan 2013 07:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMtzr0NwXM59 for ; Wed, 23 Jan 2013 07:19:22 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF821F86CD for ; Wed, 23 Jan 2013 07:19:22 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA5B81F1D11; Wed, 23 Jan 2013 10:19:21 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BDBBE1F1D05; Wed, 23 Jan 2013 10:19:21 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 10:19:21 -0500 Message-ID: <50FFFF66.2030104@mitre.org> Date: Wed, 23 Jan 2013 10:19:02 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Shiu Fun Poon , "oauth@ietf.org" References: <50FEE1BF.5050200@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020802070208070702030706" X-Originating-IP: [129.83.31.58] Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:19:23 -0000 --------------020802070208070702030706 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > For the client_id, if there is no client_secret, how is that > information going to flow thru ? In the oauth spec, the protocol > allows you to specify the client_id and secret in the payload. So it > would be good for this spec to follow as closely to the oauth spec, > that will be great. > The idea of the introspection endpoint is to exactly mimic the OAuth2 capabilities for client authentication as well as allowing for authorization based on a valid OAuth2 access token, as Section 2.1 states: The endpoint SHOULD also require some form of authentication to access this endpoint, such as the Client Authentication as described in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access Token. This means that if you have no client secret, you don't send one. You can use Basic or form parameters. If you have a client assertion, you use that. If you have an access token, you use that. Basically, however your clients normally authenticate with your AS, you can do that here. Or if you want to, the token that you're introspecting can be its own key -- a use that I haven't called out specifically in the document yet because I'm not fully convinced of its utility. > And for the action/operation, separate endpoint will be one way of > handling it. However are you going to dictate what the endpoint is ? > If not, it will make sense for the request to be self-identified. > That will provide the most flexibility. > Yes, the specification specifically defines a separate endpoint. From the introduction: This specification defines an Introspection Endpoint that allows the holder of a token to query the Authorization Server to discover the set of metadata for a token. And all of section 2 is titled "Introspection Endpoint" for this reason as well. If there is a way either of these points could be made more clear, please suggest new language for the specification and I'll incorporate it. -- Justin > Regards. > > > On Tue, Jan 22, 2013 at 2:00 PM, Justin Richer > wrote: > > (CC'ing the working group) > > I'm not sure what the "action/operation" flag would accomplish. > The idea behind having different endpoints in OAuth is that they > each do different kinds of things. The only "action/operation" > that I had envisioned for the introspection endpoint is > introspection itself: "I have a token, what does it mean?" > > Note that client_id and client_secret *can* already be used at > this endpoint if the server supports that as part of their client > credentials setup. The examples use HTTP Basic with client id and > secret right now. Basically, the client can authenticate however > it wants, including any of the methods that OAuth2 allows on the > token endpoint. It could also authenticate with an access token. > At least, that's the intent of the introspection draft -- if > that's unclear, I'd be happy to accept suggested changes to > clarify this text. > > -- Justin > > > On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >> Justin, >> >> This spec is looking good.. >> >> One thing I would like to recommend is to add >> "action"/"operation" to the request. (and potentially add >> client_id and client_secret) >> >> So the request will be like : >> token REQUIRED >> operation (wording to be determine) OPTIONAL inquire (default) | >> revoke ... >> resource_id OPTIONAL >> client_id OPTIONAL >> client_secret OPTIONAL >> >> And for the OAuth client information, it should be an optional >> parameter (in case it is a public client or client is >> authenticated with SSL mutual authentication). >> >> Please consider. >> >> ShiuFun > > --------------020802070208070702030706 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
For the client_id, if there is no client_secret, how is that information going to flow thru ?  In the oauth spec, the protocol allows you to specify the client_id and secret in the payload.  So it would be good for this spec to follow as closely to the oauth spec, that will be great.

The idea of the introspection endpoint is to exactly mimic the OAuth2 capabilities for client authentication as well as allowing for authorization based on a valid OAuth2 access token, as Section 2.1 states:

The endpoint SHOULD also require some form of authentication to access this endpoint, such as the Client Authentication as described in OAuth 2 Core Specification [RFC6749] or a separate OAuth2 Access Token.
This means that if you have no client secret, you don't send one. You can use Basic or form parameters. If you have a client assertion, you use that. If you have an access token, you use that. Basically, however your clients normally authenticate with your AS, you can do that here. Or if you want to, the token that you're introspecting can be its own key -- a use that I haven't called out specifically in the document yet because I'm not fully convinced of its utility.

And for the action/operation, separate endpoint will be one way of handling it.  However are you going to dictate what the endpoint is ?  If not, it will make sense for the request to be self-identified.  That will provide the most flexibility.

Yes, the specification specifically defines a separate endpoint. From the introduction:

This specification defines an Introspection Endpoint that allows the holder of a token to query the Authorization Server to discover the set of metadata for a token.

And all of section 2 is titled "Introspection Endpoint" for this reason as well.


If there is a way either of these points could be made more clear, please suggest new language for the specification and I'll incorporate it.

 -- Justin


Regards.


On Tue, Jan 22, 2013 at 2:00 PM, Justin Richer <jricher@mitre.org> wrote:
(CC'ing the working group)

I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

 -- Justin


On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
Justin,

This spec is looking good..

One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)

So the request will be like :
token                                             REQUIRED
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
resource_id                                    OPTIONAL
client_id                                         OPTIONAL
client_secret                                   OPTIONAL

And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

Please consider.

ShiuFun



--------------020802070208070702030706-- From jricher@mitre.org Wed Jan 23 07:47:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4ED21F872C for ; Wed, 23 Jan 2013 07:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crWp6bjZxr-P for ; Wed, 23 Jan 2013 07:47:21 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C02221F8703 for ; Wed, 23 Jan 2013 07:47:21 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 47E37435030D; Wed, 23 Jan 2013 10:47:21 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 29DA41F1D1F; Wed, 23 Jan 2013 10:47:21 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 10:47:20 -0500 Message-ID: <510005F5.6000004@mitre.org> Date: Wed, 23 Jan 2013 10:47:01 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nat Sakimura References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> In-Reply-To: <-6134323107835063788@unknownmsgid> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:47:22 -0000 Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? -- Justin On 01/22/2013 08:05 PM, Nat Sakimura wrote: > "Action" goes against REST principle. > I do not think it is a good idea. > > =nat via iPhone > > Jan 23, 2013 4:00、Justin Richer のメッセージ: > >> (CC'ing the working group) >> >> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >> >> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >> >> -- Justin >> >> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>> Justin, >>> >>> This spec is looking good.. >>> >>> One thing I would like to recommend is to add "action"/"operation" to the request. (and potentially add client_id and client_secret) >>> >>> So the request will be like : >>> token REQUIRED >>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>> resource_id OPTIONAL >>> client_id OPTIONAL >>> client_secret OPTIONAL >>> >>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>> >>> Please consider. >>> >>> ShiuFun >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Wed Jan 23 08:34:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9568B21F8678 for ; Wed, 23 Jan 2013 08:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smc0DPCb1Kca for ; Wed, 23 Jan 2013 08:34:43 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9E17421F866E for ; Wed, 23 Jan 2013 08:34:42 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so9062478lab.1 for ; Wed, 23 Jan 2013 08:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CG1cvQyJyPp9yUPdYoqFRHaIeNeyU0QVrK/VJXh+duo=; b=RTVSqhjCzTJr2YbsJpIYwIyhfodwyiQ6gWNRXRu/2rGs99NH1r2Si5bs7y5Kgvgsk5 N4P0sYOcn1KyODJH6XbePeZ7cOxtBO0ELfTGgNfKW/X/d+GhFCRu5+NM+KvvdCau5+ya etbZSpRfNQZ32LI93fqGj9gaIV7vPQF2gFS6x8Ug4AMDQv6+szqJlrcqhqiQq/iuHVkV g/4Zjjn2s6gyBaEXgMkVeEeiyZWnoCJAw4VJ9xPOnsdMSsNqEy3Qm0J4YL4rZIwSGuHt LPivjagiFuzx57la9EOFR51ZYlPy937ewpjZ6geKQTBkVIVN971ORN+aq4MiQ2ygOLb6 WVFw== X-Received: by 10.112.8.163 with SMTP id s3mr931894lba.113.1358958881589; Wed, 23 Jan 2013 08:34:41 -0800 (PST) Received: from [10.36.224.155] ([217.173.99.61]) by mx.google.com with ESMTPS id o2sm8612399lby.11.2013.01.23.08.34.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 08:34:40 -0800 (PST) Message-ID: <5100111F.1090304@gmail.com> Date: Wed, 23 Jan 2013 16:34:39 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> In-Reply-To: <510005F5.6000004@mitre.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:34:43 -0000 On 23/01/13 15:47, Justin Richer wrote: > Which brings up an interesting question for the Registration doc: right > now, it's set up as a single endpoint with three operations. We could > instead define three endpoints for the different operations. > > I've not been keen to make that deep of a cutting change to it, but it > would certainly be cleaner and more RESTful API design. What do others > think? > IMHO the purity should be balanced against the practicality/simplicity of the implementation. Talking about 3 endpoints at the spec level may be treated as the exact requirement to have 3 separate application endpoints for the single type of activity, the registration. Can the spec be re-worded such that "resources" are used instead of endpoints or similar, example, "resource available at /a will support the following, at /b - something else", or may be something similar, thus it will read better too from the design point of view, and let implementers to use 1 endpoint or 3 ones, whichever way they prefer it Thanks, Sergey > -- Justin > > > On 01/22/2013 08:05 PM, Nat Sakimura wrote: >> "Action" goes against REST principle. >> I do not think it is a good idea. >> >> =nat via iPhone >> >> Jan 23, 2013 4:00、Justin Richer のメッセージ: >> >>> (CC'ing the working group) >>> >>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>> >>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>> >>> -- Justin >>> >>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>> Justin, >>>> >>>> This spec is looking good.. >>>> >>>> One thing I would like to recommend is to add "action"/"operation" to the request. (and potentially add client_id and client_secret) >>>> >>>> So the request will be like : >>>> token REQUIRED >>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>> resource_id OPTIONAL >>>> client_id OPTIONAL >>>> client_secret OPTIONAL >>>> >>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>> >>>> Please consider. >>>> >>>> ShiuFun >>> _______________________________________________ >>> OAuth mailing 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 tonynad@microsoft.com Wed Jan 23 09:18:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2621F8583 for ; Wed, 23 Jan 2013 09:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sahysK6i2sR for ; Wed, 23 Jan 2013 09:18:05 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 635B621F8569 for ; Wed, 23 Jan 2013 09:18:05 -0800 (PST) Received: from BL2FFO11FD009.protection.gbl (10.173.161.201) by BL2FFO11HUB035.protection.gbl (10.173.161.115) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 23 Jan 2013 17:18:02 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 23 Jan 2013 17:18:02 +0000 Received: from TX2EHSOBE001.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 23 Jan 2013 17:17:20 +0000 Received: from mail241-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 17:15:00 +0000 Received: from mail241-tx2 (localhost [127.0.0.1]) by mail241-tx2-R.bigfish.com (Postfix) with ESMTP id 2032556080A for ; Wed, 23 Jan 2013 17:15:00 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI9371Id6eah542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h945hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h) Received-SPF: softfail (mail241-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail241-tx2 (localhost.localdomain [127.0.0.1]) by mail241-tx2 (MessageSwitch) id 1358961298379687_4968; Wed, 23 Jan 2013 17:14:58 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.241]) by mail241-tx2.bigfish.com (Postfix) with ESMTP id 5815B340078; Wed, 23 Jan 2013 17:14:58 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 17:14:55 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.257.4; Wed, 23 Jan 2013 17:14:53 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.601.3; Wed, 23 Jan 2013 17:14:51 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Wed, 23 Jan 2013 17:14:50 +0000 From: Anthony Nadalin To: Justin Richer , Nat Sakimura Thread-Topic: [OAUTH-WG] Concerning OAuth introspection Thread-Index: AQHN+NM+tPsrUD5ZNEKigQoex6SLPZhWGdUAgAD2SICAABhS8A== Date: Wed, 23 Jan 2013 17:14:50 +0000 Message-ID: <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> In-Reply-To: <510005F5.6000004@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.132] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464002)(479174001)(24454001)(377454001)(199002)(189002)(47976001)(76482001)(50986001)(33646001)(56776001)(6806001)(56816002)(51856001)(23736001)(53806001)(59766001)(5343655001)(49866001)(50466001)(47736001)(79102001)(46102001)(47776002)(550184003)(47446002)(74502001)(44976002)(31966008)(4396001)(74662001)(54356001)(77982001)(54316002)(16676001)(6816006)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB035; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073515755F Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:18:06 -0000 Why not just have a physical and logical endpoint options -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Wednesday, January 23, 2013 7:47 AM To: Nat Sakimura Cc: Shiu Fun Poon; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection Which brings up an interesting question for the Registration doc: right now= , it's set up as a single endpoint with three operations. We could instead = define three endpoints for the different operations. I've not been keen to make that deep of a cutting change to it, but it woul= d certainly be cleaner and more RESTful API design. What do others think? -- Justin On 01/22/2013 08:05 PM, Nat Sakimura wrote: > "Action" goes against REST principle. > I do not think it is a good idea. > > =3Dnat via iPhone > > Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer =1B$B$N%a%= C%;!<%8=1B(B: > >> (CC'ing the working group) >> >> I'm not sure what the "action/operation" flag would accomplish. The idea= behind having different endpoints in OAuth is that they each do different = kinds of things. The only "action/operation" that I had envisioned for the = introspection endpoint is introspection itself: "I have a token, what does = it mean?" >> >> Note that client_id and client_secret *can* already be used at this endp= oint if the server supports that as part of their client credentials setup.= The examples use HTTP Basic with client id and secret right now. Basically= , the client can authenticate however it wants, including any of the method= s that OAuth2 allows on the token endpoint. It could also authenticate with= an access token. At least, that's the intent of the introspection draft --= if that's unclear, I'd be happy to accept suggested changes to clarify thi= s text. >> >> -- Justin >> >> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>> Justin, >>> >>> This spec is looking good.. >>> >>> One thing I would like to recommend is to add "action"/"operation"=20 >>> to the request. (and potentially add client_id and client_secret) >>> >>> So the request will be like : >>> token REQUIRED >>> operation (wording to be determine) OPTIONAL inquire (default) | revok= e ... >>> resource_id OPTIONAL >>> client_id OPTIONAL >>> client_secret OPTIONAL >>> >>> And for the OAuth client information, it should be an optional paramete= r (in case it is a public client or client is authenticated with SSL mutual= authentication). >>> >>> Please consider. >>> >>> ShiuFun >> _______________________________________________ >> OAuth mailing 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 eve@xmlgrrl.com Wed Jan 23 09:18:31 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703AD21F8200 for ; Wed, 23 Jan 2013 09:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65-wk6BOAFS2 for ; Wed, 23 Jan 2013 09:18:30 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id A683F21F8598 for ; Wed, 23 Jan 2013 09:18:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id B2DDB9A6E8A; Wed, 23 Jan 2013 09:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0Hsm9Qsy0HP; Wed, 23 Jan 2013 09:18:25 -0800 (PST) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 5B9109A6E68; Wed, 23 Jan 2013 09:18:25 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-2022-jp From: Eve Maler In-Reply-To: <5100111F.1090304@gmail.com> Date: Wed, 23 Jan 2013 09:18:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1499) Cc: Paul Bryan , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:18:31 -0000 Agreed that REST purity may come at a cost that's too high. On the other = hand, it's a useful exercise to imagine how much more benefit could = potentially be gotten "for free" if we look at it through a pure-REST = lens, not just with what's already been specified but the whole picture. If what you're registering is a client descriptor, then creating a new = one, updating an existing one, deleting, and even patching could come = for free if something like the following framework is used: http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 With standard libraries possibly floating around to support this = framework (I think Paul B wrote one; maybe he open-sourced it?), it = starts to become a lot cheaper to support client registration on both = sides of the interaction. Eve On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin = wrote: > On 23/01/13 15:47, Justin Richer wrote: >> Which brings up an interesting question for the Registration doc: = right >> now, it's set up as a single endpoint with three operations. We could >> instead define three endpoints for the different operations. >>=20 >> I've not been keen to make that deep of a cutting change to it, but = it >> would certainly be cleaner and more RESTful API design. What do = others >> think? >>=20 > IMHO the purity should be balanced against the practicality/simplicity > of the implementation. > Talking about 3 endpoints at the spec level may be treated as the = exact > requirement to have 3 separate application endpoints for the single = type > of activity, the registration. Can the spec be re-worded such that > "resources" are used instead of endpoints or similar, example, = "resource > available at /a will support the following, at /b - something else", = or > may be something similar, thus it will read better too from the = design > point of view, and let implementers to use 1 endpoint or 3 ones, > whichever way they prefer it >=20 > Thanks, Sergey >=20 >> -- Justin >>=20 >>=20 >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>>=20 >>> =3Dnat via iPhone >>>=20 >>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer = =1B$B$N%a%C%;!<%8=1B(B: >>>=20 >>>> (CC'ing the working group) >>>>=20 >>>> I'm not sure what the "action/operation" flag would accomplish. The = idea behind having different endpoints in OAuth is that they each do = different kinds of things. The only "action/operation" that I had = envisioned for the introspection endpoint is introspection itself: "I = have a token, what does it mean?" >>>>=20 >>>> Note that client_id and client_secret *can* already be used at this = endpoint if the server supports that as part of their client credentials = setup. The examples use HTTP Basic with client id and secret right now. = Basically, the client can authenticate however it wants, including any = of the methods that OAuth2 allows on the token endpoint. It could also = authenticate with an access token. At least, that's the intent of the = introspection draft -- if that's unclear, I'd be happy to accept = suggested changes to clarify this text. >>>>=20 >>>> -- Justin >>>>=20 >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>>=20 >>>>> This spec is looking good.. >>>>>=20 >>>>> One thing I would like to recommend is to add "action"/"operation" = to the request. (and potentially add client_id and client_secret) >>>>>=20 >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | = revoke ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>>=20 >>>>> And for the OAuth client information, it should be an optional = parameter (in case it is a public client or client is authenticated with = SSL mutual authentication). >>>>>=20 >>>>> Please consider. >>>>>=20 >>>>> ShiuFun >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From jricher@mitre.org Wed Jan 23 09:18:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335AF21F85B3 for ; Wed, 23 Jan 2013 09:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCD0VBY8cRTY for ; Wed, 23 Jan 2013 09:18:40 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 720A821F8200 for ; Wed, 23 Jan 2013 09:18:40 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E27D51F1D8C; Wed, 23 Jan 2013 12:18:39 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C193C4390103; Wed, 23 Jan 2013 12:18:39 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 12:18:39 -0500 Message-ID: <51001B5C.80407@mitre.org> Date: Wed, 23 Jan 2013 12:18:20 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Anthony Nadalin References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:18:41 -0000 Because then nobody would know how to actually use the thing. In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. -- Justin On 01/23/2013 12:14 PM, Anthony Nadalin wrote: > Why not just have a physical and logical endpoint options > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Wednesday, January 23, 2013 7:47 AM > To: Nat Sakimura > Cc: Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. > > I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? > > -- Justin > > > On 01/22/2013 08:05 PM, Nat Sakimura wrote: >> "Action" goes against REST principle. >> I do not think it is a good idea. >> >> =nat via iPhone >> >> Jan 23, 2013 4:00、Justin Richer のメッセージ: >> >>> (CC'ing the working group) >>> >>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>> >>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>> >>> -- Justin >>> >>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>> Justin, >>>> >>>> This spec is looking good.. >>>> >>>> One thing I would like to recommend is to add "action"/"operation" >>>> to the request. (and potentially add client_id and client_secret) >>>> >>>> So the request will be like : >>>> token REQUIRED >>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>> resource_id OPTIONAL >>>> client_id OPTIONAL >>>> client_secret OPTIONAL >>>> >>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>> >>>> Please consider. >>>> >>>> ShiuFun >>> _______________________________________________ >>> OAuth mailing 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 tonynad@microsoft.com Wed Jan 23 09:23:23 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431AC21F85D4 for ; Wed, 23 Jan 2013 09:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMxdqE6JIDdP for ; Wed, 23 Jan 2013 09:23:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8B21F85C3 for ; Wed, 23 Jan 2013 09:23:22 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.202) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 23 Jan 2013 17:23:14 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 23 Jan 2013 17:23:14 +0000 Received: from CO9EHSOBE029.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 23 Jan 2013 17:22:58 +0000 Received: from mail58-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE029.bigfish.com (10.236.130.92) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 17:21:50 +0000 Received: from mail58-co9 (localhost [127.0.0.1]) by mail58-co9-R.bigfish.com (Postfix) with ESMTP id BF1C6380130 for ; Wed, 23 Jan 2013 17:21:50 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI9371Id6eah542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h945hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h) Received-SPF: softfail (mail58-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail58-co9 (localhost.localdomain [127.0.0.1]) by mail58-co9 (MessageSwitch) id 1358961707729033_16687; Wed, 23 Jan 2013 17:21:47 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.252]) by mail58-co9.bigfish.com (Postfix) with ESMTP id A55205C004C; Wed, 23 Jan 2013 17:21:47 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 17:21:46 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.257.4; Wed, 23 Jan 2013 17:21:43 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.601.3; Wed, 23 Jan 2013 17:21:35 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Wed, 23 Jan 2013 17:21:17 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] Concerning OAuth introspection Thread-Index: AQHN+NM+tPsrUD5ZNEKigQoex6SLPZhWGdUAgAD2SICAABhS8IAAATIAgAAAnxA= Date: Wed, 23 Jan 2013 17:21:16 +0000 Message-ID: <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> In-Reply-To: <51001B5C.80407@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.132] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464002)(479174001)(24454001)(199002)(189002)(377454001)(47736001)(33646001)(47976001)(6806001)(50986001)(56776001)(79102001)(56816002)(51856001)(76482001)(59766001)(53806001)(23736001)(5343655001)(49866001)(50466001)(47776002)(74502001)(47446002)(44976002)(74662001)(46102001)(4396001)(550184003)(54316002)(54356001)(77982001)(16676001)(31966008)(6816006)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073515755F Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:23:23 -0000 Registration has to work in a multi-tenant environment so flexibility is n= eeded -----Original Message----- From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Wednesday, January 23, 2013 9:18 AM To: Anthony Nadalin Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection Because then nobody would know how to actually use the thing. In my opinion, this is a key place where this kind of flexibility is a very= bad thing. Registration needs to work one fairly predictable way. -- Justin On 01/23/2013 12:14 PM, Anthony Nadalin wrote: > Why not just have a physical and logical endpoint options > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Justin Richer > Sent: Wednesday, January 23, 2013 7:47 AM > To: Nat Sakimura > Cc: Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > Which brings up an interesting question for the Registration doc: right n= ow, it's set up as a single endpoint with three operations. We could instea= d define three endpoints for the different operations. > > I've not been keen to make that deep of a cutting change to it, but it wo= uld certainly be cleaner and more RESTful API design. What do others think? > > -- Justin > > > On 01/22/2013 08:05 PM, Nat Sakimura wrote: >> "Action" goes against REST principle. >> I do not think it is a good idea. >> >> =3Dnat via iPhone >> >> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer =1B$B$N%a= %C%;!<%8=1B(B: >> >>> (CC'ing the working group) >>> >>> I'm not sure what the "action/operation" flag would accomplish. The ide= a behind having different endpoints in OAuth is that they each do different= kinds of things. The only "action/operation" that I had envisioned for the= introspection endpoint is introspection itself: "I have a token, what does= it mean?" >>> >>> Note that client_id and client_secret *can* already be used at this end= point if the server supports that as part of their client credentials setup= . The examples use HTTP Basic with client id and secret right now. Basicall= y, the client can authenticate however it wants, including any of the metho= ds that OAuth2 allows on the token endpoint. It could also authenticate wit= h an access token. At least, that's the intent of the introspection draft -= - if that's unclear, I'd be happy to accept suggested changes to clarify th= is text. >>> >>> -- Justin >>> >>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>> Justin, >>>> >>>> This spec is looking good.. >>>> >>>> One thing I would like to recommend is to add "action"/"operation"=20 >>>> to the request. (and potentially add client_id and client_secret) >>>> >>>> So the request will be like : >>>> token REQUIRED >>>> operation (wording to be determine) OPTIONAL inquire (default) | revo= ke ... >>>> resource_id OPTIONAL >>>> client_id OPTIONAL >>>> client_secret OPTIONAL >>>> >>>> And for the OAuth client information, it should be an optional paramet= er (in case it is a public client or client is authenticated with SSL mutua= l authentication). >>>> >>>> Please consider. >>>> >>>> ShiuFun >>> _______________________________________________ >>> OAuth mailing 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 eve@xmlgrrl.com Wed Jan 23 09:23:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22F321F85EA for ; Wed, 23 Jan 2013 09:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzk9vfFYgqu9 for ; Wed, 23 Jan 2013 09:23:50 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0B21F85C3 for ; Wed, 23 Jan 2013 09:23:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id B5E699A6FF4; Wed, 23 Jan 2013 09:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6U-G68rPSVF; Wed, 23 Jan 2013 09:23:45 -0800 (PST) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 4DB699A6FDB; Wed, 23 Jan 2013 09:23:45 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_12E8E9D3-ACA9-473F-87A0-4FA10AB7B99C" From: Eve Maler In-Reply-To: Date: Wed, 23 Jan 2013 09:23:44 -0800 Message-Id: <9034B9E7-B35F-4647-AF59-0DD222A3C60C@xmlgrrl.com> References: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> To: Prabath Siriwardena X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:23:52 -0000 --Apple-Mail=_12E8E9D3-ACA9-473F-87A0-4FA10AB7B99C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 FWIW, some of us have made a proposal for exactly this type of = standardized AS/RS communication: http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00 The UMA profile refers normatively to this spec, and at that higher = profile-specific level, it has an extensive set of AS configuration data = that includes a way to declare token types supported. It could make = sense for an RS to register its preferences for token types supported = among those declared in the AS config data. Should this "preferred token = type" semantic should be sedimented down to the = "draft-hardjono-oauth-resource-reg" level? Eve On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena = wrote: > Think about a distributed setup. You have single Authorization Server = and multiple Resource Servers. >=20 > Although OAuth nicely decouples AS from RS - AFAIK there is no = standard established for communication betweens AS and RS - how to = declare metadata between those. >=20 > Also there can be Resource Servers which support multiple token types. = It could vary on APIs hosted in a given RS. >=20 > Thanks & regards, > -Prabath >=20 >=20 > On Mon, Jan 21, 2013 at 10:48 AM, wrote: >=20 > The token type shoulbe decided by resource server, which consumes = access token.=20 > Client just re-tell the requested token type to AS.=20 > Client should not specify the token type.=20 >=20 >=20 > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39: >=20 >=20 > > This is true. It's possible for the AS to vary it's behavior on=20 > > scope name, but it's presumed the AS and RS have an agreement of=20 > > what token type is in play. Likely a good extension to the spec. >=20 > >=20 > > From: Prabath Siriwardena > > To: "oauth@ietf.org WG" =20 > > Sent: Sunday, January 20, 2013 7:28 PM > > Subject: [OAUTH-WG] Client cannot specify the token type it needs >=20 > >=20 > > Although token type is extensible according to the OAuth core=20 > > specification - it is fully governed by the Authorization Server.=20 > >=20 > > There can be a case where a single AS supports multiple token types=20= > > based on client request.=20 > >=20 > > But currently we don't have a way the client can specify (or at=20 > > least suggest) which token type it needs in the OAuth access token = request ?=20 > >=20 > > Is this behavior intentional ? or am I missing something...=20 > >=20 > > Thanks & Regards, > > Prabath=20 > >=20 > > Mobile : +94 71 809 6732=20 > >=20 > > http://blog.facilelogin.com > > http://RampartFAQ.com=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 > Thanks & Regards, > Prabath >=20 > Mobile : +94 71 809 6732=20 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_12E8E9D3-ACA9-473F-87A0-4FA10AB7B99C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 h= ttp://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
Not a problem for the client to request a type, but it may not get it.

From: "zhou.sujing@zte.com.cn" <zhou.= sujing@zte.com.cn>
To:<= /b> Prabath Siriwardena <prabath@wso2.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>; = William Mills <wmills_92105@yahoo.com>
Sent: Sunday, January 20, 2013 9:38 PM
Subject: Re: Re: Re: [OAUTH-WG] Cl= ient cannot specify the token type it needs

=0A
=0A
Well, if RS= could specify token type,=0Athen Client could transfer it to AS, = =0A
I think, but it is not a good i= dea for=0Aclient itself to specify the token type. =0A
=0A
=0A=
Prabath Siriwardena <prabath@wso2.com> =E5= =86=99=E4=BA=8E=0A2013-01-21 13:29:05:
=0A
=0A> Think about a dist= ributed setup. You have single Authorization
=0A> Server and multipl= e Resource Servers.=0A
>
=0A>= Although OAuth nicely decouples AS from RS - AFAIK there is no
=0A>= standard established for communication betweens AS and RS - how to=0A
= =0A> declare metadata between those.=0A
>
=0A> Also there can be Resource Servers which support multi= ple token
=0A> types. It could vary on APIs hosted in a given RS.=0A
>
=0A> Thanks & regards,= =0A
> -Prabath=0A
>
=0A> On Mon, Jan 21, 2013 at 10:48 AM, <zh= ou.sujing@zte.com.cn> wrote:=0A
>=
=0A> The token type shoulbe decided by resource server, which consu= mes=0A
=0A> access token.
=0A> Client just re-tell the request= ed token type to AS.
=0A> Client should not specify the token type. =
=0A>
=0A>
=0A> oauth-bounces@ietf.org =E5=86=99=E4=BA= =8E 2013-01-21 13:08:39:=0A
>
= =0A>
=0A> > This is true.  It's possible for the AS to va= ry it's behavior=0Aon
=0A> > scope name, but it's presumed the AS= and RS have an agreement=0Aof
=0A> > what token type is in play.=  Likely a good extension to=0Athe spec.=0A
>
=0A> > =0A
>= ; > From: Prabath Siriwardena <prabath@wso2.com>
=0A> > T= o: "oauth@ietf.org WG" <oauth@ietf.org>
=0A> > Sent: Sunday= , January 20, 2013 7:28 PM
=0A> > Subject: [OAUTH-WG] Client canno= t specify the token type it needs=0A
&g= t;
=0A> >
=0A> > Although token type is extensible acco= rding to the OAuth core=0A
=0A> > specification - it is fully gove= rned by the Authorization Server.=0A
=0A> >
=0A> > There= can be a case where a single AS supports multiple token=0Atypes
=0A>= ; > based on client request.
=0A> >
=0A> > But curre= ntly we don't have a way the client can specify (or=0Aat
=0A> > l= east suggest) which token type it needs in the OAuth access=0Atokenrequest = ?
=0A> >
=0A> > Is this behavior intentional ? or am I m= issing something...
=0A> >
=0A> > Thanks & Regards,=
=0A> > Prabath
=0A> >
=0A> > Mobile : +94 71 = 809 6732
=0A> >
=0A> > http://blog.facilelogin.com
= =0A> > http://RampartFAQ.com
=0A> >
=0A> > ______= _________________________________________
=0A> > OAuth mailing lis= t
=0A> > OAuth@ietf.org
=0A> > https://www.ietf.org/mailm= an/listinfo/oauth
=0A> >
=0A> > ________________________= _______________________
=0A> > OAuth mailing list
=0A> > = OAuth@ietf.org
=0A> > https://www.ietf.org/mailman/listinfo/oauth<= /font>=0A
>
=0A=0A
<= font size=3D"2">>
=0A> --
=0A> Thanks & Regards,
= =0A> Prabath=0A
>
=0A> Mob= ile : +94 71 809 6732
=0A>
=0A> http://blog.facilelogin.com=0A> http://RampartFAQ.com=0A


=

The UMA profile refers normatively to this spec, and = at that higher profile-specific level, it has an extensive set of AS = configuration data that includes a way to declare token types supported. = It could make sense for an RS to register its preferences for token = types supported among those declared in the AS config data. Should this = "preferred token type" semantic should be sedimented down to the = "draft-hardjono-oauth-resource-reg" = level?

Eve

On 20 Jan = 2013, at 9:29 PM, Prabath Siriwardena <prabath@wso2.com> = wrote:

Think about a distributed setup. You have single = Authorization Server and multiple Resource = Servers.

Although OAuth nicely decouples AS from RS - = AFAIK there is no standard established for communication betweens AS and = RS - how to declare metadata between those.

Also there can be Resource Servers which support = multiple token types. It could vary on APIs hosted in a given = RS.

Thanks & = regards,
-Prabath


On Mon, Jan 21, 2013 at 10:48 AM, = <zhou.sujing@zte.com.cn> = wrote:

The token type shoulbe decided by resource server, which consumes access token.
Client just re-tell the requested token type to AS.
Client should not specify the token type.


oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 = 13:08:39:


> This is true.  It's possible for the AS to vary it's behavior on
> scope name, but it's presumed the AS and RS have an agreement of =
> what token type is in play.  Likely a good extension to the = spec.
>
> From: Prabath Siriwardena <prabath@wso2.com>
> To: "oauth@ietf.org WG" <oauth@ietf.org> =
> Sent: Sunday, January 20, 2013 7:28 PM
> Subject: [OAUTH-WG] Client cannot specify the token type it = needs
>
> Although token type is extensible according to the OAuth core
> specification - it is fully governed by the Authorization = Server.
>
> There can be a case where a single AS supports multiple token types
> based on client request.
>
> But currently we don't have a way the client can specify (or at =
> least suggest) which token type it needs in the OAuth access token request ?
>
> Is this behavior intentional ? or am I missing something...
>
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



-- =
Thanks & Regards,
Prabath

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


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

= --Apple-Mail=_12E8E9D3-ACA9-473F-87A0-4FA10AB7B99C-- From jricher@mitre.org Wed Jan 23 09:27:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B814B21F85D4 for ; Wed, 23 Jan 2013 09:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2C2EVJgXvxt for ; Wed, 23 Jan 2013 09:27:18 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24E21F85C3 for ; Wed, 23 Jan 2013 09:27:17 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E402E1F1DCF; Wed, 23 Jan 2013 12:27:16 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D31BB1F1D57; Wed, 23 Jan 2013 12:27:16 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 12:27:16 -0500 Message-ID: <51001D61.1060000@mitre.org> Date: Wed, 23 Jan 2013 12:26:57 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Anthony Nadalin References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:27:19 -0000 I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish? You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts. -- Justin On 01/23/2013 12:21 PM, Anthony Nadalin wrote: > Registration has to work in a multi-tenant environment so flexibility is needed > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Wednesday, January 23, 2013 9:18 AM > To: Anthony Nadalin > Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > Because then nobody would know how to actually use the thing. > > In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. > > -- Justin > > On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >> Why not just have a physical and logical endpoint options >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Justin Richer >> Sent: Wednesday, January 23, 2013 7:47 AM >> To: Nat Sakimura >> Cc: Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? >> >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation" >>>>> to the request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun >>>> _______________________________________________ >>>> OAuth mailing 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 eve@xmlgrrl.com Wed Jan 23 09:28:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BB121F85FD for ; Wed, 23 Jan 2013 09:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCqGC3aYVAu9 for ; Wed, 23 Jan 2013 09:28:19 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFA21F85D0 for ; Wed, 23 Jan 2013 09:28:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id C619B9A71C4; Wed, 23 Jan 2013 09:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4SQgHPhtUgn; Wed, 23 Jan 2013 09:28:14 -0800 (PST) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 617F09A71A7; Wed, 23 Jan 2013 09:28:14 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-2022-jp From: Eve Maler In-Reply-To: <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> Date: Wed, 23 Jan 2013 09:28:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1499) Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:28:20 -0000 Tony took the words right out of my mouth. :-) Or, at least, the moment = someone expresses an actual need for the next piece of flexibility = (beyond "Wouldn't it be cool if..."* to "I have a customer that = needs..."), you're on the slope towards maybe benefiting from enabling = more and more of the HTTP verbs where only one or two made sense before. = One way to do this is to work within a pure-REST framework but say that = only POST and GET are supported, with all others producing an error. = Over time, if DELETE is needed, it's easier to turn it on. Eve * "The only thing worse than generalizing from one example is = generalizing from no examples at all." Not sure if Tony is expressing an = actual need or not. On 23 Jan 2013, at 9:21 AM, Anthony Nadalin = wrote: > Registration has to work in a multi-tenant environment so flexibility = is needed >=20 > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Wednesday, January 23, 2013 9:18 AM > To: Anthony Nadalin > Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection >=20 > Because then nobody would know how to actually use the thing. >=20 > In my opinion, this is a key place where this kind of flexibility is a = very bad thing. Registration needs to work one fairly predictable way. >=20 > -- Justin >=20 > On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >> Why not just have a physical and logical endpoint options >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf=20 >> Of Justin Richer >> Sent: Wednesday, January 23, 2013 7:47 AM >> To: Nat Sakimura >> Cc: Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>=20 >> Which brings up an interesting question for the Registration doc: = right now, it's set up as a single endpoint with three operations. We = could instead define three endpoints for the different operations. >>=20 >> I've not been keen to make that deep of a cutting change to it, but = it would certainly be cleaner and more RESTful API design. What do = others think? >>=20 >> -- Justin >>=20 >>=20 >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>>=20 >>> =3Dnat via iPhone >>>=20 >>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer = =1B$B$N%a%C%;!<%8=1B(B: >>>=20 >>>> (CC'ing the working group) >>>>=20 >>>> I'm not sure what the "action/operation" flag would accomplish. The = idea behind having different endpoints in OAuth is that they each do = different kinds of things. The only "action/operation" that I had = envisioned for the introspection endpoint is introspection itself: "I = have a token, what does it mean?" >>>>=20 >>>> Note that client_id and client_secret *can* already be used at this = endpoint if the server supports that as part of their client credentials = setup. The examples use HTTP Basic with client id and secret right now. = Basically, the client can authenticate however it wants, including any = of the methods that OAuth2 allows on the token endpoint. It could also = authenticate with an access token. At least, that's the intent of the = introspection draft -- if that's unclear, I'd be happy to accept = suggested changes to clarify this text. >>>>=20 >>>> -- Justin >>>>=20 >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>>=20 >>>>> This spec is looking good.. >>>>>=20 >>>>> One thing I would like to recommend is to add "action"/"operation"=20= >>>>> to the request. (and potentially add client_id and client_secret) >>>>>=20 >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | = revoke ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>>=20 >>>>> And for the OAuth client information, it should be an optional = parameter (in case it is a public client or client is authenticated with = SSL mutual authentication). >>>>>=20 >>>>> Please consider. >>>>>=20 >>>>> ShiuFun >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From eve@xmlgrrl.com Wed Jan 23 09:29:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4597E21F85EA for ; Wed, 23 Jan 2013 09:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ksO4fbj5-W7 for ; Wed, 23 Jan 2013 09:29:54 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12A21F85D0 for ; Wed, 23 Jan 2013 09:29:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 4F25E9A72B5; Wed, 23 Jan 2013 09:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQoNmi4N4Xr3; Wed, 23 Jan 2013 09:29:50 -0800 (PST) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 10DF49A72A6; Wed, 23 Jan 2013 09:29:50 -0800 (PST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eve Maler In-Reply-To: Date: Wed, 23 Jan 2013 09:29:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:29:55 -0000 Rudely responding to myself: I'm not saying this approach should = definitely be taken, just that it's a good idea to spend 15 minutes = looking at the benefits and downsides of it vs. the current laser-focus = approach. Eve On 23 Jan 2013, at 9:28 AM, Eve Maler wrote: > Tony took the words right out of my mouth. :-) Or, at least, the = moment someone expresses an actual need for the next piece of = flexibility (beyond "Wouldn't it be cool if..."* to "I have a customer = that needs..."), you're on the slope towards maybe benefiting from = enabling more and more of the HTTP verbs where only one or two made = sense before. One way to do this is to work within a pure-REST framework = but say that only POST and GET are supported, with all others producing = an error. Over time, if DELETE is needed, it's easier to turn it on. >=20 > Eve >=20 > * "The only thing worse than generalizing from one example is = generalizing from no examples at all." Not sure if Tony is expressing an = actual need or not. >=20 > On 23 Jan 2013, at 9:21 AM, Anthony Nadalin = wrote: >=20 >> Registration has to work in a multi-tenant environment so = flexibility is needed >>=20 >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org]=20 >> Sent: Wednesday, January 23, 2013 9:18 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>=20 >> Because then nobody would know how to actually use the thing. >>=20 >> In my opinion, this is a key place where this kind of flexibility is = a very bad thing. Registration needs to work one fairly predictable way. >>=20 >> -- Justin >>=20 >> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>> Why not just have a physical and logical endpoint options >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf=20 >>> Of Justin Richer >>> Sent: Wednesday, January 23, 2013 7:47 AM >>> To: Nat Sakimura >>> Cc: Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>>=20 >>> Which brings up an interesting question for the Registration doc: = right now, it's set up as a single endpoint with three operations. We = could instead define three endpoints for the different operations. >>>=20 >>> I've not been keen to make that deep of a cutting change to it, but = it would certainly be cleaner and more RESTful API design. What do = others think? >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>> "Action" goes against REST principle. >>>> I do not think it is a good idea. >>>>=20 >>>> =3Dnat via iPhone >>>>=20 >>>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer = =1B$B$N%a%C%;!<%8=1B(B: >>>>=20 >>>>> (CC'ing the working group) >>>>>=20 >>>>> I'm not sure what the "action/operation" flag would accomplish. = The idea behind having different endpoints in OAuth is that they each do = different kinds of things. The only "action/operation" that I had = envisioned for the introspection endpoint is introspection itself: "I = have a token, what does it mean?" >>>>>=20 >>>>> Note that client_id and client_secret *can* already be used at = this endpoint if the server supports that as part of their client = credentials setup. The examples use HTTP Basic with client id and secret = right now. Basically, the client can authenticate however it wants, = including any of the methods that OAuth2 allows on the token endpoint. = It could also authenticate with an access token. At least, that's the = intent of the introspection draft -- if that's unclear, I'd be happy to = accept suggested changes to clarify this text. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>> Justin, >>>>>>=20 >>>>>> This spec is looking good.. >>>>>>=20 >>>>>> One thing I would like to recommend is to add = "action"/"operation"=20 >>>>>> to the request. (and potentially add client_id and = client_secret) >>>>>>=20 >>>>>> So the request will be like : >>>>>> token REQUIRED >>>>>> operation (wording to be determine) OPTIONAL inquire (default) | = revoke ... >>>>>> resource_id OPTIONAL >>>>>> client_id OPTIONAL >>>>>> client_secret OPTIONAL >>>>>>=20 >>>>>> And for the OAuth client information, it should be an optional = parameter (in case it is a public client or client is authenticated with = SSL mutual authentication). >>>>>>=20 >>>>>> Please consider. >>>>>>=20 >>>>>> ShiuFun >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From jricher@mitre.org Wed Jan 23 09:31:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4221F8735 for ; Wed, 23 Jan 2013 09:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHVgGfePfdYa for ; Wed, 23 Jan 2013 09:31:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8121F85EA for ; Wed, 23 Jan 2013 09:31:15 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E854C531095C; Wed, 23 Jan 2013 12:31:14 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AD7D05310981; Wed, 23 Jan 2013 12:31:14 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 12:31:14 -0500 Message-ID: <51001E4E.6000201@mitre.org> Date: Wed, 23 Jan 2013 12:30:54 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Eve Maler References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:31:16 -0000 But it's already not a fully RESTful setup, and it's not really meant to be as it stands. I realize that's how the original UMA registration spec did things, but the rest of OAuth doesn't work that way. I would rather it be parallel with the rest of the framework, all ideals aside. Which brings us back to my original point: OAuth2 does a pretty good job at splitting up different endpoints for different functions. That's what I'm asking here, more than anything else. Do we want to define three endpoints: - client registration endpoint - client update endpoint - client secret rotation endpoint As opposed to a single registration endpoint with a switch? -- Justin On 01/23/2013 12:28 PM, Eve Maler wrote: > Tony took the words right out of my mouth. :-) Or, at least, the moment someone expresses an actual need for the next piece of flexibility (beyond "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on the slope towards maybe benefiting from enabling more and more of the HTTP verbs where only one or two made sense before. One way to do this is to work within a pure-REST framework but say that only POST and GET are supported, with all others producing an error. Over time, if DELETE is needed, it's easier to turn it on. > > Eve > > * "The only thing worse than generalizing from one example is generalizing from no examples at all." Not sure if Tony is expressing an actual need or not. > > On 23 Jan 2013, at 9:21 AM, Anthony Nadalin wrote: > >> Registration has to work in a multi-tenant environment so flexibility is needed >> >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Wednesday, January 23, 2013 9:18 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Because then nobody would know how to actually use the thing. >> >> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. >> >> -- Justin >> >> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>> Why not just have a physical and logical endpoint options >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Justin Richer >>> Sent: Wednesday, January 23, 2013 7:47 AM >>> To: Nat Sakimura >>> Cc: Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>> >>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. >>> >>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? >>> >>> -- Justin >>> >>> >>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>> "Action" goes against REST principle. >>>> I do not think it is a good idea. >>>> >>>> =nat via iPhone >>>> >>>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>>> >>>>> (CC'ing the working group) >>>>> >>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>>>> >>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>>>> >>>>> -- Justin >>>>> >>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>> Justin, >>>>>> >>>>>> This spec is looking good.. >>>>>> >>>>>> One thing I would like to recommend is to add "action"/"operation" >>>>>> to the request. (and potentially add client_id and client_secret) >>>>>> >>>>>> So the request will be like : >>>>>> token REQUIRED >>>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>>>> resource_id OPTIONAL >>>>>> client_id OPTIONAL >>>>>> client_secret OPTIONAL >>>>>> >>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>>>> >>>>>> Please consider. >>>>>> >>>>>> ShiuFun >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > From Michael.Jones@microsoft.com Wed Jan 23 09:35:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D11921F8960 for ; Wed, 23 Jan 2013 09:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2uWhCS0n9wY for ; Wed, 23 Jan 2013 09:35:53 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6E21F8455 for ; Wed, 23 Jan 2013 09:35:52 -0800 (PST) Received: from BL2FFO11FD002.protection.gbl (10.173.161.203) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 23 Jan 2013 17:35:49 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 23 Jan 2013 17:35:49 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.245]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 23 Jan 2013 17:33:08 +0000 From: Mike Jones To: Justin Richer , Eve Maler Thread-Topic: [OAUTH-WG] Concerning OAuth introspection Thread-Index: AQHN+NLaih7lXcajhEyfjdYsUHHYWJhWGdYAgAD2SICAABiJAIAAAPsAgAAA0gCAAAHxgIAAAMAAgAAAnzg= Date: Wed, 23 Jan 2013 17:33:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A76440@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> , <51001E4E.6000201@mitre.org> In-Reply-To: <51001E4E.6000201@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A76440TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(479174001)(199002)(189002)(51704002)(13464002)(56776001)(31966008)(76482001)(54316002)(5343635001)(56816002)(44976002)(15202345001)(74502001)(512904001)(5343655001)(16406001)(54356001)(74662001)(47446002)(53806001)(49866001)(4396001)(33656001)(47736001)(51856001)(50986001)(47976001)(79102001)(16236675001)(46102001)(16297215001)(59766001)(77982001)(55846006)(6816006); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB038; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073515755F Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:35:54 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A76440TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable No, we want one endpoint. Keep it simple. ________________________________ From: Justin Richer Sent: 1/23/2013 9:31 AM To: Eve Maler Cc: Shiu Fun Poon; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection But it's already not a fully RESTful setup, and it's not really meant to be as it stands. I realize that's how the original UMA registration spec did things, but the rest of OAuth doesn't work that way. I would rather it be parallel with the rest of the framework, all ideals aside. Which brings us back to my original point: OAuth2 does a pretty good job at splitting up different endpoints for different functions. That's what I'm asking here, more than anything else. Do we want to define three endpoints: - client registration endpoint - client update endpoint - client secret rotation endpoint As opposed to a single registration endpoint with a switch? -- Justin On 01/23/2013 12:28 PM, Eve Maler wrote: > Tony took the words right out of my mouth. :-) Or, at least, the moment s= omeone expresses an actual need for the next piece of flexibility (beyond "= Wouldn't it be cool if..."* to "I have a customer that needs..."), you're o= n the slope towards maybe benefiting from enabling more and more of the HTT= P verbs where only one or two made sense before. One way to do this is to w= ork within a pure-REST framework but say that only POST and GET are support= ed, with all others producing an error. Over time, if DELETE is needed, it'= s easier to turn it on. > > Eve > > * "The only thing worse than generalizing from one example is generalizin= g from no examples at all." Not sure if Tony is expressing an actual need o= r not. > > On 23 Jan 2013, at 9:21 AM, Anthony Nadalin wrote= : > >> Registration has to work in a multi-tenant environment so flexibility i= s needed >> >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Wednesday, January 23, 2013 9:18 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Because then nobody would know how to actually use the thing. >> >> In my opinion, this is a key place where this kind of flexibility is a v= ery bad thing. Registration needs to work one fairly predictable way. >> >> -- Justin >> >> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>> Why not just have a physical and logical endpoint options >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Justin Richer >>> Sent: Wednesday, January 23, 2013 7:47 AM >>> To: Nat Sakimura >>> Cc: Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>> >>> Which brings up an interesting question for the Registration doc: right= now, it's set up as a single endpoint with three operations. We could inst= ead define three endpoints for the different operations. >>> >>> I've not been keen to make that deep of a cutting change to it, but it = would certainly be cleaner and more RESTful API design. What do others thin= k? >>> >>> -- Justin >>> >>> >>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>> "Action" goes against REST principle. >>>> I do not think it is a good idea. >>>> >>>> =3Dnat via iPhone >>>> >>>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer =1B$B$N= %a%C%;!<%8=1B(B: >>>> >>>>> (CC'ing the working group) >>>>> >>>>> I'm not sure what the "action/operation" flag would accomplish. The i= dea behind having different endpoints in OAuth is that they each do differe= nt kinds of things. The only "action/operation" that I had envisioned for t= he introspection endpoint is introspection itself: "I have a token, what do= es it mean?" >>>>> >>>>> Note that client_id and client_secret *can* already be used at this e= ndpoint if the server supports that as part of their client credentials set= up. The examples use HTTP Basic with client id and secret right now. Basica= lly, the client can authenticate however it wants, including any of the met= hods that OAuth2 allows on the token endpoint. It could also authenticate w= ith an access token. At least, that's the intent of the introspection draft= -- if that's unclear, I'd be happy to accept suggested changes to clarify = this text. >>>>> >>>>> -- Justin >>>>> >>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>> Justin, >>>>>> >>>>>> This spec is looking good.. >>>>>> >>>>>> One thing I would like to recommend is to add "action"/"operation" >>>>>> to the request. (and potentially add client_id and client_secret) >>>>>> >>>>>> So the request will be like : >>>>>> token REQUIRED >>>>>> operation (wording to be determine) OPTIONAL inquire (default) | re= voke ... >>>>>> resource_id OPTIONAL >>>>>> client_id OPTIONAL >>>>>> client_secret OPTIONAL >>>>>> >>>>>> And for the OAuth client information, it should be an optional param= eter (in case it is a public client or client is authenticated with SSL mut= ual authentication). >>>>>> >>>>>> Please consider. >>>>>> >>>>>> ShiuFun >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366A76440TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
No, we want o= ne endpoint.  Keep it simple.

From: Justin= Richer
Sent: 1/23/2= 013 9:31 AM
To: Eve Ma= ler
Cc: Shiu F= un Poon; oauth@ietf.org
Subject: Re: [O= AUTH-WG] Concerning OAuth introspection

But it's already not a fully RESTful setup, and it= 's not really meant to
be as it stands. I realize that's how the original UMA registration spec did things, but the rest of OAuth doesn't work that way. I would rather
it be parallel with the rest of the framework, all ideals aside.

Which brings us back to my original point: OAuth2 does a pretty good job at splitting up different endpoints for different functions. That's what I'm asking here, more than anything else. Do we want to define three
endpoints:

- client registration endpoint
- client update endpoint
- client secret rotation endpoint

As opposed to a single registration endpoint with a switch?

-- Justin

On 01/23/2013 12:28 PM, Eve Maler wrote:
> Tony took the words right out of my mouth. :-) Or, at least, the momen= t someone expresses an actual need for the next piece of flexibility (beyon= d "Wouldn't it be cool if..."* to "I have a customer that ne= eds..."), you're on the slope towards maybe benefiting from enabling more and more of the HTTP verbs where only one or two made s= ense before. One way to do this is to work within a pure-REST framework but= say that only POST and GET are supported, with all others producing an err= or. Over time, if DELETE is needed, it's easier to turn it on.
>
>        Eve
>
> * "The only thing worse than generalizing from one example is gen= eralizing from no examples at all." Not sure if Tony is expressing an = actual need or not.
>
> On 23 Jan 2013, at 9:21 AM, Anthony Nadalin <tonynad@microsoft.com&= gt; wrote:
>
>> Registration has to work in a multi-tenant environment  so fl= exibility is needed
>>
>> -----Original Message-----
>> From: Justin Richer [mailto:j= richer@mitre.org]
>> Sent: Wednesday, January 23, 2013 9:18 AM
>> To: Anthony Nadalin
>> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>
>> Because then nobody would know how to actually use the thing.
>>
>> In my opinion, this is a key place where this kind of flexibility = is a very bad thing. Registration needs to work one fairly predictable way.=
>>
>> -- Justin
>>
>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>> Why not just have a physical and logical endpoint options
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of Justin Richer
>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>> To: Nat Sakimura
>>> Cc: Shiu Fun Poon; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>> Which brings up an interesting question for the Registration d= oc: right now, it's set up as a single endpoint with three operations. We c= ould instead define three endpoints for the different operations.
>>>
>>> I've not been keen to make that deep of a cutting change to it= , but it would certainly be cleaner and more RESTful API design. What do ot= hers think?
>>>
>>> -- Justin
>>>
>>>
>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>> "Action" goes against REST principle.
>>>> I do not think it is a good idea.
>>>>
>>>> =3Dnat via iPhone
>>>>
>>>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer <jricher@mit= re.org> =1B$B$N%a%C%;!<%8=1B(B:
>>>>
>>>>> (CC'ing the working group)
>>>>>
>>>>> I'm not sure what the "action/operation" fla= g would accomplish. The idea behind having different endpoints in OAuth is = that they each do different kinds of things. The only "action/operatio= n" that I had envisioned for the introspection endpoint is introspecti= on itself: "I have a token, what does it mean?"
>>>>>
>>>>> Note that client_id and client_secret *can* already be= used at this endpoint if the server supports that as part of their client = credentials setup. The examples use HTTP Basic with client id and secret ri= ght now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the t= oken endpoint. It could also authenticate with an access token. At least, t= hat's the intent of the introspection draft -- if that's unclear, I'd be ha= ppy to accept suggested changes to clarify this text.
>>>>>
>>>>> -- Justin
>>>>>
>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>> Justin,
>>>>>>
>>>>>> This spec is looking good..
>>>>>>
>>>>>> One thing I would like to recommend is to add &quo= t;action"/"operation"
>>>>>> to the request.  (and potentially add client_= id and client_secret)
>>>>>>
>>>>>> So the request will be like :
>>>>>> token       &nb= sp;            =             &nb= sp;            REQUI= RED
>>>>>> operation (wording to be determine)  OPTIONAL= inquire (default) | revoke ...
>>>>>> resource_id      &nb= sp;            =             &nb= sp;    OPTIONAL
>>>>>> client_id       = ;            &n= bsp;            = ;         OPTIONAL
>>>>>> client_secret      &= nbsp;           &nbs= p;            &= nbsp;   OPTIONAL
>>>>>>
>>>>>> And for the OAuth client information, it should be= an optional parameter (in case it is a public client or client is authenti= cated with SSL mutual authentication).
>>>>>>
>>>>>> Please consider.
>>>>>>
>>>>>> ShiuFun
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https:= //www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>
> Eve Maler          &= nbsp;           &nbs= p;           http://www.xmlgrrl.com/blog
> +1 425 345 6756        &nb= sp;            =     http://www.twitter.com/xmlgrrl
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
 --_000_4E1F6AAD24975D4BA5B168042967394366A76440TK5EX14MBXC283r_-- From tonynad@microsoft.com Wed Jan 23 09:51:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7E21F8550 for ; Wed, 23 Jan 2013 09:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUY0+5xrkrpw for ; Wed, 23 Jan 2013 09:51:34 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5552921F854D for ; Wed, 23 Jan 2013 09:51:28 -0800 (PST) Received: from BY2FFO11FD006.protection.gbl (10.1.15.202) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 23 Jan 2013 17:51:18 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 23 Jan 2013 17:51:18 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 23 Jan 2013 17:50:38 +0000 Received: from mail26-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 17:47:31 +0000 Received: from mail26-tx2 (localhost [127.0.0.1]) by mail26-tx2-R.bigfish.com (Postfix) with ESMTP id 749741002EA for ; Wed, 23 Jan 2013 17:47:31 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI9371Id6eah542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h945hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h) Received-SPF: softfail (mail26-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail26-tx2 (localhost.localdomain [127.0.0.1]) by mail26-tx2 (MessageSwitch) id 1358963221627740_22763; Wed, 23 Jan 2013 17:47:01 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.237]) by mail26-tx2.bigfish.com (Postfix) with ESMTP id 946033804EC; Wed, 23 Jan 2013 17:47:01 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 17:46:58 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.257.4; Wed, 23 Jan 2013 17:46:58 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.601.3; Wed, 23 Jan 2013 17:46:55 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Wed, 23 Jan 2013 17:46:55 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] Concerning OAuth introspection Thread-Index: AQHN+NM+tPsrUD5ZNEKigQoex6SLPZhWGdUAgAD2SICAABhS8IAAATIAgAAAnxCAAAHJgIAABNmw Date: Wed, 23 Jan 2013 17:46:54 +0000 Message-ID: <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> In-Reply-To: <51001D61.1060000@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.132] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464002)(479174001)(24454001)(377454001)(47976001)(50986001)(33646001)(56776001)(6806001)(56816002)(51856001)(76482001)(23736001)(53806001)(59766001)(5343655001)(49866001)(50466001)(47736001)(79102001)(550184003)(46102001)(47776002)(47446002)(74502001)(44976002)(31966008)(4396001)(74662001)(54356001)(77982001)(54316002)(16676001)(6816006)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073515755F Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:51:35 -0000 It will not work the way you have it, as people do multi-tendency different= and they are already stuck with the method that they have chosen, so they = need the flexability, to restrict this is nuts as people won't use it. -----Original Message----- From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Wednesday, January 23, 2013 9:27 AM To: Anthony Nadalin Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection I completely disagree with this assessment. Multi-tenancy will work just fi= ne (or even better) if everyone uses the same pattern. Telling someone "it = might be three different urls or it might be all one url with a parameter" = is just asking for a complete disaster. What does the flexibility of allowi= ng two approaches actually accomplish? You can argue about the merits of either approach, but having both as unspe= cified options for registration, which is meant to help things get going in= a cold-boot environment, is just plain nuts. -- Justin On 01/23/2013 12:21 PM, Anthony Nadalin wrote: > Registration has to work in a multi-tenant environment so flexibility=20 > is needed > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Wednesday, January 23, 2013 9:18 AM > To: Anthony Nadalin > Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > Because then nobody would know how to actually use the thing. > > In my opinion, this is a key place where this kind of flexibility is a ve= ry bad thing. Registration needs to work one fairly predictable way. > > -- Justin > > On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >> Why not just have a physical and logical endpoint options >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Justin Richer >> Sent: Wednesday, January 23, 2013 7:47 AM >> To: Nat Sakimura >> Cc: Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Which brings up an interesting question for the Registration doc: right = now, it's set up as a single endpoint with three operations. We could inste= ad define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it w= ould certainly be cleaner and more RESTful API design. What do others think= ? >> >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =3Dnat via iPhone >>> >>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer =1B$B$N%= a%C%;!<%8=1B(B: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The id= ea behind having different endpoints in OAuth is that they each do differen= t kinds of things. The only "action/operation" that I had envisioned for th= e introspection endpoint is introspection itself: "I have a token, what doe= s it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this en= dpoint if the server supports that as part of their client credentials setu= p. The examples use HTTP Basic with client id and secret right now. Basical= ly, the client can authenticate however it wants, including any of the meth= ods that OAuth2 allows on the token endpoint. It could also authenticate wi= th an access token. At least, that's the intent of the introspection draft = -- if that's unclear, I'd be happy to accept suggested changes to clarify t= his text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation"=20 >>>>> to the request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | rev= oke ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parame= ter (in case it is a public client or client is authenticated with SSL mutu= al authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > From jricher@mitre.org Wed Jan 23 10:05:43 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AE621F8AD6 for ; Wed, 23 Jan 2013 10:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba0Iv8mB1iJH for ; Wed, 23 Jan 2013 10:05:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E711821F86A3 for ; Wed, 23 Jan 2013 10:05:34 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BD4AC1F1E1D; Wed, 23 Jan 2013 13:05:30 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE3BD1F1E19; Wed, 23 Jan 2013 13:05:30 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 13:05:29 -0500 Message-ID: <51002656.2050900@mitre.org> Date: Wed, 23 Jan 2013 13:05:10 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Anthony Nadalin References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------030102000409050306020201" X-Originating-IP: [129.83.31.58] Cc: Shiu Fun Poon , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:05:43 -0000 --------------030102000409050306020201 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I am very confused, and I need someone to explain to me what I am missing. Why won't it work to just pick one? What are people "already stuck with" that this would affect? It's not like we're trying to unseat a well-established protocol with a wide installation base here. How will giving people the choice between: /oauth/register?operation=client_register /oauth/register?operation=client_update /oauth/register?operation=rotate_secret and: /oauth/client_register /oauth/client_update /oauth/rotate_secret help multitenancy? How does it even affect that use case? Consider that the base URL for all of these is completely up to the host environment (nothing is bound to the root URL). Consider that clients still have to know what the URL (or URLs) are, in either case. Consider that clients still need to know how to manage all the parameters and responses. If anything, keeping it the way that it is with a single URL could be argued to help multitenancy because setting up routing to multiple URL endpoints can sometimes be problematic in hosted environments. However, OAuth already defines a bunch of endpoints, and we have to define at least one more with this extension, so I'm not convinced that having three with specific functions is really any different from having one with three functions from a development, deployment, and implementation perspective. I can tell you from experience that in our own server code, the difference is trivial. (And from OAuth1 experience, you can always have a query parameter as part of your endpoint URL if you need to. You might hate yourself for doing it that way, but nothing says your base URL can't already have parameters on it. A client just needs to know how to appropriately tack its parameters onto an existing URL, and any HTTP client worth its salt will know how to augment a query parameter set with new items.) The *real* difference between the two approaches is a philosophical design one. The former overloads one URL with multiple functions switched by a flag, the latter uses the URL itself as an implicit flag. Under the hood, these could (and in many cases will) be all served by the same chunks of code. The only difference is how this switch in functionality is presented. With that said, can somebody please explain to me how allowing *both* of these as options simultaneously (what I understand Tony to be suggesting) is a good idea, or how multitenancy even comes into play? Because I am completely not seeing how these are related. Thanks, -- Justin On 01/23/2013 12:46 PM, Anthony Nadalin wrote: > It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it. > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Wednesday, January 23, 2013 9:27 AM > To: Anthony Nadalin > Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > > I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish? > > You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts. > > > -- Justin > > > > On 01/23/2013 12:21 PM, Anthony Nadalin wrote: >> Registration has to work in a multi-tenant environment so flexibility >> is needed >> >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Wednesday, January 23, 2013 9:18 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> Because then nobody would know how to actually use the thing. >> >> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. >> >> -- Justin >> >> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>> Why not just have a physical and logical endpoint options >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> Behalf Of Justin Richer >>> Sent: Wednesday, January 23, 2013 7:47 AM >>> To: Nat Sakimura >>> Cc: Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>> >>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. >>> >>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? >>> >>> -- Justin >>> >>> >>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>> "Action" goes against REST principle. >>>> I do not think it is a good idea. >>>> >>>> =nat via iPhone >>>> >>>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>>> >>>>> (CC'ing the working group) >>>>> >>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>>>> >>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>>>> >>>>> -- Justin >>>>> >>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>> Justin, >>>>>> >>>>>> This spec is looking good.. >>>>>> >>>>>> One thing I would like to recommend is to add "action"/"operation" >>>>>> to the request. (and potentially add client_id and client_secret) >>>>>> >>>>>> So the request will be like : >>>>>> token REQUIRED >>>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>>>> resource_id OPTIONAL >>>>>> client_id OPTIONAL >>>>>> client_secret OPTIONAL >>>>>> >>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>>>> >>>>>> Please consider. >>>>>> >>>>>> ShiuFun >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> > > > --------------030102000409050306020201 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit I am very confused, and I need someone to explain to me what I am missing. Why won't it work to just pick one? What are people "already stuck with" that this would affect? It's not like we're trying to unseat a well-established protocol with a wide installation base here.

How will giving people the choice between:

/oauth/register?operation=client_register
/oauth/register?operation=client_update
/oauth/register?operation=rotate_secret

and:

/oauth/client_register
/oauth/client_update
/oauth/rotate_secret

help multitenancy? How does it even affect that use case? Consider that the base URL for all of these is completely up to the host environment (nothing is bound to the root URL). Consider that clients still have to know what the URL (or URLs) are, in either case. Consider that clients still need to know how to manage all the parameters and responses.

If anything, keeping it the way that it is with a single URL could be argued to help multitenancy because setting up routing to multiple URL endpoints can sometimes be problematic in hosted environments. However, OAuth already defines a bunch of endpoints, and we have to define at least one more with this extension, so I'm not convinced that having three with specific functions is really any different from having one with three functions from a development, deployment, and implementation perspective. I can tell you from experience that in our own server code, the difference is trivial. (And from OAuth1 experience, you can always have a query parameter as part of your endpoint URL if you need to. You might hate yourself for doing it that way, but nothing says your base URL can't already have parameters on it. A client just needs to know how to appropriately tack its parameters onto an existing URL, and any HTTP client worth its salt will know how to augment a query parameter set with new items.)

The *real* difference between the two approaches is a philosophical design one. The former overloads one URL with multiple functions switched by a flag, the latter uses the URL itself as an implicit flag. Under the hood, these could (and in many cases will) be all served by the same chunks of code. The only difference is how this switch in functionality is presented.


With that said, can somebody please explain to me how allowing *both* of these as options simultaneously (what I understand Tony to be suggesting) is a good idea, or how multitenancy even comes into play? Because I am completely not seeing how these are related.

Thanks,
 -- Justin



On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?

You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.


-- Justin



On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

Registration has to work in a multi-tenant environment  so flexibility 
is needed

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

Because then nobody would know how to actually use the thing.

In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.

-- Justin

On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

Why not just have a physical and logical endpoint options

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 
Behalf Of Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.

I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?

-- Justin


On 01/22/2013 08:05 PM, Nat Sakimura wrote:

"Action" goes against REST principle.
I do not think it is a good idea.

=nat via iPhone

Jan 23, 2013 4:00、Justin Richer <jricher@mitre.org> のメッセージ:


(CC'ing the working group)

I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

 -- Justin

On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

Justin,

This spec is looking good..

One thing I would like to recommend is to add "action"/"operation" 
to the request.  (and potentially add client_id and client_secret)

So the request will be like :
token                                             REQUIRED
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
resource_id                                    OPTIONAL
client_id                                         OPTIONAL
client_secret                                   OPTIONAL

And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

Please consider.

ShiuFun

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

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

--------------030102000409050306020201-- From gffletch@aol.com Wed Jan 23 10:05:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EAE21F872E for ; Wed, 23 Jan 2013 10:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxwyi6O2Oz-v for ; Wed, 23 Jan 2013 10:05:49 -0800 (PST) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D321F869B for ; Wed, 23 Jan 2013 10:05:49 -0800 (PST) Received: from mtaout-da02.r1000.mx.aol.com (mtaout-da02.r1000.mx.aol.com [172.29.51.130]) by imr-ma03.mx.aol.com (Outbound Mail Relay) with ESMTP id 60DAE1C000128; Wed, 23 Jan 2013 13:05:48 -0500 (EST) Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 75258E000100; Wed, 23 Jan 2013 13:05:47 -0500 (EST) Message-ID: <5100267C.1010400@aol.com> Date: Wed, 23 Jan 2013 13:05:48 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com> <9034B9E7-B35F-4647-AF59-0DD222A3C60C@xmlgrrl.com> In-Reply-To: <9034B9E7-B35F-4647-AF59-0DD222A3C60C@xmlgrrl.com> Content-Type: multipart/alternative; boundary="------------040801020305020708010302" x-aol-global-disposition: G X-AOL-VSS-INFO: 5400.1158/87573 X-AOL-VSS-CODE: clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1358964348; bh=vnTKetfdjBJ+sK+qlicrZkTqG6MqOm6xw84X5i/uXYg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=JJ1LrD/0tdVqG4vEFWBXgg4mzbNMiMKgRbXGHGnoso2IKsTOruumy1nZolHr6RN+b sbgbeDggiA9C6ILX00t8QODyKMzl41YFZgj0KSdI+U5tpQYOuBkGs1GnbGZbzo4N7d srGMJCaRhBz07MEMDgKHP8cSJjjaN4HD9XWBtY2A= X-AOL-SCOLL-SCORE: 1:2:419734336:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d33825100267b7661 X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:05:52 -0000 This is a multi-part message in MIME format. --------------040801020305020708010302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In addition, UMA also defines a was for the RS to instruct the client on what to present to the AS in order to receive a token that will work at the RS. At the moment this flow is UMA specific but could probably be abstracted into a general pattern. Also, there are really three parties that have to agree in order for the client to get access to the protected resource. a. the client -- it may only support bearer tokens and not holder-of-key b. the RS -- it may only allow bearer tokens from trusted clients c. the AS -- it may only issue bearer tokens Developing generic negotiation amongst these parties may be overkill since in most cases the client know what RS it will be talking to and potentially even the authorizations server(s) as well. Given that some pre-knowledge is probably in play, a simple solution may be to allow the client to register via the dynamic registration proposal the token types it supports and then the AS can use that data as a filtering mechanism when the client asks for a token. Thanks, George On 1/23/13 12:23 PM, Eve Maler wrote: > FWIW, some of us have made a proposal for exactly this type of > standardized AS/RS communication: > > http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00 > > The UMA profile refers normatively to this spec, and at that higher > profile-specific level, it has an extensive set of AS configuration > data that includes a way to declare token types supported. It could > make sense for an RS to register its preferences for token types > supported among those declared in the AS config data. Should this > "preferred token type" semantic should be sedimented down to the > "draft-hardjono-oauth-resource-reg" level? > > Eve > > On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena > wrote: > >> Think about a distributed setup. You have single Authorization Server >> and multiple Resource Servers. >> >> Although OAuth nicely decouples AS from RS - AFAIK there is no >> standard established for communication betweens AS and RS - how to >> declare metadata between those. >> >> Also there can be Resource Servers which support multiple token >> types. It could vary on APIs hosted in a given RS. >> >> Thanks & regards, >> -Prabath >> >> >> On Mon, Jan 21, 2013 at 10:48 AM, > > wrote: >> >> >> The token type shoulbe decided by resource server, which consumes >> access token. >> Client just re-tell the requested token type to AS. >> Client should not specify the token type. >> >> >> oauth-bounces@ietf.org ?? >> 2013-01-21 13:08:39: >> >> >> > This is true. It's possible for the AS to vary it's behavior on >> > scope name, but it's presumed the AS and RS have an agreement of >> > what token type is in play. Likely a good extension to the spec. >> >> > >> > From: Prabath Siriwardena > > >> > To: "oauth@ietf.org WG" > > >> > Sent: Sunday, January 20, 2013 7:28 PM >> > Subject: [OAUTH-WG] Client cannot specify the token type it needs >> >> > >> > Although token type is extensible according to the OAuth core >> > specification - it is fully governed by the Authorization Server. >> > >> > There can be a case where a single AS supports multiple token >> types >> > based on client request. >> > >> > But currently we don't have a way the client can specify (or at >> > least suggest) which token type it needs in the OAuth access >> token request ? >> > >> > Is this behavior intentional ? or am I missing something... >> > >> > Thanks & Regards, >> > Prabath >> > >> > Mobile : +94 71 809 6732 >> > >> > http://blog.facilelogin.com >> > http://RampartFAQ.com >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- George Fletcher --------------040801020305020708010302 Content-Type: multipart/related; boundary="------------040305070601040507020805" --------------040305070601040507020805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In addition, UMA also defines a was for the RS to instruct the client on what to present to the AS in order to receive a token that will work at the RS. At the moment this flow is UMA specific but could probably be abstracted into a general pattern.

Also, there are really three parties that have to agree in order for the client to get access to the protected resource.
   a. the client -- it may only support bearer tokens and not holder-of-key
   b. the RS -- it may only allow bearer tokens from trusted clients
   c. the AS -- it may only issue bearer tokens

Developing generic negotiation amongst these parties may be overkill since in most cases the client know what RS it will be talking to and potentially even the authorizations server(s) as well.  Given that some pre-knowledge is probably in play, a simple solution may be to allow the client to register via the dynamic registration proposal the token types it supports and then the AS can use that data as a filtering mechanism when the client asks for a token.

Thanks,
George
On 1/23/13 12:23 PM, Eve Maler wrote:
FWIW, some of us have made a proposal for exactly this type of standardized AS/RS communication:


The UMA profile refers normatively to this spec, and at that higher profile-specific level, it has an extensive set of AS configuration data that includes a way to declare token types supported. It could make sense for an RS to register its preferences for token types supported among those declared in the AS config data. Should this "preferred token type" semantic should be sedimented down to the "draft-hardjono-oauth-resource-reg" level?

Eve

On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

Think about a distributed setup. You have single Authorization Server and multiple Resource Servers.

Although OAuth nicely decouples AS from RS - AFAIK there is no standard established for communication betweens AS and RS - how to declare metadata between those.

Also there can be Resource Servers which support multiple token types. It could vary on APIs hosted in a given RS.

Thanks & regards,
-Prabath


On Mon, Jan 21, 2013 at 10:48 AM, <zhou.sujing@zte.com.cn> wrote:

The token type shoulbe decided by resource server, which consumes access token.
Client just re-tell the requested token type to AS.
Client should not specify the token type.


oauth-bounces@ietf.org 写于 2013-01-21 13:08:39:


> This is true.  It's possible for the AS to vary it's behavior on
> scope name, but it's presumed the AS and RS have an agreement of
> what token type is in play.  Likely a good extension to the spec.
>
> From: Prabath Siriwardena <prabath@wso2.com>
> To: "oauth@ietf.org WG" <oauth@ietf.org>
> Sent: Sunday, January 20, 2013 7:28 PM
> Subject: [OAUTH-WG] Client cannot specify the token type it needs
>
> Although token type is extensible according to the OAuth core
> specification - it is fully governed by the Authorization Server.
>
> There can be a case where a single AS supports multiple token types
> based on client request.
>
> But currently we don't have a way the client can specify (or at
> least suggest) which token type it needs in the OAuth access token request ?
>
> Is this behavior intentional ? or am I missing something...
>
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--
Thanks & Regards,
Prabath

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


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



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

--
George Fletcher
--------------040305070601040507020805 Content-Type: image/png; name="XeC" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="XeC" iVBORw0KGgoAAAANSUhEUgAAAWcAAABxEAYAAABZ0L78AAAABmJLR0TIyMjIyMhnRJJpAAAA CXBIWXMAAABIAAAASABGyWs+AACAAElEQVR42uzddYAUV77w/W9VtY67wuDu7hrcJWiQ4BAC IUAIEiAEDQQJCcEDwT24BHfXIIPPwBjj1tNadd4/7mVnn5vdZ7Mb9ube5+3PP0NVnf7VOdV9 ml+dOlUtXbly5cqVK0Lg5ubm5ubm5ubm5vZ36d7+o1atWrVq1fqzq+Pm5ubm5ubm5ub2P8vV q1evXr0K8p9dETc3Nzc3Nzc3N7f/DdyJs5ubm5ubm5ubm9vv4E6c3dzc3Nzc3Nzc3H4Hd+Ls 5ubm5ubm5ubm9ju4E2c3Nzc3Nzc3Nze330H3RwNYrXa7zfafCzLgQEcySKHslBqBGCOFSX6g HXCWdIQB0Zbi1nUgylq6pVUEW+03ya+8QL86wN/vGBjzgq5HTgdXJ/MR8yVQxnPReBykH8hg O6iL5BL61yAdztub+TU4O1nTs4eC8Xzw9aifQIy1xVqSwfHR80N3Z4BYKTdSDgD3XcvUIaC9 zlmeuQTUQ9JopRNoeeojc2Gwfpg1zxkLecNzymYdhLziuZE5wyAv2dZfzQaLtyPDdhksL6wF c9aDfZB9srUX6J97r/OzgTTBO8QvHSyJmaezsiB3WRapPcHVWVotVwJRnc666qBN9/wxoCDY Dubl5R0Dxd9U1HwfsiZmeGR8Dx5nQu5GZIEWr2zwigGzl2eU9w4QJp4ZK4P+O+Mm+SCoM10N tV+g1uA6H1RoArWkyiXCX4BWxrXQdR+kdaIdkSD8pWBxGaSmmAkCkYcLFwDS//FGKvzHIwnv IyEDAXzGZ6CbLS1WBsHr60mP0tbDofVnO15ZB8Kof+EaDb0nvzejcVNwTpQXS5Gg7RYz8ATf F57fGwuAvETyl/eA7rqph/kEnJx2KvlQI8gsYLWp7eFpYvKiy0vA603wjNzeYH+U6KH8Co+i E8q+WAPSdV172ybIbpY6VVyD7EG5Y30+A+/buq8N9yD4W//kQjeg5M4iOWXXgbW7fYJuIaSF JwfmhUJUk9BlYhhYx6s5lklQ+IhHXmRN8Otf6MvIaZDXzPos7Svw8/foFLgfLjeN/vLATrAu U7ulNoWBES0HTZsNjp/k7spHUH5zyY9CN8GTL59/l1MRDo25fPLbGZDtY7Xc6AFeHeRRvn6Q 8iC5so83zLs/KWr59D+7m7u5ubm5ubm9C+9uxFlGoAFZkgk/oC6auAjSEpEgVJBGiNuyL2DT bxGXwPkobXFSCzAG+BTwugiav/aRVh14T1fa/A3oL8qq1znQ/ES0uhSERUxzBoJyQ4oQdYEL Xq/9u4Bhpnd84IegTXJ96LgEnBT1teogZNdOe1Nw+iT7xe4B9aO8DzM6gTrC2dz2KYh5Wck5 E8ExPOtI+k2QLinP1RkgEnU35B6grDLcMwwDQ0NTln4+eDo9b5gPg/mYeaVHdTB8pJugfwWK pyvd8THonUJxjgDTatNlfSlQ3pfC5CCQN7pOuQJAq+ysYisOShf1Y3t90CfxuSsITL31XbWJ YEzzsHmtA2mUo569O3gP8zxqngTigFrB2RyCVoZ0CzgLnt/6HAkzgc5Lr9PfgScjonNjjoJl iqWqTQP5A2Wc+BW0gdJXUghI89hJGIgkKRALAOK/pMz/QQUEUFwKRYBUm3rSenC2Ea9cz6HA jHBvvwbQ39Khe7ND0PBgpZRyayHo5yACjHB5yE39vS/h0fAXbe5Xh+yCGYMsfsBNeaHcBQyd GSt9B+Ym3gkRo0EJU8rYdRDyxu8bqwVsSrbQe0L1vqW2tW8NfrlSYrFTkHU0bX9gOvgO86gR WBGKdAjsXmwlOHMcxYtLkH0hJ49n8KDoS+WuHoosCK/n1RaKOiIs5SvCrUkPD2eOgjf2jM2Z 00C3Xxr5uj54bZdrOpdBQq3kQ89+hNsVHtT+eQZoyyxt/ItAWLhH485bQdfC2Fc3GLzOmEfr oiDZmbwsMwZ+/fS57/GrkNU8q+/jk+Bqk5Oemwvp9xJHZxaBvNG2GNfJP7t7u7m5ubm5ub1L f3jE+S+cSAiQigibFATiMk/FYtDqS/fETJCr6Jco50HdYYm3VgGuyWsNs0CeY+igmwvK58ow 9QqIe3IfURu0QXJ/rSxIYWKFbgwIf0049SCNcS6wDAWpjH6Sx2BQZ4rxLito5eMbPa4JWpL9 jnMrSL/K83VrwHDOc5j/FHAespy3pIB01lVYiQOXv7OvcwK4PrU3sn8JaoTSQtQHwwJ9K70H GLZ6mb3rgxxlG+GYBij2u7a24DVfai2dBumCbJWMoM51TbSXAf1j+QoB4Ngmj9EGgHmMh9kc DYzLKWDZC2oVbYo2DcQSmzmnN0gbtSBlKThViyn7M/AsZhjouRxQsLs+Bu2UdWP6TMAgX9NH gXVorvymJugXexwODgDf5IBi/jMg616GLWMRvBz76suMIKh8omzLUF9wxbgGawD95Y+ZB2gi TVoESMgilv9Ikv/PBFrCAGgilmsgHkvl+RmkB+I7xQJartpYmwXWp9TWXkEJW+HRBc2Q2D3t cHI5qNWzwq7iXSGsV0BaaDLYNPWQ6xxk/pJ93/ENPBydVuT5T5D+te3n12XgzrXYyAedIPV7 S2KqN6gPcublpIFPqL74nQzQp/ptdK6BJkuKdKpYE1wVtMJyIpz75N65pyaQt+p+DKkCUlmS jfHQeEuVck33QpW5hb2rJUD2vchjiZeg4cw6Uvde8OCr6DfPEuBJk4eW7a/hRaB9neMyZMbo A18MBe+5qKbpUKNE+YuNa4D/p5Gp/rHg3ybQ37szpC9+MyxrPKSuzjKK7+D5qicfJVUD0Ug7 ap4ItnpZmQVngytR9clJhMwy3Hr9KQAN/+xO7ubm5ubm5vZuvLvEWeY/kjE/sjEBB6VmvABd SzGSnuAK1m44DaAsF+fETVBuF6tYIhfUb8R85x1QTjt7ZX0AYrx+gMkX5BdaqugCoo7cVtcX pP5yPLNAi8udnKGAdjmvY3In0O3TV/HIBdsrNVaMBK1vyvD45uDKtc63ZQJTpO+UmyD3U97j BFDQMNb7HugeSsf15cB7j9cnSlFwtHPskbqDs4g2Qu0MroVqcbzBsEbsMKaBq682SNwGzU6w NBm8intV0/UBe7Z1efYPIN9w7nSlgmdp5YD8AuR75mvGSJALqxlSKZBW2Ws5G4N1j7OlrRiw WeqjtAT7pFy95S7oU/RqzmHgrsf5oApg7O7qnTMUnCfsr3gOWa6cD9K6g2fVwAFpM0FfNkwr fQS85/pu9NsLD799Eh/fGkp/V3R7UCnQzdR5iQ6gThIfy0aQ60me4hcQ90QeCqAgof0f76DA CQh8KQJME/XFK5CbyQqDIDc2d5KtFlydfLvK7a6QWDbzbNx9yK2bm6B1gqpvKn1UahKYeno0 CgqFmMWJvV/0hrXWQz/t2Ae66rpDedvANVn/fWpfKPZrYJ+CyfBg9osHPovAsc9VxPoKvG8m 1bxfGSKC/duU+RIyT9hbpPlAkXEBSxstg9cj39Q+/AV8sKa5q0Vv8Em1bzGMhXJRZTyLroTo kvFpT3zgdVL8/tgMsNyxrbX0gpfWN0WPXQXXOjFPOQn+5a2piZdBbLauD58JZeqVLVhhOQQF Bo30OQeev+g06xNIWh9/I1UHSVszv3t1El7JiRHPZ0NQbNgVfoWsFS/C0lcBh/R26Qhklck8 bewC8j2fzp6fAzUZ82d3cjc3Nzc3N7d3490mzjKIZ7hEAkjliSQVhI2pcgjIH9NLmgeiqldP 8w6QrnBUPxHkQbJVcoD8xNA2IhCkAPS6bBCz8GUHSC5xXOwDbVxeXMpC4LkuyNsP5CseVwK+ BtU/u9vrYSBZpBpqPVDUgArh00H7KdESkwVaM1cTdRIo9z2tIbHAbZPqcQtEet4P6gQQFdQv 5UVgsEqvtGiQIrQcLQmkXHthlwVcBeRhzqWgNFIqyhmgO6LlKVNAihFPxRwQkjJdPwI4Sx3R GswZorPWBtREusmlQe5tfmK6D/I85QedF+Cyhom6YG3naqdOBy1F2qh8CbZES7BtHhjO4Mpa Dcp63Xhegvm54Zm5K6QXzFhlKQq6H4nR1kO2VepijASfwOBnURLkDrO2dV2F1/o4OX0OlGhT YkBwZVBT7b+ooSCeSwvwB2zA3/qBdQnQABVNKgLSHmaKlSCOaT3FWjCfMC0ymqBFcL2ntdfA 0eYXD9wdCbuOXFi1/SAc4/6Ss92h1s3iI8psBl1zSfW1QsGRvkXCTkK53UXrVF4KKcXzZr+6 CglyWvAvtSG4of9rZ1FwXJIaW78F/7rmUeaPQPHOuZ+VCtGn3wxz9QGLp7Xs2TtQbmmBQuH3 IW5f+tUHaTDoTLuP+obAqpNb9HtDILWXbc3jgVA3tlTpzqPh6fiXaQ8eQm4lcdDzGEQO9uqn uwq297Kreb6GMp7Fj1f/Bap8V8hUahWYfzLqPPPgzbdJtTJeQEyppH23dsOhmzcn7jkEIY98 dc7y0Oh0saCWUyEi2f+zuhYw/mIqI9WErNf+PSwr4U2lvPNxtf8NPbYqVakKR+ccnXN0Duzw 3+G/wx+eNnna5GkTUJery9XlUOzrYl8X+xo6HOxwsMNB6JLaJbVLKig1lZpKzX9Dvdz+r6pX r169evV//nWTWkxqMakFdJ3TdU7XOb+Nc+LEiRMnToCfn5+fn98fr+fzHc93PN+Rv1y4cOHC hQu/+8/Nv7sdbm5ubv8u7y5xFghkwCiFkAoiTjyRPgWOM0d8BlJf5aJcE/hcmuQTDNp1tUvu ZlBypXpKHWCUVN80EsRLkSpNB5pL51gF4p60SbsAUpjhuGcN4GNlm6kEaFcdM7N/BuZqweJj kAv5ikBPkC3hnuY0kFfqXfJZYKNpuucakC7Im82lwfV15kzLIhCD7F72xiANMMYqiSCp9uOu EFB+sVvVTWAPdxR0eoPqtN9wfAIsVLeIiqCbJJVWzCDN1H0u9QKprynPqw+IVNFBewmuRmqo KwvMK9UTch647uiLKAtAWaC7rD4E+ZjUVNKDViGvm70PqE8de9gNxvG6XPPnoEY7q9pHQs72 nBFpzcCseg32awS+83ydntshd2p2p4yvgJKpoTGjwT7VWNXoDYYY34KRW+HZqleRaWuh6Jmi +4LDQPpJuiGqAddEtFwBKI8kXgEe6PADbDiwAgINE0gRkh4NxGFxDwEUpL/8EJRquo/ELHDu dhZw/AqBg3wltQo08arUOGodWD4xLH9+EnR1tBPRo0BqmpVSOQOqDSi/o1Zl+CnslxY/X4fQ T0IHmGpArZFlP64/BNrMLH+2wBx4UjRrYkIy7P7w2OUfq4NhnHI7uQRYm6qBvtPhTuITz4CH 4NfTkOa7EqI9X0hX98N3PbZuMjggqIehkzwFrP0zYwJ3gVpaEWmnISIhYHWxk5A7yHIh6ihY ZEvDiy3A1MFDlurBrcJPWlxZB0/rxRqiS4Lc0pzpYYb4W2/uJK6H8DTP54GPoEJqwOFmN8C3 WFCVuH7g7yzQofRi0JrpSie/hLz26mqLH+hDxL5HWyG1fGp80iUASrzLDjv/9PzT80/Djvd2 vLfjvfz1epfepXfxl8T6kccjj0ce8Kj7o+6PusPNZjeb3WwG84bPGz5vOHCLW9x6x98mbr9b yNSQqSFTQRmhjFBG/P1yHmM8xniM+e+rV4/5Peb3mJ+//JeEFj/8/qyD5ebm5vY/yLtLnOE/ RjL1QuAFZPCCO0AMFrESqECYZAYRqqVrY0Bb6PLOGwXS5/JhswWk6cZDfAPSIrFEnQ8inWAR CMIgV9FVBam6tXd2LrhkWuYZQZnlMcq3H0ht/K749gbdTbmb3B/EJtd0bStIu4tVDSsHUhld aV0RoKe63mUBpYZMfD2wH3POSn0fnOFZ/XOiwZVqOeIKBGt1601bX8j7zros7xW4/FzpIgek 76QdupagfCuflxeAsYGhsnEAiHKGPtJAsE9wpjjXgXRMneuqC2pFraQSAlIdrZNoCLJDeuxq Aq6hjhGKBJ4+JpvRDq5t9i323aAddRV2/gryTt0M/QKwxdrWqsfBrhchOaXBdMonQ5cAxnL6 X3WTQPF2KvZtYB+S8Xn8c/C67jsvYDtYz1hrmspC9uycS7Z08MnyjjfcBXW3OkO8BhrjoB6I omKa9iNIedJmKQY4JX0r5YLIJFzcBzTuUgK4QDPXCNDOiVjlNMgXWW0sBmmd32RkWcC3pDzL YQD1falRZg6kh2WqVAJVnzXyQQYczrl+5slFML02yan1wPBYnx5WGDJK5sw1T4SzbZIPWtMh aUna13d2QUqOs32qGdSOuV8KLzA90mqm1wHtkm1w0m0Qd4N7hVSCiqmRA2vPA8dp627XRsjq IrucHaHw0YhBdYfDk8An++I3QFho4Lf+70HywJwF6WMhpYYlLLUVGLrlHXdMhRrtyvZoagL7 05zEQC94E53VOroHTGnU0zTQF3Rt9RPNH8NrZ0qr7IoQbYg5fvws/HLpysStV6DZ7Opd3x8O Pt/bT4Y8hRP1r0+7VRtyFmmvPdcCe/jmXXStM2fOnDlzBnaM3zF+x3gw1jXWNdaF6fHT46fH w3s/vPfDez+AdEG6IF2As1lns85mwdTQqaFTQ/MToPPW89bzVmhAAxr893zHuP0NWxptabSl Efgl+CX4JfzZtXFzc3Nz+73e5XOcpf+81G+RCgEeUnnRHTDzQJoN0ivKKANADXVMS6sLDLOY sj8CWZChOwFaP1rJ4SCdFcP4BvCQDinHgKK23tmPgDid1fwclJWe3v6dQKqvm2zsA9Ix3lNU 0Apouc5roD6X3zgegrxJO8cmYL1jlmMCiGr4O38EZ4j9VV40SDXFQ3UK6Arq7hmage16bi9L DmTVT8vOXAB2zTLGoYF4qGaLe6CbIGcoFcHDx/CrOQU8PzIM8SgB+lZSLzketCviNvOB/som /S+gCzGEmYoC7aQP5fngmuXKdL4P+o/1F+RfwNjEaFKagdcEc6LnA9D/ohQxBIBYqc5XG4F+ v7JK9gNtm8tu14Pdy+KRagPZKd92mUE7JDXRjoFtY3avjCOQfi+uxMM9oGY7tlr3QO5MyyPH S5A2S1lSK9C+FRfVy6D7WYlXNoHZYBjtUROUubLJuBTYIoIkD5AqiHnSAeAM7cgDBolQ+VNg sTRMGgBZ1XIOZsSB+aK5Jj6QU1gvko2QOcxhSr8EMekJx+KXgGuuPCmvL2TMdpZIugCFNvoN LbgPXF/kVfaV4OEHsb/eDIajL2613vgpvJqWsv15EXivXIn1TT4CQ6Rk9u0M0q+GaVpjMGX6 ttQbwbsmY6sfA9c5qmUlQs4U5xdPz0HM94mtkiOhcbXKlrBrUOqiX7FgGXRHlffvfAGRoQHX DCfBOM7uGTgK2pWqm9nSA8Z6Dy4yZAkEJoSs9VoJ702uVbjqQZAcXqvFWDjc78qJQ5th7+mT zZdtgMdFX5ler4Kic0JrBB6DpzufxJw9C0m2pO/vNIGad0tOLtMaCp8I2Pzq+bvrXNu2bdu2 bVv+8vDhw4cPHw4tdrfY3WJ3/qV0eYQ8Qh4BTZ42edrkKXy+4/Mdn++A1iGtQ1qHQO7Z3LO5 Z38bP35//P74/TBuy7gt47ZAg0cNHjV4BA08Gng08IDPmn7W9LOmkNg+sX1i+79Rwf8c6X47 Et6pU6dOnTpB7dq1a9euDR2/6vhVx69g+4TtE7ZPyC//VmZmZmZmZv4l/Ld/HzV41OBRA+iW 0S2jWwZsfLjx4caHv93vpk2bNm3alH88mgc0D2geAKdLnC5xusRv477d3ztr//8Q/2w71Gvq NfXa359K0qxZs2bNmsF9w33DfcNvj/u+afum7ZsG3Yp2K9qtaP773fxl85fNX8KCUwtOLTgF trK2srayf7/et+Xb8m35t3EGXh14deBVeNn8ZfOXzf94e//w583Nze3/997diPPbObLZQAhI 9bGzExhGT9EZ1C5SK3khyPCMxaDeTX7x7DVoMeaskG4ge5pmS+VBa0BlygIDxC1pAEjV9Z08 AcnTcFDqCdIT7SstBrBrAepOEO/Jp3WFAA/totQPpA5UUx4BSXJVKRMYIUbphgCfqE5tOEhb vfoH7AL9YL/MUDuID0V/dQv4TwhuG7IDzNPTWmUWBO2Idbm1E8hJ0mQygZKOeNs+0LWViytr wObpihJekDvO3sHZBLjlrObyB9dmbawjGpwO9apaHXgmtqgnQanAF7wP0tfKBkMTMOynjbYC sJiDiQBXT8dFfVGgD41MmeCo4vzRMQ+0eWK0owK47jiWWENA+8l51eUL0ildSUNZMHYzZ/qc B9vTjFLJ/cDyOr1EvAdkfZ8dH9EXChcp0DxwJCh3mKT/Cl7dzfSL2wZ5nfPaxD0Hv2seV33n QdAX3hWL7wVXd/a7QkAqL+LlYoCQRtIPpPpaMN+CoaZJZ/CHqOVhicW9wLJMHBcfQtLN6F9e DYHgwn4rrYXB0MSzX4oG2UHpE21+cHnRk0EpO8E41Fgr6zl4llTaeiaA+bw2Rf8NBLU2nav6 AYiPlTmSHgIOePQK+AY89imZBY+BesuVbfwOqi6qWrbME1AipE2FL8L5gRfLXJwEnb2qJ7Xo DuVaVj9Wei+8tLy+lD0MUvNeVRS+4Hcu9JfIieAT6nHsiQMMw01DPVX46fEu56EzcH9TbJ2r RyAzOWu+3zZY1+5Q5o5C4O/n39m7N5TIimrjOxK04bm1NAeYm3kcDHsBukP6G/Z0+CXqWqsT VcCc5Cf7LgFzLd06/0Z/vFuJIWKIGAJ3f7r7092fgIpUpGJ+YviPtI9oH9E+Atofbn+4/eHf bs9bnLc4bzEMOzns5LCTkJSUlJSUBPVG1xtdbzQ4yjvKO8rD6ezT2aez86eAbMvdlrstF7y8 vLy8vGDnrp27du6C+d3nd5/fHfRL9Ev0S6CqVlWrquUnRgsGLBiwYADIu+Rd8i7oRje6/V/q P2HHhB0TdkBi88Tmic2BDWxgQ/72A4kHEg8kwpIlS5YsWZJ/AlE0tmhs0ViYvn/6/un7gcUs ZvG/r/3/rA8//PDDDz/8+3OHS5cuXbp0aZjdZXaX2V3+cbx/tR2bi28uvrk4FOpSqEuhLhC7 J3ZP7J78uAUKFChQoAAYGhkaGf7q8/zz3p/3/rw3v36G6YbphulQTa2mVlPhRa0XtV7Ugu1R 26O2R0HO8ZzjOcfhK77iq79R/y+++OKLL76ACCKIIP8E8N7IeyPvjYSvHF85vnLAOtax7h28 b//q583Nzc3t3Y04a4AEUgFc5IL4gUK0BVGTBdI2kD8gxHUF5HXyPvNtcCzIK5I3CcRN1eQM ALmn9EyqBmIriRwBIqVq4guQTsgvlacgnokqYi9o72lrtQPAAlKlXJAs3CAdqCfX1RUBqZi0 1BABWrw2SNJAqiBKaqGgBEiRxjGgzPBf49kGKOvhr34IclWfegY7mLWQ06ZIMM83r3MtB+/R gX2VFDA+8fpGKwG2Rs7RlqGQMTGjYsoxsLzImvimG6ivRRFnIdBWsFUdAc5v7UOdX4PrK/WO 6A+OQcIklQfxpVxc7gbKbXmlbimYvzFuN7QDv6+82nuOA99zPmk+E8DU0ljD7A2GET5FAn4G bY22QnoD8i5RmljQrZYf4AFiuauHQwdqFfuPObnAZ8onpgaQ+Wui/ukgSNuTVj+9JrxMfr06 aQkcn/LrB2tbwqYzx/p/uxm+/XHbsR+vwU8nT07ZXgleDUwek5QM+oNis+4HUHNFf+lL0Npo yRQHUwPdNV0FOB98N+t6X7hdLa7Xk7bAVFeGshc8Q5TRfivB7O1ZzDgeDEX04YoV0r7I2Jh6 EpRdylTDUfCcrG9coCvkfWGZ6jkcwjNNUsEt4L/NZ4o+FozfmDvnnoW239acUL0fqCHcyrsN 5Y4W7+vXAU41vBBy8zgcPX7towtnoN70iht6XofzA+8WeTMe1sxcf/jIOIjxj50YPQGMwcZG Xt6glpOX2bdCtSWlRrWeAqnpMQtzVbice7vthWbQMK1qbrEjEDA60FViMZj7G3c7ZoGlkrVX xiB4Pu3l6PgpEG1N7fY4GC7efHRr9xm4MjLGtWce2CNFafUcOAdYi2TcgJiFSXrllz/erSyL LYsti8FZ0VnRWTF/fVBQUFBQ0G/LL7Issiyy5N9M9l//fv/9999//31++SMpR1KOpOQnHu+/ //77778P3/b7tt+3/WD5teXXll/LX/+23KGvDn116K8yoI2PNj7a+Ch/+e0Ukh8q/VDph0ow LXRa6LTQ/O1bGm9pvKXxP25//U/qf1L/E9jfdn/b/W2h67Gux7oey9++4eGGhxv+akTwbQK2 1Xur91ZvGCqGiqHi78d/V+3/Z8XFxcXFxeUnqv/179v9/F7/ajuOzjs67+g82D159+Tdk38b d/369evXr4eSC0suLLnwr457/Q31N9TPX57Rfkb7Ge1h2cBlA5cNzL8CoL+nv6e/B8dmH5t9 bDbYbDbbX34w66+8vQly54udL3a+gKXllpZbWi5/+8P6D+s//Kv9/bvet3/0eXNzc3N7t3Oc ZcCFIl4AQWRgAxT2kQHipXZc/RbEVDHN0REMs3ymhwwC5UulrVwBxCLRV4wHKVlKl6sCg8R9 YQPxQjwW3YEbvCefAzlIsREIzGW9GAzYxHOtMhCJUAaDVEw0EC2BR/KH6ljQulBB3gHScnqK kUDDzJLxGuRpL3o+eASOvIyNWQ3A0uB1u9SPQWutC/f0Bu1rU4bnRcj7IKet+h2Ii9oYQyGQ DboexjhwDlerO14DmdJNmxc4zxKi1APprJ/eqx+kXsqR8nIhJzw7M20w2GbnLM8+Ad5fmQZ6 jAWpqrxILgUmf+Vb3fsgd9edVZqAXlZ/cU0FW0+9Q18EXNv5XtwC40bXLEcroLZSjkgQBV2v 5M5gv+d4nDcBTJ/qFxijQInV0o27IXdU5smcrbB9xaGXl07B/evpN9bUBo8zhprFfgWlpzov qjXc7v2gwtXPIG+sLde+DD4/2GPwjGJgaCePUbqC0kLXU1sPD0vHJz+dBbpxxlLp8SC7NO/M nXB/TszG27ch5YrNM2UhhLbSeftHg21i7uS8k2D8weuecRX45Xjscc4AjzrqIf1WsF/UHbZ9 BqYzIXZpABhmmSaqcZDkaTkWXxWy41wpCa+gpldxtfU+8NyoO+BxEep0rNDtwTG40eXXw9bb UG1izUKGhuDox+RSQeDnbdqf7AslFpQvWSsD9r88+WLje6D7jMjUOMj6yPCsqRGcPa2/ijdQ +HJog6LVIdY7/lRebzif+KT0LQ/wDTKfM04F+w1rkZRpoB1WZximgm9Pr6OWRuAqnzHd9Qmk fec0mqaB84ruC+0EZHa2X8ooD7mF8ioYWwGQ+Ue6lPmh+aH5IUirpdXS6vwR6IxuGd0yukHw z8E/B/+cXz41KjUqNQpii8QWiS3y23ip7VLbpbbLX37w04OfHvwEhBNOOOzatWvXrl35f/+e t6+zJloTrYmQ8CjhUcJfJc6NxzYe23gs0IpWtIJGmxttbrQ5f/vrkNchr0P+fiL11sgfR/44 8sffjuy+fd1/vYTf7PNmnzf7HNjIRjbmj7gvYQlL/i/t+Ffbz3zmM59/2rt+isR/VzveTrl4 +/69VcdQx1Dnr6ZyBLYIbBHYAi47LjsuO/5x3Lq/1v217q9AO9rRDop3L969eHcggAAC8qeU vKv2tpzccnLLv3Gi8Pc+b25ubm5vvcvH0QlkEC+lMOJB+lL8IPUAUUhqL7aCFkFTOQ6kmVqJ vESQRwY8iPQHtadoqR4E3XC2swjEWbJwAodJEU9A2sXnUiqIDyWj0IGIoKEcCBQXA7U5IK2i Oo+BaJaIQ0AV+TsWgShtm5+zE7ilf+VZBGRVGSL3hZyizwOfloVk3elel33ButFhEt+BbaVh r3ksuH6RN1gbg0FVvC0FwXTE81N/X5Dr6kdLc0Hyk3RaDChOqZnuKrjWqD8aloGpiM8P5u8h o6A1PrMX6MrkDs0aAGGLjLfMF8Ba0fWxKADST0oR3VXQYkQwcZA3yOKZWw1s3bMaZn0BOaNy vk59DtZFHpu924H9fVd3VwyIwU5dbk/wuGCM8I0BESUqqANBNwcvvgTjaPvTPEBpLX/r9Add UVu/3NkQWMSnSHBt0I1OeFK+GZCmdUv5BsI+CDa6JoDzlnH860/g5dbH9WwF4fuNG+f/1BwG neqyp0s5SGqV+Ch7FdwMSwy9EwEn1770mvsUfLaJ7wKKQMbD1Kb2oaA0Uh7I8yEuWBqotAZT qq6WuROUPlfqG/M1yGyccsC5F4yXg6flREOZuqKQ6g0J7yfWTVgAxkTpgD4QvId5mQu8BIdq vaHch2bfNshsvBv8pnsF+heBhDvpG4NfQqkFBdrpdkOC/vVFy0h470KdlMJb4HHE437yJag0 tuac0l9B3mr7Nx80gBvdoz9/PRX8qwRd85kDz7ToWTcioNX2Zmv6LYUjDa8PvB8KjSoXK623 wZOZcaUe9QePqeZx3odAOaRLeyJDcAf9VktjSO6mK+V9E7RhYrJnKEir1Fu5+0B2Kd+yDQLb mbaLusD5P9at3l7KL3OxzMUyF+EhD3kIHJxxcMbBGTCAAQz4q/Jz0uakzUmDOcxhDnDw4MGD Bw/Cl19++eWXX/42vu2S7ZLtEtCVrnSFgEkBkwImgfdj78fej/9+vUwrTStNK39/O6Rb0i3p bz3F4+1c50tc4tJvN/+9BEZbri3Xlv+N9UO0IdqQvzp+w5XhynDABx98/rz2/7v9d7VDVBPV RDXgEY/4qxMlnU6n0/2B/03eTs34i7dPfWlGM5r997XXnTC7ubn9I+/ycXQSAvAXaQQAe5GJ Bu6JSKkdSAF8o5UAuaW5UuCPIPbJRXJPAYtFRQ4Aem064cATJnEExGj8hAS0JExeAtKP2lzt KIizwqgNBToqY+W+IBJFWykepEWc1YaA+FgpaHwJ4vO8+MyboPXP7R3bAKSfvId5x0Des5uP bgeD2OVd2acfOJLVnfpDkHcurVVWHkh2qW9uM3AsFYplF2TqMmum7AHdCvlHaSLoHiu3DZ4g +csLdDPBY5Z3jN8WUGbktfSTwbQiNzJ7IASuNZc0DgdXiK6FfjMoQXIn5SjQ1znJ2RMMw+Uo aRYEHjXc9S0FrgjPc8bekHfO8aP/L5C2ylZWfxuSlznnWCPBViK1f85x0Ja57PYGYEqSrpmu gGGNdFHsBI97cnmlAhjfc7rskaB++7DPjcHgbS89reRZ8Nka/oXzQ0hekDXH7gmOs1l9ciMg p1mivtg1KNujYP3mgyF0rXf5Apvg4MqTq092hpQb0jfWtfAyPnHa5bkQcMdniPE7KPx1QENv C8S4tAQpChwWl8YOKEHwhapn4PKK6EWXfSDuZfrDvPkQtlBf3+8bCBkZsdr8KRgXyg3rLwM+ U9Yk1YW4CVk1nzaFQn4eJyMnQ4UZYcbalyBuY0Lt+Otwd1Lm0lfV4eUniXVT1kGhKUXCg7pC yZ8Kng26Cf4l/GW/zeBfLWBd3scgWsnddMlQuGuZDYX7Q+rHlk/lJOj4uk3rinPg6OcHCylP wZhkmmEdAfX9qw8qsQY8rilbnT9D2YqlrwR3A7tkv2QIhFPiasuYOWBfIbcx9wb9N8Y+0lPQ lXGMyxkMoTE+jQMkeB1lqxR/Ewp/53PB9z+mJrR8F92rx8keJ3uchOlMZzqwqvqq6quqg/8O /x3+O6DdtHbT2k3LT0AuOy87Lzthyf4l+5fs//txC3cp3KVwF0BCQoLOBTsX7FwQRnQd0XVE 1/xyT8Y9GfdkHMTExMTExEChuYXmFpoL5t7m3ubeEJ4YnhiemH8T1plFZxadWfSXAWfOLDyz 8MxCoA1taAORHSI7RHYA0zTTNNM0sGXaMm2Zv/94eGz02OixEYLjguOC4yAlKiUqJQpO9TjV 41QPaJ/YPrF9Ihw5euTokaNAd7rT/d23/3+Kf1c73l7hYCc72QnmB+YH5gcQFhEWERaRPwXi 7VNfWrVq1apVq/wrHx07dezUsVN+vFM9T/U81fN/bnvd3Nzc/pF3O1UDQEJFApxSCHpgj5Ao DLKNtbo2IIZKIz0agLLVsFhZCeKJ8FJngtqXHPUBSE+lFdp2kGuLXcqnwFaRLmWBKK1s1+qA /Imo6ZoF2gK1t2wDuZk8XtKDdlF8rlsHyjRtjfM8OBuK5qof5PreqHV1PIi6Yq7zNChTIsYE e0F2odg7aeUh5XpybsZVUPu5Xth/gdzPU0+mTIEXn6Tsz34D2Yd0Kw2dQDlkbOxZCIJeyh8Z Y6FAkLmYRw/QlTdL2TNAPquLf90efLP8PpeDwDZBDHOtAamR/nPvOmCoZFzptQfsT7RedAO1 ldzIuBkMnYxnjF+AfFlv0JtACtWZHN+DIc7nsaE8mBpL4wM/h8RsdamlG2jV7FLGAvC8Zqgu 0sBcS1SRaoD5jbxY7QfKx/Jc/Q6Qat0vFn0JAg77lXUOBZ8Poh7HXYLYuMSHCZ9Czlxj/fSv oEKRMoc71QHfL6z+xR/Cr97xQx99D8lZmR1vTACDb7CatA/ks9J4xz7wr+N9wtsPHI+tm6SX 4DvYsMM3DXJSHfOEA4KyzGcMxSB8hOeeSBWSnsYaCq4GQ7WgFdZNkDUv/vyzvRA1JDgwKBp6 9Wr2slcrOPbsxsKtxSBmUvbypxch6bK9TOZieDAgO/bqBsjJyf7euA8Cqvj8kFcDzn58anJc X8jaUGWXKw06+TbvHq6HoPWBD72/hLMDL294FAMtHzeVKvjAy1kvOr3pAqkL0q9kTwFdOUOY tgP8eviX9UkDj1OBixVPSH+elGH1h5v2GxPvNYGXa7PaPRPgP0p/KvhjsBxxbn6ugNcRXbJt Ejgai9mKDLm7HV0zq4B3Aa1j8PuQc0UZJCKAyu+mW7Xd23Zv271w9cDVA1cPwOGOhzse7giz Zs2aNWsWzPOY5zHPA2QP2UP2AMd3ju8c3+XfZPaXkdj/MlLY4VCHQx0OwaaTm05uOgk/6n/U /6iHp55PPZ965o8kvn2MHTe5yU1YV2tdrXW1gN70pjf0K9uvbL+y8HWxr4t9XQxmRM6InBEJ ++/uv7v/bv7NgW/1s/Wz9bP9c8fg//CfI5Jd13Rd03UNrFixYsWKFTCr86zOszrDlpJbSm4p CS8DXga8/L/cRPmu2v9ne1ftePuYQ/sl+yX7JZg5a+asmbNgbNzYuLFxUOBWgVsFbkHfCX0n 9J0AC5IWJC1Iyr+isT98f/j+cHhR9kXZF2Xz47ydY/82/p/e3gQScD8G0M3N7V/wbhPn/3gc nRMTYMJTxACwR0sEtkvDqQ2UF3U1DYSnFC2lgCgrrdHlAs2lcNELpH1iEZeAPXKsPAXUvdlD nk4Ge4eX++94gjwhwL/Ih6DPMj0zqOC6a9XZPgDdj2HlS3cETdZfDTwNuo7UV6qAI+LN4rzG kP4kbdir04Cr4PPQHyBuf1xScnewr7Vf1w6BGCtOuILA9oP1O0zgU8Wzht80KNy+SI1iqRAY 63c1MhU8Oxq/8TGBFKvLpgU4b2hn886B1dt6KlMAty2hOZGQszX9ZBJg1Pv0MkaDMc50TG4L use64nILkO7IE3UbQDpOUaklSC3FGaka6Pqqm9WTQJR2NW8MeMZ4DpSngGeAT4qPJ7jO557i JhgmiDDHe6BfqEbbjoP5mf2w+gj0X3h0CDgBKMqCjCOgXXveP+0WpBZ0FpCbgj7J0NazByjf Wlq6NkNcP9OaixWA4ICreavBY6elaomt4NXU91OvCCje2HSi4Rlo6lP9dvW58LpCXpPHm2Fz hVMl128CPw8vR/BFsFVO2S6thXtN7U6vb8CzgHar5iio06pe6uMUSC6QdDKrF+QOzBnryoEX u3L0l06C2txx0hgB9beUedmkP4QvjbcXaAA+Rp+4oA8gzZRsjR8EXpfKfh7pAdlNc4fHlgRT f9Mty1NwLbTHpu2GbT/sq3HiQyhgKFgw3BtKtIvwK7wQXAvte9VRUF4tOzdiDLwoE3PszXnw XOL9taEEGAuZW3qHg36dq73oDllCeuVoAIYnfsXLjoY2cqlxDTZCTtfM+nGV4dXUFNW6DGLk 7FW53iB7Mkj/BZjsuaXtP4Hk6zUgJxvMHmSbwt5h3/rPRHHGkBlDZgyBKrFVYqvEwq5Juybt mgQvmr9o/qI5GE1Gk9EELXe33N1yN4wZOGbgmIEwNnps9Njo34YNCwsLCwuDlStWrli5Ar4t 9225b8vBlR+u/HDlB5BuSjelm1C1ctXKVSvDCGmENEKC0nml80rn5cfpVqRbkW5FQB2vjlfH w5ZXW15teQU3D908dPNQ/n76PO/zvM9z6Hq069GuR8mfU/IvGlBxQMUBFSG3T26f3D75j0dL upl0M+kmTPGc4jnFE2Z0mNFhRod/X/v/bO+qHUMZylBgzcY1G9dshCtXrly5cgXy7uXdy7sH LGQhC6HHiR4nepwA+aX8Un4JW7dt3bZ1G9xceXPlzZXgV9Wvql9V6De93/R+02HE8BHDRwwH WtCCFn9+e//r4wjd3Nzcfi/pP74YhahVq1atWrX++QBWq91us/GXp2rgAbiAu1iQQCzBQzoH 8kU2SO8DXZjhCgfte3WTPR2kWLmZ3BKkwrKnsQdwW/NXGoC2VndQNAP1u5T7d09D3oizQw+/ BhGvC/ftBYYy4a9CMkEUz36UOg/kgb5rvBuCcWrV1l28QGkgfaTrAFmx56ZebQEpfV4NjV0K z/zidE+TIWtuxiutIDh+VtdqSaDY1EDbEzBskA2GhhDWJGBTwGwIHxk1P/JLYLsyXpcH2l55 lDQKXC3JdYQDVeyBzs9A7qJvou8JfkejrhYqBvFHn52N+R6kq/IX8hAQd+QvRCuwVbTfti0B EeWyqN+C1FF0k2sDRs2kTQd1o/2A9WfQ5qrf8BzsT+XpWOBNTN5nWQPBeidrQdpM8A01PJNK gflze1e2gmmMVtZQDPQ230e+AgSJvXJCwGRVl6pD4MTosk1eZ0D09/LOh5XBZ4C9gtdnkLlP nMrUIOMjdbd6FopM8UqsdR5KeYYqFU+CPFY/Oe8XsNa0p+s3QkB704eiJ9z4+UXYjeUQFe89 rsYCSEt/M+r1LdA/8XQWKALJ27K87xWCIoVDm7r6geFL+WXATOCeOOWKhbSNGQnpo2F0tf6j vy8E+tVyE89EiPVKWP1oOZysdbfnrgWgP+fYZEwHtbxjjaknvHj1pla6gPBigd7aVZAyTF95 mcH3A93aYpdAW2Zro/SGmi0qF6o9GIK8/D/27AnhVwo88GsOx61nrz3+ETL7pZZ9dQsa+Nc/ U+FrsPs5CsvHQfHTrZGWQpl9xWcX7Ax78o7uvNwKdkScKrzzJISuDfKzD4f0OZk18h5CeC39 FctJkMZoF4QEIiLSJy0LCl6J7O1dCiYqvdeeWPZnd/P/97wdUV9ZbWW1ldXy17+9ObDM+TLn y5yHW8NuDbs1DIbeHHpz6M38qSwXL1y8cPEC6Nfp1+nX/dmtcXNzc3P7n+7q1atXr159lyPO CgIBZEoeyCDVFzeRQJrJTdaD1gmH8Ab5PlvkTiBGaOGurqCUk8Z5ZIG2VTRTKgKDWaQ+Bamb 5iu+AKmm4zS3gOVegwr9BGJfdnLmCrBuivk4cRRoUx3tc1eA1D+lU2Ya6NIKmhMugfRZwddl zoNnwWr7Si8G25G04KRPIOgDn7mR9cA5wqBZ9oDW2iacKeC33LN6wZ/B/EBJUoPAZBRlhAvy vrW+zJ4IOk/9WGMM6DerNnU5eGcqvURpMH0UFBf8Akz7C14usgyUEv6TPOqDqJC52XIJsj+w Hsv7FayV7BttDtD9IO3UnQW1gPSJyAJaS3ZpAsjz5daKBUQ7baTucxCHpMHq12BYpGQprSBg pmmCTwbkrrNPyO4LunDn2hwTqKtt/R0KaDXMi30+BYEjOmc+KCbvaYZ1gJz7WnwG2pis8p71 wP9zvzqecVAls9zHUdEQM/XZNyWaQdKQtFKBvqB4qA2ldZC0w9YlqxeYYrxsUiiwT/6i6Bp4 nhnf23oTCrWQ79btDVr9nG268yC+d0UF7Qb1gu1UdhKE5fq3qNwJrAE5mVkdwVFXCiQP1IP0 yd0KeT84P7FZ4FTSjSnnJoH5qflo6Dy4/t6THXtrQ8XPCi2PcIAx3DrQLwpu9ryXlNUVGh2u JJo8h5QmOZWfFYTMw9YVd4uA1y3v80FjoGS1MoF1mkOJ3JJLwvbCy2vPH8R3AdOwzLvGbyD3 fvzZ2DtQ6mb51ZEZ4JxrmyKbocAPkXeC7HC3+h3lWUXQH3T1Ep5geqwUTj0IXl957ot/Cfqj 5orKRCh43XHSYQPbDs/tOMA4UBfvHADOEcoV8yyIn+W47HgOTP+zu/r/mwzrDOsM6+Da4GuD rw3O/+GKjSM2jtg4AkIjQiNC/2oO7tubEJtNaDah2QTQp+nT9Gl/divc3Nzc3P63+eMjznl2 u80JaGi4AA0DCkgRpOEEqhPLDRDj8KUySE6ssh20a9poe3sQr6Rp+jOgzJXiKQJSMb7TPgdR UgRJBhAjHetyloG1zY3Hpx6D9eaTjo/egKuOtUTeGDBU8u0XLIPhi5LDyv8Arhn2b7IWg8+U Gg9b1AK5lNzTkAf2J696vXgDuWPvTLvVHK4cSTfmbYc3Wmqh9KJQMNnre/8WoNvn6G7PAdMo 6Y3SCYwXTCX0VcAYTbxrCARHFXgRNQACYmqsqn4RZDlcDXoIkkvfR6sNtuc3VzzYBrnnYi4m fgVphXOH5O4Ha7L9saM8aAuYpuWC443jluMuiBrSGhENVBC9tRrA164kbRFoYc5nmieIIbog 5QbwubG0MRWsF6yns+dA5vYk3/gpkJNzp949GQIfBY0JOQyeLQKPhM0HLcd3T8ghsJ7SGhq/ hUcHPF329mCZb3joageGxeK+2gO0F9YVshmyD9mXqX5gaZO5VxsArgKuabmbQc2wRjt3gm2i c6XtPdDl6V3K96D96mxo7wWuS+ojOQwMNfSxxuFAZaWT8AfjEdMY78Pg+dDQW+4Jug9M88Uc cJQRj0zeoNp0nbUQUMJ0C+RUCNzse8Z5Drycfoc9F0KlNaVmvDcOlARXilYAHkc/7f/0OgSm BYSam0B86/g7j19AgwKNQmr9Aq7X1k+D90DwrtD65kfgHevZzacM5KXbB1McEq7HKFnXQTtp db06D+Uzq82qlAmP70Uvft0RYnwTasQaIeXTZJ/nRSBuX9r+uE9AsfjkpGvgaTLNyT4I8piM vq5+YN/kEeAaAAE1/Mf5z4S0+a6+OZPB+rncR64JuWGZ8zOTYO3JzzddSv+zu/n/u9Lnps9N nwuLzy8+v/g8XCp/qfyl8pDdK7tXdq/85103b9a8WfNmMKLmiJojaoJ5o3mjeeOfXXs3Nzc3 t/8t3o44//HE2WHPs70AqaQULpUB8VC8EXFAIilSDUAlnXSQuhAkigLVWKocB7FBDHdVBCbL 06THIA0SkWIiuJawUHcQ5Pf0L/R3QJ0a/ebEfni5Y8ukzVGQ/kvux6bNYH7oOd5nNPj39ooy WMEsAn6RVoPHo+pnG3qA2atcl1pFQY4kTrkF6vc2U/Z9cC2/mXz7R3imPZ1wuy/kfaFlil/A +ydpXsgdUC/wrSEVvL/w3u1bDDyijAU9+oO5mudLj1gwO6smlhgH/BTs8C0IYpetvO0q6H6w zM2aBXlBj0680kHqnpjKSdGQ42X92FoFnD2kdpoCwsIIMR8cTxzfOdaCY4jLaP0G5KkEixLA Be0yPwORWpRSCbR9Ul9FA9IMr5VNoFYTg0gG22Xb+5YRkDXkzZO8bZB5N7Ob7Tko20KXBkwG Mc0kPH+CTKdjt7U3pCe4sjN6QFpussgoDRZd5uSs1WCLsdTNegL2E471rgzQb+aufBH0sq6l YSPIF/UD9BqYQow6QwxIm2S7UhcUh764fhrITeX+clWQJ8njxFkQ00RpORK099RMKoBzvPaN Vgi0urRQvUHc17YLB8jj5En6bqBMNpYwxYCxhOmxVBcMn/gYg9eBvpmvh380+L0IuBUQBboi 5tLGxeB8kRL3sj1k1rF+9CQUinlE6vR3QN3uuO9RGxrPaFRwQCMwj9N1c7YD5wNZJyaB3NpR xPsY5FV8U+lxU8h7LX0qNwf2aDeknaCaRBdjF3hU5kWHyzYQm62ez3ZCdu/csfL7oO9n2uga DtbC5jux84Axjq+kJWA1O+son4HpF7+Wumh4/Si9XkZRSGuU3JOrsN+xpPWF2n92d3dzc3Nz c3P7I97dVI08KUCaCqKa+E4cAclTKo4B6CXu8SmQxli6gigv5QgFpHrCIuoCYcpKaRBwXBsk rQaRKApry0D+UXkh7Qfdl9mrYhvBo0NbddtuwPWPX2wTPaDIkwr1qpigTFKDIVUvgTMgdv2T S6C76Llevgb6ruEZkRtBDtfP9foSNKfrln0xKB8bqnvOgbwRdot+KhS5GdYsqhVYD2ujc9Mg cVeC1VED5GDzIfM6MGzSpym9wFDMt515NjDI0EVOBFetnL1Zl0H/tc9241PAnHE6Mwdydz5+ 9bIs5M1I/C5XA2cv9ZxIBOEp+TAVtGPqKHENtEs008JBOiZXkduA3MIVoI0HNVSEOkqDFCYd kY+C3EP+XE4BubtIUasAeu0rpoCjgG6G71HIG+35i9cDyBsatd5ZGtJq+pbNGwO5dXIWpG+G jB/jxkUfhIztiS+TDJD7LLeVLQTkWPmutg28Er3GeIdD4C2/2/4zwZTjfd7rEBh3e4SaloBu uamgfhvoFHm9/ANoa0Qst0FcE1axB6SCtBFTQFda+lI6CNIl5aR0DzBKM/TTQYmQFxIJ8h3x rdQMtDCtt3IftNZivKs1qGPtRTQ75O62Z1nvga25VVarQN7NN0FJrUEMS7uc3BpyCr+p7ucE 08dedfxCwPsjYxVHKvgv95jh3wLudnp2xi6grhplkcLh2U/3Fl96BRaH3NtjKRRYGrrJMwrq bK51unExuOn3ZGL0GrCeMlq19VCsSIm8oB/AuF6e6GUBXZqaVK4v+JXzXVe9NnicD+gaOBtO l7l6Y/NqUFOyZiZ2hcBbHjOlkeBRSI6p+g3c2/Dm6NWiENgsZLypNaibRDn726dXxP7Z3d3N zc3Nzc3tXfjjifMgsZaNQH3pvmQBomlOC+ARPcRHwE+ck9eAKMhiZSBI9bRXLh1QRnRVKgDz pGz2gpZFE0qD/id9QV0c5H593+N6LKQ1v5+TUgUKPamSWy8Jyo1r2aHSXPDdFFrQtxE4a/q/ LL4cxDbted4wcLXN6Z3dCIxXwrZIXiC9J6rK2aA1d8y1nwNR2elPCuQcdzwO2ge2LdnXnNXB 2SurU9wy0PbZRrrmgaW0+rX0ERiClUbyLjB+WNYR5QWSL9tcl8HVJ+biays4ziafypgL2vZs s+t9cNWRb8jXwDXBeUSrCCLDdYylIH2GSQwHXWN5n9wNnN9oqVp7YIWkyl2A6dp9vgNRS5TU moLorW5xfQY81I/znA7ZjaS5Hh9Bco6zvGaBNGFtnv0xpC1K2BlXHpIPv+7+aj+kizdfJnYA 7ZL6k6sTeF713xSwEKI8ixcr7AIPs5/idRv0PxjOKEfBdcr1mWYFRy/bN1Yd5KVl/ZjVEcTY jFHiGsg7xBeSEbRtdBS7gDFyrOQDugLKAt0OMKQoPkpRUEorOYoGOrPiK28ArZS8T14Icjsl mTugy9VtkYxgqKFboFsPbDKX0fuAZ6bXUK9c0EooGXJ1cGa6looaYM+0NnBVhbzLuR/klgZb tdSD2a0gdYEyx3ASzKu8NpvToOSYco3rhoPxpV+A9xGocLzEofC6EBwbdjKkB5h2mG4ZBoGx m2GYmA6VA5stb+ANppnm5rrDQCDLqQdKf8Ll7WDo6GEMaAy2N6KV+gH4VjP/aJwG5bNKd+kz Fp75vcx+EQZ5bR361yfAKyxQ510PCr/nHft0PmQX98zLuglhEQUaeJUH3Gmzm5ubm5vb/zPe wYgzn6mpwAfiiLwJmEFxKRGwSyvoAdpuMUbVgW45b3RNwPFG+oJWIHUQ50QQyF2VPvJY0LVy TZZXAXf/I6yrdkpGam0o2rNex1rjIWrE8JIfhYL03KuiwQ55ZV42fFgO1DBb78xdIL+QY1wF wbSt8PYKE0Hr6lpt8wM26m9L00Br+XpH5hRwNbLvU12Q+XPOjJyOkHXozbTUPeDaZg2wdYPg Pr5V/KdC0PaAFl5hoPykFCAC1OMJi9LSQHxRJCZkOSjbjDadD3CewrqTIIpIBVxRoDRhkmQE 5ag2h94gGaWX0mSQjonORICoqsW6GoJyUZohDKCskqbIP4NWTrqifARis2GHx12wD9B/5aVA 6mfqSKU2vPkub6vFB5Lqx796eQ5SVzx58+g4pN5KeZh8CpS2xknGPPD/PqJY+NfguSK4bVBr kBP10ZjB2dly0xYI2c9TnqVFgqO7Y4hWAZQGcmV9FpjGm22GN+AR4Lndaxh4TPOs6bkejJ95 KKamYOhp/M6YCbod+vn6M6CTlar6RJA+UQ7hDaKmUEUeSCOEQesG2hV1hPYraEu1Ey4FtIWu 647+IL5zVHENBa2Qy6A+BPTOA47+oEt1fSBZwYA8XvcCvO96mQ0zwLXT+1djEjhbOW1aHOR+ YglzNgPLjrxteePg2YFLH5yuDPa8iKPh16CkK3R4/cYQris4JfBL0NaLAKcTtBuuD81O8Orl WZuTkNs/19caAvIF+WP5CmSuSe9t+RRMA03DTA6I/C5gtncuqBdcg7UFUPn9Ct+UWgW6X00r C5WBq/3uhT8/BrYsZaFjMpQNKbm1xGa4dSg6a/9ayD3qWPp4KfA/6Nfl3Nzc3Nzc3P6YP5w4 67rpPzR9CGoJZxFnC2C4NJMGwHzWSHNATuETeRs4WrhaOYzgiEmZ9+ZDMIQZk01OkNcHBAT8 Cq5NDm9HFZCf61SpNhhWlq5V8nMI7hllV3NAHe9l9+oDTMq+l/gGFKvczfkNqI+ty7O7gRJW 8tvaN0E+aJrqOxqoqxZSJ4IIVsvZO0Ne35d1k4qCbWn2eFsBcLW2JWuTgRvSWb8ccJ2Syqky JLyKP5wUC64Ae6LFCGFFI0sWGgZysqu3cwnoy/O52AWiQmRy8PugjwxZ4H0exBZbnG0q4Jdz x74FxBD9RHEddI/VSywCV1PHIXUgCFl6RAMQA1lEDdAd1s02dgWb3bjcewdkLTGcME+AFM12 2ZEESe8ndImZCEmVHqy+5w3Jvq8dryYDd0y1PUIhsE1R72JTwFwusJRfc3CUdpZ2joGcccmP 0gaDWsNWRU0B03vmoYZr4Lss0NdvLfitC2kUdA38RgXs9e8LvlO8v/DqC+bFnkVMXUE3Tf9S 9x4oh6QSyjgQGxgsvgWtnxjIEpA/EEFSEogB7KcVMEp0FhtBvaZO0T4AdtNJNAfOaEeEBVwb tJvaLnC9p+5Qm4Lmqd1Sj4BIdI5wXgdne+vgvGBQO9tLWO+Da4N6wjERXKnqQjEFDF10D6Wq YFrou9XYB3wq+wiTBHk/2gu4hsGbgWmDUwJhw7BNLX/uC/6XAj4K2g4h84M7BJWBqrGVBpb6 BcqXLbev8HzI+iRtj/QAHIOkB64b8OZO4um0JWCYYQjS/wIVPav7FysI0ibdZ3I7UKzaTedq KLWomK/hKNx78WsHx8fw9PW9g/eiwOdcxWnljkEDtdzmvkfhzOMrn+0pC8D7f3Ynd3Nzc3Nz c3s3/nDifK7BpVFXRkOdCtUfVK8L8g1pq0gEsUIka3eAk9IIORXkitLPSnnwWBGQHHwDkqsm dktJBd/CpiX2K2C4bCgjfQXaGtWTzWDoEppWbDSo17J756wBUcOhs/8M0nzplXQYyJa7GONA P7xY0xrfgP7bIBF5Czhpv533K4ixOk/9C6B/3mdaNii37DOEBnKa8tS4Czy3eSYbboOXp3ej wCbgzBafFdwAFo+kJXHlIG7ts0v3toJ1e3paaj0I+zkqqPAbMN62dsiNAmVdWli6AXSRPm18 H4LWx/nUdQfklnJl6T0wvC+ayFFgn68JbSfoaikHlfngaqTV0/qDWg+Dbiu44v2O+w2DNKcz UpMgbkbK0KRlkLjqif7eBHh9/VHIw1VgXeWarhUC3/VRJQu0AeOuwM989oLTy7lJnQ2pTeNm JXwB8lP1BuEQ3CCoQWBRCE0vc7qAC0IbRa4InQ2+G/w9fX3B44x5gikTDGX1KxRP0Buki1IQ KJLQ0RXEdbWZqAzWJ67p6lrQnmgztaYgvZAfywbQbrheqZ+Da5Bm1YaDVkEcFC1AaSpaUgCk oVJjqRwoj+QVog8oVRFSCiiXWa3UBAk5RwZ05fXC8Aock0zfmY+Aq69a0xUCYp3L4rCCva7j C9sgcFWwlrbWAsdQ+0LnMFAmqJKWBYYQUxX5Nnh8Zsr1ex+s961dHKUhvX9WyfQOkFI82zej AuRMz7VmLIT06ylV3uRAwzsNrzS8BYaffZ/5FYKgrkE7/LLAVUsdqc4AXUG9Q3GA2tIVL2LB pbhKynshjRRj7g+QOzLzSuI5yHIkffH8B7j0LHdXbB8oNa5kZBk71N1UrlfTTX9293Zzc3Nz c3N7l/5w4pzTJiPKXht0o5VsqSS4mquVND+Qe0mfcBDEZzjEDJC6yQ2k66A09ZQ8IsEUEDjR dyI4uzruOGPBs5n3OL8ccL1Ux6mrQawx3woaArosU7i/CVwlst+ktQT916ay5uug1AwfWmYe SC9ooHwL4PgkrwqIL5UByisQ5aXa+IJorT3TxoHYI88RlYBgxmufgDxK+sTVEbyGy+Wtp8D5 iRbh3APG7f6JuqLgiraER/wAb/SJGTEdwHnCmhJdC4K/Cj8aOBm8mvndi/gEtILWPvaPQMyS 2isPwbnJ9b3zKojl2nJhAemeNFIcAXmAs5vjF5Aa6Wbri4K9jOfooBCIDbU/tsVC7A8xnzzp D6+ybz+9tQ+SWiTwaioocf69fJuB7/jIchGxoNQVvaQ1kFEqoVSyA3SjNbuyACK/j5wTXhEK xZU8WmQ8BG8pkBy+AnwL+eZ4nQLTNf1hwy5gA2uUJqC2VlX1FciztQZCA9dERlEL7NPV9WoB 0MaKEAxAU8lfXgsGi04nFwDdEKkXeaAFSt9oo8B13rVO6Qq20eoDtTQ4s5gujoGrq/qNOgCc nTWjOAPKFvlrKQr0TumItBXUMtpTDoNdUlNcP4EoTw1GghQhtktVQbms22j6AURf6WOjGZQP 9U89EkGf57pk/wz0y631rA/AFW/PsN8HXX31kbMN6DuaSytZYPjSdNzHA3K25KXYh0JCm8Td yZFgG2ef4uwOxBgbmbqA/yKvr73KQU5W5vbc7mCtbxmT+zPYEx31HZ6QN8Tm70iHvFfWLXmV ISHlzf6MdmBZZemQchh8x/rOUqaBtaQ9XG0Jv37wqOr97yFlT2qThCLQgIbU/wP96+0PeOTm 5ubm5kLDzQ03N9z823KZRTOLZhaFAx0OdDjQAfpY+lj6WGB1jdU1VteAoUOHDh069N1/gaxa tWrVqlX/evw/+no3Nzc3N7f/TvIfDXDz5xfavWdwv+Sj1i9XgkdpU3+TDK5S4pjsAzQWw5kB rMMqRoFrtjPFeQv8vvb51nsX+Kz2m+H7NTg6Ozu6wkCsEYp4A9IB5YJSCdiqG2yUQbfZp0mQ EbhkaOqlB22G2k+1gBiufmRtDuKW1Ec/HrSH4lPxPkiV8deaAtvyCqW1AftPGTkpTrD/ZD2X kA7iUbbrUXt4vOpemaPxcL3OiYUbOkDazCf7z9YG/zxjo9zRYPQyv/YsCRl+rn7Gh5DYOSEh YxEkjYsf8tgKlh65vgmnQC3uqpUdB1pt9YplFUjBItS6BqRnji62ESAP0nXwzQNLXd9zoQ/h yey8gRleED3vbuSN1fBgwOmdJ5dDQu+k53HlwFQq8quChcCzY8SA8Btg3ZRlyrkC2YsTaqfc hDBbYMewsVCrd+OYOvFQt2yzVw32Q+n0CkPLfgfBLYOOBo4F4w5DA6M3iEhtqHgGWifXeVdh EOVFK9EWXDXEbnEYXOXEKzELSJAz5NYguktWRoCaLrpo9cFVQRzQrgCHOKjNBX1dpazUChRN Ga3uAFFW7S0egbOT85J6CRxZ6q/OtmB/rq5yeYP1qXOS8yBY6jpruAaC9ZVaUj0Gjs6aUeSB 4yu1mVYIHN20Cdo1sC5zdnD2BXW25nQdANd18UY6Bmp15TvjMZDLe+T43gB9hPcz39Fgeujx i0cvMOv1p6QfwTOAMY7CELDHfN/gDX6PfEd614EMa7Yl5wUcanpEd6YabDPtPXfyLvxy5vz1 G6Pg2LgzS668gZ9TDn73iwyHa58cdvwunPK5kH42Be6/fLL6YUWIv5biSB0JaQ8zTLkBYHhB Gc0Euu20UOtD8o30M1k7/ngHLb6g+ILiC+Bl4MvAl4GgVdYqa5V/W+7tT24XnVd0XtF5IK2W VkurYVDlQZUHVf5n9/r7/dH4/+76/VHihrghbsBO/53+O/3/eLysHlk9snrAOv06/Tr9b7e/ Xf/3/q4evnr46uH55W9Wu1ntZjVYq6xV1iq/LX/p0qVLly7943odL3K8yPEisPPFzhc7X/zr 7Xt7IvT3lt3c3Nz+t/vDI84vN6b2fXoBzha6UyPAAmXeL7UjciDocuVX8kIQa0U7qSTQhRga Aw6icYF6TjNqepAaSgsYDtIj+RsmALvJkQKApZTDBFQUHbSVIBZJi5TlgEvMVT8F3X1OiEog DmORn4J4IDo6vUE/X3/csxM4TWm9XvaHnIGXip+ZDWqR5H7JXUDcUs/mVYEX7z1Y+rwM3Pry 0YYEP5C22htJ0eAryoz1LgL6l8rZ5A9AnYKXdzkwOP2U8F9Ad11XTLoIWTtdx9PbgmN9ZkCK Bfw9neutQ8B8yrDOfA+kMmqgYRToznpXDZ4PyQ28UgMWwMPJiW8SdPD82g3pel944nn/6M00 cBRUnAYd+HxTaE6hXJDTdcHSQMhemrAi7Q74Kh41zU2hVKE6kVUuQeHzpScWTYSgbwPOB+4G /UT9B/peIB1kFbVALFQlrTKIdC0RJwirGCzMIKusZSkoXzBf0kD9WtrCp0Brbam2DMQyEaRF gL4mbaS+II5K5ZgGcnntvhgE4or4jh0gDtNX6wZsEwXEKlBqyEVFOpimSMFKHti/Uo+KmuCS MQoZtMXaQjEb1DPqZ9oT0CpQWBiAOmKfpoFoI6ZJ/YA02rMTpAOiHWNANBXbRGsQPyITAOo8 UVsUBNqJVCkZtLbyAIMXSEHGg8pM0FdUKuorgjgsvZ83EfjcWd+1F6Sh0l3qgHJH2W2aBlkX LIXkT8F+V53gvAHeQb7HvKPBMNdT9agE9kOSqvwIWWXSbyebgafyfbk6iF1iihoA1q62/a7B kPx96oXcUWC8aBikvAavTj5NzQtBSxD71J+Ba3+sf/n4+Pj4+IDfBL8JfhPgdePXjV83hkIU otBflXubODc41eBUg1NAG9rQBtbeWXtn7R0YWnNozaE18xOZ2ndr3619F576PvV96gstJ7ec 3HIynJx/cv7J+WAtay1rLQtF0oukF0mHu7q7uru6344M/734lQZWGlhpILxs/rL5y+b5JwDV q1evXr36b1/fNKBpQNMAuHXr1q1bt0AMEUPEEFCXq8vV5VD2fNnzZc9D5eWVl1de/m/5Lvw/ PN/xfMfzHfB48+PNjzdDxtcZX2d8/a/He3vCc+7NuTfn3oBzmXOZ82/8FPsA5wDnAOdv1796 9erVq1cQ3za+bXzb/PXZp7NPZ5+GlgtaLmi5AArMLDCzwMx/vn4vJ72c9HISDEkfkj4kHShK UYr++4+zm5ub2/82f3jEuchgsy50HLwWr64lToa9lw+eOPccTEcNNvPXoNUSzfkWiCCeRyB9 LS2SFgEqLpwgBoop/AjSUnFcqgkSRDAQxClRTLwP0iRpoxIN8kZxUusN3KUkK0ArJS3QJQBN tF0uT9B2SX6MBrWUpWniXHAcTBz5YDpYG8T4RR8FbbwrImMnkK11th8H0wavcqY1UG9wncaV PaBOdFNXQx8wrgjOjawCqe1s6zwPgOTymu+/HTxfmr08JoJO9frMaxN4VvWuHPkdiBVKg4AA yPouq6jFBzI/slzI+Rnsjzw+86kKKQneHfyvw6MLCQ1fGSB63fmKZx9D9I7bi26EgaOn8ZjH UTCHRx4PfR9ctRwOuwrW9980zbgPRb+JMoXsgyY1W8yt1wYqn695p9JaiLoVMTyyLHi9NEw2 WkFpqZ3XVoPumCihtQDTYrm3vAr01SgmLwNdDfGVVB2kWNGS74ED6hw1GHTva+fVSFBimac9 BuP7Slf5E9DL7BFhIH3p2uO6A46NzgGubmAd6vzRlQ5545yKuga0sWIFhcD4SG8Xn4HuoHTY NRjkzlpj7SQoX2jnXJdACRKyKAG663JvckG5LPcQuSBdlIKkciBdk8aIOiCH8Z7oCLoP5Hhp ABi2yDr5CeibSjFSNTD2ltZIHcAwSOpBMBjmSjdER1BCpZ7SCFAu6rKMl8EgeTzzXgHmfebW Hm/AY6a8RSoL5k3S92o/8PXwqqWvBt4f6XKVzZBdOTUq9SHYq9izrSch9G7Y5NCHEHkuokax 1SDfE1dNfUAezxrhCbr+ygzlKthGOQZqnSGjQ9ZUy31Q76ht1O4gO8Q8Z+S766glsktkl8iG 59ufb3++PX991qmsU1mnwDnAOcA5AEJfh74Off3743bp0qVLly5w0XbRdtEGxTKKZRTLgJ49 e/bs2RN8n/o+9X36z9c3ckbkjMgZ0CGxQ2KHRLj7490f7/7498vfH3V/1P1RUG1ltZXVVkKP rB5ZPbKg05tObzq9getDrg+5PuSfr4fNZrPZbOC84rzivPL7X+f92Pux92MoX758+fLl//n9 /ldXfrjyw5UfoHTp0qVLl/79r1MHqYPUQXDnzp07d+5A9dXVV1dfnb8950zOmZwz4DXOa5zX uH++XqezT2efzs5fPhhxMOJgRP5xO3HixIkTJ2Bz9ObozdGwrcm2JtuawMliJ4udLJZf7ve+ D7833p49e/bs2QOpUalRqVH5cfbv379//344d+7cuXPn8tc/Gfdk3JNxcLrE6RKnS4DD4XA4 HHD06NGjR4/CVu+t3lu94XDHwx0Pd/z79X574ndv5L2R90bC7sm7J++eDC8+f/H5i8/zR+S3 +2733e6bX//HjR43etzoj39O3Nzc/uf7w4mzbJBXewyCxruqbm10F5qY672q3gGsTsdTezuQ 4+XT0nGQakplqQJilpgrZgPPeMoTYLb0hfQliLbiM+0kiFJqvPYp8BPDGQW8wSx8QNyiutQf UEmjGbCVXHETtFSpjaSAvNW1JdUH0sIOHV31C+RYf/x6wwMw/Vhwc3gtMIws16LUIDD7Sj2t gP9a437DEpCqmU76NwfnLu/LHm3A+sSzaXAV0JTAkwU/BnNDn9n+h0HXSOfpGQfqZX5Q1oFc Vq4oG8H8yKdfwFJwRXuUDZ0M1o6moqG1IDMtoG94PPx6JH53fFm4bzi39VwUPDE/6vzYBLZy 3tc9BoGxRGB1/y3g7JITaSsFYpv1pP0uVKxeJbkcUPN4oxW146CEqdzkkqchfIlfF98oEF/a R+StAXsNx/C8w6BckipyEMzN9ImG9cBkrYG6FpSvsKiJoDfJAeJT0Fslo7YT9DukqWIzaOVd u109QZ3s/FENAMsvtsKOVWAJsJmdP0FeC2e0tgLU5+ILtQyoBdQrro1gj3GV1WqDfYkzTi0C ohZtNQnkdEaJmaDkohNPwJArn5RCQN9G/kVaBrJBPJA+AaW6VkeqB8pONO1bMF6krXgEXl/o RkkLwKOffoK0BHTfK3PFr6CfIW0nBnTPiBd1QGnEIcaDLlNqRCIoHaUaeIF8iQtkgm6ZNFM+ B0oDQ4bhQ5AXmD/0WAHGD/QW/XMw28VU149gfmIOUwzgkWUaoT8ItqLWZpYvAeRT2kUI+bjA ipAFENEyam6JPWBaIG/0mAi6ZkqwfB6U8rqj8nXIM+edUQuD7Zj1mCMRpLVaJc3x7jpqsa+L fV3sa3gd+jr0dSi4lrmWuZbBy2Yvm71sBsW6F+terDswjGEM+8fxypYtW7ZsWZCqS9Wl6pAQ nhCeEA4lS5YsWbLkX+23R7EexXr88/WNOBBxIOIAeER7RHtEg1pZraxW/vvlOxboWKBjATA/ MD8wP4AH9R7Ue1AvP2F+O2Xi90rpnNI5pTNs9tzsudkTtnht8driBXl5eXl5ef/49SFTQ6aG TIWo2VGzo2b/6+9b7J7YPbF7wN7f3t/eH0r0LNGzRM/f//qHDx8+fPgQimUWyyyWCfra+tr6 v/olyreJ89lFZxedXQRr1qxZs2YN7G29t/Xe1pBxIuNExom/H7+JTxOfJj75y+0j2ke0j4AL fS/0vdAXPD/1/NTzU+id2zu3dy70zOqZ1TMLvBt7N/ZuDBfLXSx3sdw/bsc/G6/gzIIzC86E hPYJ7RPag3pNvaZey3//3nR80/FNx/z4iQcTDyYehIJvCr4p+AZu3Lhx48YNiIiIiIiIgF45 vXJ65UChroW6FuoKVwZcGXBlwD+u99sTy7fHt+Xulrtb7s4/sWt3oN2BdgcgZnfM7pjd//rn xM3N7X+PP5w4O24ansVb4Jln7JfH24J3Sa8+XlVAviYma7tBsouL4jsQvcUVbEAur3gBPOQZ z0D+QboqjQRHfcdrZ0+w73SWcTYAWZOrygkgdoolIgzIJlvEgVQFPzKBCuI58SCP13DKkJd5 rcTZQJAaZmTnVQdpRNk2lV3gM/69X3tvhmBL2yOD3gffIa2iupaC4D7VelfOgdC0gFXe74Px MzYoQ0D92HTGQwVlu+66KRaUPbrXZgH2a5qXNRzU3o7P1PNgb2efaCkGtq6Wlpm7watU4Ijg muDyKnyxjAwPDAnfJNSG6NXn9517AM+7P24Q3RvsC733GZ+A6YlPNb9e4OySG5IXCV5Plcly M6g1uvbranao+ku9RVX2QsFeBXsUqAj7DIdrHn4Jq9I2/bphOfw0avvWbd/BSq91U9ethNO/ Xjx67iNIOJ18Lm4tGI6afOSGIJt1p3STwHVDOyu+BE7Ki3V9QH5jGKsfAfoPTC30m8DjhOF9 /VAwDGWcdAmkh8JbnQGmwXKuuAqG9+TZ0m7gE3FdlAC1kVrINQ6sO1zfOQeD9XvbXFdlkIeI BlJ58Mkyv1ZugmmeXicVAr1emqRWBEMJaYq6FDxqKT9SEMxL5A+lX0G/WY6iB6i71KfqTnAs c2qum+A8qiZpncE1kWytP7jm0FaLBacqhroywXVDG6n2AJdFXSR2gKutaKvtBUd70VAkgytZ jKQEyK91nvoeYNhi+sbDA0xPjedNm8FjKcGiHJhSTaulDuAdYopXpkDO6Yz30h6DZYLlRE4D 8DsaMsbnEBQtVOhGYR8wVdWf97aCIdo41SMLtOnyMFNFyN2YN1w0BNdg1x7ztHfXUY0/GX8y /gTh8eHx4fEQGxwbHBucP0Wj+MniJ4uf/P3xdCN1I3Uj85e169p17TrIq+XV8l+NaEpDpaHS v3DTnnxHviPf+f3l344MPn329NnTZ/kjvlWHVB1S9V8YaX47teLtVA/7Jfsl+yXIXZi7MHfh H347/qG8xXmL8xbnTz2p96Deg3oP+N0nNtpybbm2HKKjo6Ojo6H02dJnS5/9qwIrWcnK/ESx /oP6D+o/gA+Xfrj0w6VQsHPBzgU7w5kzZ86cOfPP1//13td7X++FKoOrDK4yOP8Ei1vc4hZU vlr5auWr8OrnVz+/+vndx3vbrreJc8qRlCMpR/KvZMgj5BHyCLBesF6wXoDEGYkzEmdAgQIF ChQoADGTYibFTILSvUv3Lt07vx5lLGUsZSwQ1zaubVzbv1/f/3piGTEjYkbEDDjd63Sv073y rwC8vWm3ZYuWLVq2+Pd/rtzc3P58f3iOc4U2BbfVmQgGIT/M8oOEkkkeSS2hRIXim4vchewa uZ1yRoH+hP6RfhTwGZuoCvQniHrAZXGVG5DlkRmRfRACpgV6BlhA6y7KalEgbZEipFFAhrgq 6oK4xxi2grRDXiF7guu9rHIpClgbxobH3wRnYnqg9TYEX+6/fOBO0J8P7hFxF5wj7Wl2Kxg3 FzpWbgmID+0z7TfAv1v1GX7p4DHl0uanzeBV7ZiLKSvANoYouTa4qjkC7KfAsN/gLSwgv3E+ V6NAOqietC8BqZIQ0iawnfI65PkBvHid/Ch5Mjy2X/ns0il4lvJ4xcOvILurx7fG6+Cb7NXQ aynIqdYm9rvgY/NoY5oKEY+KHy84CEK/Ln66wDIw3NVvNw6Duw/vH3vQE+43i859Xg9ex8ee TbCDMlLZrH8Ntiz1peNruKePfv9FNhz+/nidU35QbVdlS4VxUKpx8UdF80D5SFfY0BCSBiXl JdWHIK+gA0GLQfeeeKbvAuYZelX1gpAyobNCOoPnQ/M0/xrg+Nh+xfEVOHe7wlyHwPmlK1fr AjSSWyozQflc1JMGghyg+1RngfTk3MOWMpDVJFufchp8u3l/5LcUDDuN35pSgfuKiR/ANd5V 2bUBnLNcF9gEajcxUKwH7RPxDSmg9hdf4g3s56m2DLTxAnEZsJLBr8CnjBGtQa4jPuQbwFMc E81AFOWhuABSeaGK8qAOFU/EbhAucV5EgzxFfi2dAqmwsaRpKBjWapmcAq/B9lbW4yBSDMXZ CBQRQUpZyL6XFpOyHjyb+w92CfBfFNDBrwyEHhfnpfWQfCLp2psT4EgVwpIMmQHZRe1VQHul /8jzwLvvsCV6lehVohfcXn179e3V+SNxAfMC5gXM+9fjRrSPaB/RHp7OfTr36VwoQxnKAM92 PNvxbAdwjnOc+9fj/yNJSUlJSUnQc0TPET1HgDnVnGpOhbi4uLi4OOAwhznMXxLGf5SAvj2R sBqtRqsRjHWNdY11IeRsyNmQs7+zUn9A+tz0uelzIWVWyqyUWbB+/fr169f/ttzbqQHdu3fv 3r07+Pn5+fn5waspr6a8mgJh08Omh00HZYwyRhnzVy/8z/Y3HNZwWMO/cRwqXql4peIVuC3f lm//C8MjYqVYKVaC3EfuI/f5GwX+c/9/uRJQkYpUfHfxQuJC4kLiIO1J2pO0J5AQkhCSEAJh pcJKhZUC5YhyRDmSP3XJuM24zbgNTCmmFFMKWG5Zblluwfob62+svwGsYhWrAAUFBaQL0gXp AtCHPvyN+vzXE8uWgS0DWwZC2idpn6R9Am8OvTn05hDcfnX71e1XwFGOchRa05rW7/iz5Obm 9j/LH06c4+unfPn8BLTwqBfVXoELd64+vxoCNi9XT3stKBJbQI2qA0qw3EfZD3QTVcVW0F6z SRsNWnk127UHaCL6aT+A9JGoLI8BeTEL5S/Aucu1w3kb5EJystISpAgpikGAUzJgBl7bFltG g+huvW4vCR5nKlWomQd6j/ByxWuB9tr2a14PkAKUu8YzID7GIi8Fl29asKUDGMuG9y9aC/w7 1ZlcZi84N+R8bQuEjMicRa7BQFPjN7p00JqrPo42wOfOolnHgFJqe/UV2I9FdC/8Obzcn/Pa XgqeFb4SeekUPI+43/12DqQP05fRrwCPVqYcXxO4ljn7OEqDfEi+Jb0AZYvPAf1SeDktYVFM Z4g7k/xpfDbY9tvKunpA/L6kX1Juga2stbyjGuji5E5KA1BTRXNHIIg2rkxxC1xhQi8eQOau nCj7j3Bg77HDZwbAJcvVrBt1QH4uL9NZIfdA3od5F0CuJ30ilQZzQVOguQ6IA+yQ2oJPW9/L HmWgR0JH73Y1wN/Hd3DAIDB009cw+oB+g2G7oS5kj8xZkJsCjhnO75zp8KZJarekELhW7Ub9 OyMhbWX66DR/CD4bWirgNZiyTcXNv4BnrmmL2RcqKxVrVnSBV3ejr/dlUG9rX2mtQGtDL7aA NlbM0EqCNliT2QrijmgpKoH0sTRSOgPaKO1TrTkIX1QeguYpIkR90I6JD3kfpBhqi+YgDdM2 MBS0QSJQJINam5piO2jvsUbkgmwxzjdcAX0NeqobwKO2tbrtIxDjDZPlAmCupTVU+oFVykpO nw1ynnGOvhhEdCpEaDkoc7Tw88gPwGem4a55MZjf9yin9wUPXejKiPkANOYd3swWFRUVFRUF Z3ud7XW2F1ScW3FuxblAVapS9V+PW79+/fr168NJr5NeJ73g1x2/7vh1BxQtWrRo0aJ/NRI9 lKH8Gx4bV+N2jds1bsP+evvr7a8HpmmmaaZp+SPsweHB4cHhcKXdlXZX2kFtalP7/xLv7Yhk JSpR6a83lKY0/8Qc498rp1dOr5xe4L3Ve6v3ViiQXCC5QPLfP1z/6DF8f7mSkFI8pXjK39jf f07R2B+2P2x/GHSO6hzVOQo8PDw8PDwgNig2KDYIgl8Fvwp+9c+3p2Cngp0KdoK7te7WulsL akg1pBpS/vY7Ve5UuVMFonpF9Yrq9e7jybIsyzIETwmeEjwFHhV6VOhRIeh4sOPBjgdBN0c3 RzcHLvW/1P9SfyiZUzKnZE5+PJ8mPk18mkDT7U23N90Owa2CWwW3yj9ucR5xHnEev/947Gy+ s/nO5tB2cdvFbRdDWVtZW1kbFOxVsFfBXrA7ZnfM7hjgMpe5/C9/jNzc3P4X+MOJc9kKJVpX nwp5sxxPcq6A91iPX80fQ8qO+P0pn0IBjxAf/3jI/sB6TOoMt6fd3311EQTV9Y0JKwrR1V/X u9gVIvz9yxduAZEXc8+W0kGhuOK7CncA4xp9hmkciIdSnhYLTkl94poB+pciQ+wHRssWvMDw fYHZoRp4GevNbdoRXK3kAB6ArPJQHABKck8LBjoY85Q00DXyf88f0DL0ZTyGgTmg1L1SI8Gv VPzszEzQ2p6/etMJ1lhtr1QPXA9z36QFgOWTnBfOAHCtKXKw7BtI+drzC58y8GrqXf314/Cy 9N15tyyQ+kKbxADQHfd65jUXDBalO1sge2pO5dyRkNFIvWIbDPETMtu9KQSuUQ4fbR04Kqnl tQOgxBm+MFhALaL2Ui2gDXZ2cdlA/la+hwW0Ta6lro6gthbnlQQgF0V9Bq5+zjlqBphrmBp6 bQVLLWuo1hzUUU5b3igwDTLuNq0FV5bWT/WHbN+cllYdqFmudlIqJJdLM2U3hlVjNmTu6Ag+ E3xKe16ACvtLxZX6ENTl2jqtLjx8Ee31+DzoBuotcmOw1rS9bzsPVvK8HKcAsygtDwWtq9JS Pg2OM46nGftAPHQNcnwMhpLGNH0nKOYo9Lro5+D30Pd+wCwQs9RH2hCQ7iKJi6BfqnTTtQDX bXWJcwpoHdU3FAIWCpcoB8LOWfEt0EJkEwjSBLzFANC+EtPkNSDaahnq9yBdpSK1QAtVW6nz QG6gXOAeqPOkcyIb6K9XDH6g76UN0vaAOdY23FkJ+MoQIt8GbY9oqFsF1scZ5dLmg5zsvcdj ANSY2mB51UFQPaFGjSq3gQtSOaqCFiVKcv/dd1ilplJTqQkf1vyw5oc1/3H5/5qY/b1ELa1w WuG0wtAqtlVsq1gwfWL6xPRJ/qXwaFO0Kdr0r8f/vevLZ5XPKp/17o/bv9vulrtb7m4JH/Ih H/6RQP85op6QkJCQkAB169atW7fub4u9nRNcvVH1RtUbwYE7B+4cuJM/NeXt9ibeTbybeP/z 1Wjg0cCjgQecP3n+5PmTsDV1a+rW1PztbxPyBhsbbGywEWhGM5q9+3gFkwsmF0yGlNkps1Nm g1cpr1JepUAXr4vXxYNlsWWxZXF+OcIIIwwaN27cuHFjOPfBuQ/OfQAul8vlcoHuru6u7i7U XVh3Yd2F/N0R5/+q8qDKgyoPgv3h+8P3h4M0QZogTQCps9RZ6gwNbza82fDmH3nj3dzc/reQ rly5cuXKFSFq1apVq1atfz2QFuQarN6AtLT0dcmXwWOw+ZnfPrj306MXp8dArCvWkd4biumK by17ApK65XR+/is8mPei6NlgCE/1XF8wDF4XTZwcfwxaxdY/3K8keId6tTfdAT+jzwv/wuB/ NWh6yEtQF4mWYjqoq1Iv/PoY1HQ1R1cdDBPDd5SbBvJt+wtVAjVamaqOBSFL5eVFoPNTv5ce g9rX2FYuCroT8lblDli9Hq27fRuyiu4PPBIHb0YmNcv6HnIq25fkPQNHTN7nhkjQJRWqUNoK akaVXWUD4Pmhx3PvzoK7YccK7B4FT68lD8m0QF4jD7PvBfA94hng+TXYe1jXW6tBapHMaWkd wNLFEWB9CLr2+mz9A1DtWqo4C7q2upuGdqBNl+tqqUA7VS/qgWO6fZZzGohjoqHWG6QIqQ7+ oIVpJ0VpEN4imD0gssVJTQb5idxVagzyY3mf3AHkS/JAqQZIX0hLpD7ABslMH3CMcySoFcFw Ut9W2Q+qJBK0uyCNFS2UZiC5pK/4BaRQqaDWH1zeJGvZoEuR7bqGYBisvyxPA3WOeko0A/mR dFwpCNpmV6Q4D3RmttCB/pQpT7cDRG9ti/oZFJ4RVaXACQjdFxoSvBUKDAk7Hl4Kwt+E7ArL AKfVOUL7GLJsWe9l7IHAVYHzAu+BZJAy9b1BriR/rM0E9Z66yXUDhF601U8C1ya1jtMHpA+k ZGkRKAflc7INnE0cX2hlQKmkK61VBVsf5ypxE8RgySAdAt0q6miDgBHOxq5+4Jpir2K/C9Y1 Dp06AWxr1AyKQ85A+wxnP9C7TGPMn0LhlYWLFLwI9WOqyZW+gbJ9yq4ssRSUVM8Ohntg/sgQ af5fkAiezT2bezYXTBtMG0wboJqoJqoJuL3m9prbayBrQdaCrAXQrFmzZs2a/fH9/b9m7969 e/fuhU6dOnXq1OnPro2bm5ub27t29erVq1evgjJ48ODBgwd/+eXbmyr+WfvOnp2xuDrYDM6a 1r0gNZUvej6GF7we/+QR3PB9+OzaDghe5KMVy4SmmxpNbFAA3ojEDnGfQFybhFYxZSBtxf/H 3l/GaW2tDfvwsZJcOj7MMDC4e3F3aZHiWrRYgQJFWqBYcSs1pDjF3d2htLi7F2dgYIZxuSTJ ej8897xz/7r/vbsp7N393M8cX2auZGXlzCnJmXOtJHFzU0MgelByqaheoD0Qe2Mi4Nm9Fwui 1oP5furr1E8g1+yc93PnBG9hxmhOUPuZA1yzwZrTnhT0CMyTaiVfBYSvatW/AcVU8zlnAE/E 56wEyotDugHeOXeGny0N8c1P7P/5NsSX2NB/z16IGfLb7lcB4HExJ7gmKA2dzXMMAWu5bKML 7ofAdpULl3wEr5TYhCe/wrVPD+t7G8PD1Cc5n38BcX21r3yeQMBMH9N+CeRkvbK+G2IPJ/aK qwaJF1I+T6oLTFBviX6gBSr3xX2wDbBu0oaAaC9u6KdAuSp3msvB28b7kaGCXtS4qTcC+YMc KZeCcdy4o38C7EE1BYiPlI84CFKRN8yKwH75M5FgXjNPmvnB1KVD5gJjihTyA9DjjA16D5CV 5FPzN7Ac1QqLKiCri5/lTZBXZR3hArnMaGZ0B9NqrjKDwXRSio7APrOVeQYMaWYzV4MZL7fL tSBD5CT2g5nFHG/WB7OS/MV8CuYZM0I/AjKb6K+Gw6uPomYknoGYNjFfvt4JnobeDqn3wTij B3sjIPR46JOwXBDZ/uWiSAdYF9u22AaAJdzS2B4AT1c8bfPIAGWVWk1cguQ8qRU86+Di2Stb Lk+H6LzR56OrgVbYukpbBj7RPoXt7eFV9ujouMpw9vOLpS5/CNFzX9eN3AiZf8vcJqgQaDfU G44YIFLZq7wANTeFzN5gDDOX6IOBCPWO8hOkVnKN9FwF45Lez/gVopcmzE2MBk+B1FruZ+D7 pWEXd8C/W+aA4JF/d7j/OaGnQ0+Hnk5/X/PJ2Sdnn5wN5nZzu7kdqsdVj6seB7bctty23H+3 tP95vOlr5jLIIIMMMvi/i4iIiIiIiHcwVePsT+f8jwl4tD5Xo6slwDbYSCw5BoI+8m0VFAOv Jrie3rgMwas9SlAbeHz48cyHRyF+jvtBogHnZjw6/LQ6ZIux3QqyQP6tIU1K3oSX6qvKyQvB FmEfEL8HbhR51easPxQZnf9k0coQ2C+bJ+9xcM3VvvWbC6av/FRZD+pUUcY4BSn5rit7uoFl WaY+eXeAVsH/cdBtcJ18UfM3F7hvPioVGQDiFy3ENwp8CtT01K0I/t7Mqdl2gH1CcMegzhC7 +sTuqwXBHBk0MuAOvFDMnDHL4P6+s3VPRsOzgY8DHidA9BAM9Qw4Q52H7SawXMwTOiS3TKqY eB+SwlICkp6C8rn1O2U22Ofa91i6gRxlRMhX4OloTHH7AgM5wGugg9lTfADyvllYrwvKIPE+ M8DoLf/P3NxZWnalDIgRxgPzM7ANshUQ88BMkjXVGEhJSE7STVBS1O8wQE6mvnIXzMHGPfM8 iM+5oNwDZaVYwjzw5nbHm1Fg3KY0RYBD3NY/B28V86RsAFocPymtgNGsksXA9LJBVgPxg3lK XADxvXhJEIgYsplFQD6TBagOshh9OQNKKf1D0RM0f0ug8R2YZ2Q1ORuSMiWjn4HIVS9Lv1wJ TrtjqbU90OP+cXUT2Ac4GzlbwIOvH2V/fAU8mqeXWQpc11wLEr+EpE1JNUM+gpePY0/EKhDz beJ3cSuBdQmDtIXwsEjE7Cc2KHXsPVFgF0QcfTo9ZT9E+cXmja0Fon7MOn0IKM3UifIUqI2U L21+oD2x7JPXIJc77FXWrWB2YpaRC7QIMVQbBfZa2jGRHxL1+B/ipoDypfOY4yO4kHi79YOX 8HjFk2LPJ8InFEvI/3dH+z+BTw2fGj41oDnNaQ7/7Z//IjvZ+Qs31hlkkEEGGWTwv4m3Tpxd HW1VPAo8+iq686tICO4Q0PtUP7g/5smdVB1KnA15UCcEDnrON12fFzwNjZ/NjZCTHP5560CW AO3nTED9xmX7NO4EtdbXcdc7CI9PPi77wB/cJ923UwaAi7jsRm3w9tAPub8E/Zoc69FBeWx5 6FcBKGns1L8AkUOMclcHT/Bv3J0Or5PXzdyZAiF122fvlgvss/LmLusA2648VZxJoF6zVlEn A6eUEtpj8PaLKfg8BpKynu9wZgxo1a2bEiUYB7PeDu8Gj+5dmn95Dzwtc73M1dzwKlfqTPdB kN85/H1fgq2pdY36I6SUSmma9Axe10lcE/creC7o+YzjIL4TP6t1wBPhyuL5AvQW3rVGUfAu NAvKpSD3yHixEmQmaTIBpEemmr1BpIp2BIKIUdvLsSDaslSsBlt722eqH4iaZm7qglTMIKMA WGc57ysXQW/pXmmUAzOb/siIAC1CyyvKgVwtuxrngU/EbTEajPdljLwF+mK9krkYZD8G0g7E QDVYywJmVTlOClD2y+ViAsjN4jv5Bciq5lizMjCTw3wOIlbkEC8BQ2wS34G+0EwwO4IawyC1 Apj1PQ29B0HVLEUZCGq81krbBbH94jMn94GLFa/Mvnkdcs/PeTvRDrK3vG5tCa/bxzyJyQWW ipZx6lHwz+/3lV9u8Ozy7pVAYlJykYR4SPYmdU06AcZkOY3V4DrqDkjMD8frnW6QOAPED7KG OhbkUQqrhUEpq3yvZIb7PR/eirgJ1BYTZCqYE7hh/Aivsr6sGpkV8onsjcJagf/nfl+EbQNR SC2tVQJ0/bbZARL9o3LHfA4cFEfVw+D9yPPam/aWgUF/d5hnkEEGGWSQQQbvgrdPnNebowmE 5JGvg1zxYDFiU+2XwdbIZ25gRXjuJ+pf9YLlvbDueiNItRubXn8OSStfWgIj4NP4lpn6jgLf ZtZdPh1BTGK2OR3y9czbrLAboh8lTHnuhIs3E2P3rIGAzd6J5TtDWCG1hPV9cMd6tuiJIJZp dttXYPRmqeEEdaZ/D78UCFxZ9dNK+8H+S4l6NSNAlDet3oogO5lH9ZtgbvQWZQR43n9Z4dZY iG+0c8R2P/B0iDumZwG/BRW21mwILxzJYxIS4In3wuBT4yByU8zN2EqQUkw8V1qC/xpHUZ8s IAP050Y9SDyXlClxMbivGKfNASBX8kzcAeE0b5kbQTYQsbQF00/O5yNgnixFNpAt5V3ZB0QV 9nMTRA1a4QL5pfxZ6sBiczi+YN5glpwO7vv6QD0JtKeipOIHoqt4DzvwrZ5ZrwKmxXggt4C8 bpbgBogA5YlSAGQveVpuADpRWgkH4zeZ1WwBbKC8fA5qa9FTESCiRTe5AcwW0od2YJQ34o1T gKSw3AzqZCWr2h/MabKtORHkRrlVTgDxo2gkMoPlkGjHJdD6WBrRHyiIyTzQp5lluA3u0u4k YzzIh2YfWRtEPrFRqQR3D/xW5Vkk6C6jr5EF1OFaY/UsKIlKAeUXiLHELYr/GLJbwmeFNoPY CvGv43KA3s7MJNuB56T7oDcWlFS1hNoMPJk8A93ngRbmaDEdlHvKRXUraL6aULaBMl5UYjWI a2oO1QT5oYwUW+DVjtfrkm+C41vrkte5wTrMMsh5CWznbNEB2UBatTClB7gT3DtSW0Bq1YRh 8dvA2OMMt1YGNhH1F8IqgwwyyCCDDDL4D+StE+eEr143TBkDWS5YWhYrAb0Cm0QNaQ/WB0EL vTXh4JLLhdbOAG8nZ3vXNfA5Yg9Mbgobm58cMmMcdC7qLPb5E3DtTdkiTsHpbjtjD1vAecdn QYgGek1llzEJ8g8MvpDvKjybG78ysiiEFg6Y+ewK+DqC2oRFgNnYHGYsBmWj6Gs7CZYJ4Uvy 9gfle78GQcnAMKWYFCBveY54a4MspxzUjgIubbV8Dd6Ux8m3F4Nn5qspcSdAHZk1oVBV8CQF X/Zzw51+v/5yZAM8W/pw1/0B8KqintssCNosxxS/NqCO5hN5AuJvJKcmHIKkS64yrkFgaWcz 1UOgX9WLG0dAsSoJ4jzIdqw1Y8G72bvd+Ao4wBTxFNQYra7aH8xCRmF9BOgT9dJ6ECg2pbcS CCyRQ8UsMO+aec0N4D0iR8s94JFyBQYoDiVMXALWcEX8CuY68765A8RImUmUAG+sZ4R+DGgp Sou9QAVxTLYCI1auMrOBOkiNU/YAF8RQWRHMxsanRlmQdWUnFDCXGquMHKBm07pqO0BukEdN AUpVMZldoGXX6qp3QQ6RYbIjqPvFTb4H9XNtJl+B/pHxpewHrJa58QWjqVHbiAJls6YpB4Bq zDJ3gN7bvCA1UCK1uUp20IOk19wLTNVPylqgh+ovzdXwqO1jn1evgfvKFvkcxDLlAzMMrLes 19X3wXvP63EXAuOI8bG5ENRDahNtKcggGWACYqPRThkA5hIxhDqgdiVV7gRzlPxE+wLkI/OF VCHyx+hhcRXBP9SvrM8SyPJF8Ec2OyjZuG79DNT2Iov4ArzJycuTvgetg/W27/i/O7wzyCCD DDLIIIN3yVsnzoUHhY2uvBP6yrbNh4WBj39QIcc0iO778uTrvJCUMyqv30243eXxrQcF4eXL Vz7PH4Cy1po/Uy7YZTlT9FAfcE5W1/gMgrhvvWOeZIIXDTwtfjsFyWuSQlMmQkJS0umXa8Ev 3rPFZzLk6JWtRpZGEFQxzMieAu4dqR083YBXdLO7QB0aciSPBtRN/eH1PlDOGkeNMNBLKkNF KVAOyIdcBCqYxVxe0AYExPvEgaqGzfLtBpluVvm2TBt47ePKkWyBp+cuHjzfHiJ7JXhd2SD1 M7FM8wdbOXOc8QRSzqWcStIhLjVlbMIy8DQzRxpdQe2px0kd5Aq5jnngLeaNND8G7wjDZSSD 8gNB6lIgmUfUB2OPd5lxBMxXZqy+A7Sxyhn1MxDhyhAxFbzl9Q56MRCbqSZKgHhqPpN2kH1E vOgNRhY5XA4BMYYB8i7IcnTHBfKSaEtrUIeJQASYuc09cgnIh8pKnvB/3j+6EcQOpbk4A2Kn mEwekFf1xzISqCtbUws0j7ZJCwaxQbGKwkBVpspbICqKgiIAzE/M4mZTELN5Xy4HYzx1WQHe oy5NdgCzuLwic4J1pbZCyQPmr+ZwsRHILhtRDuRyMY66IJ/IuTIY6C3zmudBXJebKQ4yizlA HgXzYy7yA3gXmPuNOqCu0j7RQkBi9jQ7gfm+PGA0BDnHzCnvgfxatpK5QR6Xq/WZoPQWU825 wHi1s3YZLKUs5RSAWhSiEOiV9VeeLmBbYd2m5oDUM+5vxECIeO9Vl6jW4HPf/p6PG3xNZ0zw evDEifEiGMyC3ij3WTCPpx5VbgEtafV3B3kGGWSQQQYZZPBueOvEObfMUT/bPDjT80rSscZw 9O452+Gc8GxE7NcRAeBYm6lK7GTw7xC42dECYpXnwzwzwbezc4g9EBKzu757VgMSN5mnE4Ec Lfx6B1wD/2kBKeUSwXdf5hRHNhAOXkoblB9bcm2Ti3DXcivXud8g19NCk/OVArpbDthaAbX1 Iq7poMUFhGX5CeRU20LWgjSNDXpNEOXFHSURlAdyqNEUZFFpOp6ArVzej4vXg0wLM4fkM8Bn SJa9+b+Dq5NW/bR4DLyIeDT68QGIHWMU5QMwdopUvgf3itQRycNBD1ZGUhPcyd4PjUVgbjJj GAnysfm5uQzMBmaouRqMCbK93ApGGTPMbAPiA6WCvAEsYRxFwOwtC5uvQG5ljugAZjyvZBiI wrI8a4FQclIfpC9lZXYgr5jCJhDdKSIrg0w0+8o44JAYz3NQuspUooCboqsIA/kVBZVpYLbC qqeCnGh+Tk2gCAPEajBO6EHyPKg/qiVEEKjPLdWVeyC3yQ4iChggh8g+wB4aMwlkXtMudwNN lUxyNZgXjcrmI5DZjGOiM4jM2sdKHFjLWEOFDfjaekp5DEpNfZ/8AozpfGPmBjnZfK2tBk7R g++AauQ0M4HRynwo1wCqPKyFgNiORWQHs4csow8AORIPs4CSZpyRE8RoYdVyg75Af0ZbUIqK AJEXRDk+MT8AkVNmNz8Bczj3xV0wpptljJYgSui6DAVTNe+IzmB8rw+QZcBTQ3TFAsp6rbaS BV7HxfilDoJXtfxCXseCc4o92rkTrM/FLOcxSPlMLDVzg+dA6kF3wH8Fya23D9Q7d+7cuXPn 33FKyCCDDDLIIIP/vRQqVKhQoUJ/ffu3TpyP5rixftdyeHIpZlH8AHAWsnbT5oH+2DhidgER HrfAakDm0EwvAyqA66vM9ue1IEsnT64ipeBFeOLkyI/A5741xHoCHqx/9Z6xFPzmxleM1MDy sTZXd4Bmc4qU7uDZf7+XXA+3V1xzbmsLmcdmS9Q/hIqXap7v+xWkFEu1pg4F1aYWczpAfOgc m7Ub8ExGyJqg1CSEvmAeFRaRFWQEMaY/iA3a8bBAsHcJe2IdCAmdn459+B5cbvNLnmPl4PW0 1EyeOEhZzVwxHZx7bYHOANBziE0iAJJLua6l+oJ3ob7IXAHiI5GsnAIlSs2h9QHzI32KZz8o F8yWZhwoUWpJJTeYjc0H8jiQgyoMA6EIj7gDzJRT5SbARnE+A2nK4vIUiG9EZWU0yB6yi2wO Wl3LeK0WGAvMfub7YM40G5jfgVpFZBahoNxSbiutwHxuBslnYDahDFvBkmjpbisMekUjm54D TMOYZLYEPpJ2hoMpzdbyFQCTzCygJCiV1X2gjFavqCfAyGt0NLqCWkQUFJtBZjNTjfIg18sX XABMtao4D0wTFvqATKEssSDne4qZgFncqGHuBRkj2qrLgRv8LJeBPCs/kH2BMrSWy0FeN4rj D+InkVUvDqKnoijngUryjrIBzEPmObM2kF1E8yOIEdQ2dgEfyzhzM3jfY5b5HogDcpmaBThM EfMkiL3qx8YskIO0kdoSMEVuMPIAAIAASURBVEoZvcVGUBsqmvQFc5kMURKBziI/j8CyQlRS 6oK3pD7WsEHM+tiBSWUgtEOQPckCvr2cWB+DsOrTyQ76Sb2icAOdefafEOgZZJBBBhlkkMHb o7xtB651nn1Rbihhy2Uzm0OpeqXaJjaBrL/mLCt+hcio1GueoXCn72/DIzODTzPXXc0P5Bn/ nq/PQt5GhQvlrwBRkSllZQcwi3I95WuIXpx04e5GeHkrsd3jzyGmdMq252fg0tUrPY4WB59+ IWXyN4bTXK6xvzIkbo3s/2AAKFbbREtfML6SmfXnYB6ivr0SUI/uIgdQiYbyCFCW+nwOSkVz hRgDZlXumT8AM5nuDYaHcadXno6GiGaP/J5aIXqoZ4n8DLSvbA+cdSFgj8/7vmNAXab8pNwG M0BqPAJrgi2nbSwo9ZSL6gMwl5hbjTmgbFA2KktAC9UKaUVB6ad0UI6AyIaFJyDuiH3iS1A+ UD5WvgSRUy2qOsCSzVLcegHkE3lB1gBLSUtJLTfYT9hP2q+AtaulidUDtpq2C/ZEcJyx93KM AGWlskPrC2oNta7WCbTrmq4+BrFH5KEsKAeUT9W14LDY5tjDwbnRfsdWAuyzrLesucH6XB1m OQ3KeInyEbDTKGDOAlHX/F4uAUsWdas6FqRJTc6DES1ncxvMrxnNepAPzVDzBIgkqlETjAZ6 FpkbzNbucBkN5hFjlHIVZDV5hkYg6gi7UgVYyAE+BYqxQLwC8aMYpSaCiBC+Yicwn4WsBNrS WV4HUVm8JwyQ480isiWYVrOY0hoUVbFYu4ElRdviPAWykrlPuQ3GK70Me4GJbFZHADPN1VQB Y71ewYwAQ+gJpgU4Ip/KJmAU9B7VH4HxkzfM3AX6PWOY3hOie72ekVQaYh/FRyQ1AVpLu7sf aF8oH7MXjNpmFr3c3x3eGWSQQQYZZJDBu+StK86Oofbz9jGQsNU9NbExhKfwgbML+IyXL/QP IGtE0If2BAi9og3wXwA5W2WyKo/ht00Jq18ughz97RXKfgbF5pZanSMaHpd9eufKQ0g6lWD6 jAQNy3eWvKDesXRKDALlmHuzbQYEHfRXAlZA5MO4Iin1YW/NAzVnh0C7VR2uTs8HyY/lEe1D UFqJGDkAZHZxX84BMhOjdAb2iHayNZgVaCd7g3JAaaPFgLdh3NX4snBdPdfjdFGIHpwcmrwE kr1yqPI9OHs6WvqEgrJXvjBOgnes+6Q7L+AQ48RWUC6JjxUBSrxS04wAfa7nhn4DlLHihuIC 0Vwrq1YDusn24kcQ64g3vgRp54hsAtShqzgG5ufSQgSYTrOcbA7Kj8py9SdQFdWp1gchhamc BEM1XMZgULqqO5V5ILaJo8ppUAdbDO1XMA+ZZcxToI8z6um3QJupjlMXgrHUTDYvAZNkQfaD ZbxaTUkA8URJUKqC0lDprFQD47reXnqAikySycBvYjlTQEwRA8UV0GbaWqm+YDx13fdcBPOw nkXPCkolxUepACSa34gYMEuJnKIyiJmyNAdBllV7qE9Ay6Ju1Bwgk2WCmQfIywoRBtp1ZaT2 PtBFIPMBP4hh6kgQsxhNXRA2ZYDsBOIZL8VjED3V+SIvWC/YSvr5g1yJXVQFdT4dlHqAV85P ugDeHzzDU++D+YPRUDGBYeZX5jNQtsur7AFsoq9sBmaguU6fAup6tYOWCOKkLKAUB8dRx2D7 UlDWa01styFxcnJB4wx4FnmbG4GgNlP9xT6QkdLuXQy0/btDPIMMMsgggwwyeFe8dcX5Vdeo sNQtYA2yTbX3gGAREpWnJbjsSnT8RbB0oZgcA/o665LUUxAZ5f46Ng+k9EnJl7oHrpZ9sf7g Hbhb89moq3UgIeZ1PVkeLNGOsfa74HQEn/ZdAmzSz6lnQXY0ehh34WHBe9anwZBYJvaK2gOe HzYuPEyAuysfDF60GJy37NetDcCcRn3DBSzlsnoEuCweSBPILJfxI7DcbGtuButsS20tBV4N u131xhV40vF+9/ufwutoz3HdH2SQmG7RwBZge602A9cGTxXPVUippWue7WDmkVdNK3hWeMp7 T4AxxTig20E7aXlsXQDepXplYwNIaZwxl4CtuaWk8giUY1oXzQaqptbSzoNlrKWJpQHYilg+ swQBV7giawAlKCXbAwPoT30Qe8Ru1oGsLXMa98C1JnV4ymvwdvUGerqDt7j+3OgNumHkNbaD Gq4WV1NBuS7OK9NB+Uzc4jJIhYnmDRCXlHFKbmC0XC0HAsmUZDSIxUoql0HuFGF8Adoybbt2 AvQJ5vfmVlCbyGWiJtiGWkvbJoPaXLtnrQVqiOZUfwRZThYVtUFazAnmMjAjmEIeUOcxUFVA e6I0t/iBWEtxZRqYsaaVpmDsMZ6aAeDt4+2sbwHLcrFXKwKWxYqP5SJY91o/dz4C82uziSwK Zgl9p7kPPANSbyX9AJ5PU+4nloeU2sn1E4aC8Z53iV4ZfOr6qYGpkPV2tqiChSBoXfCyXBfA 1tGnT6b14AwM/DDzJxCyP3RKrh8g8JuQjjnygaNPwLiQPuBXLahf1maQ+WjYgnAbWKY5VgYW BW8XfYtaBizfimXGQtA6imra6L87vN+coXWG1hlaB9oebnu47eH05dPzTc83Pd/fLd3/O5Qr V65cuTcYsfh9+7/LXv+q/cYfiT8SfwS+3PDlhi83QPVb1W9VvwVVB1QdUHUADLgx4MaAG/B8 7POxz8f+cT9bn2x9svUJTHk95fWU139dnre1z7+aP7LDf4qf/BmXyl8qf6k8DBo0aNCgQel/ 05CfyE/kJzBjxowZM2ZAbf/a/rX9ocryKsurLId+S/ot6bcEnj179uzZO5ks938nf7efvqmd 3lWc/6t568Q5x5nM7azXIXxh9kwBERCRGnM39jg88TwelnoEXjVPfuFqBzEPXb4x0+Fp+1cX lUug1TY6OOpD6o9ydlJjcFfQTxs5ICWnt6StF4h7Cfniq4LSj9cJ9cGI1Gap4yAl2vQzZ0Dq ObNzwlzQV2t7HjaAp61eW4wcsKTbrimbTsKVRsf9lkWD46b9nE9P0JfKvO6NQBbZUgSDzCRL ia4gVooyajaQI43c7gfw2/gL5S8shOjOsU/jSkFiZ88LdLDct19zLAA1VNxQOkLK9NS6KZ+B +4q8ZQ4GmVNEiS1gmWiZryWANkVtbJkC6lZ1qLISrJWtodpeMB/INeYBMDfLuWZL0NpqHdQP QK2s1lTrgDJOGaVMApEknrAKOMkT5oD4SawUFcEMNQvJrSC6iy7KF2Atr9W32cF+xfbUMQiU wco67Rsw42Ud9oMSonZWNFA8IkZdB0Zj41NTAa2/2kCtB7ZEq2LPB9p8zanNBJGqPFQqgWgo EEuBUxh8Bda8WnltOBDIDRJAKS+qi8JAHbkNH1CtYor6EWjD1SVqeZApZlXRDeRQtphzgYo4 5TTQjmuxSmMQTcUjFoO5zCgkvwe5wnwhfwERyQQxFYgX15SWoB5RH1vLgOeQt6TnBpjjjB1G ALgXpJxKegHen71HvJPBXGTOkGtAXBDdhAnyoOxm/AQUE1VpBko2rZZWCYwCpk2+AL/LfnV8 vZD5Vdbe2fNDjis5BhZ4AjlqZRuV7wfIWT17t5zDIdfKLPFZjkPu8+GdQnwhy+HA5Y5kCFxk 26PlhoCbzk/tjUGrqlxXeoDSXgxV2oAaqmxXOv99gf1X+Tnh54SfE2Dd3XV3191NX74haEPQ hqC/W7oM/oiTH5/8+OTH6b//Lnv9q/abduE9PP3w9MPTod3hdofbHYbPfT/3/dw3/fhHjR41 etR/u2E90u5IuyPt0hPEqQenHpx6EC4suLDgwoK/Ls/v9f2fxh/Z4T/FT/4I/T39Pf299Bub U55TnlMeOH78+PHjx9PbHZ95fObxmbBq1apVq1ZB99PdT3c/Df2X9F/SfwmcmXtm7pm58HXb r9t+/f/wqN/f7advaqe/Guf/bt46cdZvW5JdC+BOkwcvH1nh8vTbS27vhLDq2av5FoTUCzLl 1XOIOh9TylERlHsiyLYdopYndzbPQ2y/+Hz+O8Hb1Gib6QDYegV9Fn8fUip7eyQthdcHnmRL ViD+xKsJ7vFgjjVuysXg8kmdolaFV0lxHeObQ2SHmDIR4+BO/ogXcf1h+YXDzSbHQ4Ttds8j k8Ce3d7Grx6YOcyCehcQa8V+2QqUB9qXyhJw3Y/aFlkIHt27cfLGa4htkzrbHQNJdY0pLABr Vce3tl7gGe0taFyC1HmehalhoFehDElgLDb3GENAKOI6TcE8YTYxAdGZddwD7YDWR1sBlr7a J5oE85VZWf4G+gf6h/ouMLIYwUZjkLVkPdkXzAXmGnMdyCXmQHMXyP6yDj+ByCs8ogWwkI9Z D4zmqpkMLBTrZSVgCd/pg0CEs9vQgAfyBUdBdFbmKFlAXareV1uCslidoW4CywJts/YDyJ/k bioDm+USUQoUg0nKVRAuSovdwEiZyi8gC5lj5S1QlyutlYHARhTlHhiTzSXGOhAdxABFAdFV dFOvAR4iRHWwLLXs0xqAklWJUT4G6zXrVetxkE9xGnEgblJRNgMZbH5tnAU9SE/Qr4Bcaz6V DcG7yRjsLQ3Ji93T9bmgLzXG4A/qK3WdNh7QEOID8Db1fqTvBu9M73zjGMjK0m5sAL2bfsh7 F1J+TWmRsBEia724+LgVxCyIHhAxG1I6JDaLeg5mord40nZIzpbcKv4UJDRIyBnfHpKdyfdS vgDX5+5w7yNILJTcKzUIEl1J1RJHQvzlpG5JCeA9azT17AJba3WGeePdBerBmIMxB2PSK8Et crbI2SInNJvQbEKzCbB9zPYx28ekt4+Li4uLi4Phw4cPHz4cGm1vtL3R9vT2Iz4Y8cGID9Lb jYkYEzEmIn37PhX6VOhT4R+X97rQ60KvC9CpU6dOnTrBreq3qt+qnr6+Z8+ePXv2hEmTJk2a NCl9+c7nO5/vfA5fNfqq0VeNYN++ffv27YPWrVu3bt06/XgaN27cuHFjWHp16dWlV/9RD2kV kZU3V95ceRPaJ7ZPbJ8ISUlJSUlJ6ZWpJuFNwpuEp1c00o7zz3jXckXnjM4ZnRP6qn3Vvio0 b968efPm6etvrLix4saKP5YnLYFourvp7qa7YW7JuSXnlvzHdmkVnD+y15vq503l/qP9/rO0 mtJqSqspf1zxioyMjIyMhNCtoVtDt0LvC70v9L6Qvl3W51mfZ30ONwfeHHhzYPp2p7ynvKe8 8HLiy4kvJ4I5z5xnzvvn5foj0vSdpre0kZp69erVq1cvPc7mnZ13dt7Z9O3+qp+m6WWWe5Z7 lju9//nz58+fP/+ft8Of+cnEPRP3TNwDu3bt2rVrV/p646xx1jgLDZ82fNrwKbw+8PrA6wPv zr5prK61utbqWpA7d+7cuXND9uzZs2fP/o/t7FXtVe1V08+HnTt17tS5U/p5Lg1d13Vdf3P7 vun58/d2mn1y9snZJ9O361y0c9HOReFZ5meZn2X+1/vB2/rpu7Lrm9rpr8b5v5u3Tpy9RY0I /wngjY6xW/qBTybTE9AKMl91EvYjFAkL3RryEByZfSxxfSDxkdLnZUPQVlrLxkwHHiUNjtbA XVbvkdgUiBPfprjAmOVbIf4K+G6zexwvwSdMrWsdDJTRt7l2gW2fXw/XCPCM8pS2vIaIRhG3 lPPg+jJ1tqsqaHUCmoQchMWVtz4cMgMSZ0X0vnkatGG2z3yegBmq9/b+ApzQBikBEFP/YfEH 5eHp4+f+z45AbFxqiLcSGK+UiuopsKRaz1l6gyvJ09P9ElLGe0u4m4IoK1xiOsg8xjXzBRiK Xk8vCmYTWpv7QJYwvjAfAnFmfbM/KIPEb0IB0ViOFqvAzGc6zFzAMc7Kj8C8YV4zKoEYLLoJ QI1SU0UkKAY1aQnylZHPqAHGWT3WcwL01+ZqsxnI7NIrcwKDZR5WgKOeTbNHg3WbpZ0lGKw5 LNIaAtbWlmLW2iAKma9leeB9WYwFoPZS+6ktQTxUvhWLQIlRKigjQe2mBCt7gDX48xuY/cwH pj/QhGz0APOq3CEXA5vENY4AcWIK1UBDc1nzgtZdK2+zg62BzeaTCo5vHFF+1cDhdvTyvw6O es6dfvXANtpa2LkT/Gv6HgkqDH5N/R8GNwFjvJHJeAzmVW6zH/yWB0wJngFaW1s5+36QxXnA ZvD66u31MDDOGIVMN5hRZjVZFVxBKTeTu4L3K09gqhX0du5cKZ+Aa3vib3Ed4KUjcvLzG/Do s4eL79nh4TdP+z4+DxEtoxbETYeELu6t3iIQv8J9hgSIGBDbK7USRB1NbeENgdgWyQn6SYgO jv/YfRBST3haGftBeYDFbPDuAnVC9gnZJ2SH79t/3/779ulDzgt6Lei1oBf80vGXjr90TG8/ 9cDUA1MPQOiT0CehT2DX813Pdz2HbU+3Pd32FMLHhY8LH5d+pz8h24RsE7Klb7+w7MKyC8v+ 8fLK1srWylY4v+D8gvMLwDPbM9szG6Kjo6Ojo+HKkitLrixJ3+5in4t9LvaBKteqXKtyDdbe XXt37V34pMwnZT4pk348y64uu7rsKsw7N+/cvHN/rpfVq1avWr0q/cKRdgJPS9Rrrq65uuZq +OHXH3794dc/7+9dy/V1/q/zf50/fchx27Zt27Ztg/5L+y/tvxS+K/Rdoe/+h7el1K5Vu1bt WrCk4pKKSyrCylUrV61c9T/4yR/Y603186Zy/9F+3xVpF/a9Ofbm2JsDLEstSy1L0xP4yN2R uyN3Q7GPi31c7L9V2EZtGbVl1Bb4rsN3Hb7r8O7kSSPtxiYwMDAwMDD9xmtr6NbQraGQ2D6x fWL79PZv66flRXlRXsDiS4svLb4Ey6sur7q86pvb4Y/aNWjQoEGDBnAgz4E8B/Kkrz99+vTp 06ehcMfCHQt3hEwfZPog0wfvTo9pCdPqmqtrrq4JQ2sPrT209v+gh0vlL5W/BMMChgUMC4BD 0w9NPzQdunm7ebt5IcerHK9yvILxTcY3Gd/kzeV50/Pn7wmpH1I/pD7saban2Z5mUGddnXV1 1sH0n6f/PP3nf70f/J439dN3xZva6a/G+b+bt06c7RO9H3v3QfAi//U+TSHE4b/P0hWUAuZa oyLErzSSHUdAa2Lek/UhcKS2P1M2sC2yrTQugOu8kiNyO3hKe3fExYMnMTmHXybIdcG/T9ZE sFeS9/VGYPktab4aDY7zRl5bGbBMdmyUjyHTy6wTrSUhJCRTeX0ohLuDZ/sUgZQz0RbFChGt XFNTT8HqOxvaftkbiEuWcTVBzLcMcTYHbZesSnOIPPf0w7uF4XWh2OZJLoh7pe80T4Ka2SK0 PiDGiwrKTEjOl/oisQO4l+uJnukghhlNzTWATm2xElhjDhIVQB3M58oHIK8wXb8ARnbzaz0K jHaG19gMLGQk5cFsbHaUa0GxKYlKMChfivdZCZaeWn9RHeT3HFZKgZpXO2fpDeKGMlzNBMY9 MydTgTDi5GEQbUQDpRowWExUJ4JRR86nK8gfzCnYwdiij/ZuAuWV2C52gtpXHa2WBTrSkLsg uoq2ojOoK1S3eh3oIvzZC8o8tbLaG3ikxAkLiNniDk1B2cBZFoGqq7M4Bdp6Za9yHcRtWVYM Aq2l9UftMoRNzdYg9zDIejNr8wJO8JsQ8CQkNwSuC0nKXA9C3Vl+zVUNQrOHF8vpD4FXMpcK ywNhTbKG5hkJ9qvO8UHJEPZj1pn52oGyVHOoo8E4oM9yTwR9uDdSN8H8yjipfw3mNGO39xDI 1cYR8zKYG5iqlAaRl3hzMOjJhr/eEJyl/O8GHgbrSFs/RwswGsrKRk1Ivp+4P/4KeD5zrUwp C+Z081tjNVj2WQ7YxoOjubNW0FywL7UVC8gK5geiteMxJI/Qf7FtgqT1nixMBxmgfKa+wzvi tBPlmJ1jdo7ZCcuWLVu2bFn6Bee7b7/79rtv09uf7Hqy68mu0ON0j9M9ToPyqfKp8imIRWKR WARdZ3ed3XU2nPj4xMcn/sIJKC0BvrDwwsILC9MrAOWV8kp5BbQr2hXtCsRMjZkaMxUuKZeU SwpUqlSpUqVKsKTSkkpLKkHwxuCNwRth/bD1w9YPg7nn5p6be+7PK4NtWrdp3aZ1+nGlTTFp trvZ7ma709u1jGoZ1TIqfUjwz3jXcqUlHL+Xq+qyqsuqLoO53eZ2m9vtj/tLu7CGhISEhISA t5u3m/d/aP9HvKl+3lbuP+P3larHWx5vebzlH4/7HypZZShDGdjx4Y4Pd3wIvRf2Xth7IeQ9 mPdg3oMwpcWUFlNa/HW53pS0oeO0yrymaZqmpds/7Qbsr9rh95TrXa53ud7pFbm/6g9/RNkF ZReUXQAPvnzw5YMvIeGbhG8SvoHd43eP3z0emr5o+qLpiz/v503tm3Zj061rt67dukLmrzJ/ lfmrf17uXJNzTc41Gao7qzurO+Fp5qeZn2aGRZcWXVp06S/Y9S3Pn02yNsnaJOt/s290y+iW 0XCx98XeF3v/+/3gTf30Xdn1L9vpPyzOf89bJ862cdplpSx4f/GctUyFlADjhe9ESJihvzCS Qdtl2500COQYxymZG0Q5eck1B5y9OEQX8KjGb/aXoA0Uh1MXgW288iMLIbFLfAL+4Ip1N0/e DcZkpbW+FZzDw8fYvgPzVtILn2vw8ufoF94+oD5WVisbIaAB63yOQcC18E6pW8GvtH2IXxSc 7xQR93w5nJh/oPWSU2CZ5SmVOhLERtPryg4R6t1Vj8Mg1pWa4moN7uv6Vv0G2ExrfUcxMC/K A/IVuE67Yl1ngENsE6fAKC/LGzaQPeUp8ykYO+RyYwHIy3KjWQbkTHlU7gfZ22wjk0DWkY3k OmCJuMAy0HprDbWsYLY1y8sgEDbRWe0L5mhzKxLEfvGrKA7qp+oEZTqIKqKd6ACc5BB1QBnO AfVrUIeJReoTsF7UClrqAtfMkeZDEF6lgIgGJUV5T/kBlKnKQfEK1CHaGm0rKCdVlJegZtHK avlBe6AuUj8AZYy4oYSAskjNJg6CmlV9X7WBVtRSyXIStCjtQy0ZtLlqOa0pWD7QguyHIKhL pntZzkFokTCZ6yyQnTPqXYjvH7/h5T7wbEm+HFUR4idHlX/8NSQMifki4jkkETctsgMkfh+z 8cVkiO8X/eDpePA74bvUfgzcVVL7pgZBYsW4z2Mbg3HBE+vdDcZCb6hrLBi+ekV3YzDG65M9 wWAulCO9t0D8LLfqFUAP0KNkENg2OWMDEsBmOL/1HwF8JE/I0aC/NNZ6N4PfY39XwK8QNC2o W9YQ0LJa5vtkBlFPw34TLJXt5XyygGhoGemsD5ZOzhIBecCe355s/QD0O57uKaGgtzOqpg5+ d4H6faHvC31fCL68/+X9L++Dz2CfwT6DYYlliWWJBQYOGjho4KD09rKMLCPLgHZVu6r9f0wt EBfEBXHhrw9dlzhV4lSJU3C39t3ad2vD+YXnF55fCKWN0kZpA8qcK3OuzDnY32p/q/2twO+u 312/uxC0MWhj0Mb0Icq9+/bu27sPwneG7wzfCT3O9DjT48yf799+037TfjP9d1SuqFxRuaD2 vdr3at9LP3FXslayVrLC66mvp76e+uf9vmu5jHnGPGMemJ+Yn5if/GP7tBufPyKt4vK2vKl+ 3lbuP2NW8VnFZxWHTZs2bdq0CbLuzLoz68709WnL0/66T7pPuk/C0MChgUMDYcLLCS8nvEyf wrKi2opqK6pBludZnmd5/vb6+mcRF8VFcfF/WP9fcfZX7fB73pU//BFpiVSde3Xu1bkHO7Lu yLojK1xecnnJ5SVQ3VHdUd3x5/28qX3T5sKmjWT8UWKWNlXobI+zPc72gKWWpZalFigQXyC+ QDx87vO5z+c+6QnlrvG7xu8a/+Z6eNfnT2WRskhZlN7vv9sP3tRP35Vd39RO/6lx/g/2fNsO Yp2J7xtdwByrZvJ0Be+negcS4MX2qKGp34D+fbJQc0BQFfVkyG8QlingtyQnqBHGWbEYMh/y bRQwGTJ/mOlzMRMsdSx1ovtCaGjwIUtRcH7sl9nWG3xH2RqyHaLnJp+MPQ16Zn9P/FIIHZR9 aqqETO8FLHYWAWW7fQTfQVL++M5MAtdLt7+3P3iOOu6ktoZ1AWe7rO8K+4rvDFq8BNzVX6x+ 6AfPmzx2PAuH+A6eAG8BSNltTDPHgdrE0tnyI3i76Xm9B8A1wpPqGQqyKIPVWcBqOikVwbTJ WeYwkL2Ik31A+spz8j4YdcwouQGYoDxTWoH4Wd2hfA5yIcX5ApRWzBe1QcyTr3gAegH9rH4W zMHSTz4EeVn+Ko+BsdqYbi4EnKQgwTxvHjX3gewpe5rdQZ2ozlaGgNJKaSfqgzpSHa/MAWWN WCg+BvWlGqHuAGWfsk+ZCsr3YpIoAJYylgGWr0FrqWxX84NWTJ2uRYPm1GpodUBL1mItpcBa xXrDth8sW7T8Vn+QU0WkCAdrdpufVQOfev5P/K6AdYB9nz0XyEbmVPM7SMr3eknkBaCHd2Zy eVDuiOxafmCSvKE8BfUa5zx9Qakk5xvjwHJX6akUBmtXy2tVBZ8Z/vag8xBcJ+Ry5uWQKyzP 4EKvIKxFjk35gRzF8919LxByXsw/t0wlCJ+ap3/JLyHbrbyzSs6CrD/mnFPkZ8hRLl9C6bKQ RyuwoMxqUOta8wRWAt9bwYMyu6FAxfcGVT8BQVnC/YvcBcei4NchyeAT5N8rqAiI97WWliJg PGEtX4C6TFuh7gYZkNw66hAk5Y759tm3kNopeVDqHjAqGwulz7sL1LbftP2m7TfpldA2sW1i 28SmJ9JXfrry05Wf0tunzW1bPmD5gOUD0p9uTvu7dNnSZUuXQbVq1apVq/bPy5G2fVrFokhy keQiybC5/ub6m+tDabO0WdpMr1ylnegqX6t8rfK19H4uX758+fJl6Hel35V+V9KnBKRVIP7/ /Ffl4c/INj7b+GzjYUXVFVVXVIXz58+fP38+vWIxYviI4SOG/3k/71qutAvi7+egn5Pn5DkJ X2X5KstXWd6dn/yRvd5UP28rd9p+/9BeTbM1zdY0fS6rdal1qfW/JQJpy9P+pg1tp1Xq0m7c 0vzvQO4DuQ/kTh/y/neR9rR/2hBz2lzNtIRqoVgoFor/dtzvyE//Wf7MDn/ULm3KxlxjrjHX SE+k/yiR/D1vat9199bdW3fvHxOv3ydmaSNraVPC5pScU3JOSfix+4/df+yerteoFlEtolpA gYQCCQUS3lxvb3v+3Pli54ud/60yvyV0S+iWUChzvsz5Muf//X7wpn76ruz6pnb6T43z3/PW 73G23wqLiC0PYoW3ricMvFe9ur0nJO12D423QNCn8lHoQijYOsv8rEMh9IZvi8zfwK1IS7fn QfAy4V4HMzPYzyilAzqAmCBSUurCy2XJz42hoJ2Jq2DdAsGdgodqZ8BTPnj16xEQEfXIkXoc MrVw1POfDsmV/Kt6FSAxsafvj+DXz98jZ4KtY4iwTwCPM/LbV8Mg7rS3yssZcLzi3Q+OFAJj e3K0ZTJErEuo4loByS/cDu95MC0il7kOtJra+9pocP2k5/U0AW9Jo453Gug/UE7MATHUWGj2 BNlQbGIryJVyIglgzjVHGKGgrFByiV1gtjB7GntAH6F/pc8GrZ+2wDIKxFBxWVQDY4MxX/8B yK+Y4ggY+T37zPPAVST1QOklJos2IAqKWPEhUJGJDALjF9nUyATmbblWbgL5iNJiHpjr5PvE gbpWfC5vAauYyAgQiIviFcj6sgGvwTimz9FXgvKFNk47Bcp15WfhBiaSXZwA+YF8IleDmCQU tQjwQAtVVoAmLEWtyWCZY3vmaA3yrphv/RqUO2KsVhFcE5JzJrUG8z02e7aDLKOWsyaDiFbc 1vmgbRKPPJNAs6pWNQLU1rZDzqUgcloeWSX4TPPZHdgb1AbaTlsd0KUcbCaC2Y1e4kuwvvJZ 4D8AxCX8lUag9tZaW61AO3KxHeSvBMv1oISTzbSBpljuWIeAa2hqcuIlsBZU7XofCOji/2v2 n8AczxSjIChP1GVqCZAjZHmOgNHfFLIGiI/EBtkN/KXvDOsV0C+4BuhnwfVMC7eeAcfjkEXh 3cAS7pjlWx3EODFYmQwMfTeB+vGJj098fAJ6lu5ZumdpUKKUKCUK1BXqCnUFjF44euHohent R2YamWlkJpgyasqoKaOg2e1mt5vdTl9fdEfRHUV3pD/k8mcUOVbkWJFj0PFsx7Mdz8Ia1rAG qHK9yvUq1+GWzy2fWz6QNSJrRNYIcMQ54hxxEJUzKmdUzvSpHZSiFKXSH4JJe5gw8H7g/cD7 UMYsY5Yx0/c3Y8GMBTMWwCAGMeh/kG/cuHHjxo2DidMmTps4DVxbXVtdW8Gx0rHSsRK+yPZF ti+y/flxvmu5Rr4/8v2R76cnmuvC14WvCwfnIOcg5yAYk2VMljH/gsT59/YaV3lc5XGV/3n9 /FW5/8hP/ozNIzeP3DwSGMlIRv7j+tNzTs85PQeoTW1qw7XK1ypfqwzXuMa1/4/+mpxvcr7J +Xev19+T9vDYJH2SPkmHhpkbZm6YOV1PrXe23tl6J9CFLnR5d376pvb/Izv8Ubuix4oeK3oM 7FXsVexV/vkpGn/En9k3V8tcLXO1/Mfl1inWKdYp6b/Dx4ePDx8PWeZlmZdlHtyecXvG7Rnp ibanl6eXpxdUNCoaFQ0YkWtErhG53lzetz1/Pnj/wfsP3k9/mDI4d3Du4Nww7d60e9PuQUzP mJ4xPf/1fpDGm/rpu7Jr2g3YP2unoXOGzhn6Hxjnv0f8n7lsUlasWLFixYpv3kG398bcK7EX ygTm31WhPrii9fOeX+Hs6dvPTl6GgPXOAT6jIEtZ/4rZX4D5Utlr+RheP3v5QeR5uL3gYcn4 hhD6Q5YTlptQ8nrYR7nOwuNmr3u6veDfgppmX4hqqU1IGAI+tuDBektQrhsV5QJ4vjK+jLs2 BPUUh7LPB/NJ0riUXyBsatZRmeLA/4Z1V+ptiCuV7HC5wbtVOxA3HfJcDS5VqRcUfBTsqueA 7ZcW91q8FC6XeVLy0VVI7S87WBdD+Ons4/LEQlJM8sb4zfB06vMGj/eCUUDk1x6AecywyS6A Ql55DUQ7brAUzFBpmkVA7pNnZFcQuUVz0Q7ME+YBcycoudRBSmVQ1orL6gKQt40v5AvAIXrL 52B+yjQxCcxfzBvGGVC+wUVjoLxcJ5qDqKKcF8NBuJU76GAppGFvBOKhWEIvUEYrkfI6KL2U A+oWUCLUrbaJoB3X7qt9QQvRbts6gZxMHnMDyOsyVbrAfsx+2fkIrJots7MNqM+UYmppUDKr g6xnwJJk/dyWFZRY7bnaGYz94mO2g1JOPLQcAW6ZoeYdcEe6aiTPBHYxwfgUHL3sXewvwVxp nPG0BH20a3jqt6BV0nZYB4Eob9lpHQ3ie3WldTbI+axUPwbTMMPNVSBPihBNAfFUWabsBXO3 eVifD66lqU8S24Piyx6ZALIO/kon8EaajdVSkDo+MVfsBXD39aam9ofgnsGVQz4D3+99k0K+ Avdst09qMdDPmC9SxoNlqbJd3QeWfI5hwXXBHeNu61kFgV840BaAcoAfvWMgrlaiJ+kbUDdY n/g9ATW/8iExoBzkip4PcpbLHG/zhcX2JZcW/fLvD+wMMsgggzclrQJ5Sb2kXlLh2/bftv+2 Paz1W+u31u/vlu4/n7SRmrQKcgb/uzhz5syZM2feQcX55Q9xeVUvnP7xfvit0yB3ex4njoSQ fj7fOP1A0f2OK2cg+pX1btRWuJB4Jur1BfCt6DgpToCtlayotoFMswnKNB7UAr65zPGQ97JT tVyCZ2eePI6JB32bdXJydojvmzLHWxO0vOYxn1BwDlalZQ548rsT5UpwbgscJI5AUj6x7EUL eOkXd1MvArZdtt6+xcFvmJnTdwqUH15wT41nYChxLW2TITZHwi+JY8H1hVHOqAvKZq2yeB/E LvWMPAVui/sDbxMwKutLpQVklFbcFCCXmePNpiBDZHZ5BWRFBsksYJ6RR2UMqDfEHNUCZOcw zUHmlw+JBrqbPcRBMMbIzYYAauGSALdlQ/EDyHMiGBsoA5SjtAYlVHymHgMey1siFqSfPGku BVqKMqIiGO/JnGZ2cPS0XXQGgzpF666qYB1r7+/zG/jPC3gR8huIg+Iz6QJlmOhjUcC0Gl08 K8E0jcvmcbD9ZrfaF4BWwDbEvhTkY9He0gzUFHW4KsByWt2qfQB6vFnUUwWE26jn+QBkFWkY NUCprvmqHvA57TfKJwnMAd51xkggxuzo6QJC8JQhYLvl2yrQC1oWrZkWAmoPbY39MZjHjZ/k UBCnRRN5C8yWHJUTQW+of2TUAPO6fi61CJir3EVTjoC1vvQxboDngRFEHLi/8i7Qc0GcEvNT bBFI/iHl59isoPWjiRwNuuLqlvwrmFWz3jM7gr2ko5DdC/ohjyG3giinbJNzwbspOWv8GJBT ZXd1CLze666W7AJzmVlIbwGiu/W8dS9YsxqTXJvBGKP/Jl9CYE7f73zLgNYHp3oLWPZ3h3oG GWSQwT/H7gm7J+yeAN8nf5/8fTJMmT1l9pTZ/HHJL4MM/h/krRPnnC/Dlin9Ib6r62RkTwg4 oK501oVMHTQfxwqItaRkT2oI7pHaL/rnUNwsGORrQEp5Y7HsC1qCutk+GWyvEm9YRoFZIdXl rQeBZuAV32lgT3W1NiaBj5/4LttIcK+3f/bqBbivGDNTTwD7vQ0dLUEsYGBsJLgq6F20a6Bt VUpoCgQNDmkbfBxct5xXXYPAHB070HEZQr4KsOYOgV9vnux89DB4TjKXvaC31781x4Fls7W4 aAssEG0IBO8UY4AeDNZAh+kzAyzXnUF+caBHeofI28AlHCIA7BMcdud5sA21XbOXALOg8Zve C7xHdOkNB+WOOl7tDULSU1kDxhyjvf4pKFeU92UKWG5bo/yqgWkVD8xywGoZKTaCNs9Sz7YS eC3zcQSMYG+4+xdQB4myRknQllq81oKgRWmVrHlB/VKzWjRgiSKUL8GS3zLW2QTMX5HGftAG Kru1T0F0oofsAGoFda4aBMan5nk9J/AVD5VeIMaJDVwGtsma8hnIZrKXXh20tlyVB0B1WLs7 yoIRJ9soT0DMUpuqZ0H/1FvT2w3kj8RSGayfWYbYioPjsP0j6wVw39bnyYZgLjUTdQvIgeY3 Rigov4lWuEHEcM/wB+M9kpVuYNw3epjtgTOyuswDvid9gp3PQc7Td5jfQOS5KHvUCIhxvB7w sjN4WrmrJz0A87hx0GwKqRe82c1nYC7hsOIH0eejWkUOB5/ZzgEBucDW3pHJ9zeIP504LSY3 2N93eq2lQTxVJ9g3gDfRfdRdG2xjVD9LR7D8rP+qnIGUWG+25LngzOtbNGA5xM9O7JzkA74X 1UDLlDcOpwwyyCCDv40mL5q8aPICmtCEv/AWt//n2fZk25NtT/5uKTL4V/P273E+kJjJlQ1y dQ5elwXwLWgr4nwMSaXVBD0Y1AX6b2o0ZIrQ8vrUguBcuS4bn4G9oj2L0gBCmmQLDz8G0aol Iq4IvMz3srD1F8h3z79EyRDIrIYVDFwKmVx+d9wmZGpvSw7rAcpXfGJtCNxnrdwJ3tepbeRx sI2xzNN6gTOPrZH6A7h326u9WgAxzaJuPzwA7xXJc7/0VhBjFD8awtOikRfu9wXvl+Y1wwHm TbMGP4H4QmmoxIOZ18wjeoASrXVSX0BghZAToTshNE+WZXl8IVvnPPcK+kP44Vxl8+sQ1DHz 0+wNwMcV5Be2DHznZPos633wV0Pv5mgCgb+ElcvtAH89tEbO/hDQPNOP4cvBNzCwfqgT/DoF 7c+yBfxCAtuE/QL+l4Kuh5YDRyW/G0HPwPG5X/vg0+BXIGho5sPgHBnwfVgBsC70uRm0BdRw R3P/OiBKWTv45ALrAXsp3wOg/mxNcMwGax3bHZ+VoI61uhx+QCPbPOevYK5XaqmzQKmoHrH2 BKWl+sxiAVt/yxPbarA/s0c5DoDR2jxthoOYqFXUfgRRVT2o7AUt0hKu7gARJSKVILBPt19y jgOfFj5ZfBPB7vSxBHwCsrvIZtkFygCjh/kMtMciihhgt/meSwVPhLtg/IfgypLaK2kOJNeI Xxg3EFwdUtsl+4LyVFmmzAJlhbbHOhKM+eYUT1UIbR942bEUshQIKRhUC5T+yjKbBvbH9k6O DpDlXi7fXFbIfDnH2RyjIPDDwIqBu8Dfx7+obyWwPLM91DJBYIPAMsHPIaR0YLewOmA1lGvm z6AV0M4rpcC8rHhEHBgzRD99KNh6W+tqy4HxjKIJ6KNFTzaCdzA7+Td+YjeDDDLIIIO/l+yv sr/K/urvliKDfzVvXXG2fKZ/EzgGzNYxP1uawqt27qWp60ALCXKlloLEvBww9oBxJPJb92EI Ku9coMWBbZu6RvGFuDHyxMMkcGQK6Ok8BMnHXFMS1sLZxdfPnQe0L6wT1F7gOOBfh0/ANS4x Xm8Celkq8xP4RPu+UGqBpZ7rpDMEvO1THntSwJ0lqK3WCCwTU/x934cQizZHtodChbJnq/Qh yIGpw5RU0PaaP4tq4P5Q72XkAm9R+Uz2B0czdSTPQRZklSwD5OWMNha0s9Zl/p+CUdXc4H0F 3kUpg1KugmwjG8troPyoDbT2BvWM9b5vNlCXqCUcS0Dpp7Z06yAH6NeMxiDK8aHRGkRTNTdV wJKkLvdxglwr13hLgVnRrGUWB6WBsGiLwEyluFEfmCjqKkfBnmz/xM8CwibXm6fBkHyBD/CN KGaOAe29//PWDXWKmCg7AC9xug0QrVmprgRxk2jZArQWZnN9DZi6JyFpBtBE+cL6EJT8apzW H4xJejheMNvwIT2BibKvbAzUk/tFJjCuGI2MzGBU0u+nDgSjob6DoeC55X3hmgwpM+NjYzKD 7Yb9B1tHsHe193UcBR8tYFtIDxD+Yro2GZReZgf3CDCHyl0iL5gXZT8+AdtENbNyFFIquqt5 e0OsNX5LYjLg8mvumAKWm+oadT74nvP7JfAaBOwP+T7LJVAdzpdhA0F5rIXxIajv2QZbKoA6 2xghAVlXlJGTQZml+VqiAUPt6xgC3qDUxclbwXUmpVmiDYIm+TXz2wZqAbWYtSukjHF/m7IO jHZEqvtAL6QbTAM1n1rFLkBdap1BEaCotkPrA0CnvzvIM8gggwwyyCCDd8NbJ84vLsb8lDgX Ho5RD8e0BXWzXzE+A3uXlPq+HcF0uj6WP0PSVo8lNR5Ml+uVvQOEjXc8yuWE6K+TYm9fhXzV bB/b80FKJq26lh3ixrrzG53ASErsmnIE/Irn6OGZAI7G9jXum5D8y5UJrp3grWotpukQttrv dVBfcLaggX09ZGqvrnP+AklPPX0im0PNbWXc9e9Cnt2ZBhfaCI/st57dzgLu/vKyqYARJoYb RcBYwUr9Fsg65hDtAMh8coioD7iEv5oPlPctix1VQXZXcmk3wFbKMcvvLnjXefN6poLWwBqm VQelsniiNQSzhF4ltR4QSKTxIfCVmSRGgXJLbS3aARFiptYDtOPWho7eYGyQsewCaz7rJIsC 8raeYNwB+ZPRhsegebSVYgV4ftLPpUSCOUs+tQ0GbTpD5E8g2xiDUquAt4J51dsLPOP08a4c IBoox+QcsA+0bfXtBa7v3OEpI4BOSh7qg/Y1H9ligHxaVm9eED7Gx3QFVVezakPBGGS4vR+B +Yn+nvceqCWZYd4CV7eU4klNIH5dfLXXh8Hd3T3dVRiMZXoNVx6wZrO014aBe7r7uigNySHx w5Th4L7lHpvaDUyPYtgmA43Nvt4ekNowKSFpFfg99z/utxhsj/0IPgS25bY7tjJgCbbksZig H5GVjLLgKODoa/8StAaOj30fgv69PEpOCLmXtY71B3AvTtnj/Qy8Nb1Rrk0gIoTbWxrc7VJr J1UDczzHxUlQNim/JLYBd/XUuom1wK9c0LAACzj7+U7xPQ3JBRKaJN0CcdRI1NeBtlpYCQT3 J24b9cHzSerZ+HtgetTMpILfALWwT9a/GFQZZJBBBhlkkMF/JG//OrouzuZJjcCWai/s+BxS 4/Re5n4IaGCr71MS8u3P3cBZBO5mfXoj5jW4Tqb8qD6EpJaukMi7YN1h36iEQ9zhpGBtM+iN U2cZtyD5vlI8NTs4CqjF/I6DuPl0S4odEjqkvvRq4L2l7/M9Bm67UcqVGXImB+70PIBsH1eo FLQJlIuOprHvQ7FeepPyj6Fco0Ij2zUEZxnf4qFRYD8h9bsRoLa+1E08AX2FPki8AnW/mVNc B6OdGOmZCmZ2WcLsA7SVq42cIJeb2827YPnaUlBrAp7+Zm+jBKgN7OPtsaBs0xpYPgAx15wr d4HoqGf1xoF+3OhsXgNTkZP0C6Bel5ktfcFy3LrGWhC8G719jQnABrFf6Qv6MU9LfSEobcmi rAbjE+/z+MXgKZ5a0NMR1I7qa+dEEOWtBZRDYJb3Rrm/BDnOyOutBcZtrpnLQMkpU00/sN60 rLeOA5cl1S/ZD/RwvWrKIdC6a+stoeBZZ1yW34Bnh3u3Nx9YF2iKbSwoF5WS6mkwFumX3YfA XthyVd0HrtikfgnTIaljYtOYcWDO1xcbD0Dv7umV8huobiVW+w3MIuQVF0Hvrh8y7CCaysHe 7JDy3auGLzSwhTnX+jwGZT+DhBeMCG+qNx6iG79+nboLnG29I40g0GZaqtsDQRmh7NSWga2j bbzVDkZfsUQbCgkV3BON4WAGyd/wgHe2Pt6bBbQZ1u3aUxD7jK+USuD5yvurfhc8/TxDPGPB 3SC1fOJhULNoe2yDQfUqmWVj0D/3SM8geLH65Z1XgZAclKDEtQBrQbWCzAe2dfZ7vt3AUl8b 5eMEd8XU26lfg/ZE7WwDlF3mWXcFoCnwF94jmkEGGWSQQQYZ/Ofx1omzcUZfYSkJodcdxe0m PI9LbO3dApoi7Y4WkNra28s8BKnTYudZBPhf8s/rnwwPekVkfvoEvK1Sk9Qu4OfjN0fvAFI1 H6nDQTwwOsTNBnOHOlY9CDFfP5+sVIawz4J+si8F31o5VpgVQLmf2M/ZA/zaWiOSNPDmfVzS nADt6zeuPOkTyP9Triq1poMnQM/PNFDzKH2NTCCOxUz0ewbsfv2LNx9Y+1rKWx+AsUJ9KF+A cs3oonUGsZ9B4gSY982R3kOQejjxXHRV0IM8VR2BoPRSotVoMDdrz+yNwHysjbPNAznBqC4L gW2Rva69NFiD1KnWaZCa39U64STIJgzBD7zXjL3GL6AKS08tJ4jvzPGenmDW8bRzXwMcajt1 BLhSks4m3gKzsXFPfwjWKHtRGQceb9KDV1XANtdew/4cfKf4dwnqCeoRpaRlFegjjfuGDTz1 POtchUF9YolTfgBRlivGIVDmaktsd8HbXDpSr4JWj+ZKe4hrHLM/MgUs9dQE5SyYWcy7+lVI XchKaQGzhjnVyAfqNDVR9QM6c1rpDKKLmIcOelFzhHESVH/9nPgCvPX0+UZ+MJuZO71TwYwy H4nBYEawUowAStFQrALrNcse62dgPOCYjATvYHkZCepA0UiZDjJFIiuDjJC75WzwNHXHemeD 2UaJNDxgHWU9Y3sIeqCnlpkA7iV6ubjvQETqW7wVQSmndhOPQPtOuLWsoE0PaBY8HpyBge6w I8AD83O5EuRwfbpeDczCnp+MSeCY5dyACcJDJe8ooL3yqzUZaCKWi63gl8fvQfC34D3kvmuU hoQur+0vhwJxf3eIZ5BBBhlkkEEG74q3fjhQa2i/Ln+GhAbGuKheoK/ynHSfg9jKMVlSu8I1 z52hSXkguZFtBw3h9UNPg+dTIDxr0BYZDlmKZrqtLIHkV84pKXeAfayQnUDpqgZYHkFwF8th 72SwNVcLmmPhUfWkwLjrkDgmOVh3gLsjP7hLQ4knYUPrPIV+JVr/sO4G5JmQM1+d5ZDy0PXA 6wue7N7343+CZw+e1biyFKKb38wWMQQyp9i+cZYHm6b+oNpAGaSc4AHI+6K1cRbEWmWXMguk ZkbyGORuo4U+G7Rh6lrrE3Du9rsQFgG+XwV+FVoWHKpPik99sJ53eiyjwHbX9p5aCgTSmXQL HGsCjgSWAd+7/tWCW4LzkqOGLTfYgrS5ejlQByPkr5AwPP6D18cgqVzCzpjqoPykPtcSQG+k z/I6ILV8QsWXDjD36A29D0COFxGqPxitZYC5EvQRenfXeTCns17eA3t5+3lHVdByWupa94P2 i+Wg4yTI68oay2uQX4o4iwRPD1d1z1jQ63kHeMpBUrbEB9EXwPUiNVNCGKQ0dE1NqgnyidDN VWCulXflBhBNxBbpAxyjhdgDpq/R0lgL5iQj2KsD4/QunqFg9PMO121gvjCXe1uA95D3B3cn kEFmW3Eb3GW9kz31wTrYfsm3L2jblS+tG4Hn0ksOUHdo9bUu4D2r99C/B0+EZ13qKDD7GbH6 HTAr8A2VwfKrbYQjEtQT1ml+pYH99nOWJ2Av6yzoWwecCwOfZnoKPjX8C4RmA1sPS4KtEFjG W17aeoDb11PA+BW0/kpTtR04Nzkf2luBTz6/lkHREFAz2BrSBXyiA6r7J4Clrb2p7RhoB2UL bxFQV9mqWN7Rx0/+k5meb3q+6fn+cXna+0z/XaR90WvGjBkzZsyA2v61/Wv7p38BLO3DJs+e PXv27NnfrbX/e1i1atWqVavSP2SQ9gXIATcG3BhwA6JzRueMzvnvk+df7Vd/5M//2/l3x+u/ i61Ptj7Z+gSmvJ7yesrrf1z/n+bfGfzfwVsnzi6bbWTCXnD4BZ71eQKWRz6lZWtIijIqxJoQ /VnM96/XQ/aFlqSAsxBXKaGwsh58c9n2Z80FPjnt3yjnoWCukMe+MRAQ55OqLITcvfz6hE0H LVEron4FlktyuXURaBO97oDCEH325Z2kxvDedyHWQl9A29vd7kw5Dc7vQrRs+cH9oys2aRaI XDJKLwPxV18Ev+wJamfv3YAroKxODDfmQ5a4rLr/JlCaiHtmFVAfqw9tL0AONtp4W4IIlzX0 D8A+0PbYOhN8fgiaEdoZ/D8M65rtR7DN8V/olxnURNtj2ymwdHG4nOvB71yQPXQZeLrpc5Nf QJIz/tzLbaCe885N6gyegJT68fPBPSglT3wNSCmV9FXCIcAiN5pnwVf3qx40AtQb6hw2gHLL ukxtBNYdTrfDH+xfOvb6NwDfFUGxmcPBJ5+Pr+9xkD10t7EJZEHRV+0K2jYtWd0PZh2zu7cu JA9JHp7wJaQudMuU0hAz92W/Z+Xh+Zlnhe4+g9QprscxB8D9nqt86gLQd3v3GbXA3GQcNYsD q+USNoOnlCfOMxm8Zb2K5xIYVqOUnheUvkqo0hhEVWERPcFsRwXxK9BCiVNmAIFii1gN2hS1 n3UjqEfESOEEbwVvlZT3QDmsZletYNtry+NzFTTUKlotEMWFIlJAmas11o6AmmpfaS8D1ofW rvZQULurLZVRIOvrB/QPQZyU8d7bYBlnS1FNcBxwlsw8EMymyky1HSgfWefaI8Ca2RJknwLG Js8Fz31wfZW0Nf4CUFPO9j4HKjLS1QXcFlfjhMWQsjflTkIrcB9znU+sDe4LyZOSX4DZx7sz NQ5s3ZxfWd6DkLEhL8O++bvD+1/PhqANQRuC/m4p4PjM4zOPz0y/EHY/3f1099PQf0n/Jf2X wJm5Z+aemQtft/267ddt/25p//M5evTo0aNH029Ean5e8/Oan8OQtUPWDlkLJz8++fHJj+G7 wt8V/q7w3y3tu+M/xZ8z+GscaXek3ZF26TdAUw9OPTj1IFxYcGHBhQXp7f5f9e8M3g1vnTj7 mO4+mSdBoOlrzXULwsv7nwj/EOrcybW6XGFosL3mwwqnIXho0AORCmWn5T+UvTPI/Vo9wwO+ D3ymBd+DJ/mTZiQ3h/g8qT6W5mCUE8NS84CyWayzp0DmZYGFstSD7DdUv9jq0OhS4R2lBkF3 v95XZjUAV5DsYFYD44rnQWo/0GZpsfZjkDo+uURCADh62BcrZyA25mmB5yXANs9qt0ZDkYFl osoKsHXXfhTvgVZcbLNUA9ncjKQDGFHiQ/VbUEztV/sKULYpD8RtkM+NHJ7fwPDx2FO6gPGr q37iK9CPulon1QZPtpTmSR+CNIwslmXgnOtjBq8Ad9aUPsl3IDVzyut4A4xv9PfkaVBaKg2s ZcF93RidOhq0B7aV2lNw5gu0hCSC7ZzPE79J4HcvOD7sPjiSg9aELQLLDttrhw56sq7on4A5 xDhvLAZhmg/MacAEo5RRGTwe13rXcLD2tdWy1AbtkrbDkgB+Y4O3h/SB8NrZHUVGgd9gn9/C vgDzR31EakMw3jM2e+eDe4AnyH0NPKrntLs5GNv0RfoxML1S6mXBO0zv4p0Iuq95yACMrtSW T8FI1Rd7ZoL53LjgWQ1qsrJH/ADKFXWPpRVoeaxxvqvALzhTlcwvIcgM+TR7ZrA2s8/0KwRi of0H5+egZrWG2+KB88Y3oj9YO/GedTjIHCJa3QRyIk61AKgPtV8sv4AsLY+IO6CcMPLrr0CW 8A72akBlo77xK6hblFJKJiBe/cyeF9Qp1us2Fezrncd8xkLoJ5lnZakC9r6OaQHh4Nsz4GBY ZQhYHXApLBSUaK2x8zaIK2oeyxywXrGd8mkD5lpthCMvWIraNzprvLtAjYuLi4uLS/90aqPt jbY32g7NJjSb0GxC+qdf09rt27dv37590Lp169atW0OLnC1ytsgJjRs3bty4MSy9uvTq0qv/ uJ8/qjz9fvmYiDERYyLSf/e60OtCrwv/uF1apafp7qa7m+6GuSXnlpxb8s2Pv9WUVlNaTflj +exV7VXtVaHt4baH2x6Gzp06d+rcKV1Paei6ruv6X7fDP6uf3y//rsN3Hb7rAE3Cm4Q3CYdv jnxz5Jsj6XZLe3/urGKzis0qlr79X7Xj2+pzT7M9zfY0S//9aYVPK3xaASr2rdi3Yl/YP2X/ lP1T0j9N/Lb6nH1y9snZJ9Pt1blo56Kdi8KzzM8yP8v8j9v9mV+9abz8kT+/aT+RkZGRkZHQ zdvN280LzZs3b968ebpd/8xPVt5ceXPlTWif2D6xfeLbx/G71mtSUlJSUhIMGjRo0KBB6f6c NqKTpod/9vjelb+mccp7ynvKCy8nvpz4cmL6lxD/Lv/O4H8nb504B+QOOOjMDUlRSccjV4Ln UvLt6LagnwfvjzBm4MfJ6yrAJ20a7+63HkIz+/mnpkD+XtnqZx0KWedr/f1OQZYPnS2tyyFT zsydjBPwwvAEWW/Ck/eT7kRPAiW/u+zdPtBQLW/5qBZ07tBbmV0MlBYBpfwFiFLeaWpxEO3U IPU66DfkSOMESH/zE89jSO7rXeT6HuK6v3gVOQJyfVvqRPVX4LMgNFfOMeBItKzVwsCeT/O1 BILRWe4w54LiwMf4ANQJoq84Bu6HKQ1cr8FdwLVffwpyrnkNF+jSHezeANKm1/DOAGOf/rXn Omg5xAajD7DPWtURC9ptu7+vBRw4a/g7gPetp5VDYN3hqOb4BXxD/RODS4PjvM/uwIlgG2v/ 3jcSLBGygcgL+u3U39yzQYzUKlq8oO6z1ndUAwu+tuBgsK7xLRR0HER/dZvlS/DMMlepLcDS 3JkQUAqsvzqPZBoKTqt/3/AT4HvYr2DmwuDbIahsaElwtgsaGzYXsg3IO7H0lxCalG1+3ggI 3hk2PKc/BG8LO57zJ/D9KCg6S02wFLEl+waCkmSp7zML/OoHHAirCEELMlXJfhUcvXyXh2ng 9yA4f441ENIu+6iiyyAkb852JTZBsMgSnO8bCMkeNiL/I7C39jmReRKIuko5tQRY6qq/iE9A mS2dxq9g7DWqpJSG1MepHeM+Be+XqV0TZgMz9FquTmCEeD5KCQcluww0a4NRS1+v5AAzB8Ge BWC2lBUsCngqebIb0eBd65mX3AOMPh5P6kRQCsnCZj0QC7jNHOCWMOVH4Cnh3uVpDPoOb7S+ CmRO02POAsVHGS1/BL2ge5OxEVQrPuICOHNZLDLy3QXq1ANTD0w9AKFPQp+EPoFdz3c93/Uc tj3d9nTbUwgfFz4ufFx6RXXt3bV3196FT8p8UuaTMulDlsuuLru67CrMOzfv3Lxzf12eCdkm ZJuQLf33wrILyy4s+4/tateqXat2LVhScUnFJRVh5aqVq1auend6SaP8pfKXyl+CYQHDAoYF wKHph6Yfmp6ewOR4leNVjlcwvsn4JuP/hi871B1Wd1jdYemJzvph64etHwbtpreb3m46LOm7 pO+SvrB23dp1a9elb/evtuMf8fTZ02dP/9uUlq5du3bt2jU9Efzoo48++ugjuOW85bzlfPv9 hdQPqR9SPz2hqbOuzro662D6z9N/nv7zP7b/M79603j5I39+036mx0+Pnx4PHzz84OEHD2Hb tm3btm2DHHtz7M2x95/Xx+pVq1etXvX29n/Xep0/f/78+fPTE9idz3c+3/kcaq6uubrmavjh 1x9+/eHXf/743jWjtozaMmpL+o3qH/Hv9u8M/nfx1g8HirXBB6OXgr2KZUdQW0jZGLfT8wxs z5nv8IHdE3YNn3EUzC2u7okjoMDjLNdqTwdrsnupZxg81I3j1ydBsRv20dXDIWWa8MRWgZ/D z9WMyQOFKoeMyj0Muqzq0u7L3JD1TIG15Wzg6eP92vsT6F08O/TFoDxQX8kToOQiTI0BfZ03 3BUIYqgZZXjBd6V9fXANyH+73E/Vi4D/vmzOoJKQ3C5qhnsSZGocuN+vEmj1o39M6QuygXud 2w3yobmWcqBc04aqg0DMSj3sOgKpnybWjZkPHq+1u/MYWEpoL5gDLjP1O9c60BppVyxXQI2W l2VuMMdIt1EfxC4RIraC/kKv5/kVLFbLFZsDjC9c6xJXg/51cpwxGISuPtbWgXWgvbvvPBBD 1FuWYqAm2r5XloF+R1/i7gtUNq4Z04H58jcjL4gIJUxbCsYd+VodC0p+5aQxEsR7POEQGA/0 PeIyKCHWjjIbsFc5pU4Fc5ae17gD2m1rX+u34JPDsiHsO3C2NKNCk0HpbvFT2wBez5zUK+Cd 6XmZ/Blw1pgkPwXVo3UVfUHOFWuUcmCZrIwVK0F65DzjIhh1pSLKAAhdrQTSn6dKR9Abmu0o BkZL3enuDrbC1udKceC60dVigpHfcLnLg/26Fq5JMD63HrY3AmUvfiZg/8DSUMwG44J5VdYD XeqhZjSYJUS0EQLKRGWdZSSo5bRCjiBQTXFLuwpagFJHTwC9iPelZzCI9XyhRoBWVs1p6Qvu D9xXjI7givHcNlRQ2iiNLLPAUM1CcjswRbrENRBVVa/9WxCXLTXMHuDjVZvom8BuWLuosf8V JO3ePlBPdj3Z9WRX2JllZ5adWUBZo6xR1qSv79q+a/uu7eHDjz/8+MOP4ecCPxf4uQBc7H2x 98XesD5ufdz6OLhz7s65O+fA/ND80PwQ6EEPevzrTjBpF1hLiCXEEgLeBt4G3gbAec5z/o+3 S6swPd7yeMvjLX/cbxrnz58/f/6/9Zdrcq7JuSZD9V3Vd1XfBWsyr8m8JjMsurTo0qJLMIpR jPrXHfY/UHJOyTkl54BYJBaJRf8fy7eKrWIreMt5y3nLpetnSaUllZZUens7vqk+88TkickT AwQTTDAMXDFwxcAVkHNfzn0590HH7zt+3/F7mJxrcq7JuWA729nOX6dJ1iZZm/y31ze2jG4Z 3TIafhrz05ifxgDHOc7xf5T3j/zqTePlj3jTfmRpWVqWhgnZJ2SfkB24y13uQv3N9TfX3wyT mczk/0EPbVq3ad2mNSg3lZvKTVhydsnZJWf/uv3ftV5/Tvg54ecEWHdh3YV1F4BOdKITtIxq GdUyCpbMXTJ3yVygKU1p+ufH96789ffx/2foJfWSekn+bf6dwf8u3jpx/s36WyuPBtlj/Nsa H4F9ivKlOQdOrX9W+OJJ+KX1w/ZHd0CBK8HLw8dAkbH5bxTdDq+64f9iFVyqc+fsqzmQ3ZG1 vZ4MOJJ9XV54r1jBT/NPgI+ytVs+sCEEWbIGlUkA99bkSSkHwUiyvJanQWkrLmufgZxmrjQa glJYy01PMNq6ElPuAlO0F9YLoBxQVvscAOOia8bLOeD9NvUL23gIuR3ul6sL5EjMMSf7eDhv Pvo+ei8opzyG0gLMjmZvMwm0epZytq9B7PPm9C4CNZN9gqUxWJooXUQM8IVcZgBiJ0WUJ6Bp lu/sm0Cd7WjnfA2itt7RK0AZYQ4xbSB+cukpNcCbx/3ENQtMzfzIuxS8Nn2FSwMtQe2orAL9 pRlhXgBLVUcrnyKglFavaz1AFjO7yk6g3xKaLAiyslHSuwjsFWwzlBBwTLC3tw8DGSVV0RWw Sn+zH7j6emelHgW9hOtD0QaUutbK9qGgnBW31S2greMjJoP1ki1KRoDYwVwzFOJaJL6fnB14 YbySK0C7pEVbD4ESbm2s3gPjc9ek1Csgd5nb3cUhZbZ4wEFQDXlWzw6W3eoBrTCIq3KKmQ3U F1Qy2oByT1Y0ioMaoH7muAnOFG24WhvEVO2RcQhkI+LUThDwnn+xwBhw5dArcA2MUGOb+QCs me0btNkg58sCxmjwtvIsJBXc0d7l7m/BYbeN1ZqCOC5M5R7o+73bjN6gHVNria2gFrR1t9tB PJT55GsQnZVy4hX4JMnCym8QNMHniN8wcG3UnxuHQK9gupQvQRbUH8uyoF5TJ5sLQMtkO2Ir A/6/WM6oI8AqbcGiEgCfvotAlWVkGVkGtH3aPm3fP64XF8QFcQHMp+ZT8ykMMgeZg0wI3Re6 L3RfeiWpWrVq1apVgx3sYMc/sV/PbM9sz+y/LrdlqWWpZembbzer+Kzis4qDt4O3g7cDfGb7 zPaZDV40edHkRRPYtGnTpk2b0tuf7XG2x9kecGPFjRU3VkC3Et1KdCsBn/t87vO5DxzcenDr wa2wK25X3K64d5c4/7P6+X3C/GfL00gbEn9bO76pPtOG7B/2ftj7YW+oXKlypcqVwH7TftN+ E4L6B/UP6g+vWrxq8arFO1Dk71AWKYuURel+/3v+zK/eNF7oSEc6vn0/aVMD1EPqIfXQf2t3 UVwUF//8uNP0m8a7sv+70mtUrqhcUbmg9p7ae2rvAcpRjnKAFStWEFPFVDH1nz++P+JN/fVN CdoYtDFo49/n3xn8381bJ86ejfHfWApA6kGtUYIO1q/E1MBSYB9iNDVeg/83PotyD4fXBZWf jQC4VuHh/RtJkDVPyPXAH8C/Ztinvg3g1VJP6M0kqLagcLkGraFDofeTBsWCNdy/WN5I8K5P fZlyD5QbqkMUAS1crlF7gewhc+g1wdzDc+M4KLeYIS6CZ7n3UGokOGf5R4Y8gqjBzzO9uAWW OZaWhh9YOzmj7BNA8Vg+dFSB8BU5K2fbBc6frc9v/gyJ1zztbP3AGCcXiURwvrLmt5WHxKPx ReLnALGu6a6KYBkc8K0jGdwB7mx6XrC1tAc6PwTGiPfJAu6Z8eVe3QdbA/sa38Mgtojs2leg /WCZY38BYpD6k/YYbNiC7COAe2K3qABildHfyA7Gt3ol93hQCyjBaiR4cnhq67nAtkyrpjUA 9Wur1WaC/EB+o64GChmv9MaQODBOi34OVDcOunuD+7BeRV4H+zPfi/4JoD2xfevbEiz1LJq2 FbSS6h3rDWCJuV4PBLFYbvF8C9qvZLK0BscvWjmzCNia2M+Lq+C843yilgY1QUZ484AcZD2p muCp5d5s5IFUp5FX+oF9pPOuXwFIPe9tRzx41/KtchTc5/Wtug/YWqoF1Pag3lN/srwPcoEy UW4DR6rjkL0piHmygVoD9NIy3FsfAo44slmygdZI7WQNA32V2Y0RIO6LSooBcqYlVXwC3of6 MoLB8qPlBy0JzJpmZbkGlPGOC5Zj4O3g3eAqBWozbZSqgqghl8mcYDYzVxghILIor1UJSh52 akXAJwex0gBRkVFmc7AuYJqyBjzB+mLzDrivmd8Y4WB7rNyVX4NzhDWHteJ/Bcn7bx+oaW+H WD5g+YDlA6Cv2lftq6avX7ps6bKly6Dajmo7qu2AE7NOzDoxC7Zd2XZl2xXIdCvTrUy34PTp 06dPn/5vHZehDGWAi1zkIliuWq5arkJ0dHR0dDTc632v973ewHKWs/yP5Ut7q8WfJYL/LNma Zmua7b9VrKxTrFOsU9J/586dO3fu3Om/b0bfjL4ZDXNKzik5pyQkd03umtwV/Kv6V/WvClHu KHeUG4rOLDqz6My/Ltdf1c9f5fLly5cvX35zO76tPmscr3G8xvH07mZ0mdFlRhcInB84P3A+ ROWMyhmVE2pYa1hrWN/+OHe+2Pli5wtoT3vaA1tCt4RuCYUy58ucL/MGlcQ03jRefk+aP79p P8kLkhckL4C9fnv99vpBS1rSEtjfan+r/a2ASUxi0r/P/u9ar9nGZxufbTxMbjG5xeQW6fH0 fOzzsc/Hwunhp4efHg7sZz/7/7o/vKm/vik1btW4VePWv8+/M/jfxVsnzs47/nlDZkK2rv6F cxeG0pXCPshTD4IuBhz0+sEZ87etj5Lhwsio1jdPg745rLZzIwQbnpGeACi63jPHkQD1tn04 aubPUDyoQPcqAeBaLMY6+4AYIqZZ+4CMEgv0+oAiN5EC8j1RjqEg2sshShdQQ5TpainQ42Vz JRkcrW0zfTtA/MOXx+KewW8XruQ4FQeFB5aZVfEVqJm0p7aVIPeDuAvZduVolH0l+ATZl9mP gZI1ta9rBjDVOKgkgCXSksk2G6yJ9k2ODWAUtQxXPwG9ApHiIvhYfef4jwN9jzfC0wCMQXo/ b0FwZHdGBKwF7xA9iu9Bqa49V7uCWtESRQ9Q+pvfibkgCip7lN1gxBtX9Crg2e+unHof1MfK LW0XyAsyQG4G4rTWij/IPWKi/AS86z2RKY2B60qMcgaMme7znvYgy8nfRG0QqjXUdxQ4XzgH WfyBlXxt5ARzsWecsRg8V02P8RC8TRQf91UwTuovjZsgr+hV5Q9ghtPLfAyWKIupGWDtTkHR ApKGJ05IfgRGKSOCKWD5TD0om4NuctM0wPdJwOSAl+CK8A5SYkAmKoY+AsLyBi4IuAV+Hlt3 pSBYtmqrlGIgQkVxpSZ4L3hm6J+AOpzMygcgVqvnFAnJFT1r9QFgGa48MteCMlAtp04Ho7hs b14C72+eCe7BQHm2qgXBO8ZzUtfBzOrt724Ctgm2GVoLEHbzMZtAeUEzuQSMDXpb/RHYClqn aQGgthbDLWNBr2HMNQ+C/Fr8YPYE8Uh2MjRQL6u3tIUgj6rrlSBw7Ure46oBxl3FX7YG47j2 XNwAbYA1Tt0HzH03gZr2kMqUUVNGTRkFzW43u93sdvr6ojuK7ii6I/1hpb2l9pbaWwp69uzZ s2dPCLwfeD/wPpQxy5hlTChyrMixIsdgxoIZC2YsgEEMYhDQuUjnIp2LQI+5Peb2mAs1v6j5 Rc0v/liutH46nu14tuNZWMMa1vDu2Txy88jNI4GRjGTkP65Pe53U7Rm3Z9yekV6R8vTy9PL0 gopGRaOiASNyjcg1Itdfl+NN9fO2pD109aZ2fFt9ti/YvmD7ghDdKbpTdCfYkXVH1h1ZwX3C fcJ9Iv11fyNHjxw9cjSwkY1s/OvH+eD9B+8/eB8aPm34tOFTCM4dnDs4N0y7N+3etHtv3t+b xksav/fnuZnmZpr7Bv0kVUmqklQlfa7tmtZrWq9pDfXq1atXrx6oFdQKaoV/n/3ftV7HjRs3 btw4mDht4rSJ08C11bXVtRUcKx0rHSvhi2xfZPsi25v3+2f8mb++Kf9u/87gfxfi/9y5Slmx YsWKFSu+eQfVcvcalbMnVNqY63K5g/Dlrx0f9n0FV7Pd639tLiwrsrvdqt6g3PIdaqsHL3ZF LXz2CrrUKl+l5h5oldCkwITj4F7jbW+fDcoWn7O2vWBZ4vPQNwxEP7OfdIPhkjuShoBySAx1 TAbZWCzXQkG5yEf6AeBX87l6H4iz5tIeQXzrqD5PQiBm38sLrzuCMVjv8DoXZBuW7/33/MC5 yVEvZA+oe21j1Z5wv/Spzw4nwUT3xNJzp8HdzyKfv/oGrKdsef0vQeCi8M45i0FS/dhdkR+D e44xUzYEi8Xnin8nEH7Gfu8OYJLp9OQE8f9r767jpSrXxv9/VkzP7G66pUNKkW6QLhFQkBYF BEUFJJQGFURCQAEBEURClG6U7u7cbNhd07Pi94ff/dt+8fAczxEfz/d55v3Peq2Y+7pnhnu4 9j3XuuczxoprQGwhVTXMB+2YmCZngbVXeOu4+6Ae9NRx94Oc8ZmFk4+AHq2WCGwFwzl5hVwY DD+bQmyJoO3lefEiqIovNfskaIsMFaxnQR4qbpCKgW7QmutfgXRMnmcYDCzkXeEEaCY9QdsP 8tfGlRYNxO/1OOUq+Eq5C+VUgUC2f4B3MsgLpN3m3iA8I5UV7CBUEUdr90HeIuXaQkB+xbjZ WAL0aK1KYAIIs7Xx2j3wvu8b410MWrJeWrWCctN/2t8A7DesfU0HwITtaiignFMbSulg+dqy 12iCsGHWSENPEBYH4v31wfit4br0LhhekpoJVcFc2HBDbAhST9FJOPgrB57R+4M71bvWkwvy Gd2sfgBKYTXMJ4E/PLArUAsMV+QTBguo3bXBNAe6ChvZDfpI1cEY4JT4FkeB53WH8gzYhtul CDdoZ4RGciWQqsnXTTp4e3vHuuNA26JsDVQB41fG0pIfhG7ifrE2KH5hvPAFaD8pDcX+QKhm DcwB411TRWkhRK2xPrDPgdB6EW+aR8Nb735w4oOLf/cwDwr6z5RXq/qv1qj+p8qrAa5apWqV qlUg7FbYrbBbkDE1Y2rG1PzVJPJWbfir/E97XYOC/hMcPXr06NGjT2HGmWQhLPwMXKp+c+Cp qjC70apbM1uCp7py3n4JcmcbvLoI4r7sUcmN4dXZ0c1qHYT2lap+P64TZF/ISnb1AW9oSudr +6HA4edtjXuCf6C6TlkC4kS9qJINoiYsNvYBIVusLwwBYYSeoS8Cra4wTV4CTGWusgZMVqGB 4VnwTZKue9Igu9vxvVtOgWvotgVn34TY6eObTHgA+oOKB6JvgP4Jz4l7IPZm4ZJFV0OhCuHb wxvAzVbpnZ1HwGcIiN6PQCuuK0IsyA+NNy0mcJ/ObpTRDQxrLM9YFJASpUvSUlC70EboBYb2 8nrjQ1A/0UZKzwFz1XWBRAjscj1KXwL++d7d/hpgOWN+1VIUhGQemgygndV7ai1BD2ecthL8 8wLPeSuB8CGKtAGETaQafgBlQeBC4C6QqPfwvwTyUDFXXwv+o4FLShiI/cVR4ikQj4m/6HdA 7G+MMjogZFHo+TAFeE57IVAA2C7dNA8G3yRPDV9f8Cf5Brs6gxajJ7jOgXu1JznrO7CUtU6w ucG3QamsDgb1ijZZnQvW2bZrxlEgtbXGGR1gvGYYL1lB/kT2sAyMG6QP9G+Be3ymXgRnT38D 8V2QWgkBaQi4vvWXJBQMB8V93AehjS8yYAHjKcMFwzrwF/F9G/gOAi39n6jTQXpfU5XhIJ2Q zooJYJtpvRRSDOTFYiuxH/h6eU95O4Nrq2epdy4oHcUhkgT+Pe5CqgXMXQ3fGF4B6UNff19j CFRQP/YMBNXHIE8FEOfIY00rQZHVosIgcNqdoe52YLpg/N7cF9Tv/bP9RcE60NJB3g9amLDC PBnUn9VD4mqQL1uPCqdB8Mrr5Hl/9zAPCgr673TQc9Bz0APnLect5y0woNyAcgPKweraq2uv rg1VY6rGVI3583GCgoL+Pn86cbasMlV1vQQhmb4Xo4DElQ/dgW8gamfcEG0imC5qyennoJMz +uuaJ6Ht9jbHx3vh7j7vkBQNrNdSv3b/BJGFKyx6thBoi7TlnAOhqD5B7wdqiL4osxNIdvFo mBvYzBXhCug39XvifCBU/cHfGaQU63JbI7hX8fbxw5XgwdBJH09YB6aev/yQ3AO0Yr6D0j0Q P/UWUFuArOCXq8B98WC73Rlgmxc11bEQyoiVvCU6waHZd19KPgz+BF9138sQeMFXSPkQDH3M w8IPgXAoa0XGq6CX9hv9SaD/ZPzFsgPoqxeT3gdlpbJRfx2UzUqE6zLgE3OFdPBvzNydHApS H8MMgwVMWyw/hlcFz2vec54VYLlqbW09CmpJtZ92AUxV+EyqB9JWaaX8E/CmeIMDoG1Rx6mb QEtRXYZDIJTgjloRpFeED5Rs8Gv+VG00CF21O4GPIapVSIytAHiveL7xfAu5YrY1YwvQWX3e PwL0FL6X1oOlsW1T6H0QSkk7xF6g68oK73LwtfFtcg8AqZmhvrEVOCrYu1rOgVBCc8t9QD2o vaoUB6UZ5dR54Lvku5HzAPSPtE3atyDfMEy0tgPhtvCj6WVgIhcEP1h/sm4zAMotbbo4GKim N2E2eCN8dfzfgHZaOCj0A8N+4x1rffA183X2DgbPdvdJzwPIaOVsn1UFTJMMNukaGK7Kow1D IfOgs6V/FITvcnxkdYFji/2Q2BjUdmI3w/uQudu5wfMdmFxCWCACApM0i/Ae6MeEePk6yFuk MdJCMB0z9ZFngf87bz/vTRCNQgTHwf+l4gtsAsWtRirHwV7f+IEcBebr5qGhDpDOil/IjQAY i/p3D/OgoP9MG+9tvLfx3t/di6dn0KJBiwYtglE1RtUYVQPqW+tb61uh/KvlXy3/KkzaMmnL pC1/fT/+p72uQUH/Sf504vxs17AGBftD1m1xakgMhM2ytXRsh9AKpk6BTdCjfNeItwdBhQrF +3WfC9rW6NyoPRD2zEXvkV1gS4tOKesAU6OwxREPwRce+CHQH6RW2iV/axCn6tPlxSDO55Tp CKj99Hn6JyBUxOJvD8ZOpvfNm8Ad7VRT6sLZuZ/e+LgolF58pHOaH2xVn9lTSoOwrwy1Q2LA WrXs4JIHQfEEBCUXrOmFGhbaANaTtjYmJxS0Rt2NSoewBvbTYbvBedwVn7MTXC2c37sTISw7 umF8LzAWM8+2rgV/Q7W8GgLm0ebB1kjQDwg79Dmgvui/6beB5bChrOFFUF6V37GVAfMz1tRA DFBQre3/AnxXfac8VcHYzdBI/gQCAwKtlcYg9JRWys3A8IE0XE0FRWKz8g2I03SncAAMleU4 iw/0eKmDdgLoqbf2dAAhQuggTwHDHNMs4xtgnGC4aMwAb1/nw8zNkCw/fD2pEoh9DK2MG0G2 GyqaYsBkN80w7gB5pLzJ2A38Y7wn3ENATJZOG38EyWV8aIoCQwu5jxgB8myuK1fA0M38tnQH 6KgfN2ngm6gM9I8HzmqxUjegvXhZfwP8K72H/EtB/EyvlXMNoluERZhlEO+oDgaBYbrsMe0H w2Yj1oHg6e/vFrBCoKVaLnAf5FrKSFEEQxuhpj4DpB3GeOJB8an9xTWgf6J9F0gEYbRYwNgU wl+NGhDdGPwDfVPV3qCf8ndX74Mqituk6mBebjpuKg3WBea5lnjQD+jLxRpg2m5YIu0AQ3Wh gpQM6jXlur8ABE7JmZQE4a7pF8ur4LH6DimFwGoynOEliNkS/oxxMIQ3C+sVXhrUQKC/UgPY 93cP8aCg/1wFUwqmFEz5u3vx9MR8EPNBzAewjGUs+0cX1KIW/0ZJ5L/qf9rrGhT0n+RPJ84h yAVil4J3VGjz3BQoeKdIrUBn6Ljg2ftDsiF+Von06lHgPiiMF++BWMqz3HUeQs+X7FZ5KnBb nG/YAQHJF+v9Agx7xS2mWhAom1vqzgEQW1kp0AL0JD6S+oMwl6P+94C3xDj5EXi/dLtd9+BQ keVvf70IrL2zPoqSIGHRe4bWOmT2uzz9fGlAv1rrQQRoh5Rxrs9AOmJZbC4IoRULnCxmA/NV QzlxJ8hRju6W98Hcx9LY7gLDA8t8Rza43K6e6evBVim8YNxwML5snhoyBLI6PTp5uzrwrtZK qAvmo7aV9p9BK6Xu9n8MmsgEoShIFioKu0Axq0u4BYG3tUdqadBj1EFKCPCAEnoJwCx8Jd0B eZO+Q8gEraF+KPA5CF5hhOYDaba815IKluXGk+Ir4H3RLbrXgDicesoOENfJg201QX1RHCIt AlXzT3T/Av4xAbvvPYj+rFDHErXAtFV63/gFSDIn/D6Q6mke5StQGviXudaBNNjYRg2HQKrv I3UL+BZ4xviMoDYVPxJDIaSSA+uXoF9iEevAnex+1ZsMalWtlrcY2OqYvpfuQ1iK442Q4qB4 tLd890AeqNc1VAPplJAmBMB6x7RY/wK8jXwrRQ+kzs3e4esBlvrG5dp7YO4o2jkPXos/1XsR 9Gh9r9ALzGsN0cZ3gAzxgjgS9FtqReM4SD+W2iNlPlBQNhlngFJHaCc9C2EpjijTOAj32kpF 7gNPwG/0HoHsU+549S6IlYT5nmUgPyt+G/ILeIZ6TvqagamfZaB8E5QywjLxHGQcTgtk7YOw XSERtkdg3ixu03xQ7EwRIcwE9g2OjY44cMW6qnjvA9Dp7x7kQUFBQUFBQU/Hn06cHzR09je2 hfD0+L5qS/AlpY678xJ4Xsw6mj4eck8JxTydwbROqmnpA8oNPtM/ASlXb8EsYJJa1z8VxOVi D+MIUHXlUEY10Ieo3+tfgfCp6Z2wONBfwqDMACZqV7TTYJpuLG3eAEc7Hll+LBNOvn6mR/pu 6JXWe/4rrSBkdqPM6iZIXd334+HNwaU4C6Z3hKzczeVWvgEO8wsPX3oVTFeK7YrbCFm1Mxu6 CsL9Mtm9LfEQuyrudvQSSG2dU9c7Fdxdc61394D7NZfPVQPsgx09Q++Ddarpjm026GmBjq5e oIYE9uqPwBBlMjqeBd0rhIrzQd9AnD4P1OeVQv7rYOhpnCCfAoPTOiRiKOhFtY/FJOCmtkC5 Cpo/sM61GwJDfWc910D+0VBdHAW+DO9N92DQJ/riBRv4t1LW9D1Y37AeCy0E9p62kuK7oAU8 h5wVwZJsv6BtBtdMRTa3A9d0b3f3RTBUkud6NoMeGojxxII0ROqmPQt2h3mYuS0wQ0q3bIHs y8JBXxVwiPJS0yTwjwwMZBx4ve5u3hvgGpK7P3UvRO6OjLV+D+bGhnRxHKTH5Gx0fgHZpTIX 5Pog7JPQt+yRoIrC+2J9UDcQLb4KBkvOLqUbqM38jXNvgelZ6z3DKMiumj1OvQ/+ToHRvurA XLETh0A+La80vAfKxdyxOcNBnmUob1gAfKIt13uA8XnrGssh8FXyR3oTwPQORQOdQHwlcEoL Bbm5XsO3AEL6G1fLaSDdsHQ0DoKAQTlpGAdaLaGVWhkMftt6cScElql99LrgbanEe8qDOcmY JA4Gb/fcmKxfoOS6oifsEjyTWmF04e8gJyqznXgS9EfCGyGev3t4BwUFBQUFBT1NfzpxrnCj YtPC5yFx/IXz7pbQ+PvnPT1XQ/xH1c21VwDDTaWsOmhVlO2cBuFb4UtxC7BTyDDMA92gpvtf BmGqWEpMB/1dpyEjBwxj9ObW48Bs8SuxDfhPOYvllgNhgjBfLQhai0B/tsC9a/cnyIOgoeHl ZvVSIKrdcyXKJYGr2qMpSa+BIGTtyTkEYWcKnikWD6bcYi9VOAHpz87puqwDxEtjOg64BVkV nNbAK2D8yhoVMwNKTS2+r3gY3Gn5KCqnImTPyk6wTwb3iZxA6pdg+dphK1IBLDVDRoYLYBjI vZxmELLa0UmWwfmT55jbD46ytnsh5YBqwiGpIMj7wquEfwr++0K08XNQdypf+iLBWyFrX9ow 0KvofZVXgHjxuiSAtEeaKDQEcYcQJYaCONYsmoaAuZztln0jhBYyWiwpYH3bst5cEPy5zred k0Fd4N/h+QLSns09qcWBs7Z/nrYd9ONSnFgFHBdCPzNXAnmf+IF2Gwy7pUJ6Z2APNf0mcJXO Xax0ArWlvlq/DpoqGIw7QeumqdpeMDWTd4mpUMxYsnjCI5Bb6ue1UXCja5Ke2x0kDMPkOPBf 0FprpcF/VX+XARD+cugvYWGQsTmrvrsIpHmyT+RmguWCeaL2JShXne2VuqDbMOoxIJ80TpDn gJ5BCiZQf1BnqRPBeNB0zBQK2mxNUOqBoY9psjEelA6qRasDgRTte/0nsL5izTQ9gMAe9aQw BdKOZbRI2w/2MfZ3HFfAeMIwxDgOpCi5n/kKeER3L9d9QNEdyhxQt+r3hI2A6i7nSoRAmOQX H4K5kv969gqoYCliigpA5CPLckciZI1KHui/AaEdou2OTPhv/Xm6oKCgoKCgoL/Un19VY7S3 zr2bUPVqsUmlC0EFmkS/VA40xRoptgd/6/ROmfVA/Nq82RQFosI4JRHU+cJAxQbGGuYs+8ug rhTr6MNAbZO9xl0SAjX1h/a+YHkxPkTfDLkdczb7CkKoFnYlbDZ4Gvt/8NeGOqcbvF/KDPEd C6jhTcCn5BhSuoGqZnfJagLGBJdONojNY0qY54Lhk/CQmFbALdvEsLLgP5P9KLsMRE2OnRn3 EsTssH+ilgQpMWaIJRLsJ0JOCRvBWCVsbEwyOK+mFrzTETyFPW3it4DZbFkXvgJEu+t1rwPC yhj3mheBbbzwvVIfZKuamiyCcFG4KFUB7W3P9NwPQP1a3SVZQFyqTZFagu+hME9tCcpJrao+ E/Sv/Gt90SA3s7S0/QxCda2o4gbdrdRx7QK1oGeztA3EeGGycRdwXCjh/QL0QlqG6xcQaht2 2yaAukH93j8IQlVLXbkwWC9ab9k6gPWSYbleF6xvyNNDIkAdFRjqawWBc/5J6k9grxFyVFgG EQ7TfMPrkNPT31+cCf5Gngb+tVC0WMxSkwRKnLJYugbZm1zFvUehYFTMO9YwcL/inhooBRlF tD5CV1Dv+VI8PUFZ48xJuwWFvrIOUOuDc5NtX8h+SDXmfBnoDFqiUsnZFxzVLKJxJRhqGEob E4BDJDEStB/0aKEEBBQtVj8NgXFKungYhNnCEfEC2I5Z2solIHpQ6FCLDGbNXMCeCsrGQKIw FHSd6z5AH6y6NQ/4M7x7vUVBOGTYpiRB7ihnVM5QELy6W3sXfLW0n1QFhOpqA2UxeM75e6mf QfFb8adNYyBsTIE6xQpAQPd0FkuB8XVbX8sLYGsR8X3I5b97eAcFBQUFBQU9TeKfbUC6o9fP EeH5C821jgpw3bbA8CXkhCb3vd8WDkz6oefqcHDtuX8+cT24R6RnZr4DStnc2NyXIbXGmUPH V4P6vHuhMxmyK2S9pgLqc5YLod+Ccty/V7GC8ki9YckBYbl8S5AgdLtdMu6CuLTYliFvgK+u q5TrAxDPOubFpIFezHlUWw/ipPSK6T+BuMowwuoFaUFI39DjIDSyXbRVAH2vdMAQCUK2/xNn OyhhLpJWeB+EPYz4WqsFjp1W1ZcLoZbQzjGhIMnGbPMwcE/PmJ40BtRYqZJpEniOCkNt78Ol BYkfZ46BnGG+CK0mmH4MPVDgFthNti8i2kFmp9wRXsD3lWtW7gHIbJmRmtQa3O+472UvA/Wc f4jrLJg/MAWkBmAtZGxNBzBVNlktg0G9pp8SJ4JyJfCyqxxkXs0ulXgLcp2uxc6hkPYgK14d BEnt07vmlIXIJSFRtmlgKW36wHAA9HPas54rIJzWXxEd4Fhk0cxvQMgex7CwSWCINj9rGQpi tFTNsQmySuTMFdeCs3e21TcVlLP+xa7D4Ovpecf3Pvhe9q9xRoB1u5SpKRD7ScgLlgWgfK9u 0MPAOc33tnsKuMPVttoxsOnG1/TyoKXQSLKDOEYNVyPAUEZoJy6AqNdDDeGZIM8xbbK2B2uS 9RPrTpBeYIQ8AvQlwvMEwPSaqMpDwVTc8Lq0AIROUgHCwJ8duKV+Cf5bvlVaRdDK+PFJYBom x7MJTC3FDwyfgXG59KZcHIQWwnTjTXDdzHnd3wxcGZ4mzp3gy6K57gcp1LjFWAnEtpYSllUQ diekv30PFD9RPKVQcdB6yWmhmyFlUs5W7yyIe7VA90g3mM5r/cRCf/fwDgoKCgoKCnqa/vSM c2GXtWX91yGhXjG1hhFyTOlrkhPgWoVT1Y/Nh7Rb0SvFIfDjzAMXNzwPRbNNiYWXQt153cO6 CMA+w3iDHWjoOpgZDoHtWZtSN4PJ+cyKCpUhs31ygWP7QWqt17FcAsMB07tVZoG/YWCrogD9 1ev6VJDPCFmGhSBUFgZIV0A5mbQk9S4ofaUfLclgjo8sFWMHoWzc2QQDGL8OSw5pC8INrbJe EwyJtjqmZpD5ha325SmQNje79slt8MzPz9yKaAOPDuf28Q8GR52orwvnQEbJBytv1APvdmeP 3EZgftFmDnOB8IU/1/02ZHf3lda/B21oitO1BUIWGjtoKkR8EDMiegfoC7QQrRyYJzsb5I6H yNWh88Jqgn4ag/gmuD733/E8gtwT7jb+T8Fj8JT0VgchWRpgbg3afQYIIog19LbqIHAJ3lW5 RhDaUpnFEN8rcr5jAoSGml4X6oNrmHeJthOE98Vewj6w7DK2l26Br3igtd4Psk5n5mQMAH9x 5QrzwPOpEu/8FvT72lu+mWD/zDhL6QiBKz5foAh4ZvnnMAji6oaNiD4Nd/qlrUx/EzJ7uRZo z0Lga72IuBAsM01jAhXBnmx8Qy4FDFd3Kh8BI41dpUqQu9pbnrGQXd89z2sH4wopUvoB4r4J q2qeCGKiuEeqC8o0c2eTCYwV/fv8rUE7ImzmLRCHKolCcdAzlSr6RDC5TCJFwNfGO803BaQV wmQxCbJ65ARcOyBQSZ2k14ZAjLZW+RYMm00nrFbwnveluE5C6Kuhx8IXg3JN8WufgzJW36oA 4gZ9puEnKBwddlY8ARVulDIU7QaWDw2lbMNB6ilvszeHiKIR6eEKnFr5S5+rTaEKz+/i0N89 zIOCgoKCgoKehj894/zspMbzO70Bfo/aRVkC0mmDySIDIyO+kLdCVgf3qpyakDZWnuoqBSFh BRbrFSDQMO3jm6lgfC+ybOQoYJbnZPpQiHoxtrDjNki1zFOMwyCyQnS1Zy5D1Nq4RiX6gXJG +V4fBkIUW/QaIH6nX2Qd6DcEL1+Ctgf0NNA/U0sLIcBGW0PHVtBtvmXaa2AYaLAYtoJkLroo bCmwRZ8qbgS/6H7gngOldhWMi/oMcmfoSXoouCdnzEpbCIVDI3aJFcCw1TE1qjmYqzkiwm6B b2Jmk5RyICRoHxmngXmR7QtbC/Bc93URfoScMXo72QFZHiHaPAM8nyvjhb6g7dA6SOPBsMu8 y+YB7S1tpJoCrrOuO67uIF1Q0/17IOGl8Gh7KBROjLke/gEYA9oSnwZSQD0RSAVHFfMi29dg 3mJcbmgHltmGY9JeMD+Ujxl6wO2WKZnpJ8Bv0wepX4Gti3WqowS4J7haesPgwWtpBdKXQ1Y5 14WcT8D9ordq5jTwzHZHpdYC5dtAX2cuuO54GmthIEVLZ7TFULhO9KqoFLgYfvuV1AhIbJIZ 4u0HmT1dQzzzQZivK+omCDVJ9cR1EDPfVk9sD8IGYwOpBGRYnNWlXPCvCnyvvg/RkWEtLRvB tsR82GABAvrr2mZIvZAh5dSDzJnZ77ls4K3usXo+A+/OXF/ut+De6mqR3Rmkl5jj/QhUgzdN PAt6pt5BbguZF5xLfK0hfayzsKc1pNzMqpeVDZmjnGPcKyDzWHbzrI5gPG/0MA+MpcVtwl4I WW173vgphC2xh9u2gyFgyGIGFDhYJClqF8TfjesRFwGhG0zhtodQ6FrJy6W+gEBN9zDNBDe9 p8xXGvzdwzsoKCgoKCjoafrTM86O01FhCdVBe1NfTgKIujHCcAZS38j6PvNFcGn3LY9sUH14 2ftV7kCFrysvbzgalFOm+fIDkOppR3ULqDW8Oa7vgcNCZ5oDa9SVrpKgPcr9ydMKxDIRbRIe gDQ1sFa5BdrP4lp2AMXFV9HBP0dt5nsNTCP9/f13QW2rnJS+BD3blGsfDsJmd395EvAIpF1g XFegRmw54DslMfAZ+Nuk1X9QCHL6O7qkZECZ5tWMz9aGC8cvHl7kg9rtKn1V9hWwd9aXxKyE X1Z7NxfqA1nHHgy+UhI8w3PeSF4Nlrbhr0UcA2lw4G3fHNAKKAO18aCNNV6LrgQ5z+p11O9A ec9X39UCDLfUb7VD4HrZc9RdCmydrUscpyBkvtBYOgrWjw3tDT+BtJv52mEoejR+VuRgcJ3w Ccoy8EzJXZHVDApOiT0ZHQHOct5QtQaIteSPZQsUbGX/vPBdEA06XhU8093XnCvA+ciTnL0d vCc8KzxeMO8wnTaFArOFA6ZPwH7FuinEBpZBcqjwFljmSVWUL8E0wfip1Qg3pj246ZwJrkVa lm8AWPYa3jHdguitIeVMSyBpYvKwh2EQvcjRx/oS2Jvb2oVWgYuB+xMfNQLTh6Yo+3BwvGiY aS4DskFJcA0ErauWIu6HRFP2SKU56InqRv8d0CrzorELZDVUhwaSQBO9nZW1oLVSLru2g3Oa /I2eBqJdqKr3hPBAdPW49yAwSalHBsjh4iP1EjhSLJ+KZ0HP1gfpBcC4Sd6rPQch98wWCoK6 P3DX1xPMu+z7w02gr/Fv1ztB2I+xxe3REHW55MEyG8CTqemmvhCdGl88phmEGxM2RCfB8fj1 g3+xwe0Nj167HwJ0/nsGdlZWVlZWFixbtmzZsmX5x3v37t27d28ICwsLCwv7e/oWFBQUFBT0 /6o/nTjr14QC+hJQba5auWMgQ3k083oMFJum2iwVoMykyvIL/aBAwcpbn38BtO9jmhUoDeJt /21fAog39BBhMTg/uNv67BCwpsZ6K5UF3ekelPsm8JF7QGZN4GHENwmVQb8qNtTTQa8jPEQG 6aCeIqwBvQZFA2fA+7Ev3NUHAtVvrU7cAdpirR89IKufbM95GRxn76+5MgO8W0/2PFkZLM8+ s6fYRTBXrKKVPAL6I2/NkEnw7NsFP7N4wDe8yZZ7N6F82XIftImE5nNqD/LWgOSz05/9tjOc /dI9PM4D7k/Trz84DXIDS6rjbTBNNZ8M+xl893N/ytwK7slZxzM/BoPPZDe2BqGIsEDoCe5j elH5U7A0MrrCyoJ3lbqMA5DVQlomNgdfZGAnvSB6i+NFmwAmk7msbRzktnVmux9AIMI82dQU Qhdbn7eegdg64R3lFPA28U3Vx4KTnNzs6yD1Fu7oH4I0117cMBZst8xtQj8B7xhfQ8sAoKPy aaAyiNEG3XgTMru4dyrfQWCxXxCmAHvkEWIFuPDJnQIpqRC4Lsdpc8BhNG0xlQLmKLXSysCD DqljxB5gf9bytckDpIgpHgHSTBk/mr+EsF/CpkUPgzhjeJJ1JGTLWdVyHoHf5S+rvwxpo7Pv Oz8D3wb1tHoNolaH/GxuDCbRNE5/E2xvBQaKRyBN44R8EOQ4SQ2/CtEHQk6ZYsFUWl6qZoC/ tb+2uBs8jdiplgGpu1Ew6CBt005YqoJeUW8Q+AHUzVoXfTbkLndXVB0gvWbaZ1wCOd2cB70j wXHavNWwBhI2JJyM2QVCWfGwdTmobdQq8hWwH4/dEXcVAmNdS13vwhHfYfdJE5ypeqfJbf3v G9gNGjRo0KBBfgKdJy+RPnPmzJkzZ/6+/gUFBQX9T+F0ulw+H8ycuWTJL7/AtWt37mRm/nXx SpcuWjQ8HN55p1+/OnXAbrfZTKbf9sfnCwRg2rR9+y5fhmvXMjK83r+yPxERZjO8916DBmXL gt1uMhkM+ee9Xk3TNNi/Pz09JweysxVFUf66/oSGyrIsQ/36kZEhIWA2i6L4p+sr8v35VTV2 uja71oM31301aynYaoStjR0GhZq0LlSrPGhTuagfg0Bp5R01GfQFXtV7F+gnhultQDUG3nYZ wRwe/lpkDZCrF1pctjxIM+11QxqCvtMWGT4WNE21C++C3lP4jpYgzOeSEANaObrxHZg2CA7H TFDr2mzhmyB8W80qCTXh7PEHDb1+OFUz5vOrV6HbGCnjbjg82lpWf/AxJNwo9m7hcLC9Y+od /xpIpcxzwz4BCb2N/yNo+mYT/+jyoH+mZ9IXhPcTjvMOdKreLO5Ke7gzaH2bc6sgK8J1JKss OMdlNHyYDmFibOlC48BUyhYZshQ8PXNPZe6FwGxPM+0oCG3Eg+wG4RfDHNEO4t3AJMvXoITK lYwfg3unuZ8cD9Ia32eenuDLUV9hFeQudrXL/hjMZ1VHTiPIHJp2/9EPwALz1+EDgNmB1spm EEfKS9RpYF5jWWvaBMJwOsqnQc8NhHrPQUgv032pNmhGyWFrCUqqmGaOB3eUe6xSBVwdPQZP HWCtNtjbF8RWwnHrdgjLjrhrN4DrmZxdWQ7wPHJ/lb0F4k3Rhqj3ID07rcr1nhDSOWxp0SoQ +qVjTOy7kPnA181/EfxZWW+rFyDtHW9G0iww77B8ZfoaMk7n/uK9B54O3lhfUSiYET8v4jwY DhmqW+cCL6udvNEQfjr0BXNDUCf6m+cMgOQYV7irC6Rrwip5IOgfk6J9DFovStAETN8YXMYC oB4RGunHIfCT9rE2H3wTA3O1n0F5VnnD0wOkCtpnQnXQh9LaI4JjvbWofAaKlS/sLKVBRP+o K5E1wPCx/1UtFcJ/jHZG7wHTPXGZGAqHj2xYd3IF/HzuivPaJ5ASrxi063/dB8OT7Nu3b9++ fXD27NmzZ8/C7du3b9++nX++WLFixYoVy78uL8EOCgoKCvr3TJv2xRf790N6ek5OIAClSpUo ERUFgiAIgvD04ui6rus6pKSkpTmd+XEnTRoxolmz/OsmTdq588IF8Hg0TRDg+ecLF46I+LU/ T/N5/9obuH07Pd3pzI87bdqLL1atmn/d7t1paVlZYLVKkiRBlSqhoXY7PN3egP5/JqsePPB4 fL78uK1bx8RERDy9OH86cXaXcRbJfA6Ml42LzPNAyg6ZFH4QPE5vW09hEApr94RkUFfLO5gA wjNiC30MSHGEGLaAvlN91/0yGFsV+a78RTAet+1y3AS1Jj9yC4hhsFgIDCa9l/85CLwg+NgC HNEbi9mge4Vj+n2gDbXUMBDv+PcbCoO1bIM3a7wJuRcyim7PhKxSiXv9HSGnKXvd+0CdUeJ4 ocrwS7trFw+kQbMDIWfKvAzesJQT5hPw6JN7lnQFjLUNyzJGQGbXpKWPTkPmkkcDryfB2X53 X0qMAus4R8OQn8H9Il+V6QDeYXcOn9wKuaMyD6S2gZC7kRExW8FYz2L214KA01ck+xWQ+osd hGFg72WNCGkNzDRYjMPB2EhOFCdDaLa4SLsIhmLGe46j8OB2ziQ9FnydXN/6XoaMs/pAQw4o dY1ZUToUnB9S3PgxpE/IWOoeAdIi7upZkONy/6RbwFdCreczg1xMXiakgresVkJrBHILMST7 LXioZV107QdJNFZzlAdjDYPP2ABMUwwVHC+B9RS3vQfB98izMCMZ1DPM0K1gGmreqYWAckp9 X6sEBRvFVig9HcLrRsTazoPnJddleT7kJGVe8XQEV09tgr8zOKrZL1pOgbdxIFErBd5e6g46 QuybMYujzoF1vrWNpSA8cDycmOmGwODAAM9J4IQ+J7AasgzeDX4XCAvlV60NILBUu0dtMM+1 fGFcBcbDcqZ0CpQxWrjYCRRj4JG3MNhmGUYI68DypeyQS4L8g7Q6/Dpkb/GfC3QG+1TjNrE9 lBlWqG5sMhQeUHh64UdgWCM8kN6C2IjIYeE3ISo88suornD1rV+KXvsONrbdWmJfKCQ+8JV2 ZYPcSdxpf/v/DJIdT/fD4b9SpUqVKlWq5O/Pnj179uzZ//y6oKCgoKB/z8WL169nZEB8fIEC YWFw587Dhzk5f108u91iMRjy1LxYzwAAOi1JREFU4z7u/PmkpOxsKFkyLi4sDA4fvncvLe2v 609cnM1mNufHfVxqqt+vKFC8uN1uMMDlyx6P5y/8gbDwcEmSZUhN/TWBftr+dOKc9OYN461X wWdNvp8xCarc7rKhUxr4I3ylA6+CfkY28y1IF7TTnAChuTBQWAR6gniWd0G/ol/0NQSxuBgl fw7aT8J9uQBwQ+sbaALCy8ISwQ2BKcIb4jQQr2gPxPpArHBG0UEYrh8Sj4MWgkO2Al8JXwVK gVrW/YryNZQamfBmpU/hrur1HPgI0sLlw7l7oIBJu+HoAEkvqt/In0NG9Ue9H+6DTx3v3Pp0 OdwxpRgC4yByrGlqzmzQjyhznaMgPca1xPMaeBbaNxWpCvE9Cv1YNAGYH9IqdBukPojKLnwU vIdTOyfGgve8sZF5PzhCQt8JuQfCXRbqRcGcKS4KSBAWMOjqDdDfV284nRDaxfiKWALMe6Ww QBTcaJ34StYZ8HXQcqx1QT1Ef8kFeieqa8NB/lHool+A5OTsEP8+sDV2lDW3BXmwXNkyALzV POmeDyA0Xe6jSiAGeFW4BcbSclfbOTCHmcPNMWBcYN/uSQOhIC25DeJOIVF4BtRC2oeB78C2 Qk6VboL5FWOJqJngfd7XKbsyCO1oYTwGvqzAM8o88O1yvpCbBYGmpg1WN7iM7lnZk0FfJLyj fARFvOG9hWpgdAmR0kTINHsWaQ8hpmvobksuhJ4xpWqnIato7tLcnuBWtc91NxBHquFT0DLp Q1MwX7FVtGaB5VXD84YToDbVj6vdQI1RdwpdQO2rHxdvg7xB0gM1wdTPXE/2Q/im0DmOjuBd 6S0qXwP3x74avgpgO26wS5OhyLbYC6GXINZYeGWRt0AvJHxsCYD9iNjNeBaKjithKdASXIHM O+4ZsO3FnzYfvA33u2bfvV0LLEX4xBsHyhwdIQp44a/7cPhH8mqXly5dunTpUujTp0+fPn3y z+cdD9Y4BwUFBT0diqJpqgrZ2b+WbPz59gIBrxe8Xpfrt6V2dntYWFxcfpy8uI/z+/3+QADu 3cvKcjrzjycnnz17+HD+fmxs5crPPffn+5sXJy/u75+Pquo6pKUpyj86v3v39u0nTsDBg4cP 374Ndes+91yxYtC4cfPm1av/6/3Ji5MX92n701UfmX61YdpESAvQLqctyN8KinQLhG76Xi0a KMZaToIwWVgrbAdS9QPCMRA+FlYIVcFf8EbIzyZQ9mTmZO0D8bacKAdAixS6i2+BvgOPUAqE e8Ln9ARGC5W1m0BHhgrlQRepoFcBYbzQXCgM4kqimQE+RXhP3wiFJpZc2OAKNC1QY2anlmB/ wVwmvjpc25YmXyoFZrPlTGgmHEw88vzhsnDnisV8/x3wW63VPbvB3qL0wpJnoUqVFz9olQUl GlYpVXswDCs5oEbXrlDXUU6P+QhiP2BtznywLoppWnA1yP6wHyM7gOdAVqPkEuDu5W7u/QCM je1VQzqAlq6L8knw9PLM9kwB47Py/UAuePF+6v4BLsXffuPRt5BoSf027S54Mz2jXSVAemi0 GH8Cs8/6mq0rcFbwSv1AumjwGA+AMkBLM+yDnP6uSl4rmJaaXzQugTBLSE3r1xBVPqRqSDMw nxIjlKPA4IDP2QdC7psv8DzEfxXxaVgixNy2+e21ocDHth6O5WAUxGb2LPBvV2b7wyD3m+wX cgtA0tFHCxOngepQewdmQW6IEuZ9BW6dSJ9yZgnIdYW73tnAXv1q9jlw/+Jf4S8BD4+n3063 guFzKdK/B+zPWItJb0OSMa2IcwE4p3ju+XeDr7y3ivc78Mz1bQs4QXnEWmERSCX4TJfBGGPc I48He1l7tKk52MqY19jGgVzNmC6KEOisHxDTIf3jnAztPlyfd6d3agKkbcksmn4dlN3Kd54f IfrrqJesKyB+f5E6CbdA/FYeamoJ3t3+itqH4GgQ1yq2C+RMcKYIr8H2h9uOH4+CYz9f/+py Z0g9kLM/pSM4a2d0ftQG/CM9Mx59//QH7B+VdxPgHz3+Z1WvXr169er/fNt1d9fdXXf/fa/L 09ZpSqcpnabkP78nvS551/2nWO1Y7Vjt+OPvW9722shrI6+N/Lt7n29K+pT0KenwxYAvBnwx 4F9/fG733O653eE543PG54z5z/N+y/st77f8u5/df+6/n6D/m6oqiqqCqqqqpv37W5/P63W7 YcqUoUMbN4ZNmxYsGDgwf/v7x/0a93F+v8/n94PfHwgoSv720KGPP37nnfzt4+f//PbXuI8L BDQNQNN+TWMf3x4+fPZsejqYzZGRBQrk7z/p+j+6zYv7tP3pGWe5VklrzAwwp4WvCZ8D+m6e ZSzojenO6yDs0WL9CaB+o9/T3wahnfi2YR2IjYSSUgEQjwg9DCtB2mOPiVkO6nv698SD6OFZ pSwITWkkmUE/rI+lAej1MdIbiEYQmoPQVXhOfxNop9fUz4GexjqxJ4g/iprlMChH5MKBOVBI K6TXvwviOhnpGqSni6Ov3YVbzuSUWz/AldRb5z01ocyaxkl1XoQLn/zQ+fQACBtUpKMjCcpG l1peYRu8dLL77d7lwbrDVtjUCvZ22VPy28LQeH/MvdyxEHL6VLa2BS6U979Z4j5kfKQdUyaD b0lawaRFYOwjzSxUGuSR9mfDo8D3iX9WzkeQ5ctZnTML3KUDs4ROkHnE+0DPANNJw6eGJmD4 RtgYKAdiT+WEW4BAmNclJ4J5muVHUysIzPC/6rNC1tGclzMvgq2gZZ5lLCh1NIvlPDivegtK H4GxhFzEeAb8Rn2edhyUS4Fhnmtgm2KYY9sJnva56wLTwP+Vr03GTXB9qNy5ZoTksymH0laD 9JPcmKtgWCFMt4wB7yavKHUBfa0UbQ4DvhQr5QbA5fd3yTgDYg1m2n+GnDK5w3Oi4cKj2x+4 ikLxI/Gjo1SIOW895CgASY1Snss9BN5uZPjHg6UGo+X1YC4lJ5MJYatCK5qXgLBKWGA6CcoB 8Yq0HOQDhk3SB6DGBR6IP0F2eO67melAdaKktmAdYj1pLQ8x80M66C1Azfb3Mq0FQwdzV+Mz UHBa+IawAxBxp7AUtwjkrZZajpugVvcOYRREfxVvibwEsmrrE6bD4Zd//vlqVThQ4ESbsy9B an02B34EbaFxdpQM3ufp/uBTEDpITaXywMO/Ytg+WV7N8v79+/fv3//783k1d/Xr169fv35+ rfPTEtkssllkM3jjjTfeeOON3593XHNcc1z7731N/k7jfxj/w/gfwG632+32v7s3+WrXrl27 dm0Yv3z88vHL849PbDux7cS2T34f41bFrYpb9Xf3Pt/65uubr28ORToW6VikIwxkIAP/hcfv 2rVr165dEKgUqBSolH98e6ftnbZ3gn70o9/f/SSD/uMpSl4im5ey/XumTXvrraZNoUSJwoWj on5//vH28+I+zu/3eAIB8Put1v/qJjy//9cSCkXxeFyu/OOybLHYbKDrqqooEAi4XLm5vx63 WkEUDYbf3oz4eNzHBQK/3hyoqvl1yL8lyxaLw/H7/Sdd/0flxX3a/nTinGF9kJDYG+JGhO8o 9REIn6rxegYwhDewAD49W7oM4kaxkTAXCPCpFAPa51oLrS9ILQqNKL0UxMPWIdEHQIhQh/gO gLZJvy2fA0aJY1gKgkXfpA8HPYlQzCAUw0V1oLr+sWAA/TrFdBvwUDfq34PenItaP5A6yrWk BFDqqJ8rP4P0yDDNugee2Rdbon4PiMjWfwo5A1GBYsfMu2DduaUZ2+KgRPvy5yJcUDW7ylFT A0gMeRB7sQIk1E05qe2CyLfsJe0doVSVsNWWt0Bop7VIeBGSFstJVz+Fhwn2zaGNQK9BWOnv wLn84aqLMuTY039K9EH4jMglBTaBPts62+GFrEqB7lpVUEd5HSlnwNBCHiZ+CzEbIopEvQSG jiSp4yH5UEb9++UgtFpouYgXQCvkOyMdgdCoED1sNth3W+5Ju8H5s/tn9wjwt/Qez90PwjVD Z2MskKr38j0CV5bnvmcGWMaYXpYPgjpcmeR1gfu+N9dVELw5gRbpHtC2Gnf7eoK8ydDaPh3c w93PZ70AYrZ5ntQWrEvN+zkDcn3hff0ciOhjbc9BXHh0dKXjkDvF1SrrBhS8H9k49hZIX4kr UvtBwrbQqJDJkFEmfZlnDTz4Kp2sn6DEq/HP2rdCIFbIDdQAcZJ5lmUSKPPoyidgj2ea4gXT CvGsfgUMTrG9XBnS9+Y0TVsF0Qn2eMM0iLsS9X7Mj2B+1/y1fBKS6qT3cJeFO+OTmz8cBqVf Lrmi4EVwbC34XnRxMCw2drWdAU+H3JuB3hBVN6ZozAEIWREzL6oB3H73YusHPjj25um0M1Xg 0RW9sn4c1JHyZ1E3gZn+6KQjYJxvnSnfAVM7S9H4l57+gP1n8maU8xLoiRMnTpw4Mf/8+PHj x48fD0WLFi1atOjTj5+XILZJaJPQJuEfXJBAAgmgLdAWaAvgy1pf1vqyFmzcuHHjxo2QlpaW lpYGUVFRUVFR0L59+/bt20Pfo32P9j0K4mBxsDg4fyYuL2H6fvT3o78fnT8zd3f93fV318OJ EydOnDiRHz7vcXFxcXFxcWBZYVlhWQHOMs4yzjIw4sqIKyOuQNOIphFNI0CppFRSKsGM7BnZ M7JhS6EthbYUgpIlS5YsWRI8HTwdPB2A9axn/e+fbl6NeaGUQimFUqDhsobLGi57ev2oqlXV qmpwr8W9FvdawIMfHvzw4IffP+/HFdtZbGexnVCMYhT7zfGJTGTif/U+vsM7vJPf/8KTC08u PBlqfVnry1pfQkbnjM4ZnWH3jN0zds/44+/PzbU3195cC9NLTC8xvQRcuHDhwoUL+WHLvFzm 5TIvw7CLwy4OuwhzD809NPc3PyyU197wlOEpw1OeXNv/uC0pW1K2pECZT8t8WuZTMC4zLjMu +03iXK1ftX7VgFOc4tSf/3f0me8z32c+2Jq6NXVrKjidTqfTCdUWVltYbSFMnDBxwsQJEHUv 6l7Uvfx4vkO+Q75D0G1GtxndZkDOrJxZObNg6IWhF4ZegJYxLWNaxjy9cfWk93V61+ldp3d9 +p8b/69TlF8TTEX5c4layZL/d8LcocOIEevW/fO4j/P7fb68meDfzkhXrDho0KRJ+fsREeXK 1agBcXFe729roG/fzsxMTweDwe3OyoLq1UuVKlQIrly5f//2bcjJsVqjosBodDjCw38f93GB wK8J/5P+rJBls9ls/v3x6dOnTdu8+cnPv1at6tULFoR69Ro3/u3NiI/Hfdr+dKmGIdcfGrgH 4ZVNy0NGQaAoFYU3Qa8nfCi8AMIKcbVhM/Cc4JXSgdXCPkxAL2WOewJow7JbpIwFymn3xHNA G94VVoDQWOyvuwGZZvpcQCSDaMAgmJGAZHK5C3orOuqJIFQRKusO4FtaKd+ALmhD/RLofZhp 7AnSAiFUag5qH+Wi5wyEF3VYy96AspWKj289E7z35O8MjcEslmpj6wc9HS9NatsMHE08oyIG gP/Bo2HZh8ApXDyanAgh8w33wvZAkeWRgbhuoA+S+0sFIXR4odWmfhA5wlYxxw6RY+xfSolg HhS3p8xOMB4yTLSsBnf9DMcDCdQOnss+J4TMDHkhtCk4WsacK3gZYmtE3YpJhti4qJjoSRDp DQ2N1qFkv0LhJS9AxI+28yEHIOqgo5ehPJh26yPcn4LU2PtOxlYomhQ5UN4Pod0NpZTpYLNJ n3u3gGE9ZZ0FwPqVsYS5AXgHeOyBopD5Tbqa8jl4Drl3+zTArCU4VoEpTjtRUYOwM6Z+xUPA 2tBwx9IPeKDazYvBsd90oEguZDZzBVKHg/8lfQaFIKNhcneXAoZ39NdCmoB7jTcxtzGUSI45 UWQB2MbJKeEHwNXMN9d7AmJXRhSw3gb7PtMS026ILxPRPjwOCtQPK2T9HLzNcy8E7ODYbFHF 0WBsoX+iFIW0io9eu9cP/D/4tyUPhOwCnhVpneH6mpSyZ3vClYT74YnLIftwzgV3ESh3styF gglQrHNJodi3YDps6h2qgKuwe4/2HVhPOiqENYUwYt6PyoaHt+5+k1ECTjx7MvPsPbhdPPeg +xh46+kesR94xns2Z78Bzs+dD1IKgCHD8jBqBbin6VvMC5/eQM1bPm7ChAkTJkx48nV5ifOT rstLpO/cuXPnzp0nt5P3+H912bq8BOZJX/VvLbS10NZCsOLyissrLud/xV56X+l9pffBzOyZ 2TOz8/fzzq8asWrEqhFP7/VM/ij5o+SPoPPUzlM7T4Ws3Vm7s3bDzL0z987cm3/d8heWv7D8 BVgfvT56fTQ0u93sdrPb+V/tp3yU8lHKR0+Ok70ne0/2HsgtnVs6t/S/348VK1esXLEyvx/N Rzcf3Xw0lJ5VelbpWfkJ83+3xMTExMTE/MT9hWEvDHth2L/eztQdU3dM3QGnBp4aeGogTNoy acukLTC9y/Qu07tAYmxibGJs/oz45EmTJ03+TQIQvzl+c/xmeL/Z+83eb/bP4z1KeJTwKAFO 1zhd43SN/AS3aXjT8KbhcLvp7aa3m8KNGzdu3Ljx5Hb+6Pv3leErw1cG+MbxjeMbBzR0NHQ0 dMCUIlOKTCkCV65cuXLlCsypMKfCnApPjtP+o/Yftf/ov/h38pTG1dN6X/+3+HdLNXJyMjIe PszfPu7x83+0VCMQ8Pl8vl8T519nnn/dnj+/cOHYsfnbvONr1owe3bdv/rZ379q1S5WCbdsm TXr9dZgzZ9CgLl1g+/bJk994A2rWjI21WH7ffl7cx/n9v9Yaq+qv63A8vpUkk8ls/v3WZitQ oGTJJ2/PnLlxw+d7crt5cZ+2P504G5eY04zPQHjf0MMRMaC9pU9S3CDkCiFCMpCCSW8A7NIr CitAGCd+Kk0C4RPfzOw5oF7NqZUTAuJCYYH5AKj9hTR9LQg19a+ZDVTQRwkRoLsphgBICAB6 Dml4QZjHPKE+6KuQhPmgZ6gzPBKInT3XPb2B3m6fdyNgYq6WBEJVoRIZINaV3mY6PFqTUTX1 IYj7bj53IxXGW7qvHfYWVDpZrl6bG1Clbq2XWreH1hkvN+3cHwwTyn1cIBx+XLOn9e51sKv9 gYxzW8F4NjBPy4HyjR3h4fUh3qEneN6HEn5TdPazUPb5mGvGdhBSNK5fKQGkA5aDjh7g25bx Wsp58A93XnH1AWOibAktDXorkynyPKRszhmoVYIHlbJn+hpC+k5nKbUdJO9KP+IWIfXLzMGu L+Fhi7TtWd+A+ZS5iuQE4Z4/RRsOclemqsMgKtP6qlARor+1LjRXA8dF2aaWAut505vGePDH KG9QD7zD1NvZyZAtBvafjoSU17OqXzwPGbsDva6OAGcN39fuWJDus9sgg7tNIMTzBRAuDTA8 BHcvnzGrPOTuChxKXAyp/bNO3pkFaR9mfe15CGkbnMaU98HwYtgtRz8IERyZUdvB0d70NXYI M4QcM5YD4RVlumkC5F7OTfC8AMbT0nnFAzwn2mkPag/RbtsA2lxzU99gEDrYBmQlQvbVQJHU LnCt3sPQm3GQGuk5//AKFBxVokvYLCh8rHCbkn1BUIR46wBwF84tEkgFS6xjcMjrELou5n5M RUj9LDE05yCcjz3+9VkB7ryUfSQ7DNTahhGGs0AXzSd0BdYJTYSaIL0YnlwoDpTNcmi8AEKG OEL4A/+B/1F56zHnJb55M0aPr9P8z+SVZjxe65zXTl67eXH+1fbzEph169atW7fu99u6l+te rnsZdk3fNX3X9PzHjR07duzYsVBvVb1V9VbBmPVj1o/5zQzu49f/WQXbFWxXsF3+DF7ezGHG 1IypGVPzr9vfY3+P/T3y94etGLZi2AoYeGLgiYEnIPxW+K3wW399Px4vqRlqHmoeaoY3lr6x 9I2lEPJOyDsh7zy91+ePCm0U2ii0Ecz1zfXN9UGbh20etvk3ypPynneembNmzpo5C3Zm7szc mQlDTUNNQ02wwrzCvMIMcUlxSXFJ+dcblxqXGpdCbKvYVrGt/nm8bVO2Tdn2m5rhJk2aNGnS BBq/2/jdxu/mH9/eeXvn7f/Fjxj90ffv4M8Hfz74c/5+XglMw+sNrze8DktOLzm95DT07Nmz Z8+ev49TYGKBiQUmQvfc7rndc/Pj5MzMmZkzM/+6pzWuntb7+r/F46Uaf3S7e/eyZW++mb99 3OPnH3/8k0s1fl3HOW/G+fGZ5/zr/vHx9u2ff75qVXA4LJZ/NBPco0fdupUr/779vLiPy59x /nX/8W3ejPO/un3xxYYNy5d/crt/1Yzzny7VKDI3sk/hhWC4Yz5hdYC2Ws/UyoAQz239HuhW vZuwDcQEpin1gZHCAuu34Hsua3bOLfCf8kihx8BoMPSUeoLYRb0WWA5s0MPkLcBKsZfuBeFT fT65oB/SL/MLCP2FrqwANVJvqyWA1E0rLtwA38Dcd3wCCEkep/cBCLpc2rQIpNamjdp6EF6Q RbkF6Eu04+poMGz2rvHEQoPQZ30dqkL4LdvdEgngC/dnegeCvXv08CIjwWEU6hdrAFHeom7l R4jwRLwV9gzs77t/+K6PYG3y1cPp5SFmhqeufhlKXA6bbGsHxnhxnzcKCnYLE9UmsOEZrQI5 cNJmqFViEGj7Mvrd3wiBj3I2pR4A3lF76b3AUiWkcfhh0JbIG4W54G/k76FtB/ejnFGpWRCI 9IXktgd7VXNLaQhE9rap5q1gv2A4bC0Nnk/1xnoYRNUOX2qYChEDwwqEZUPKV2nfeZaDbYj8 uWs9mLbI6dJBSCmcISTvhoT3IvvFdYfU3b5h0cMg9UtfvesDwR5precYA/pE6X2zCqnr3drd jSAszYmVT0PIKcu3sYVA+tH6g3sz2Mo52oQuALG78n3EZ2D8RbxvTARtOkVdP8Ldeg8mpZUG 32veVOc6KNQ4Zqm9ONw5kFJJfxncCcra1AFQMCu8pdwXAvOUheaj4G7haRQIh8xH7gHaLIgs Zf+m4EVwvRYYRAmwRZsWGUdDsU4xO8uchoL3Cn1S/CiEvRE+In4Z+FsHpkoNwF3DX84XCqEn wztGxILjWnT5iE6Q+VzqdudyuHPubOylTXDfkflW8kDQZhgjQ4cBC9RXhbdB68Ym3wUQy5ka h5lAmK4dD0SA9ryvXOZhkB4FdFcMUPzpDNTHSys2bdq0adOm/BnhP7oec15t8+Py2slr90lx /5m8BKbo6KKji47+Ly704OE3yxEJJ4WTwkmgGc1oBsIp4ZTwm6/Gtf5af63/75t5/Lh6TD2m Hvvn/RQHiYPEQb/ZXywuFhf//jq9v95f7w9YsWL9TT/znOQkJ4EudKHLH3+d/tV+BCoHKgcq 5+9Lg6RB0iAQ7IJdsIM0Whotjf7n8Z62kNUhq0NWgzhaHC3+g/h/9P35sMCHBT4sAO0Xtl/Y fiEce/HYi8dehKN9j/Y92he2FNhSYEsBWDF9xfQV02Eta1n773S4GtWoBltmbpm55TcJZ94f jI/LK9kYUm1ItSH/oGTjj75/eSUUv7vu/5S+/DNSTammVPOfx3ncvzuu/tn7GvR/yy/V+MeJ 7NOM89v2n1SqEQh4vb+9OfBJnnR+5cqjR69dgxUrjh+/fRvGjWvZsnJl6NKlevWSJaFmzTJl ihb99fEnT/4+7u/j/N8zzo97UqnGxImdOxcp8uT+37+fk5ObC273P273P3bG2XzCVVduAobK 9JAKAejzuQfcEioIN0D0ya/L90BFmKpvAIYLR/XjoH7gnSVdAV8zqXrsHBAHS4tRgFLaBRaB Pkx4n9vAJX21Hgl6Kh4igP04uQR6N70WX4BhgHRE/hYMTY2zjJVAOuooEFMbEjf5JhkLwdWl 6aP1BZA101dYGArSD2Ib2oKyRdnr3wMhBeOLlP4eQu3RRQt1Au/3itf9CITPxPYMAuVtNd27 HAJ1Asu8I0A7431LXQAJfeLKVT0G7dfXlJ4vD/U+q1guIgfChharZagNynrjQN/HUMwSvSci BspEla4Tchqq6NbQrGrwzCijpLWAMCU6pMgKkAhrXLglqA19t7Nqgys+63jSJOCqVo1pEHo6 9OfI0RA7toCvaDYUeFDojWJDIdRnqxBRAoRbhllyWQg9FL0oIgAOk2Wa6WtIPpDSPusGnN91 pXTKR5C9zRviXwm2PvYWEZlg/8Im2dpB5V5FdxRZCqV6RsQVjgKDnba+L6FwbtTRYj9B2cFh mXXfhUJX7Q0KfQ22GxaLpS6UTCh2qWILiLCF9Y48BRGTQk1xk0GeJkkRZcDTTT3pUUAZoduz 94NJNM80d4fwDfaXCIOEj+O2hBwEVcRlrQJRb0X95PgGnj1fulTCBQgNt30c2h+kqUKk3AJs oZZESy+wum29jVYQm5namY9B7L2w+KJfQKluRdJKy1D2cLk61ZuCPTHkuwI/Q3Z311Q9F7KG ek3KI7DWisyKrA6miZFzI3MgW3/QL7sS3L1w8uXTpyH5cEbfW8dAjTBXtiSD/qoUbbwEmqKv 1VuDUEz4nILAI3WXty4oNt9G5yNQKqgvuG6BYqWRsu/pDdS8BLZIkSJFfvtBkvcf/uM/rf1H 5T3u8cQhL85fVQvdeE3jNY3X5O9/tPWjrR9thYNlD5Y9WBYmTZo06be1eE2bNG3StEn+fl4N bvKW5C3JW2Bt47WN1zaGB+MfjH8w/un1s87QOkPrDM3fn/3K7FdmvwKLhEXCIgEyu2R2yfw3 EuZ/Vc3TNU/XPJ2//9nhzw5/dhjmH59/fP7x/75+/FH/6vvzlu0t21u2/BrnqserHq96HAbX HFxzcE2wvmV9y/rW72dYhcXCYmFxfq1wXonBk1wPvR56PRRuvXvr3Vvv5rf/+DcjeTPCSeOT xieNhwtfX/j6wtf//utRZ3md5XV+cxPmJwc/OfjJQdjTbU+3Pd3gtfmvzX9tPqy+tvra6j9x 8+yfHVdB/5780ol/bca5SZNBg775Jn/7uMfP/76df5yoBwK/Lgv3+KoXj3vS8X37rl9PTs4/ v3Tp4cPXrz/58XnbvLi/vy7v5sB/XFIhy7+WZjy+PXDg1q2kJLh0yeXyeH6/zc39db3mJ5dq /IfeHGj7JXJ83BLQO0q1DFdBXMl4PgAlyb8v0Bt8z3jWuiuB6dVQ7J+BsbAwRj8PF+bdzE7v C6ENivYo2gaMY5ilDQfvh0I7cREIP/GT7gP9XU5piSDOEnpIx0CoxBZhHegXqEEpcL7uzMm6 Cetmrb+w2QK+z1VzxC6osvO5tvV2gl7Q8IC9IPWUU+QLIEZrO5VioPUXTxt6A69QQ/gcAs/5 b+sXQPRLbdgFbNK7kQ7Cat4WpwLzxaLqK0BBbYhshUBPUsS3QVxT4N3KxaDiMXGcfRMUe8O0 6NwcyCgRnpw1CsTLOSc8NhA/KfDeMx6oMLbCgcBlKLAuJcU5Hc4WzfApG+H8fPGa/V24X9bc pOh90O7k7EkZDb7O6U2TB4BWyP5l6A6wvx/yZYgCpp8sTU0FQPzE/pX9PGgBpbO/KaTsyooW +oOrsOeSmg2uWfpLhj0gxsjF1dvAMO1LPQruv55yLs0LbFVfN4RCWPPQIpbzoLwknfcdghI7 Q/oWeRHkBMOCiEKQc97l8SwFfZaww/cemLdrg8L2AG20xgwE0xS5g/gVGK/SOiIFDP1s/bKu gOc7j5RxBdKN2V1YCOp4/+TES1CqRExs2QCETpQOxr8Kto1hs/CBUsF11inBo5GJqmsMpPR2 JrssYH7FrJrOgdhU2KMeB0eKeaqtJ4SWiagbsgDs4x2GsNVg/tA+21IefLm+4sI+cI5zDvYL IL1netcUDpFq7NKYZWDuYt5jGA25k+/1Tv4UUtff6X/DBDlNsrW7JcGD0RD+GajDGGt8A/Rp 2jz1139/g9XLoN/Xj+oVQBtJrF4RiBAy1I0g2ok2vgO8QEu9yv8ZJB2e3oDNqz3OW585Ozs7 Ozs7fz9v+6SZ5X+26sbjcf4qr3he8bziAb/u1/06bBy5ceTGkTAybWTayDSIvht9N/ouDCo8 qPCgwtAz0DPQ8zcfyCNsI2wjbDDbPNs82wzfjvp21LejIPpe9L3oe5BCCilPoZ99KvWp1KcS PHrx0YuPXoTtk7dP3j4ZCu8rvK/wPoicGjk1ciqk70jfkf4X/tDNAH2APkCHh6Mejno4CjYn bU7anAQVIipEVIjIL1HIS1T/bv/q+5OXwM5cPXP1zNUw0jbSNtIG6lH1qHo0/2bMkUVGFhn5 mz8cO6Z2TO2YCj90/6H7D93zbxp80k1seTdVcolLXILW41qPaz3u96UieTfbfc7nfA5sn7J9 yvYpUOGbCt9U+IZ/Wb9+/fr16wfO2c7Zztmwbd+2fdv2wZa7W+5uuQs1/TX9Nf35Nz/+u/7s uAr696jqrz8h/aRE9t9v979uLy/u4wIBv9/vB0n6ddWMJ8lbVeNxly8/ePDbH1Z5fP9Jj8+L +/v+/Drz+6TCCZvNbrdYwOdTlN9esWvXkSOJiaBpgUBy8u8f98wzRYuazVClyrPP/qMJnry4 T5tw5MiRI0eO6HqtWrVq1ar1rzfgxlU/szpwzXDG3g2EDD7UKoFW17/QfxR8Me7uHh/YjOHz I5aAek1/29cXLk3bEXmqJxSPrDWm6i2wvhZ+yjAY1Etqul4UOKE69Z3ATn21+hoIvQzPGsrA raIPEi+uhCLbYmqUrA1KX6W9Hgf70w44j1cF5y8uixoJtHZ8V6gHFE8v4Sv4M5R9GL/RkAjW rtZCHAK1rNpCfAhSR2ECZ0Apq27z7gfRL/SQT4DwulRBnAP6O1oH6SCwXvxEC4DeCEFIAPGQ Lirvgb+as1xORzAmGdqqi0F90TU17U3Qvkh7Jf1bkFyRM8O6gPd++pZHDtCnpk5PfROkvbLO avAmS/c9KZBR9NaerFRYd3N/sUct4NTwzB+lVPAv807ImAv+dHeLzKkgVJFHWa5B2FshtSK2 guOd0M3mLWByGF7XHwKD1B5+GbzlXZu834Av078r8BkoK/Qr2nDwx/pveFPBN8hlyToMZqdl o3UIRGRGvhn2Nnjvu8d6u4GnsDvD+ROkV87ISm4M6kxhi/MeaB2EVyyFwNnFvyszFUJyHKvF SuBPce8UPoTseu5sVy8okxI/odBnIF8WoywV4U542p0HJ8BQW95l6Q1R68PU2A4Qud98yVQS tP36aKUrPBh8f7h3J2he42A2gmNSqGQVwPyqvMp6B2Ky4zfbFIhoHlkkKh0Mg803Qy6CNk7Z Z3gLXMnOskoueNPVzYERYFHCLoadhNAV4fPCHoJYXvvJsBucUY+yHnUB36rMgfeTweNTPs+e Cpl+1zuBw5CzUx8d1g30kuIC80kITGKW1Ah8j5QPeB0CvQM9Am0gcFhZ4zsHyqxAZ+9FYLH6 0DMdpAr6Ml8vOJl88NPNZ5/+wM1LbPNWD8hLoP9doaGhoaGhMHz48OHDh//1iXPQvybvm4Gk NkltktpA2/i28W3j82ubX97/8v6X9+fvb2m3pd2Wdn93r4OC/neoWLFVqxkzoFKl6tXLlv33 21m16sMP27TJ3+/RY9y4/2pViXPnTpy4fBnOn9+yZdSo/OPR0V26TJsGJlPhwvHx+ccTEz/+ +NVX8/cLFhw5cvnyJx9/3D+7zue7d+/hQ0hN/e67997LPz5kyIkTt29DhQoJCVbr79tNSXn0 yGCA06cfPvxX/vDw+3NzMzKgTZt69UJDf3/+woWkJLcb5s2rXr1YsT/e7pMcPXr06NGjT2HG WVM9P3gHgOEbY1PLcdDaah/rnUAubfzGUBXkZSbFXADUEH2E9h2wzLPJPwkcnzsO2faCcaHl C0MfELdJtUUTiM8IV4QXQGvHS+r3IEXLaYY3IDknc25SLtx689aio9uhSNu4rnFNIH2hu6Z7 MDidpkmml6HwmlKLyxcCf0H327jh7qxHr7iGQII7vJ/9DliP20sbMkGvoQ1hGHBKb65fAnGy sFj0g7BM7CwvBL2QvlCbBtoAvvdmAOXVjeoIkJaKpy2jQD8uDjY+BHmuY2NkFGh+tX0gFPSO hhnqGlAWWyo7m4PcznI/9gMwh0XWM88FesUUKNkPmOpoGzMVLA8lsxwNEUurzvEehzfPVXv/ 4rfwy4r9l0//CBvnHSqlfgUPXzedCy0KytGczqkHIfNwesVHH4A3x73FshTCd4bdiagHYedC S9ttYGkRedeSC3odfZk6EPTNite/DvyVfBNMu8A13FLXcA5Ml+RYaTCkX8n80vsdeF9Q9gXe A/mScWLgJGQt8/bNHArWtub9lslgj7RstD0E0zFLe19LkNcbJmjbwXU/J8Q9G8IKR8wOKwq5 Nf1G33HIWp3bKasPCMekkeJWMC40TDK8AtfG3mlwMwtsr1uPGtpD6PawhkY/RI0ufKXgJoic ERIZ3hTC74X5HJ3BNMvkDNXBUMa2yz4BAobAamk4uCZm/+h7FnI3+q4EWoFktmYZxkP4yZgb sRJYdluPOkygvJpzxXsQ0jLv37s7DNLWP6h0eRME4vXGOQtA+0R/V/gAcou6K2urwNlDlXOq QSBTK6gtB38V9Vt9JCg79Y76M6AeUvqp28BfNfBWIBL0idoOdTroZ9R+gTqgBgJNfB/8+YH6 JHmJbV6im5dA5yVYd+/evXv37pMfn1eKkXeTYF47wV8U/M+Ut+zc3lV7V+1dBf3pT3+Amcxk Zv5ybW+lv5X+Vvrf3dugoP9dNO3XmeHc3IyM3FwwmazWf7TO8b/K7//HNcM+n9vt8+XHfVwg 8Osv5+l6To7TCaL4j2/y+1dLOJ50naZ5PF4vKMo//mVAn+/XfmZmut2KAqGhFov8m+yzRImo KI/n1/WhQ0Lg8uX0dEGA/3q+HJ5/vlix+PhfZ7Ld7vzj2dkej6Lkx33a/nTirEx15eo/gqFu 2CoxDtTl/i1qdfDN0b8IrABjA1MTYkBuIzcwFADP0cBXvmYgXhKWafPAsMLcxfAuPBr76N6d jaDsUn7xfwcmpK/0XuA4YRsWfgRyn8vqnuMD+2vmmxFjwVTSvMk+CKLC7dvMEeBc5yx4XoPr q5PaZ38JBcpFzopKAdtuy8tqPUj6JuWAvxQUbhhe0HQW1KaCj4KgjFGKB46BMEVsJzYECrFY CANhF4/kNaDbRHfmBBBqUk2sDEQqTvUFUB44XVnPgaGxvWnBNqBWFB6qV0F2Om7FVQPDBXtY XEXQXlCOOzNBbes9klsOjHXNdaN/AnW3YZ3tBVA/117RJdCs8ivmY2CrWvZkvfehVemyfZ/v C2Uml6qy+WtY1O37r47Vhms7rHKJM+At72qWthY8g3JvZseCf3fKlgdDwfVFzjbzRAj90pEb FQ0hiSGrTUfAds36qvlbCH0v5COHAlGXomqoKeC/4FnvegEMiq1AThkI7FP6iSVBKeDV9K0g f1o8t3AnyOmb/bZXA1MTw5vmKiA9UNeHJIPb4K7uXwT2Q5YBQgmI/yGifPQ5sGN4IWEqpMw0 tk56FUL22g/bJkPUwZC10fvA2bnQO56+YJhjvMk+cCSFW239wXLT7Az7CowNZLN9CAT82i7p OfAXCpiIgays1IXeFyHwtZrFDtB+MXY1dwDLV6GjLO+BvXL4hohWIBX2HcEF2Q3unErdDK72 GY8S+4ByQVmc+jHYutq/1L4A33blumUReEv79/u7g120FNWOgrQpsMBdCHwfKuX0kqDXk8uR C8o9rZ8aCvpzpjg+BKWfbtKfB+2ktlUTQbgqGIx+UERltfwnvnL9o/IS3bxE+vFl5PLWcc2T V8tcpUqVKlWq/PX9C3o6Kr9W+bXKr8FylrMcYChDGfpnWw0KCnoannmmRImICLh/PykpLQ3i 4hISoqKeXgKdJy9hfvTo1zh5cR9XvnyRIhERcO7c3bvp6SCKoaEhIRAWNnjwF1/8/vonHf9n 1+m6x+PxgKZlZ+fkQKVKRYpERv7+caGhRqMs//rT3H4/JCT8WkARFmaxSBJkZIiiJEGRIqGh OTlQu3aBAjYbSJIgiP/FnXh37/4aNzdX12UZsrI8HlWFpKTsbL8/P+7T9qdLNR7Wv/Le7e0Q uemZaYVHQiDV01ktBkq6GhsYDaY+xpaGU6DListng+xR+7odDYGcOfpXcmUoeK1R5TptIdOT 5XlYD3wrleHKGDBlGleJVeDCm9cSfkmC7Kvq67mvQKkS0StLdIMENXJ9+Ww41/my81QOXPzg gf/yVbhy/sE5qRZUeqv8Ry1fhFqTKqQXHgPPnIzaLLQEobihk1gYxC36dn016NO0Zuo90JPF tkIKiN2FIobGICSL+/VWkGzKvHV1IKR29c65XRoihke0D+kN2qdOV+Y0CLeYnOXHQeg8R+8y dcHXXivnvgyME2RRBmEvSXJvEBdqEYHhoMzSf9LagqiLlQ1vAgX0aC0ZhK/0Bfo5UFP1+kIC UJ6DUhTYFloqyQ1hbeisvp88gI3tThhv9wU9wTYz6gq4p3obB+qCusldLPsX0K94ZufcBFHW zvqXg/V9OUeaBea99q72XHBYHBbrXAgZaX3ZfA7MM80mgwyGkfJotRFov5CkGcBfUv1Y8YJ+ Riuh9ABtgXYu0B0CJuV5VQNPFe8b/jEgrJEThVYgzRfixOogzRAWCVdBW6S1EAQwuU0fGPeD tkVorv0MpkpiHePLYMg1/2h9FrRw1gsXQZsSaCAmg7eit5lWFpwHvIX9AQiMDuwIpIFaV1oi vA1SjPG47RQYJ1rCjbkQXSqktgUo6IsdbLsK9wOP3kz7CXKVrHKpCyGzZnLClS6QnZvi8c8E 9SRbA7+AHKe01YqCaBLXmOoD64xmOQLkD8WNUiHQ3+Vd6V3wT1JL8x7on5CrjwcEGgpnQE8Q fhZXA+PE7dIXoMvaWb0GaG8Lt8U9oKeJF+UZ8EP3n0Z9t/PpD9ygoKCgoP8MGRlZWU4n9Onz 7rtffw2XLl2/nvI0brJ4gnLlSpWKiYGlS6dPf+UViIgIC/vtL5OmpmZnO53w4otjxixeDGfO XL/+j9aJflqqVClVKj4efvxx8uT+/SE6OjT0t/3JzPx17njcuPPnExMhJeXXmee/SkyM1SrL 8OGHFSsWLAjh4U8ngX5qpRryBMe3xg0QmJlVO9cN+quZ32TtBWGiK8llBX1M6QUlWoJa0t3X vRKcRbZd/OUdCDO/9E77XBAOWhKEU5Aw2fhqoYGQOdhdKccOp9NOaYdngaW00Rj6MngO2tbr dyFqt7V4fAMwvGssE14bdqfsDb/fBx6OFL5/0AXcEdLGwG3YcXLvpe8ug6+zn25fQ4kCjTcV qQsWl+kSvUA9pL0hekA4Kz4Q5oE4StgvdQItmw/9CSAvoq75PLhr5vgyBsC1ddd7nSoByjF9 puEL0BebRmg+iD4bEZl4BcrvKvi5ryhEJ1obF9gLWMQhBg/oq0S0BsAUYZsYAgK0NLYG4UO9 qloO9I30ZDOwS1guTAYxXLhHYdBm01kJQEBTCmpHQCjvz87VQdyc1uQWIE/Q5qsfgNzX3M2+ GbQXw4pFXgXl55DKETdA7e0XnN+Bf4BvW25HUKIDY7XqENicMSPjCmQ5M+rIHcBUz/ih+C6Y Labdlg5gqmAYYSoJYrhpgbQZpNuSLB8BqbahjHUPGPfLTcQOYDCHHCAAyDTSkkDwMklcBkKI LumbQWuq36U0KMP0ZK0vqGWUSJZAbnOlFK+Cb0NWX28sePsEpikiBMRAMeUyqCc4wAWQ15sS zQvAuNy62jYdjB3N9a1HIG60faVxOVTrUmZ21Hqo9m31VyrOgrjPil4rMQ22vbdjztfFIfnN nCl3SkLV+tV97drCuq3rH/40FPRtntcMxaHpt5Vq1EuF63EXOqaVhpPfnCxzqRzcX5IRkTEW fK2UIUpXsIw3rTD3Bvmk4TVDf9DKqwX190CtoX2pnAb9a2Gg+A2IzfUeYiho1/QHmgG0U/pB dTTQ/a/7cAgKCgoK+vvlJa6bNn3xxeuv/929yU9cjx79/PO33vq7e5OfuM6d+49v4vt/zZ9O nC1fKFP9rSGw8k7Ow01ApK+FpxJodbwF/S+BcZ/Qtvh6INQ1x/UTsN1/K7AMTJ/ERIZUAcNK ZshbIP1t94Y0AU5tOjXi4BxImG3cGfc2uBLNzV3hEJYijHQUgNitccWK9IazZ29+mSKCeC5k SIFFoC9JX58UCoUKlh1RqR0kVbvV9/p8uLzohvdmGhzfXrRDRAI06lp+tr03BNYGVvimgLzT FGF5AdRj2iZvEghnhXmmQkA/vZQQDoZxlsmmvRBTrJxWCkg8dtZzfTiU2CdFxK0B+1VXpKUd 3Ezetm9tHNjnl0yp0haEjUInqSjo99gkdwDDyEK7SnUD+d3ozGLPg75Lb8ACYLXQi0zQF+uX 0EFIZDQnQKyuRwslwNBAT1DHgfC1tlTtBq6vnM+mPwL5NWWfpySInc37HJtBjrEciogGY47l cuRVEKtZ5tl+ANNPoe5wAbRpzgEZseBFidXmQ+AD/aGWBdpRvYimg7O5Z4PnFIivuPy510CR 1L36FaC57uY8CGuF8+IUMC7mGeES6HvEvvQF/TVhieACoQFLhQTQv+BHcR3oU4TFhIA2QH9B OQh6mPC+WAr014VC8gMQNki75BYgnTGcNBwB+UxI/bC7YJlhmWH7CcwO43rzEYhLt7q1PVCt aZGaFjtUaV2zUuU6ELevtFxNAmWJcNEcDYEz+mz2QIP36rm7TgBnQWeg4XsQ0Tvh9ZKfQ7Sl x+LS+8G+2FGqlAyhV8P6FHkfyqVXn/GgPxTdUbXbxWHwnXvl3c33wP9+btZFDyR2Sv46szyo vcQZkhOMDrNmPQGGAtIywxcgm6XFYh2gO06xC+hr1XjtPGiDlFP6ZwCUoeHfPcyDgoKCgoKC noY/nThLm+Xj0jnQ3Y56th9A2BqTEjsahI5cFtKBCrJfbgK+lffjbt0GuWvUa+FjQf4gJiL2 G/CEBB7lVoWcMTmJDwdD1R0Va9deDNEDwmfG2+Bw6qXGm8dAeLStR8wU0NvLtwxvwcVBp6ru 3gvG2dZ2RZZCkdm2L8tGQ42dpW88Z4PL9SN7FQeEVuqX2vNQOa20J1IA3xjXC6nvg/C2p3FG S9DWyqqtCIgrrQNsPtAbGnKM34N01bxFjIakQaflGxUg6UL2+5fbg21R/IemDIhIjmpcdDaU /aCir+VQ8JjLV3ngBz0xo8bDguBb9LDL7e9BL+p6P6syqFJ4WccGMLwQER+dAzwjDA+tAlyg v7IA9FZcZAxwlkTWgNZS+IEPwfeJv6PeDHy5/s04QRsoPzB0Ae+9wBL3CsDgPebeBUJO9tr0 n8GUa8p8ZANrS/vYMD8U3l64QFQSdIjuV69ZJXiU+vBe5stwb/XN+Ae5cG9A2hBXL0j/zF0s MB1yz/gXC7XAnaVfVM6A0EaN1EdBIFRFiwf3aTVV6wE8I0zQN4EeLexnAbCBD0kHMUYcJj4H YpRhnOF7EDZLkYZVIG80tDHWB2mWnCZPBnmkwWP8AAxFxbfllcBEuvACGKJVayAVtBlpDR5V hUZFWnUs0Ryef6EtHYqD932xTdQd8H0RGO+NBv2YuNDXDMRY6ZrYBaSXzGG2JRA1Wi5nyQV9 LJXNS6FA4UIHmkyAgEmZruwAf7r/mv8UGD+w7TO3gMAldUhYO3j+tartK/kgfl5YWuHXIPGI e6f+Muy6uP3TAy5Impf+5oO94DEbLsibwCIoX5lOgWmNqbpxM4hHxYPiCZAjDM/Kvy6fE5xz DgoKCgoK+h/iT9c4BwUFBQUFBQUFBf1Pllfj/Kd/OTAoKCgoKCgoKCjof4Ng4hwUFBQUFBQU FBT0BwQT56CgoKCgoKCgoKA/IJg4BwUFBQUFBQUFBf0BwcQ5KCgoKCgoKCgo6A/4/5ejy7tb MCgoKCgoKCgoKCjo9/4/mpaRs8gjp8MAAAAASUVORK5CYII= --------------040305070601040507020805-- --------------040801020305020708010302-- From lainhart@us.ibm.com Wed Jan 23 10:40:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7148321F86E6 for ; Wed, 23 Jan 2013 10:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.792 X-Spam-Level: X-Spam-Status: No, score=-9.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W7QSfOilYJk for ; Wed, 23 Jan 2013 10:40:55 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id E12EF21F85D9 for ; Wed, 23 Jan 2013 10:40:54 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Jan 2013 13:40:53 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 23 Jan 2013 13:40:50 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 485ADC90041; Wed, 23 Jan 2013 13:40:49 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0NIen7B333384; Wed, 23 Jan 2013 13:40:49 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0NIemiH004583; Wed, 23 Jan 2013 13:40:48 -0500 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0NIem9N004577; Wed, 23 Jan 2013 13:40:48 -0500 In-Reply-To: <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com> References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com> To: Eve Maler MIME-Version: 1.0 X-KeepSent: CE17A9F3:B4FE6513-85257AFC:0066892E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Todd W Lainhart Date: Wed, 23 Jan 2013 13:40:47 -0500 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/23/2013 13:40:48, Serialize complete at 01/23/2013 13:40:48 Content-Type: multipart/alternative; boundary="=_alternative 00669C8485257AFC_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13012318-9360-0000-0000-00000F9A56D2 Cc: Paul Bryan , "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:40:56 -0000 This is a multipart message in MIME format. --=_alternative 00669C8485257AFC_= Content-Type: text/plain; charset="ISO-2022-JP" > On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. +1 -- Todd From: Eve Maler To: Sergey Beryozkin , Cc: Paul Bryan , "oauth@ietf.org WG" Date: 01/23/2013 12:18 PM Subject: Re: [OAUTH-WG] Concerning OAuth introspection Sent by: oauth-bounces@ietf.org Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used: http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction. Eve On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin wrote: > On 23/01/13 15:47, Justin Richer wrote: >> Which brings up an interesting question for the Registration doc: right >> now, it's set up as a single endpoint with three operations. We could >> instead define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it >> would certainly be cleaner and more RESTful API design. What do others >> think? >> > IMHO the purity should be balanced against the practicality/simplicity > of the implementation. > Talking about 3 endpoints at the spec level may be treated as the exact > requirement to have 3 separate application endpoints for the single type > of activity, the registration. Can the spec be re-worded such that > "resources" are used instead of endpoints or similar, example, "resource > available at /a will support the following, at /b - something else", or > may be something similar, thus it will read better too from the design > point of view, and let implementers to use 1 endpoint or 3 ones, > whichever way they prefer it > > Thanks, Sergey > >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation" to the request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=_alternative 00669C8485257AFC_= Content-Type: text/html; charset="ISO-2022-JP" > On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.

+1
  -- Todd







From:        Eve Maler <eve@xmlgrrl.com>
To:        Sergey Beryozkin <sberyozkin@gmail.com>,
Cc:        Paul Bryan <email@pbryan.net>, "oauth@ietf.org WG" <oauth@ietf.org>
Date:        01/23/2013 12:18 PM
Subject:        Re: [OAUTH-WG] Concerning OAuth introspection
Sent by:        oauth-bounces@ietf.org



Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.

If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used:

http://tools.ietf.org/html/draft-pbryan-http-json-resource-03

With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction.

                Eve

On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> On 23/01/13 15:47, Justin Richer wrote:
>> Which brings up an interesting question for the Registration doc: right
>> now, it's set up as a single endpoint with three operations. We could
>> instead define three endpoints for the different operations.
>>
>> I've not been keen to make that deep of a cutting change to it, but it
>> would certainly be cleaner and more RESTful API design. What do others
>> think?
>>
> IMHO the purity should be balanced against the practicality/simplicity
> of the implementation.
> Talking about 3 endpoints at the spec level may be treated as the exact
> requirement to have 3 separate application endpoints for the single type
> of activity, the registration. Can the spec be re-worded such that
> "resources" are used instead of endpoints or similar, example, "resource
> available at /a will support the following, at /b - something else", or
> may be something similar,  thus it will read better too from the design
> point of view, and let implementers to use 1 endpoint or 3 ones,
> whichever way they prefer it
>
> Thanks, Sergey
>
>> -- Justin
>>
>>
>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>> "Action" goes against REST principle.
>>> I do not think it is a good idea.
>>>
>>> =nat via iPhone
>>>
>>> Jan 23, 2013 4:00、Justin Richer<jricher@mitre.org>  のメッセージ:
>>>
>>>> (CC'ing the working group)
>>>>
>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>
>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>
>>>>  -- Justin
>>>>
>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>> Justin,
>>>>>
>>>>> This spec is looking good..
>>>>>
>>>>> One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)
>>>>>
>>>>> So the request will be like :
>>>>> token                                             REQUIRED
>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>> resource_id                                    OPTIONAL
>>>>> client_id                                         OPTIONAL
>>>>> client_secret                                   OPTIONAL
>>>>>
>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>
>>>>> Please consider.
>>>>>
>>>>> ShiuFun
>


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--=_alternative 00669C8485257AFC_=-- From phil.hunt@oracle.com Wed Jan 23 10:54:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BAA21F87DF; Wed, 23 Jan 2013 10:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxLe0JdKMApG; Wed, 23 Jan 2013 10:54:17 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D65BD21F87D6; Wed, 23 Jan 2013 10:54:13 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0NIsCXf015577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jan 2013 18:54:13 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0NIsBmE026268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 18:54:12 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0NIsAcq000595; Wed, 23 Jan 2013 12:54:10 -0600 Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jan 2013 10:54:10 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_46D4A055-32FC-4C49-A8B9-03514F999ACF" From: Phil Hunt In-Reply-To: Date: Wed, 23 Jan 2013 10:54:57 -0800 Message-Id: References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com> To: Todd W Lainhart X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Paul Bryan , "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:54:19 -0000 --Apple-Mail=_46D4A055-32FC-4C49-A8B9-03514F999ACF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My understanding is OAuth is an HTTP protocol. It is not intended to be = REST specific or by implication be RESTful. @independentid www.independentid.com phil.hunt@oracle.com On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote: > > On the other hand, it's a useful exercise to imagine how much more = benefit could potentially be gotten "for free" if we look at it through = a pure-REST lens, not just with what's already been specified but the = whole picture.=20 >=20 > +1 >=20 > -- Todd >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: Eve Maler =20 > To: Sergey Beryozkin ,=20 > Cc: Paul Bryan , "oauth@ietf.org WG" = =20 > Date: 01/23/2013 12:18 PM=20 > Subject: Re: [OAUTH-WG] Concerning OAuth introspection=20 > Sent by: oauth-bounces@ietf.org=20 >=20 >=20 >=20 > Agreed that REST purity may come at a cost that's too high. On the = other hand, it's a useful exercise to imagine how much more benefit = could potentially be gotten "for free" if we look at it through a = pure-REST lens, not just with what's already been specified but the = whole picture. >=20 > If what you're registering is a client descriptor, then creating a new = one, updating an existing one, deleting, and even patching could come = for free if something like the following framework is used: >=20 > http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 >=20 > With standard libraries possibly floating around to support this = framework (I think Paul B wrote one; maybe he open-sourced it?), it = starts to become a lot cheaper to support client registration on both = sides of the interaction. >=20 > Eve >=20 > On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin = wrote: >=20 > > On 23/01/13 15:47, Justin Richer wrote: > >> Which brings up an interesting question for the Registration doc: = right > >> now, it's set up as a single endpoint with three operations. We = could > >> instead define three endpoints for the different operations. > >>=20 > >> I've not been keen to make that deep of a cutting change to it, but = it > >> would certainly be cleaner and more RESTful API design. What do = others > >> think? > >>=20 > > IMHO the purity should be balanced against the = practicality/simplicity > > of the implementation. > > Talking about 3 endpoints at the spec level may be treated as the = exact > > requirement to have 3 separate application endpoints for the single = type > > of activity, the registration. Can the spec be re-worded such that > > "resources" are used instead of endpoints or similar, example, = "resource > > available at /a will support the following, at /b - something else", = or > > may be something similar, thus it will read better too from the = design > > point of view, and let implementers to use 1 endpoint or 3 ones, > > whichever way they prefer it > >=20 > > Thanks, Sergey > >=20 > >> -- Justin > >>=20 > >>=20 > >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: > >>> "Action" goes against REST principle. > >>> I do not think it is a good idea. > >>>=20 > >>> =3Dnat via iPhone > >>>=20 > >>> Jan 23, 2013 4:00=E3=80=81Justin Richer = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > >>>=20 > >>>> (CC'ing the working group) > >>>>=20 > >>>> I'm not sure what the "action/operation" flag would accomplish. = The idea behind having different endpoints in OAuth is that they each do = different kinds of things. The only "action/operation" that I had = envisioned for the introspection endpoint is introspection itself: "I = have a token, what does it mean?" > >>>>=20 > >>>> Note that client_id and client_secret *can* already be used at = this endpoint if the server supports that as part of their client = credentials setup. The examples use HTTP Basic with client id and secret = right now. Basically, the client can authenticate however it wants, = including any of the methods that OAuth2 allows on the token endpoint. = It could also authenticate with an access token. At least, that's the = intent of the introspection draft -- if that's unclear, I'd be happy to = accept suggested changes to clarify this text. > >>>>=20 > >>>> -- Justin > >>>>=20 > >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: > >>>>> Justin, > >>>>>=20 > >>>>> This spec is looking good.. > >>>>>=20 > >>>>> One thing I would like to recommend is to add = "action"/"operation" to the request. (and potentially add client_id and = client_secret) > >>>>>=20 > >>>>> So the request will be like : > >>>>> token REQUIRED > >>>>> operation (wording to be determine) OPTIONAL inquire (default) = | revoke ... > >>>>> resource_id OPTIONAL > >>>>> client_id OPTIONAL > >>>>> client_secret OPTIONAL > >>>>>=20 > >>>>> And for the OAuth client information, it should be an optional = parameter (in case it is a public client or client is authenticated with = SSL mutual authentication). > >>>>>=20 > >>>>> Please consider. > >>>>>=20 > >>>>> ShiuFun > >=20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=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=_46D4A055-32FC-4C49-A8B9-03514F999ACF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = understanding is OAuth is an HTTP protocol.  It is not intended to = be REST specific or by implication be = RESTful. = ---551393103-1944681668-1359227169=:88220-- From hardjono@mit.edu Sat Jan 26 13:24:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530DB21F8931 for ; Sat, 26 Jan 2013 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu3e3b07jV20 for ; Sat, 26 Jan 2013 13:24:14 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3224721F8895 for ; Sat, 26 Jan 2013 13:24:14 -0800 (PST) X-AuditID: 12074424-b7f2a6d000007b15-78-5104497da722 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A8.E9.31509.D7944015; Sat, 26 Jan 2013 16:24:13 -0500 (EST) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r0QLOCJg032249; Sat, 26 Jan 2013 16:24:12 -0500 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id r0QLO9ik004427; Sat, 26 Jan 2013 16:24:12 -0500 Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 26 Jan 2013 16:23:23 -0500 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.74]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.02.0309.002; Sat, 26 Jan 2013 16:24:10 -0500 From: Thomas Hardjono To: "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: New Version Notification for draft-maler-oauth-umatrust-00.txt Thread-Index: AQHN/ARF5zKVj0xSUE2QXZp2EbgHD5hcHexw Date: Sat, 26 Jan 2013 21:24:09 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A10E1CA4E@OC11EXPO24.exchange.mit.edu> References: <20130126203231.15744.760.idtracker@ietfa.amsl.com> In-Reply-To: <20130126203231.15744.760.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.184.223.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGKsWRmVeSWpSXmKPExsUixCmqrVvryRJocHOnmMXKSTvYLd5dWMpo sXTnPVaLk29fsTmweCzetJ/NY8mSn0wey78+YPHY13KVLYAlissmJTUnsyy1SN8ugSvj7smo gj2iFasXyDcwfhHpYuTkkBAwkdh+8Bg7hC0mceHeerYuRi4OIYF9jBJTFs1hgnAOMEr83zOF HcK5wigxa+dZVpAWIYHtjBKPenUhEqsYJdb0vGUESbAJaEic+70XqIODQ0TAUuLETX6QGmaB F4wS617eAqsRFvCWmHN6OROILSLgI3Fm2jU2CNtI4s20g8wgNouAqsS3mdfBlvEKBEn0nb/D BLHYXuLPlp9gd3MKOEgcvfEQzGYE+uH7qTVgNcwC4hK3nsxngvhNUGLR7D3MMH/+2/WQDcJW kni09xwTyJ3MApoS63fpQ7QqSkzphhjJC9R6cuYTlgmMkrOQTJ2F0DELSccsJB0LGFlWMcqm 5Fbp5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBEUvu4vKDsbmQ0qHGAU4GJV4eD0WMAUK sSaWFVfmHmKU5GBSEuW96cgSKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN1sBKMebklhZlVqU D5OS5mBREue9nnLTX0ggPbEkNTs1tSC1CCYrw8GhJMHr4QHUKFiUmp5akZaZU4KQZuLgBBnO AzRcDKSGt7ggMbc4Mx0if4pRUUqc1xgkIQCSyCjNg+uFJddXjOJArwjzeoFU8QATM1z3K6DB TCBX9zKDDC5JREhJNTBOVm9ScPcuMxHkiWxT/i7x4n7hnHW+BmI/axQrWzeZCnRWeP+Y0Wmm c/uQO8/9N6FzhPOklOYphGjaPr99MS9Jbd8d+9BWg0sZHLv+r9Rw63j28aYRr4bQAaVPdlsy /1+aoOZ2omOLyQSubSarX6Xe/CcsumrqHBkRsTZbvcnzCt15GORqTiqxFGckGmoxFxUnAgB5 337liQMAAA== Cc: "derek@ihtfp.com" Subject: [OAUTH-WG] FW: New Version Notification for draft-maler-oauth-umatrust-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 21:24:15 -0000 SGFubmVzLCBEZXJlaywgRm9sa3MsDQoNClRoaXMgaXMgYSBuZXcgZHJhZnQgZm9yIHRoZSBPQXV0 aCBXRyBvbiBhIHByb3Bvc2VkIGNvbnRyYWN0dWFsIGZyYW1ld29yayBmb3IgVU1BIGVudGl0aWVz IChhcyBkZWZpbmVkIHdpdGhpbiB0aGUgVU1BY29yZSBkcmFmdCkuDQoNClRoYW5rcy4NCg0KL3Ro b21hcy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6IFNhdHVyZGF5LCBKYW51 YXJ5IDI2LCAyMDEzIDM6MzMgUE0NClRvOiBUaG9tYXMgSGFyZGpvbm8NCkNjOiBldmVAeG1sZ3Jy bC5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWFsZXIt b2F1dGgtdW1hdHJ1c3QtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1h bGVyLW9hdXRoLXVtYXRydXN0LTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFRob21hcyBIYXJkam9ubyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOiAgICAgICAgZHJhZnQtbWFsZXItb2F1dGgtdW1hdHJ1c3QNClJldmlzaW9uOiAg ICAgICAgMDANClRpdGxlOiAgICAgICAgICAgQmluZGluZyBPYmxpZ2F0aW9ucyBvbiBVc2VyLU1h bmFnZWQgQWNjZXNzIChVTUEpIFBhcnRpY2lwYW50cw0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTAx LTI1DQpXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiAxOA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1tYWxlci1vYXV0aC11bWF0cnVzdC0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYWxlci1vYXV0aC11bWF0cnVz dA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWxl ci1vYXV0aC11bWF0cnVzdC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVXNlci1NYW5hZ2VkIEFjY2Vz cyAoVU1BKSBpcyBhIHByb2ZpbGUgb2YgT0F1dGggMi4wLiAgVU1BIGRlZmluZXMgaG93DQogICBy ZXNvdXJjZSBvd25lcnMgY2FuIGNvbnRyb2wgcHJvdGVjdGVkLXJlc291cmNlIGFjY2VzcyBieSBj bGllbnRzDQogICBvcGVyYXRlZCBieSBhcmJpdHJhcnkgcmVxdWVzdGluZyBwYXJ0aWVzLCB3aGVy ZSB0aGUgcmVzb3VyY2VzIHJlc2lkZQ0KICAgb24gYW55IG51bWJlciBvZiByZXNvdXJjZSBzZXJ2 ZXJzLCBhbmQgd2hlcmUgYSBjZW50cmFsaXplZA0KICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZ292 ZXJucyBhY2Nlc3MgYmFzZWQgb24gcmVzb3VyY2Ugb3duZXIgcG9saWN5Lg0KICAgVGhpcyBkb2N1 bWVudCBwcm92aWRlcyBhIGNvbnRyYWN0dWFsIGZyYW1ld29yayB0aGF0IGRlZmluZXMgdGhlDQog ICBtaW5pbXVtIG9ibGlnYXRpb25zIG9mIHBhcnRpZXMgdGhhdCBvcGVyYXRlIGFuZCB1c2UgVU1B LWNvbmZvcm1pbmcNCiAgIHNvZnR3YXJlIHByb2dyYW1zIGFuZCBzZXJ2aWNlcy4gIFRoZSBnb2Fs IG9mIHRoaXMgZnJhbWV3b3JrIGlzIHRvDQogICBzdXBwb3J0IGVuZC10by1lbmQgbGVnYWwgZW5m b3JjZWFiaWxpdHkgb2YgdGhlIHRlcm1zIGFuZCBjb25kaXRpb25zDQogICBvZiBhY2Nlc3Mgc2hh cmluZyByZWxhdGlvbnNoaXBzIGJldHdlZW4gYXV0aG9yaXppbmcgYW5kIHJlcXVlc3RpbmcNCiAg IHNpZGVzIHRoYXQgdXNlIFVNQS4gIFRoZSBhdWRpZW5jZSBmb3IgdGhpcyBkb2N1bWVudCBpbmNs dWRlcw0KICAgdGVjaG5vbG9naXN0cywgbGVnYWwgcHJvZmVzc2lvbmFscywgYW5kIG9wZXJhdG9y cyBvZiBVTUEtY29uZm9ybWluZw0KICAgc2VydmljZXMuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From hannes.tschofenig@gmx.net Mon Jan 28 04:53:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5377921F9224 for ; Mon, 28 Jan 2013 04:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.626 X-Spam-Level: X-Spam-Status: No, score=-100.626 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3glDq3wLjV7 for ; Mon, 28 Jan 2013 04:53:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CC22721F9222 for ; Mon, 28 Jan 2013 04:53:42 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ljwk3-1Ubd0e3CUj-00bvy1 for ; Mon, 28 Jan 2013 13:53:41 +0100 Received: (qmail invoked by alias); 28 Jan 2013 12:53:41 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 28 Jan 2013 13:53:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19iUmoReC5iOob6NdIT0o4UMHtZVAOoBgIBvY23kJ 5R1LMVNAn3JsHq Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=GB2312 From: Hannes Tschofenig In-Reply-To: Date: Mon, 28 Jan 2013 14:53:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2EF51CC5-C203-4B71-A318-E94890021324@gmx.net> References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: [OAUTH-WG] Security Requirement -- was Re: Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 12:53:44 -0000 Hi Zhou,=20 sorry I missed your mail because of the subject header.=20 On Jan 18, 2013, at 11:22 AM, zhou.sujing@zte.com.cn wrote: >=20 > I have some questions concerning the oauth-security document.=20 > 1. collusion=20 > Only collusion between resource servers are considered,=20 > however, collusion between resource server and client could happen.=20= Correct. I should add this.=20 > 2. AS-to-RS relationship anonymity=20 > if "the Client must not provide information about the Resource = Server in the access token request." =20 > then how AS can encrypt access token using the key shared between = AS=A1=A1and RS?=20 > I feel this requirement is unclear and conflict with some security = measures that might be taken in OAuth 2.0.=20 It is certainly true that there is a conflict between security and = privacy here. For this reason I was hoping for feedback on how important = this requirement is. There is a trade-off decision that has to be made here. =46rom your = point of view, how do you see the importance of the added security vs. = the improved anonymity? Here is the current text: The Authorization Server can be prevented from knowing which Resource Servers a Resource Owner interacts with. This requires avoiding direct communication between the Authorization Server and the Resource Server at the time when access to a protected resource by the Client is made. Additionally, the Client must not provide information about the Resource Server in the access token request. [QUESTION: Is this a desirable property given that it has other implications for security?] > 3. Compromise of client=A3=AC RS have been considered (separately)=20 > But the result of their compromise may not be limited to "client = accessing more resources ",=20 > it could be compromised client/RS redirect RO to a manipulated AS = phishing RO's credential, for example.=20 >=20 >=20 Could you expand your thoughts a bit? Here is the current text: Prevent the Domino Effect: Compromise of a single Client MUST NOT compromise keying material held by any other Client within the system, including session keys and long-term keys. Likewise, compromise of a single Resource Server MUST NOT compromise keying material held by any other Resource Server within the system. In the context of a key hierarchy, this means that the compromise of one node in the key hierarchy must not disclose the information necessary to compromise other branches in the key hierarchy. Obviously, the compromise of the root of the key hierarchy will compromise all of the keys; however, a compromise in one branch MUST NOT result in the compromise of other branches. There are many implications of this requirement; however, two implications deserve highlighting. First, the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material. Second, a party that holds keying material in a key hierarchy must not share that keying material with parties that are associated with other branches in the key hierarchy. Ciao Hannes >=20 > =20 >=20 >=20 >=20 > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-17 21:43:26: >=20 > > Hi all,=20 > >=20 > > We will have our next OAuth conference call on the 21st January=20 > > 2013, 1pm EST (for roughly one hour). > >=20 > > John & Nat kindly offered their conference bridge. It is the same=20 > > bridge we used before. > > https://www3.gotomeeting.com/join/695548174 > >=20 > > We will continue where we stopped last time, namely we stopped our=20= > > discussions at the crypto agility requirement=20 > > (first requirement in http://tools.ietf.org/html/draft-tschofenig- > > oauth-security-01#section-5). =20 > >=20 > > Here is the slide set I used last time: > > http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt > > (We stopped at slide #2.) > >=20 > > We also did not manage to get to discuss the use case Justin raised=20= > > at the first conference call. He distributed a writeup on the list: > > http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html > >=20 > > Ciao > > Hannes & Derek > >=20 > > PS: I will try to distribute my meeting minute notes from the=20 > > previous call by tomorrow.=20 > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon Jan 28 05:17:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B0B21F8427 for ; Mon, 28 Jan 2013 05:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=1.646, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtmojEHp8dpm for ; Mon, 28 Jan 2013 05:17:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C8FAB21F841F for ; Mon, 28 Jan 2013 05:17:32 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MP3Jh-1U2pGW424t-006QZk for ; Mon, 28 Jan 2013 14:17:32 +0100 Received: (qmail invoked by alias); 28 Jan 2013 13:17:31 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.219.140] by mail.gmx.net (mp030) with SMTP; 28 Jan 2013 14:17:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++eAsthkm++NzKLKOJrV8n3s5l4uTscmbezgh9Pp ab++V9HxxuHKSE From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2013 15:17:30 +0200 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Design Team X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:17:33 -0000 Hi all,=20 at the last IETF meeting we decided to schedule conference calls to = accelerate the work on the security requirements and use cases. We also = planned to create a design team after the completion of these conference = calls. Now, it is time to start this design team work and we suggest the = following approach.=20 We want transparency and for this reason we create an open design team. = This means that conference call information will be shared with the rest = of the group and for discussions the working group mailing list will be = used. We hope that those who participated in the earlier conference = calls are also willing to contribute to this design team effort.=20 The goal of the design team is to take the feedback from the security = requirements and use case discussion as input and to prepare solution = drafts. These solutions will then be used as input to the group for = discussion at the next IETF meeting. Note that the output of a design = team is always subject to approval, rejection or modification by the WG = as a whole. Since the next IETF meeting is approaching soon already we will = distribute invitations for two design team conference calls: * Feb. 4th - 1pm EST * Feb. 11th - 1pm EST=20 Any feedback? Ciao Hannes & Derek From tonynad@microsoft.com Mon Jan 28 16:10:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCCC21E8047 for ; Mon, 28 Jan 2013 16:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgf3mMaUQE4R for ; Mon, 28 Jan 2013 16:10:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id C28F021E8044 for ; Mon, 28 Jan 2013 16:10:44 -0800 (PST) Received: from BL2FFO11FD003.protection.gbl (10.173.161.203) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.596.13; Tue, 29 Jan 2013 00:10:41 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Tue, 29 Jan 2013 00:10:40 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 29 Jan 2013 00:10:10 +0000 Received: from mail52-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 Jan 2013 00:08:45 +0000 Received: from mail52-ch1 (localhost [127.0.0.1]) by mail52-ch1-R.bigfish.com (Postfix) with ESMTP id DF8F41E01B4 for ; Tue, 29 Jan 2013 00:08:44 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371Id6eahc85fh148cIzz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h) Received-SPF: softfail (mail52-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail52-ch1 (localhost.localdomain [127.0.0.1]) by mail52-ch1 (MessageSwitch) id 1359418122499959_2070; Tue, 29 Jan 2013 00:08:42 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail52-ch1.bigfish.com (Postfix) with ESMTP id 6CCF74C03D9; Tue, 29 Jan 2013 00:08:42 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 Jan 2013 00:08:42 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.257.4; Tue, 29 Jan 2013 00:08:34 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.614.5; Tue, 29 Jan 2013 00:08:32 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.165]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.165]) with mapi id 15.00.0614.003; Tue, 29 Jan 2013 00:08:31 +0000 From: Anthony Nadalin To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQAIurswAAcAY7wA== Date: Tue, 29 Jan 2013 00:08:31 +0000 Message-ID: <38216794ddab41239562c5d9a03575b4@BY2PR03MB041.namprd03.prod.outlook.com> References: <51042160.5020908@lodderstedt.net> In-Reply-To: <51042160.5020908@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: multipart/alternative; boundary="_000_38216794ddab41239562c5d9a03575b4BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(52604002)(377454001)(189002)(56816002)(5343655001)(56776001)(63696002)(50986001)(20776003)(16236675001)(512954001)(53806001)(54356001)(16676001)(76482001)(51856001)(4396001)(74662001)(15202345001)(44976002)(54316002)(31966008)(49866001)(74502001)(5343635001)(77982001)(59766001)(33646001)(79102001)(47976001)(47736001)(6806001)(550184003)(46102001)(47446002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:; A:1; MX:3; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0741C77572 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 00:10:47 -0000 --_000_38216794ddab41239562c5d9a03575b4BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. OK with new wording 2. My comment was meant for "token_type" (i.e. "bearer", "ID_Token", etc)? 3. Would like to see a way to revoke via auth_token in case someone wants t= o revoke before it is used, right now I have to retrieve it then revoke it 4. OK 5. OK with new text 6. I think clarifying words would help here 7. I prefer the wording you responded with and not the current text as it p= uts a requirement on the client From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Saturday, January 26, 2013 10:33 AM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review Hi Tony, thanks for your review comments. *** @Justin: thanks for jumping in. *** I would like to recap the results of the discussion so far and propose some= changes. Am 24.01.2013 00:54, schrieb Anthony Nadalin: Review: 1. Since not stated I assume that the Revocation Endpoint can exist o= n a different server from the Authorization server (or is it assumed that t= hey are 1), if so how is the Revocation Endpoint found? Having read your arguments I realize the current text is a bit specific abo= ut the means to obtain the endpoint location (as it does not mention other = means). current text: The location of the token revocation endpoint can be found in the authorization server's documentation. The token endpoint URI MAY include a query component. proposal: The means to obtain the location of the revocation endpoint is out of scope= of this specification. There is a range of options. The client could, for example, automatically discover this information (along with other server andpoints and properties). Alternatively, the client developer could also get to know the endpoint location from the server's documentation. Note: As this endpoint is handling security sensible credentials, such info= rmation must be obtained from a trustworthy resource. 2. Any token type that is supported can be revoked, including refresh= token ? The draft currently explicitly states support for access and refresh tokens= . Do you want the draft to be weaker at this point and to allow for the rev= ocation of any token? 3. Why does one have to send the token, can't this just be an auth_co= de ? The draft is intended to support token revocation. I agree with Justin. Aut= hz codes are short duration and one time use. I don't see a need to revoke = them. I also don't see the need to use them to revoke the respective access= token indirectly. 4. Says CORS SHOULD be supported, I think a MAY be better here since = a site may have issues supporting CORS I'm fine with MAY since I tend to see CORS as an optional feature. What do = others think? 5. Does not say but is the revocation to be immediate upon the return= of the request ? The client must assume the revocation is immediate upon the return of the r= equest. I could explicitly express this in the text current text In the next step, the authorization server invalidates the token. The client MUST NOT use this token again after revocation. Proposal In the next step, the authorization server invalidates the token. The client must assume the revocation is immediate upon the return of the request. The client MUST NOT use the token again after the revocation. 6. Does the revocation of the access token also revoke the refresh to= ken (if it was provided) ? Or is this a revocation policy decision ? As described by Justin, there are two use cases: - if the token passed to the request is a refresh token and the server supp= orts access token revocation, the server SHOULD also revoke them. - if the token passed to the request is an access token, the server may dec= ide to revoke the respective refresh token as well. I think every client must be prepared to cope with "sudden" invalidation of= any token type. So having different server policies with respect to relate= d tokens shouldn't create interop problems. What changes would you expect? 7. Section 2 says "the client MUST NOT use this token again", well th= at seems odd, not sure this should be here as the client could try to use i= t gain, there is no need to put support in client to prevent this. The client should discard the token immediately after revocation. regards. Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_38216794ddab41239562c5d9a03575b4BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1. OK with new wording=

2. My comment was mean= t for “token_type” (i.e. “bearer”, “ID_Token&= #8221;, etc)?

3. Would like to see a= way to revoke via auth_token in case someone wants to revoke before it is = used, right now I have to retrieve it then revoke it

4. OK

5. OK with new text

6. I think clarifying = words would help here

7. I prefer the wordin= g you responded with and not the current text as it puts a requirement on t= he client

 

From:= Torsten Lodderstedt [mailto:torsten@lodde= rstedt.net]
Sent: Saturday, January 26, 2013 10:33 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

 

Hi Tony,

thanks for your review comments.

*** @Justin: thanks for jumping in. ***

I would like to recap the results of the discussion so far and propose some= changes.

Am 24.01.2013 00:54, schrieb Anthony Nadalin:

Review:

 

1.     &= nbsp; Since not stated I assume that the Revocation Endpo= int can exist on a different server from the Authorization server (or is it= assumed that they are 1), if so how is the Revocation Endpoint found?=


Having read your arguments I realize the current text is a bit specific abo= ut the means to obtain the endpoint location (as it does not mention other = means).

current text:


Th=
e location of
&n=
bsp;  the token revocation endpoint can be found in the authorization<=
o:p>
&n=
bsp;  server's documentation.  The token endpoint URI MAY include=
 a query
&n=
bsp;  component.


proposal:

The means to obtain the location of the revocation endpoint is out of =
scope of this specification.
 
There is a range of options. The client could, for example, 
automatically discover this information (along with other server =

andpoints and properties). Alternatively, the client developer could <=
o:p>
also get to know the endpoint location from the server's documentation=
. 
 
Note: As this endpoint is handling security sensible credentials, such=
 information must be obtained from a trustworthy resource.



2.     &= nbsp; Any token type that is supported can be revoked, in= cluding refresh token ?


The draft currently explicitly states support for access and refresh tokens= . Do you want the draft to be weaker at this point and to allow for the rev= ocation of any token?


3.     &= nbsp; Why does one have to send the token, can’t th= is just be an auth_code ?


The draft is intended to support token revocation. I agree with Justin. Aut= hz codes are short duration and one time use. I don't see a need to revoke = them. I also don't see the need to use them to revoke the respective access= token indirectly.


4.     &= nbsp; Says CORS SHOULD be supported, I think a MAY be bet= ter here since a site may have issues supporting CORS


I'm fine with MAY since I tend to see CORS as an optional feature. What do = others think?


5.     &= nbsp; Does not say but is the revocation to be immediate = upon the return of the request ?


The client must assume the revocation is immediate upon the return of the r= equest. I could explicitly express this in the text

current text


In=
 the next step, the authorization server invalidates the token.<=
/span>
&n=
bsp;  The client MUST NOT use this token again after revocation.<=
/o:p>


Proposal

 
  In the next step, the authorization server invalidates the toke=
n. The 
client must assume the revocation is immediate upon the return of the =

request. The client MUST NOT use the token again after the revocation.=



6.     &= nbsp; Does the revocation of the access token also revoke= the refresh token (if it was provided) ? Or is this a revocation policy de= cision ?


As described by Justin, there are two use cases:

- if the token passed to the request is a refresh token and the server supp= orts access token revocation, the server SHOULD also revoke them.
- if the token passed to the request is an access token, the server may dec= ide to revoke the respective refresh token as well.

I think every client must be prepared to cope with "sudden" inval= idation of any token type. So having different server policies with respect= to related tokens shouldn't create interop problems.

What changes would you expect?


7.     &= nbsp; Section 2 says “the client MUST NOT use this = token again”, well that seems odd, not sure this should be here as th= e client could try to use it gain, there is no need to put support in clien= t to prevent this.


The client should discard the token immediately after revocation.

regards.
Torsten.




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

 

--_000_38216794ddab41239562c5d9a03575b4BY2PR03MB041namprd03pro_-- From zhou.sujing@zte.com.cn Tue Jan 29 04:10:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0483121F8860; Tue, 29 Jan 2013 04:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiP9QXTAJ3uH; Tue, 29 Jan 2013 04:10:12 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 23EEC21F8462; Tue, 29 Jan 2013 04:10:11 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A2679125CE0E; Tue, 29 Jan 2013 20:11:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r0TC9j3b055781; Tue, 29 Jan 2013 20:09:45 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <2EF51CC5-C203-4B71-A318-E94890021324@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 29 Jan 2013 20:09:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-29 20:09:44, Serialize complete at 2013-01-29 20:09:44 Content-Type: multipart/alternative; boundary="=_alternative 0042D6FF48257B02_=" X-MAIL: mse02.zte.com.cn r0TC9j3b055781 Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Security Requirement -- was Re: Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 12:10:16 -0000 This is a multipart message in MIME format. --=_alternative 0042D6FF48257B02_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEhhbm5lcywNCg0KSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ+INC009ogMjAxMy0wMS0yOCAyMDo1MzozODoNCg0KPiBIaSBaaG91LCANCj4gDQo+IHNvcnJ5 IEkgbWlzc2VkIHlvdXIgbWFpbCBiZWNhdXNlIG9mIHRoZSBzdWJqZWN0IGhlYWRlci4gDQo+IA0K PiBPbiBKYW4gMTgsIDIwMTMsIGF0IDExOjIyIEFNLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdy b3RlOg0KPiANCj4gPiANCj4gPiBJIGhhdmUgc29tZSBxdWVzdGlvbnMgY29uY2VybmluZyB0aGUg b2F1dGgtc2VjdXJpdHkgZG9jdW1lbnQuIA0KPiA+IDEuIGNvbGx1c2lvbiANCj4gPiAgICAgT25s eSBjb2xsdXNpb24gYmV0d2VlbiByZXNvdXJjZSBzZXJ2ZXJzIGFyZSBjb25zaWRlcmVkLCANCj4g PiAgaG93ZXZlciwgY29sbHVzaW9uIGJldHdlZW4gcmVzb3VyY2Ugc2VydmVyIGFuZCBjbGllbnQg Y291bGQgaGFwcGVuLiANCj4gDQo+IENvcnJlY3QuIEkgc2hvdWxkIGFkZCB0aGlzLiANCj4gDQo+ ID4gMi4gQVMtdG8tUlMgcmVsYXRpb25zaGlwIGFub255bWl0eSANCj4gPiAgICBpZiAidGhlIENs aWVudCBtdXN0IG5vdCBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSZXNvdXJjZSANCj4g U2VydmVyIGluIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdC4iIA0KPiA+ICAgdGhlbiBob3cgQVMg Y2FuIGVuY3J5cHQgYWNjZXNzIHRva2VuIHVzaW5nIHRoZSBrZXkgc2hhcmVkIA0KPiBiZXR3ZWVu IEFToaFhbmQgUlM/IA0KPiA+ICAgSSBmZWVsIHRoaXMgcmVxdWlyZW1lbnQgaXMgdW5jbGVhciBh bmQgY29uZmxpY3Qgd2l0aCBzb21lIA0KPiBzZWN1cml0eSBtZWFzdXJlcyB0aGF0IG1pZ2h0IGJl IHRha2VuIGluIE9BdXRoIDIuMC4gDQo+IA0KPiBJdCBpcyBjZXJ0YWlubHkgdHJ1ZSB0aGF0IHRo ZXJlIGlzIGEgY29uZmxpY3QgYmV0d2VlbiBzZWN1cml0eSBhbmQgDQo+IHByaXZhY3kgaGVyZS4g Rm9yIHRoaXMgcmVhc29uIEkgd2FzIGhvcGluZyBmb3IgZmVlZGJhY2sgb24gaG93IA0KPiBpbXBv cnRhbnQgdGhpcyByZXF1aXJlbWVudCBpcy4NCj4gVGhlcmUgaXMgYSB0cmFkZS1vZmYgZGVjaXNp b24gdGhhdCBoYXMgdG8gYmUgbWFkZSBoZXJlLiBGcm9tIHlvdXIgDQo+IHBvaW50IG9mIHZpZXcs IGhvdyBkbyB5b3Ugc2VlIHRoZSBpbXBvcnRhbmNlIG9mIHRoZSBhZGRlZCBzZWN1cml0eSANCj4g dnMuIHRoZSBpbXByb3ZlZCBhbm9ueW1pdHk/DQpQcml2YWN5IGlzIGFsd2F5cyB3ZWxjb21lLg0K VGhlIHF1ZXN0aW9uIGlzIHdoYXQgd2lsbCBiZSB0aGUgT0F1dGggc29sdXRpb24gdW5kZXIgdGhp cyBwcml2YWN5IA0KY29uZGl0aW9uPyANCk9yIGlzIGl0IHBvc3NpYmxlIHRvIG9idGFpbiBhbiBP QXV0aCBtZXRob2Qgd2l0aCBib3RoIHNlY3VyaXR5IGFuZCANCmFub255bWl0eT8NCg0KDQo+IA0K PiBIZXJlIGlzIHRoZSBjdXJyZW50IHRleHQ6DQo+IA0KPiAgICAgICBUaGUgQXV0aG9yaXphdGlv biBTZXJ2ZXIgY2FuIGJlDQo+ICAgICAgIHByZXZlbnRlZCBmcm9tIGtub3dpbmcgd2hpY2ggUmVz b3VyY2UgU2VydmVycyBhIFJlc291cmNlIE93bmVyDQo+ICAgICAgIGludGVyYWN0cyB3aXRoLiAg VGhpcyByZXF1aXJlcyBhdm9pZGluZyBkaXJlY3QgY29tbXVuaWNhdGlvbg0KPiAgICAgICBiZXR3 ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIFNlcnZlciBhdCB0 aGUNCj4gICAgICAgdGltZSB3aGVuIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZSBieSB0 aGUgQ2xpZW50IGlzIG1hZGUuDQo+ICAgICAgIEFkZGl0aW9uYWxseSwgdGhlIENsaWVudCBtdXN0 IG5vdCBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KPiAgICAgICBSZXNvdXJjZSBTZXJ2 ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0LiAgW1FVRVNUSU9OOiBJcyB0aGlzIGENCj4g ICAgICAgZGVzaXJhYmxlIHByb3BlcnR5IGdpdmVuIHRoYXQgaXQgaGFzIG90aGVyIGltcGxpY2F0 aW9ucyBmb3INCj4gICAgICAgc2VjdXJpdHk/XQ0KPiANCj4gDQo+ID4gMy4gQ29tcHJvbWlzZSBv ZiBjbGllbnSjrCBSUyBoYXZlIGJlZW4gY29uc2lkZXJlZCAoc2VwYXJhdGVseSkgDQo+ID4gICAg QnV0IHRoZSByZXN1bHQgb2YgdGhlaXIgY29tcHJvbWlzZSBtYXkgbm90IGJlIGxpbWl0ZWQgdG8g DQo+ICJjbGllbnQgYWNjZXNzaW5nIG1vcmUgcmVzb3VyY2VzICIsIA0KPiA+IGl0IGNvdWxkIGJl IGNvbXByb21pc2VkIGNsaWVudC9SUyAgcmVkaXJlY3QgUk8gdG8gYSBtYW5pcHVsYXRlZCBBUw0K PiBwaGlzaGluZyBSTydzIGNyZWRlbnRpYWwsIGZvciBleGFtcGxlLiANCj4gPiANCkluIHRoZSBj dXJyZW50IHRleHQsIGl0IGlzIHBvaW50ZWQgb3V0IHRoZSBjb21wcm9taXNlIG9mIGEgc2luZ2xl IENsaWVudCAoIA0KUlMpIHNob3VsZCBub3QgIHJlc3VsdCANCmluIGNvbXByb21pc2Ugb2Ygb3Ro ZXIgY2xpZW50cyAoUlMpLg0KVGhlIHRoaW5nIGlzIGNvbXByb21pc2Ugb2YgYSBjbGllbnQgY291 bGQgcmVzdWx0IGluIGRpc2Nsb3N1cmUgb2Yga2V5aW5nIA0KbWF0ZXJpYWwgaGVsZCBieSBSUywg b3IgdmljZSB2ZXJzZS4NCml0IHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgSU1PLg0KRnVydGhl ciwgZXZlbiBpZiBjb21wcm9taXNlIG9mIGNsaWVudCAoUlMpIGRvZXMgbm90IGxlYWsga2V5cyBo ZWxkIGJ5IA0Kb3RoZXIgY2xpZW50cyAoUlMpLCANCnRoZSBpbmNpZGVudCBtYXkgaGF2ZSBvdGhl ciBjb25zZXF1ZW5jZSB0aGF0IHdpbGwgZG8gaGFybSB0byB0aGUgc3lzdGVtLCANCmZvciBleGFt cGxlLCANCmEgY29tcHJvbWlzZWQgUlMgbWlnaHQgcmVkaXJlY3QgdGhlIENsaWVudCBhbmQgUmVz b3VyY2UgT3duZXIgdG8gYSBmb3JnZWQgDQpBUywgd2hpY2ggcGhpc2hpbmcgUmVzb3VyY2Ugb3du ZXIncyBwYXNzd29yZC4NCkkgYW0gc2F5aW5nIGNvbXByb21pc2Ugb2YgYSBjbGllbnQgb3IgUlMg b3IgQVMgbWF5IGxlYWQgdG8gbW9yZSB0aHJlYXQgDQp0aGFuIERvbWlubyBlZmZlY3QuDQpJIHdv bmRlciBpZiB0aGV5IGhhdmUgYmVlbiB3ZWxsIGNvbnNpZGVyZWQgaW4gdGhlIGN1cnJlbnQgZG9j dW1lbnQuIA0KDQoNCg0KPiA+IA0KPiBDb3VsZCB5b3UgZXhwYW5kIHlvdXIgdGhvdWdodHMgYSBi aXQ/IEhlcmUgaXMgdGhlIGN1cnJlbnQgdGV4dDoNCj4gDQo+ICAgIFByZXZlbnQgdGhlIERvbWlu byBFZmZlY3Q6DQo+IA0KPiAgICAgICBDb21wcm9taXNlIG9mIGEgc2luZ2xlIENsaWVudCBNVVNU IE5PVA0KPiAgICAgICBjb21wcm9taXNlIGtleWluZyBtYXRlcmlhbCBoZWxkIGJ5IGFueSBvdGhl ciBDbGllbnQgd2l0aGluIHRoZQ0KPiAgICAgICBzeXN0ZW0sIGluY2x1ZGluZyBzZXNzaW9uIGtl eXMgYW5kIGxvbmctdGVybSBrZXlzLiAgTGlrZXdpc2UsDQo+ICAgICAgIGNvbXByb21pc2Ugb2Yg YSBzaW5nbGUgUmVzb3VyY2UgU2VydmVyIE1VU1QgTk9UIGNvbXByb21pc2Uga2V5aW5nDQo+ICAg ICAgIG1hdGVyaWFsIGhlbGQgYnkgYW55IG90aGVyIFJlc291cmNlIFNlcnZlciB3aXRoaW4gdGhl IHN5c3RlbS4gIEluDQo+ICAgICAgIHRoZSBjb250ZXh0IG9mIGEga2V5IGhpZXJhcmNoeSwgdGhp cyBtZWFucyB0aGF0IHRoZSBjb21wcm9taXNlIG9mDQo+ICAgICAgIG9uZSBub2RlIGluIHRoZSBr ZXkgaGllcmFyY2h5IG11c3Qgbm90IGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbg0KPiAgICAgICBu ZWNlc3NhcnkgdG8gY29tcHJvbWlzZSBvdGhlciBicmFuY2hlcyBpbiB0aGUga2V5IGhpZXJhcmNo eS4NCj4gICAgICAgT2J2aW91c2x5LCB0aGUgY29tcHJvbWlzZSBvZiB0aGUgcm9vdCBvZiB0aGUg a2V5IGhpZXJhcmNoeSB3aWxsDQo+ICAgICAgIGNvbXByb21pc2UgYWxsIG9mIHRoZSBrZXlzOyBo b3dldmVyLCBhIGNvbXByb21pc2UgaW4gb25lIGJyYW5jaA0KPiAgICAgICBNVVNUIE5PVCByZXN1 bHQgaW4gdGhlIGNvbXByb21pc2Ugb2Ygb3RoZXIgYnJhbmNoZXMuICBUaGVyZSBhcmUNCj4gICAg ICAgbWFueSBpbXBsaWNhdGlvbnMgb2YgdGhpcyByZXF1aXJlbWVudDsgaG93ZXZlciwgdHdvIGlt cGxpY2F0aW9ucw0KPiAgICAgICBkZXNlcnZlIGhpZ2hsaWdodGluZy4gIEZpcnN0LCB0aGUgc2Nv cGUgb2YgdGhlIGtleWluZyBtYXRlcmlhbA0KPiAgICAgICBtdXN0IGJlIGRlZmluZWQgYW5kIHVu ZGVyc3Rvb2QgYnkgYWxsIHBhcnRpZXMgdGhhdCBjb21tdW5pY2F0ZQ0KPiAgICAgICB3aXRoIGEg cGFydHkgdGhhdCBob2xkcyB0aGF0IGtleWluZyBtYXRlcmlhbC4gIFNlY29uZCwgYSBwYXJ0eQ0K PiAgICAgICB0aGF0IGhvbGRzIGtleWluZyBtYXRlcmlhbCBpbiBhIGtleSBoaWVyYXJjaHkgbXVz dCBub3Qgc2hhcmUgdGhhdA0KPiAgICAgICBrZXlpbmcgbWF0ZXJpYWwgd2l0aCBwYXJ0aWVzIHRo YXQgYXJlIGFzc29jaWF0ZWQgd2l0aCBvdGhlcg0KPiAgICAgICBicmFuY2hlcyBpbiB0aGUga2V5 IGhpZXJhcmNoeS4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiA+IA0KPiA+IA0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAxLTE3IDIx OjQzOjI2Og0KPiA+IA0KPiA+ID4gSGkgYWxsLCANCj4gPiA+IA0KPiA+ID4gV2Ugd2lsbCBoYXZl IG91ciBuZXh0IE9BdXRoIGNvbmZlcmVuY2UgY2FsbCBvbiB0aGUgMjFzdCBKYW51YXJ5IA0KPiA+ ID4gMjAxMywgMXBtIEVTVCAoZm9yIHJvdWdobHkgb25lIGhvdXIpLg0KPiA+ID4gDQo+ID4gPiBK b2huICYgTmF0IGtpbmRseSBvZmZlcmVkIHRoZWlyIGNvbmZlcmVuY2UgYnJpZGdlLiBJdCBpcyB0 aGUgc2FtZSANCj4gPiA+IGJyaWRnZSB3ZSB1c2VkIGJlZm9yZS4NCj4gPiA+IGh0dHBzOi8vd3d3 My5nb3RvbWVldGluZy5jb20vam9pbi82OTU1NDgxNzQNCj4gPiA+IA0KPiA+ID4gV2Ugd2lsbCBj b250aW51ZSB3aGVyZSB3ZSBzdG9wcGVkIGxhc3QgdGltZSwgbmFtZWx5IHdlIHN0b3BwZWQgb3Vy IA0KPiA+ID4gZGlzY3Vzc2lvbnMgYXQgdGhlIGNyeXB0byBhZ2lsaXR5IHJlcXVpcmVtZW50IA0K PiA+ID4gKGZpcnN0IHJlcXVpcmVtZW50IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXRzY2hvZmVuaWctDQo+ID4gPiBvYXV0aC1zZWN1cml0eS0wMSNzZWN0aW9uLTUpLiANCj4g PiA+IA0KPiA+ID4gSGVyZSBpcyB0aGUgc2xpZGUgc2V0IEkgdXNlZCBsYXN0IHRpbWU6DQo+ID4g PiBodHRwOi8vd3d3LnRzY2hvZmVuaWcucHJpdi5hdC9PQXV0aDItU2VjdXJpdHktMTFKYW4yMDEz LnBwdA0KPiA+ID4gKFdlIHN0b3BwZWQgYXQgc2xpZGUgIzIuKQ0KPiA+ID4gDQo+ID4gPiBXZSBh bHNvIGRpZCBub3QgbWFuYWdlIHRvIGdldCB0byBkaXNjdXNzIHRoZSB1c2UgY2FzZSBKdXN0aW4g cmFpc2VkIA0KPiA+ID4gYXQgdGhlIGZpcnN0IGNvbmZlcmVuY2UgY2FsbC4gSGUgZGlzdHJpYnV0 ZWQgYSB3cml0ZXVwIG9uIHRoZSBsaXN0Og0KPiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTA0MDcuaHRtbA0KPiA+ID4gDQo+ID4gPiBD aWFvDQo+ID4gPiBIYW5uZXMgJiBEZXJlaw0KPiA+ID4gDQo+ID4gPiBQUzogSSB3aWxsIHRyeSB0 byBkaXN0cmlidXRlIG15IG1lZXRpbmcgbWludXRlIG5vdGVzIGZyb20gdGhlIA0KPiA+ID4gcHJl dmlvdXMgY2FsbCBieSB0b21vcnJvdy4gDQo+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QN Cj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo+IA0KDQo= --=_alternative 0042D6FF48257B02_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBIYW5uZXMsPC9mb250Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7DQrQtNPaIDIwMTMtMDEtMjggMjA6NTM6Mzg6PGJyPg0KPGJy Pg0KJmd0OyBIaSBaaG91LCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgc29ycnkgSSBtaXNzZWQgeW91 ciBtYWlsIGJlY2F1c2Ugb2YgdGhlIHN1YmplY3QgaGVhZGVyLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgT24gSmFuIDE4LCAyMDEzLCBhdCAxMToyMiBBTSwgemhvdS5zdWppbmdAenRlLmNvbS5jbiB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBoYXZlIHNv bWUgcXVlc3Rpb25zIGNvbmNlcm5pbmcgdGhlIG9hdXRoLXNlY3VyaXR5IGRvY3VtZW50Lg0KPGJy Pg0KJmd0OyAmZ3Q7IDEuIGNvbGx1c2lvbiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBP bmx5IGNvbGx1c2lvbiBiZXR3ZWVuIHJlc291cmNlIHNlcnZlcnMgYXJlIGNvbnNpZGVyZWQsDQo8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7aG93ZXZlciwgY29sbHVzaW9uIGJldHdlZW4gcmVzb3VyY2Ug c2VydmVyIGFuZCBjbGllbnQgY291bGQNCmhhcHBlbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENv cnJlY3QuIEkgc2hvdWxkIGFkZCB0aGlzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAyLiBB Uy10by1SUyByZWxhdGlvbnNoaXAgYW5vbnltaXR5IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7aWYgJnF1b3Q7dGhlIENsaWVudCBtdXN0IG5vdCBwcm92aWRlIGluZm9ybWF0aW9uDQphYm91 dCB0aGUgUmVzb3VyY2UgPGJyPg0KJmd0OyBTZXJ2ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiByZXF1 ZXN0LiZxdW90OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyB0aGVuIGhvdyBBUyBjYW4g ZW5jcnlwdCBhY2Nlc3MgdG9rZW4gdXNpbmcgdGhlIGtleSBzaGFyZWQNCjxicj4NCiZndDsgYmV0 d2VlbiBBU6GhYW5kIFJTPyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IEkgZmVlbCB0aGlzIHJlcXVp cmVtZW50IGlzIHVuY2xlYXIgYW5kIGNvbmZsaWN0IHdpdGggc29tZQ0KPGJyPg0KJmd0OyBzZWN1 cml0eSBtZWFzdXJlcyB0aGF0IG1pZ2h0IGJlIHRha2VuIGluIE9BdXRoIDIuMC4gPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEl0IGlzIGNlcnRhaW5seSB0cnVlIHRoYXQgdGhlcmUgaXMgYSBjb25mbGlj dCBiZXR3ZWVuIHNlY3VyaXR5IGFuZA0KPGJyPg0KJmd0OyBwcml2YWN5IGhlcmUuIEZvciB0aGlz IHJlYXNvbiBJIHdhcyBob3BpbmcgZm9yIGZlZWRiYWNrIG9uIGhvdyA8YnI+DQomZ3Q7IGltcG9y dGFudCB0aGlzIHJlcXVpcmVtZW50IGlzLjxicj4NCiZndDsgVGhlcmUgaXMgYSB0cmFkZS1vZmYg ZGVjaXNpb24gdGhhdCBoYXMgdG8gYmUgbWFkZSBoZXJlLiBGcm9tIHlvdXINCjxicj4NCiZndDsg cG9pbnQgb2YgdmlldywgaG93IGRvIHlvdSBzZWUgdGhlIGltcG9ydGFuY2Ugb2YgdGhlIGFkZGVk IHNlY3VyaXR5DQo8YnI+DQomZ3Q7IHZzLiB0aGUgaW1wcm92ZWQgYW5vbnltaXR5Pzxicj4NClBy aXZhY3kgaXMgYWx3YXlzIHdlbGNvbWUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5UaGUgcXVlc3Rpb24gaXMgd2hhdCB3aWxsIGJlIHRoZSBPQXV0aCBzb2x1dGlvbiB1bmRlcg0K dGhpcyBwcml2YWN5IGNvbmRpdGlvbj8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5PciBpcyBpdCBwb3NzaWJsZSB0byBvYnRhaW4gYW4gT0F1dGggbWV0aG9kIHdpdGggYm90aA0K c2VjdXJpdHkgYW5kIGFub255bWl0eT88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIZXJlIGlzIHRoZSBjdXJyZW50IHRleHQ6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBBdXRob3JpemF0aW9u IFNlcnZlciBjYW4gYmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByZXZlbnRlZCBm cm9tIGtub3dpbmcgd2hpY2ggUmVzb3VyY2UgU2VydmVycw0KYSBSZXNvdXJjZSBPd25lcjxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW50ZXJhY3RzIHdpdGguICZuYnNwO1RoaXMgcmVx dWlyZXMgYXZvaWRpbmcNCmRpcmVjdCBjb21tdW5pY2F0aW9uPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291 cmNlDQpTZXJ2ZXIgYXQgdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aW1lIHdo ZW4gYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlIGJ5IHRoZQ0KQ2xpZW50IGlzIG1hZGUu PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGRpdGlvbmFsbHksIHRoZSBDbGllbnQg bXVzdCBub3QgcHJvdmlkZSBpbmZvcm1hdGlvbg0KYWJvdXQgdGhlPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBSZXNvdXJjZSBTZXJ2ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0 Lg0KJm5ic3A7W1FVRVNUSU9OOiBJcyB0aGlzIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGRlc2lyYWJsZSBwcm9wZXJ0eSBnaXZlbiB0aGF0IGl0IGhhcyBvdGhlciBpbXBsaWNhdGlv bnMNCmZvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VjdXJpdHk/XTxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgMy4gQ29tcHJvbWlzZSBvZiBjbGllbnSjrCBS UyBoYXZlIGJlZW4gY29uc2lkZXJlZCAoc2VwYXJhdGVseSkNCjxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7QnV0IHRoZSByZXN1bHQgb2YgdGhlaXIgY29tcHJvbWlzZSBtYXkgbm90IGJlIGxp bWl0ZWQNCnRvIDxicj4NCiZndDsgJnF1b3Q7Y2xpZW50IGFjY2Vzc2luZyBtb3JlIHJlc291cmNl cyAmcXVvdDssIDxicj4NCiZndDsgJmd0OyBpdCBjb3VsZCBiZSBjb21wcm9taXNlZCBjbGllbnQv UlMgJm5ic3A7cmVkaXJlY3QgUk8gdG8gYSBtYW5pcHVsYXRlZA0KQVM8YnI+DQomZ3Q7IHBoaXNo aW5nIFJPJ3MgY3JlZGVudGlhbCwgZm9yIGV4YW1wbGUuIDxicj4NCiZndDsgJmd0OyA8YnI+DQpJ biB0aGUgY3VycmVudCB0ZXh0LCBpdCBpcyBwb2ludGVkIG91dCB0aGUgY29tcHJvbWlzZSBvZiBh IHNpbmdsZSBDbGllbnQNCiggUlMpIHNob3VsZCBub3QgJm5ic3A7cmVzdWx0IDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aW4gY29tcHJvbWlzZSBvZiBvdGhlciBjbGllbnRzIChS UykuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgdGhpbmcgaXMgY29tcHJv bWlzZSBvZiBhIGNsaWVudCBjb3VsZCByZXN1bHQgaW4NCmRpc2Nsb3N1cmUgb2Yga2V5aW5nIG1h dGVyaWFsIGhlbGQgYnkgUlMsIG9yIHZpY2UgdmVyc2UuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5pdCBzaG91bGQgYWxzbyBiZSBjb25zaWRlcmVkIElNTy48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZ1cnRoZXIsIGV2ZW4gaWYgY29tcHJvbWlzZSBvZiBjbGll bnQgKFJTKSBkb2VzIG5vdA0KbGVhayBrZXlzIGhlbGQgYnkgb3RoZXIgY2xpZW50cyAoUlMpLCA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnRoZSBpbmNpZGVudCBtYXkgaGF2ZSBv dGhlciBjb25zZXF1ZW5jZSB0aGF0IHdpbGwNCmRvIGhhcm0gdG8gdGhlIHN5c3RlbSwgZm9yIGV4 YW1wbGUsIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YSBjb21wcm9taXNlZCBS UyBtaWdodCByZWRpcmVjdCB0aGUgQ2xpZW50IGFuZCBSZXNvdXJjZQ0KT3duZXIgdG8gYSBmb3Jn ZWQgQVMsIHdoaWNoIHBoaXNoaW5nIFJlc291cmNlIG93bmVyJ3MgcGFzc3dvcmQuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGFtIHNheWluZyBjb21wcm9taXNlIG9mIGEgY2xp ZW50IG9yIFJTIG9yIEFTIG1heQ0KbGVhZCB0byBtb3JlIHRocmVhdCB0aGFuIERvbWlubyBlZmZl Y3QuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIHdvbmRlciBpZiB0aGV5IGhh dmUgYmVlbiB3ZWxsIGNvbnNpZGVyZWQgaW4gdGhlDQpjdXJyZW50IGRvY3VtZW50LiA8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8 YnI+DQomZ3Q7IENvdWxkIHlvdSBleHBhbmQgeW91ciB0aG91Z2h0cyBhIGJpdD8gSGVyZSBpcyB0 aGUgY3VycmVudCB0ZXh0Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UHJldmVu dCB0aGUgRG9taW5vIEVmZmVjdDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQ29tcHJvbWlzZSBvZiBhIHNpbmdsZSBDbGllbnQgTVVTVCBOT1Q8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGNvbXByb21pc2Uga2V5aW5nIG1hdGVyaWFsIGhlbGQgYnkgYW55 IG90aGVyDQpDbGllbnQgd2l0aGluIHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg c3lzdGVtLCBpbmNsdWRpbmcgc2Vzc2lvbiBrZXlzIGFuZCBsb25nLXRlcm0NCmtleXMuICZuYnNw O0xpa2V3aXNlLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcHJvbWlzZSBvZiBh IHNpbmdsZSBSZXNvdXJjZSBTZXJ2ZXIgTVVTVCBOT1QNCmNvbXByb21pc2Uga2V5aW5nPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtYXRlcmlhbCBoZWxkIGJ5IGFueSBvdGhlciBSZXNv dXJjZSBTZXJ2ZXIgd2l0aGluDQp0aGUgc3lzdGVtLiAmbmJzcDtJbjxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdGhlIGNvbnRleHQgb2YgYSBrZXkgaGllcmFyY2h5LCB0aGlzIG1lYW5z IHRoYXQNCnRoZSBjb21wcm9taXNlIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBv bmUgbm9kZSBpbiB0aGUga2V5IGhpZXJhcmNoeSBtdXN0IG5vdCBkaXNjbG9zZQ0KdGhlIGluZm9y bWF0aW9uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZWNlc3NhcnkgdG8gY29tcHJv bWlzZSBvdGhlciBicmFuY2hlcyBpbiB0aGUNCmtleSBoaWVyYXJjaHkuPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBPYnZpb3VzbHksIHRoZSBjb21wcm9taXNlIG9mIHRoZSByb290IG9m IHRoZQ0Ka2V5IGhpZXJhcmNoeSB3aWxsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBj b21wcm9taXNlIGFsbCBvZiB0aGUga2V5czsgaG93ZXZlciwgYSBjb21wcm9taXNlDQppbiBvbmUg YnJhbmNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNVVNUIE5PVCByZXN1bHQgaW4g dGhlIGNvbXByb21pc2Ugb2Ygb3RoZXIgYnJhbmNoZXMuDQombmJzcDtUaGVyZSBhcmU8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hbnkgaW1wbGljYXRpb25zIG9mIHRoaXMgcmVxdWly ZW1lbnQ7IGhvd2V2ZXIsDQp0d28gaW1wbGljYXRpb25zPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBkZXNlcnZlIGhpZ2hsaWdodGluZy4gJm5ic3A7Rmlyc3QsIHRoZSBzY29wZQ0Kb2Yg dGhlIGtleWluZyBtYXRlcmlhbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXVzdCBi ZSBkZWZpbmVkIGFuZCB1bmRlcnN0b29kIGJ5IGFsbCBwYXJ0aWVzDQp0aGF0IGNvbW11bmljYXRl PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIGEgcGFydHkgdGhhdCBob2xkcyB0 aGF0IGtleWluZyBtYXRlcmlhbC4NCiZuYnNwO1NlY29uZCwgYSBwYXJ0eTxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBob2xkcyBrZXlpbmcgbWF0ZXJpYWwgaW4gYSBrZXkgaGll cmFyY2h5DQptdXN0IG5vdCBzaGFyZSB0aGF0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBrZXlpbmcgbWF0ZXJpYWwgd2l0aCBwYXJ0aWVzIHRoYXQgYXJlIGFzc29jaWF0ZWQNCndpdGgg b3RoZXI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJyYW5jaGVzIGluIHRoZSBrZXkg aGllcmFyY2h5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDEtMTcgMjE6NDM6MjY6PGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2Ugd2lsbCBoYXZlIG91ciBuZXh0IE9BdXRoIGNvbmZl cmVuY2UgY2FsbCBvbiB0aGUgMjFzdA0KSmFudWFyeSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAyMDEz LCAxcG0gRVNUIChmb3Igcm91Z2hseSBvbmUgaG91cikuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgSm9obiAmYW1wOyBOYXQga2luZGx5IG9mZmVyZWQgdGhlaXIgY29u ZmVyZW5jZSBicmlkZ2UuIEl0DQppcyB0aGUgc2FtZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBicmlk Z2Ugd2UgdXNlZCBiZWZvcmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3czLmdvdG9t ZWV0aW5nLmNvbS9qb2luLzY5NTU0ODE3NDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7IFdlIHdpbGwgY29udGludWUgd2hlcmUgd2Ugc3RvcHBlZCBsYXN0IHRpbWUsIG5h bWVseSB3ZSBzdG9wcGVkDQpvdXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlzY3Vzc2lvbnMgYXQg dGhlIGNyeXB0byBhZ2lsaXR5IHJlcXVpcmVtZW50IDxicj4NCiZndDsgJmd0OyAmZ3Q7IChmaXJz dCByZXF1aXJlbWVudCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2Zl bmlnLTxicj4NCiZndDsgJmd0OyAmZ3Q7IG9hdXRoLXNlY3VyaXR5LTAxI3NlY3Rpb24tNSkuICZu YnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEhlcmUgaXMgdGhl IHNsaWRlIHNldCBJIHVzZWQgbGFzdCB0aW1lOjxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHA6Ly93 d3cudHNjaG9mZW5pZy5wcml2LmF0L09BdXRoMi1TZWN1cml0eS0xMUphbjIwMTMucHB0PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgKFdlIHN0b3BwZWQgYXQgc2xpZGUgIzIuKTxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdlIGFsc28gZGlkIG5vdCBtYW5hZ2UgdG8gZ2V0IHRv IGRpc2N1c3MgdGhlIHVzZSBjYXNlIEp1c3Rpbg0KcmFpc2VkIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IGF0IHRoZSBmaXJzdCBjb25mZXJlbmNlIGNhbGwuIEhlIGRpc3RyaWJ1dGVkIGEgd3JpdGV1cCBv bg0KdGhlIGxpc3Q6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTA0MDcuaHRtbDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IENpYW88YnI+DQomZ3Q7ICZndDsgJmd0OyBIYW5uZXMg JmFtcDsgRGVyZWs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBQUzog SSB3aWxsIHRyeSB0byBkaXN0cmlidXRlIG15IG1lZXRpbmcgbWludXRlIG5vdGVzIGZyb20NCnRo ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBwcmV2aW91cyBjYWxsIGJ5IHRvbW9ycm93LiA8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxp bmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZn dDsgPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 0042D6FF48257B02_=-- From donald.coffin@reminetworks.com Tue Jan 29 12:29:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D021F881E for ; Tue, 29 Jan 2013 12:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF6eRncMUWQq for ; Tue, 29 Jan 2013 12:29:27 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 42D0221F881D for ; Tue, 29 Jan 2013 12:29:25 -0800 (PST) Received: (qmail 13600 invoked by uid 0); 29 Jan 2013 20:28:59 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy9.bluehost.com with SMTP; 29 Jan 2013 20:28:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=2/liaoMNkgoZBNq3AskoJQCvu1VFhMSOxCxuQCU7udA=; b=n3P19W/cTDJ8naDNxMiBkH+lrM+qloAN9b9yIrtGLvMsBc8yvMvSauaG9Qq+8ZlC4VeC1KJ2/fZcT35F5eYALaF/7dlfv5sxWVxwCcW69yIMl/FrmzD/10fE9lOHvoX0; Received: from [68.4.207.246] (port=3643 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0Hnd-0004sX-7q; Tue, 29 Jan 2013 13:28:59 -0700 From: "Donald F Coffin" To: "Torsten Lodderstedt" Date: Tue, 29 Jan 2013 12:28:05 -0800 Message-ID: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0065_01CDFE1C.173597A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3+XySLX08nTz+qSIW8wO67JUHy7w== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: John Adkins , Scott Crowder , Dave Robin , John Teeter , pmadsen@pingidentity.com, Edward Denson , Marty Burns , Uday Verma , Ray Perlner , Anne Hendry , Lynne Rodoni , oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:29:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0065_01CDFE1C.173597A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0066_01CDFE1C.173597A0" ------=_NextPart_001_0066_01CDFE1C.173597A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Thorsten, I am working with the OpenADE Task Force to document how the "Energy Service Provider Interface (ESPI) Standard " published by the North American Energy Standards Board (NAESB) in October of 2011 should be implemented. The ESPI Standard defines how Retail Customers, Third Party applications, and Data Custodians (i.e. electrical, gas, or water utility) must interface to each other and the data format used to exchange energy information. The interface between the Retail Customer and the Data Custodian is known as "Download My Data", which defines how a Retail Customer receives their energy information in an XML file downloaded to them by the Data Custodian. The interface between the Third Party application and the Data Custodian is known as "Connect My Data", which defines the message exchanges between the Third Party application and the Data Custodian to allow the Third Party to access data at the Data Custodian after a Retail Customer has granted the Third Party application access. It is my responsibility within the OpenADE Task Force to document the integration of the OAuth 2.0 protocol with the ESPI Standard. Since the ESPI Standard requires Retail Customers, Third Party applications, and Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I am very interested in the "Token Revocation (draft-ietf-oath-revocation-xx)" work being done by you and your working group. Token Revocation Request The Token Revocation request has only the "token" parameter with the description that the authorization server is supposed to detect the token type automatically. I would like to request that an addition parameter "token_type" be added to the request. The "token_type" parameter could be optional and would define the type of token being revoked (i.e. "access", "refresh", "registration access", etc.). The ESPI Standard was developed to support the Advanced Meter Interface (AMI) which is the interface used by "Smart Meters" to provide automated energy usage collection and other operational information about a Retail Customer's residence to their Data Custodian. Third Party applications will be required to obtain the approval if each Retail Customer that has had a "Smart Meter" installed before they will be able to access the data provided by their "Smart Meter". The number of "Smart Meters" currently installed at the three largest California utilities (Pacific Gas & Electric, Southern California Edison, and San Diego Gas & Electric) is in excess of 10.0 M and growing. The following table indicates the number of "Smart Meters" each of the three utilities had installed as of May 2012: Utility "Smart Meters" Installed Pacific Gas & Electric (PG&E) 4,696,000 San Diego Gas & Electric (SDG&E) 1,364,000 Southern California Edison (SCE) 3,900,000 The numbers in the chart were taken from the "Utility-Scale Smart Meter Deployments, Plans, & Proposals -- IEE Report" published May 2012 by The Edison Foundation Institute for Electric Efficiency" which I have attached. The number of "Smart Meters" currently installed are even larger than shown in the report as I compose this email. Assuming 10% of Pacific Gas & Electric's Retail Customers decide to utilize a Third Party application (3 Third Party applications are currently supported and are 3 more Third Party applications are preparing to be supported) in order to support the ability to revoke a token they would be required to track 500,000 access tokens and 500,000 refresh tokens. Requiring PG&E's authorization server to "automatically" determine the type of Token being revoked begins to negatively impact their processing capability. If the Token Revocation request was capable of indicating the type of Token to be revoked, the amount of time it will take PG&E's authorization server would show a significant time savings to process the request. Authorization Server Revocation Policy 6. Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ? - if the token passed to the request is a refresh token and the server supports access token revocation, the server SHOULD also revoke them. - if the token passed to the request is an access token, the server may decide to revoke the respective refresh token as well. I believe that if the token passed in the request is an access token, the server MUST revoke any respective refresh token. Otherwise, their exist a potential security risk of the respective refresh token being used to gain access to the resources for which the access token was issued. It also means the authorization server will have potential "junk" in the refresh token file to search through for any additional Token Revocation request. I look forward to receiving your response. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com ------=_NextPart_001_0066_01CDFE1C.173597A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Thorsten,

 

I am working = with the OpenADE Task Force to document how the “Energy = Service Provider Interface (ESPI) Standard ” published by = the North American Energy Standards Board (NAESB) in October of = 2011 should be implemented.  The ESPI Standard defines how = Retail Customers, Third Party applications, and Data Custodians (i.e. = electrical, gas, or water utility) must interface to each other and the = data format used to exchange energy information.   The = interface between the Retail Customer and the Data Custodian is known as = “Download My Data”, which defines how a Retail = Customer receives their energy information in an XML file downloaded to = them by the Data Custodian.  The interface between the Third Party = application and the Data Custodian is known as “Connect My = Data”, which defines the message exchanges between the Third = Party application and the Data Custodian to allow the Third Party to = access data at the Data Custodian after a Retail Customer has granted = the Third Party application access.

 

It is my = responsibility within the OpenADE Task Force to document the integration = of the OAuth 2.0 protocol with the ESPI Standard.  = Since the ESPI Standard requires Retail Customers, Third Party = applications, and Data Custodians to revoke Tokens (i.e. Access and = Refresh Tokens) I am very interested in the “Token = Revocation (draft-ietf-oath-revocation-xx)” work being = done by you and your working group.

 

Token = Revocation Request

 

The Token = Revocation request has only the “token” parameter with = the description that the authorization server is supposed to detect the = token type automatically.  I would like to request that an addition = parameter “token_type” be added to the request.  The = “token_type” parameter could be optional and would define = the type of token being revoked (i.e. “access”, = “refresh”, “registration access”, = etc.).

 

The ESPI = Standard was developed to support the Advanced Meter = Interface (AMI) which is the interface used by “Smart = Meters” to provide automated energy usage collection and other = operational information about a Retail Customer’s residence to = their Data Custodian.  Third Party applications will be required to = obtain the approval if each Retail Customer that has had a “Smart = Meter” installed before they will be able to access the data = provided by their “Smart Meter”.  The number of = “Smart Meters” currently installed at the three largest = California utilities (Pacific Gas & Electric, Southern California = Edison, and San Diego Gas & Electric) is in excess of 10.0 M and = growing.  The following table indicates the number of “Smart = Meters” each of the three utilities had installed as of May = 2012:

 

Utility

“Smart = Meters” Installed

Pacific Gas = & Electric (PG&E)

4,696,000

San Diego Gas = & Electric (SDG&E)

1,364,000

Southern = California Edison (SCE)

3,900,000

 

The numbers in = the chart were taken from the “Utility-Scale Smart Meter = Deployments, Plans, & Proposals -- IEE Report” = published May 2012 by The Edison Foundation Institute for Electric = Efficiency” which I have attached.  The number of = “Smart Meters” currently installed are even larger than = shown in the report as I compose this email.  Assuming 10% of = Pacific Gas & Electric’s Retail Customers decide to utilize a = Third Party application (3 Third Party applications are currently = supported and are 3 more Third Party applications are preparing to be = supported) in order to support the ability to revoke a token they would = be required to track 500,000 access tokens and 500,000 refresh = tokens.  Requiring PG&E’s authorization server to = “automatically” determine the type of Token being revoked = begins to negatively impact their processing capability.  If the = Token Revocation request was capable of indicating the type of = Token to be revoked, the amount of time it will take PG&E’s = authorization server would show a significant time savings to process = the request.

 

Authorization = Server Revocation Policy

 

 

  &nbs= p;   6.       Does the = revocation of the access token also revoke the refresh token (if it was = provided) ? Or is this a revocation policy decision ?

 

- if = the token passed to the request is a refresh token and the server = supports access token revocation, the server SHOULD also revoke = them.
- if the token passed to the request is an access token, the = server may decide to revoke the respective refresh token as = well.

 

I = believe that if the token passed in the request is an access token, the = server MUST revoke any respective refresh token.  Otherwise, their = exist a potential security risk of the respective refresh token being = used to gain access to the resources for which the access token was = issued.  It also means the authorization server will have potential = “junk” in the refresh token file to search through for any = additional Token Revocation request.

 

I look = forward to receiving your response.

 

Best = regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, CA  = 92688-3836

 

Phone:      (949) = 636-8571

Email:       donald.coffin@reminetworks= .com

 

------=_NextPart_001_0066_01CDFE1C.173597A0-- ------=_NextPart_000_0065_01CDFE1C.173597A0 Content-Type: application/pdf; name="IEE_SmartMeterRollouts_0512.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IEE_SmartMeterRollouts_0512.pdf" JVBERi0xLjQNJeLjz9MNCjM2MTEgMCBvYmo8PC9GaXJzdCAxNzc4L0xlbmd0aCAyNzg4L0ZpbHRl ci9GbGF0ZURlY29kZS9OIDIwMC9UeXBlL09ialN0bT4+c3RyZWFtDQp42sxa7W4ctxXto8zPBEFW 5L2XX0BgQElaFHCaGrb7SzWKjbu1hSqWoawB+6H6imnP5ZzdVWINNVZToAYW5JCcw/t5eDlylDCF KUrGz/ArU2wRbZ1EBW2bpOgUNUwaMa9x0pTQymTRx3Wy5OM2pYj1mqaUfDxPqfl4mbL6+jrlgj20 TSViDwtT8WeLU+3PMtX+rFPrzza1/ox3Qx/AQyh4MjzE6FMVneRTDXJGTCVXJGEquQYNU8lFwt6x y1Sw0IU19amO5VP9BZ/yUVc2YbRLnTDaxc5ALj6SgdwFz0CufQQvdNEzkFsfwa8Ln/MkoY8UdPoI zBorMDLsKhX7lABD+5oSJzHzfWSS5FpCFEl9jU2SGzaE/vAGNgSW1L4YyM0tAU00uLpQUrtJKlwm 5mK6z4KLKei4Naqi45pWmzQHH0nomI9kdNwstUxa3GKQQKvbpwK5ukkakFuIPVK0+VsQzoL4COIh 9ilDx3dvCZ3qa/Jk4jEGx5h4kLU6mXrktYYOTCshTIZ/6ER0XMsA5AQJYcgpBVc3eKgF2C8g1jyA JCDYurVCmZII7IcXknSrtykpAlNiQAceFjwkSIYOAJtbFA85BB9J6MC8gvDKIftbCN8IoeA0dDwZ YIjsASLIm+xGEqid/Q3fOAsCVkTRcadB26wQXATIipwRaJu7puKJAUMiCqZsnm5Az+YSIteywQ+C ZMsJGJ6J2dMKkYIO3CjIt5wjcBA6OZsHEZCzh5WnXG6ev55z4oBALghzwTr4FhLCarm6EeChXOFB wS9XDz1YP7tzXZPcIIsg9XKD3wVBCWAgI+BKEAdEOgdkkiD1SkA0CVKvxOiRK+iYx7J6ykcP6qm4 hwUvFFfXc7WIGxNqF3Fj4qGoGxP7FXVjIvWK9gwAsrkx4Zhi7nekXjGEqCD1Sg8SpF5JMIAg9aAx cBAEJTXHAXKWnknouHOReiUjDgXCFUiGDpCLzZRXCrLAvVgqwkoQKKXCxoKgLDV7IgK5IswF60qD zwWilAa9BalXmjsXqVeDxyoSoAY4RGD9Gjwy4eAamudxAQW6OrBs7XyARKsejAKI6g7xbKk+LEi0 qghGQaJBHPXsRwfDAiWrM5sAtJrrjkSryYME0VCTBwkSrSbPdbihZgSAwtPQBpmNRKvZcx0mrk4y ipQAsYnzCjqe60i06kZQWKRW5xUYvTbklkLJ2uBYxUNtzivYuAVxNhJ04FiNTu6A95Ok+RGiULI5 h7nLm+exIuOaB5Er2dyQioxrLrjCQ01hDUXGNYWLFBnXXHeF9ZvrDsJDB75SZBxc4RQI5JR9BMh+ Jn311dnjCyfgMD3tZDS31dsXZ0+2N7s3++c3u50fKj52a+j73fv9490H2PHs6fXV7k/bt1gkfdHz D293Z8/2N+9e9pVPr6/3Z99cbX/6aV6kvujRI+x9jt+fz77bfrh+tz/77vLN7o+7y1ev9ziMNuHR o7PHWHz2pNO4wz47e/Z2++bsyStQ5hHim7Nz84XqC2u4f6GtXZjWLsz3LTx/uX+3vXoOg332879/ 96/Pj2+WtVvUB2/RVm4hYe3CuHahrF241ndin2aGv7452kHWelPyw/dY606pD99jrT81PDRkdK2D da2DVR8sy9ps1bX+1bx24Vpv6oOTU9c609Ymp8VPjyy81R2Zygj+yTb5UYEqxY8IVEhmLzo3V771 +/evL3+43P/NoReEm32UHxD2lu979bCwPHyPunaP9uA9Uli5R4oP30PW7qH37oHfk6vty92POPTP vr66fvnP03n99dfX7y9w89x4SSgb1GUoPmrbeIUkm2DFXvQzPPUczoc4+cPlq3c3u19thMgqYS4+ SmQrbJWtsU1sM1sWLXMg9vvlXLxMrGuw5/nN/vLl1W7e6igLVsghU769fvmuK/nd9s2rz3ZvvvzL s89XmuDLuPErVmub7HelKBtUwKh5dYMr92yCJQugfP0EW5vETUOW4g64cfV9q4abQKp5gyvxvFVY sRWs3WjlJidrHV56tr+++bBaJt30Ihgi9esgPO/3VwhUZoHiOoEq3VjrfysQjNQ/ZYSNfwPoRvJr jBspMCTlN/EHyu5NRLR/mdsmWuhX302/q8AoSeu8l/42e8WNX8/rpha/wSPYipfwyLpAx7d1di6s 9SvTLR3szoCoTLvKtKtMu8q0m+li5B/wyMvd+T/2u5sJZfzd9b0c6/t8SMXjQfL99c2P2ytcNLav brZvXz/bf2Dm+iFkroNQZmHKC3VS6qTURamLUhelLkpdlBSixFPiKfGMeEY8I54Rz4hnxDPiGfGM eEa8dLA58RLxEvES8VI62vholf37/a2TeOng/b9c0n2WaItEW2TaItMWmbbItEWmLTJtm/PYJtIv O+EYTcY1P7374fVu+/dfrqvtnnXnfdl8BtdfnY+3E+qwcj7Wy2Dl4lX3mArtlApyXyosoaU2o134 x8eZ4GnHdiumDvDPL/fH1DqPkKFXWU3GCvvCsnZhvXfhkipZaZgeYfN5tQDh5ZItHumHU7+1e5Zc +Ac5N5Z/cZ1bYatsjW1iewrKVu+sNfyTE3dt7SO69IKwjOYvjFxk5CIjFxm5yMhFRi4ycpGRi4xc ZOQiIxcZucjIRUYuMnKRkYssEe9Q+PO8MOazMZ+N+WzMZ2M+G/PZmM/GfLZMvEy8TDx+izKWg8Zy 0FgOGstBYzloLAeN5aCxHDSWg8bzznjeGc854zlnPOeM55zxnLNKPNYlVolXideIx0LKGvGYd8a8 s0a8Rjx+Y7NGvNnriIPANrIVtsrW2Ca2t0LvrsAyrcPAMx0GXv8jwSgwZQ7c/ueFuW0jgTr1fuF1 F5PmvoP+f7P4HHrNCfm4//Vj1pD5PHoRCkeSQCQJRJJAzGxpkEiDxNmzIiQVIakISUWIJ8QT4gnx WOUIqxxhlSOscoRVjrDKEVY5wipHWOUIqxxhlSOscoTMImQWIbMImUXILEJmETKLkFmEzCJkFiGz CJlFyCxCZhEyi5BZhMwiZBYhswiZRcgsQmYRMouQWYTMImQWIbMImUXILEJmETKLkFmEzCJkFiGz CJlFyCxCZhEyi5BZpBwD/pArOFG3Pxyp32YH9Pnjifv0OCmjybA4iQsOGUTqaf+PIWS0+Rx6S5Nx MBnbaLKMJkcCxZFAcSRQGAkUysCOZFabmXXJjmGwubblzS+UjK+tDPC12QhfRpNhMFnraHK0Zx3t WUd7ltGeJY8mdTQ58kBuo8kymhwZIY+MkAfZqWQ1TXnk9TRSOI0UtpHCNlLYRgrbSGEbeV1He44o UHUEK6NgklEwDcjtQnkY60xyLxZW8SjXOKJYHTGajhhNR4ymI0bTEaMpGU2HjKYjRpMBo/W/oQ8m 02hSR5MjgepIoDoSqI4EqoMgEd4VpC4HyZPD+e9D3x5qyxN33jV5zL/jBwxOPu7/A+IwWX456fVt /MI/RRw0GpWp/X9OHJDyMlJZgXQ6YEpaRmprkE52sUWk4xV/iHQyoi4j6Rqkk8VlGWmNxdvJ4nEZ aYXFNZwsHpaR2hqko8VzW0I6MME9SEc75Y/CVkNamry9ja25wx0W6xqZjhbPZXnbNRY/3nJ5bbgb aY3FT7fJvJgtB+K/B+kY49mWkdbYKZ58p8tIaQ3SkYbzr7LljqHb4GucICfTxY/BF3NKj9/xBtd2 5fVa5fgBlDfKuyH1E2JV1vhAjmdUWs5EGX+5+I8AAwCuPU3uDQplbmRzdHJlYW0NZW5kb2JqDTM2 MTIgMCBvYmo8PC9GaXJzdCAxNzcxL0xlbmd0aCAyMDU3L0ZpbHRlci9GbGF0ZURlY29kZS9OIDIw MC9UeXBlL09ialN0bS9FeHRlbmRzIDM2MTEgMCBSPj5zdHJlYW0NCnja7FpNi1w3Fv0r2mfR+rhX V4JgMPYmFBmMO7tmFj1DyASS2DTe+N/POXq3VMG2ulXgxTAUuC2VpHd0v855pfeq5BZiKLkH/Csl BhM0KSSMl5JDsoK2hJz4WUKu/KyhRH6u+LPjr2W0LUgGWulBKtZIDJrwWVJQjBXJQRvwpYSagCMS qgJHNNQOLKnYPqG1YI2fW2iJOD20ChyNoTXgaAodthTNodMeLSFFGqSCDq1RRYcmaQ1p+KKGjnCq odM51eElFwMaSzBS4XdJMKDCcV5agJ5KgwkVyILwFPiVpAKwAlnpRQWy0g2MJm0EBHJF8IoBuQK1 GJAtAtBGSAGIuCZrAETAU2N0DciN7hiQO90xIHdaaEDutNCQp0gLcWWOtLAldGghpnOihY3ZgnMF oc45Ik6Yzlk5VdHpXGwhMz2lNXTG5UCWhMUdyMLLO5AF8wXByooaKB3IitiUzkKIMAxYqAiYgfTl CltKB7Ix6R3IxqLqQDZ4KRHILRZ0gNyQXIlAbvBSMJp7zugAuSO/EoHc4aUwajErOtgvGkdgUwSq RKAnFJFwP1aqMDQsVUmwMiPdwgwBOgzfMIeOsnIrOixfeCDJWItAZhoE2ZM0qkyOclbUq+BKlA4L fBQKkDNzj2hIFqYcyHnkFciZmUalSCYzYJ2wBBt5wYg0VMsops5oFEYN1SKsmM5olBEjXF4YNZSn FFoZOUK7OVzoG8pBBukyR4hO4+lJofHgkrDMBcQThlboiQhH+KHzP4CSnALyCdkpjFrNHAFytbEw iCEkghoSAxWEGWqRI0BuyhEgNyaFHzrhwUHpjSM1aKTN4KBG2gz/NdFmGKeJNsNJzbQZbNFMmxFZ LbQZlFBKgGBjZelRW3S4iyyq0GZwUJU2g4OqtBmgWmkzKkYrbQYH1WgzOKhGM1ExarQZF8B1jgCZ EgMvg1JjBPnQTpvBwRppMz7USJtRnTXRZtR9JeMEHKxknICDNdNmGIdYcgQaN4QRHKykpoCDleVA jlWagPhBD2kzOFiVNqOqaqXNqOBaR2iBXGkzQJEcjgDZaDM4WBttBgdro83gYO20GRdAYREScNAi bFZw0CLDDw6Crxwp6AhHBJ3OEQ2WC0cgzGAssxeMNwsFB41eKBhnTDXyGYxqT9qYNnZweWXUQTQz wCtoY1Q/BdHMmDR42wouVRCt8YaAKkCH4QfRGrmuIFobtQNPGj1AgaCDWlYQDWTiYtwq6hjpoTMF qB10CmsHd4uMavrxx7vTuNPF8P7uHZSsjd793S9vX73C5Ju7d4/ph4Spks9T//jw9OfjH+8enx5/ e3r8+J/7T5//+HUsPj3wLolF4y55tMVbYfvPsYUtt4B5L2zxP7L4NO7z55jVtUO6E7PmMeqXGOka 0q7xxDY8kTQ9keW2shMTKROprJHyRkxEj5hIvcQkryHlipi8vPg0vmWdPUnrbXeiq3EixTVS30HK Z6S5/Gukae6zSDKR1nyfKXwuTweZxxfIo73UsHzB828M/X03vSKF33nxaXzLPUdkzea6w4E6OSBr EtcdDlTnQL1wQNYErddwoO5woE4OyJrNdYcDNjkgaxLXHQ7YhQNrXlraiK7JEV3TS3TXBLVyRXRf Xnwa5xj3pKzZbHUHad69y5rN1jaQ2mRBWTO17bCgTRaUNZ/aDguas6BVb23mq6wJ1q5hw3defBoH x7P7a8a2nZT0S0rWJOw7KemXlKxJ2PMOkk6kNQn7Tpz6lJgSv7pblDUd+wYveLR28LxmWO87SFN1 8pJhPMBvIM1vjfkLhp3G8X4xyW2ib3NFsfIRwoZNMwm5rr3b0Hk+cjgj6RppJ+LpEvElgfhgYwNp ftfJZY20E6d0yV1eI+kO0iXiaY20E/F8iXhcI+1EPM+IpyVbJO9EPM+IpzVb8k7E84x4sjXSTsQv J9xUvxKatC77vJOEMjU6rct+41D5IH5clr8dl9O6/ku+QgpK3vHkEvA1WcoV377zNXKV49a3rPxD HovzbfFt8W3xbfFt8W3xbfFt8W3xbfFt8f/lYj78OI03rH4+eflpy5u71+MqdH9+89PbUNLd/ac/ Q/fnrr+F4xjzy+ePv2LB+1evAKvzMcf9x8e/vtz98lAixmt3j8fm/bx5/sbm83nG3Pz0oMeRcrwv Plrztnnbj/Y4/49XxUebz0fI1M9OvX769Pu/52mvzeO1zkPm/acPT5/nfHphPj43/2DHm5dgxwtS tOZt8/Yw3Y73KmiTt9nb4q1463jV8arjVcerjmeOZ45njmeO54/+zRzPHM8czxzPHK85XnO85njN 8Zrj+aNq80fV1hyvOV5zvO543fG643XH647XHa87Xne87nhHNYV2VCPa5G32tngr3qq31Vvztnnr eMnxkuMlx0uOlxzPS7N5aTYvzeal2dJ8GfjtArL5HnI1X56d1+cL+EGPh0zjNxJHq88ZRKYXzuUt Sfr+S19j0UHV0/jxhvu28dDtQbPLQHEZ8B9iqP8QQ/3JkhYPRXFZKS4rxWXFf4ygxfHE8cTxxPHE 8cTx/IW9iuOJ44njieOp46njqeOp46njuXaoa4e6dqhrh7p2qGuHunaoa4e6dqhrh7p2qGuHunao a4e6dqhrh7p2qGuHunaoa4e6dqhrh7p2qGuHunaoa4e6dqhrh7p2qGuHunaoa4e6dqhrh7p2qGuH unaoa4e6dqhrh/ZLqV+e6j/+a4q/6RT3yzuN9+dJac9N1m9O/leAAQCT/RMODQplbmRzdHJlYW0N ZW5kb2JqDTM2MTMgMCBvYmo8PC9GaXJzdCAxNzYxL0xlbmd0aCAxODUwL0ZpbHRlci9GbGF0ZURl Y29kZS9OIDIwMC9UeXBlL09ialN0bS9FeHRlbmRzIDM2MTEgMCBSPj5zdHJlYW0NCnjaxJjNbuW4 EYVfRW9gslg/JDAYIEh2BoLGdHbGLLwIksUECRrZ5O3zlXwtTcYmm4sBsuiWfCkeVp06pyjKmhzl sNaO1rno4cHFjuFc/KhiXOOoplz7UXvjOg6pcpiWQ7RyrYcEICqHjMEVMAFN9WgOjtrRBjjqhwo4 God6zu+HjpzPHGG+lbd747dgvsnhhXCsHU4sRgzu4JgdPsAxP0KIx+IInjXrR3Tm2jh6BcvL0YnV vB7dwWPNPsDzdgwBz5U0wQFzDHCItRYBCA5qySiYVUtPqHHUWsAiz1qTqqjcJFkh3CRd0aAr+QpN 3gAO4yYZC5BbUhYgN33Lr7ZIQJC1gsMyVaHISKEqU62DbAUcIGqWyDrImYZ1kL0QWAfZBZwOssOA dZC9JyDIUQEcIAdFMMiuQXQ2QO4FQNKmpADCZ+0QZRSqdmYYKdWRZYSyOqiZUds6SMULBS+FKhQq XlI0YEkhOSdcqSWfMW6opvOHVNLNUopI5aZzQ7EdQkUIwamWNJj3CnKjHg5Z0gjKK8iKAr2CrJTI K8jGVCc3SVE69EnS5hXkBPMKsqdu0JU4RLqkSIF3lpFIKSEdCZJzNCkdQTjFk06pnT+kD5AF5KE5 C+RB8ZPrVmoqsnCD5L1VbiiIw2OrhOnppooqHWoatHKDBSQZQ8dNEL6TUpNkjASajHwG5MZ/jq9a yyEWbkoGzjJNka2ntZTqeXorfepprlSyI52WHDulwnbEzDItSg6BHPzskI7oAETcrROm45vWUVSS 1UZGCDUQn0Np2wwen2khbyclLWgsdaYVFThW0woTjtdQMbNYWCV5BlTltGzjJnkmSm3JMwXWljxT Tm3JM0ZSTZ5xnGryzLBa8swfmq3FcZym8B3HabLurKeZk6Np9RQSttGAY0emGnjL4VE7inMkqN1y Fsgdtzn/4JJZSEdHMoZQrCRjadqSjOE4K6l5FjZ8zg2OqlnB9FgdOQuTSJapZyPLMqV/WvKT7a1R K6dmSBXAbDSKcs8OpvDnZ2sEw7OJWOaVTSq7l4/sWiUBs42hr0jPZ5ZRsokg6ijZVqA20s8dAcTZ MqAlSjYR0o2SXUByetrYclYae+SstCgkRNqmUJDTJIWgoqYhkWdkGbLXRYo79Rx4ECOBXE/b5DMp ZYKKmuJGEpFkNUoUp4IJM8NFwTyTVleKlu0bLYKMBz03iJCUIETGKRTAQlI6nrNSKFAbqcVAvZHK C4QWyVon3YAjigdyirtT/B9+eHp+CfRcjp+OoBRcf376QqF63j59ffrLTz/+mE8xWs+fPh/EmYvB WA3aarCtBlcBySogWQUkq4BkHtBL1vTkkZIueKyrxaut8OUNv7Ylflngl74a9NWgrgYXa6ZPF4O+ GtTVoCwG+1gNxmrQVoNtNbgiIVYkxJyEl+zsWfVs7POq544wx/dVwr5K2FcJ+yphWyVsq6rbak1b mD53+cXgSky6EtOiub3kO8tZnrcm9/PsqfZ4atVifdXRfNXRfNXRfNXRfNXR/NHRfNnRfNXRvK4W r6tS1xUbZcVGWQVUVgGVVUBlEVC+/095tLcud54WZjx+OU8Xj5/+dP70B366XPRx0O+u+2iU1+Dz efp4H2z/O/jHpy+vlYH3fL4+/fmf3/7x+suX12+vf/v2+q+/f/33f37564Vz2ebRcD/BaTs4lzdH neHYDs7NSJnhxAbOvU0+9opPcMYOzsVz7xOcusNzvXjuMcPZ4blePHef4ezwXC+eu81wdniWm5+P IpU6G7wWkfK9Re54duolN88zX8gOz3LzPPOF7PAsN88zX8gOz+3W88wXssNPu+oVM1+0HT3f7/Xx G1988tMNvUN9uyiL+Ag9c0/z70K/5NeFc8N7O+ycjTpmNmpjW5lth3m99p6YOU5lB+dmfmYq1R0u 4sFFf1wfLwN2vwzEzELq29z8vx59Pr/vvDM187DVDaZMH8zYzczMzNa2c7AdM9j1rhMz39sWF9f7 i898b32DC38cV/w+rvjM7b7f27//6PP5De09h1kX8B1O/ertPjO/7/R2vxqVzxztO709rt7uM0f7 2KhNPE4h8dBr3Hr19qGT+szcUbfL9rs++nx+sHxnYubY2FF73GqfGTV21N4fau+/UvvMhn1f7X1H 7f1Su80c23fU3i+128yofUft/VK7zdzXY4PT8diDx70H28yGfX8P7jt78Lj2YJs5duzswePag23m 2KE7OJfebebGsaP3+3RqM9+MDb3H25Hx/K7+dr0/RdrESO8fBzdq9Ps++nx+439Pu8yi0x2cqww6 Zji+g3OVQfsMp2/g3J9GdGK198/A38G5Woj6h/6vPoOWHeirq6jNcGwH5+oqqjOcjT007nOott+e Q+M+h+onNiu5yP45NHbOoXGfQ3XiyNg5h8Z9DtWZAXfOoXGfQ3VmlZ1zaNzn0Dazys45NO5zaJtZ ZeccGu3iuf3aKv8VYAAFjzBrDQplbmRzdHJlYW0NZW5kb2JqDTM2MTQgMCBvYmo8PC9GaXJzdCA3 ODgvTGVuZ3RoIDY4NC9GaWx0ZXIvRmxhdGVEZWNvZGUvTiA5MS9UeXBlL09ialN0bS9FeHRlbmRz IDM2MTEgMCBSPj5zdHJlYW0NCnja7JexThxBDIZfxX2KG9szY4+EkCJoIpQIAV2U4oooKSBBiIa3 zzcHOUTEiaWNtkAz7P7z2f7tW+2GVykS3qQ6S5cwlhDVxpqitbIO0QyJWsQUSVWxNlhNLJPVxV1Z q3iHVpt4zPtdqsGrIbXN+yl1wKtDmnO9FWlBHO51hdNMOtpoLn3AaTM2aTU0QdzWJRVuC8k+z6eM Ms8PGbCD2GMQp6toobBApCUgdqciA9krG/6L3oQLQHtnQ0bRqdoG2E7ZjiPRqdsDcBSMMMgBucII bNJWIAfkRiERkNuATEVE6LuUtU8fyEBjGgFLZ+SI6WiBnJBzepOQc5qTkAcdiIQ8uB9ZxYpBzsaG fCM7jSiQ6YoptgVtMB2Qc4gZjQsMNIMaOGJukKnNnCqDLK0qZOJZxe3gJB5A5s8a/Y4BuZFLDMjd IA/IHW+yQA5VNpBnk7JAnieyQE7GJEudo+FsIA+jcXhtA0cT17yoyazfC71NKvFCnCQnV6YrobtS d6JzM8jKjBl9SK1z2CAzoXRpjkRnQ3apkCtDmQyTV9ya0+LNINN7b3Qv6aJ3TiT98D7zITkPh0wY n64fHW1ONudb3Zzvxq/IxeZy8+X33c32+nx7t/1xt739eXn/cP39+Bjp2e5nM0XnTHV/kl+d7m4+ c9oSTu457RAnFnBowF9OPcQZSzi25/gBDs1awGl7jr3kvHLpGb3E+hp7tB7i9Dc5X+cjCdHukcT6 bQcsh4D5FvAd0rPdY++pBhsHQjZdGrJZWSzVsUTqO2mu0lW6SlfpKl2lq3SVrtJV+r9J7cPje3Es ERfe3edX5NO7u/a3D33kDJvPJ59O+breXN7fiJbHV/urh9vv3Lg4PgY2v1IfYZe321//RNx/8Wh7 X8TyFLC+FrC/CPhHgAEADswQGA0KZW5kc3RyZWFtDWVuZG9iag0zNjE1IDAgb2JqPDwvRmlyc3Qg MjEvTGVuZ3RoIDE3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL1R5cGUvT2JqU3RtPj5zdHJlYW0N CnjanM89DoMwDIbhq/gGxfFPiIQ4QoeuiBvQLhX3LyVvl44M5EuI9djRojKIFhf7RhxflWm63ffn e+kXgzxEz7tjt87zolX7z2pkkEkOPRvnRl0Da7/6ypn6sZ0tlte+bXJx0ULTAl5GsvU0mhmPsEIy pDGkMaThGZ7hGZ7jOZ7jOZ7jOZ7jOZ7jOV7gBV7gBV7gBV7gRf1L3MBN3MRN3MRN3MRN3Dy99SPA AOQQc9kNCmVuZHN0cmVhbQ1lbmRvYmoNMzYxNiAwIG9iajw8L0xlbmd0aCA4My9Sb290IDgzMCAw IFIvSURbPEM5MkQ4REZCODY4NzQ4RTRBNDA1MkY3QjQ2MkNCMUQ5Pjw5QTgxNTZDMTBCRDQwRjRF QTkyQTdCN0M1NUQ5RTJDNj5dL0luZm8gMTE5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvV1sxIDIg MV0vSW5kZXhbMTIwIDIgMTI0IDg3IDIxMiA3MCAyODMgMSAyODUgMjI0IDUxMSAyIDUxNCAxMyA1 MjggNzAgNTk5IDEgNjAxIDIyMiA4MjYgMiAzNjExIDZdL0RlY29kZVBhcm1zPDwvQ29sdW1ucyA0 L1ByZWRpY3RvciAxMj4+L1NpemUgMzYxNy9UeXBlL1hSZWY+PnN0cmVhbQ0KeNpiYuKTZmBiYGAB EQyMMOLPfxTuKDFKjBLDi2C0HA2DUWKUGM3no8QoMUqM5vNRYsCJ/58+LWNi4PYE9sY46kHEBiDB LA8kGPkZAAIMAMbZEE8NCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iajw8L0Nyb3BCb3hbMC4wIDAu MCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNiAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMC4wIDAuMCA2 MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDw+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9iajw8L0Ny b3BCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNiAwIFIvQ29udGVudHMgMjQzNyAw IFIvUm90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAwLjAg NjEyLjAgNzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1RyaW1Cb3hbMC4wIDAu MCA2MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltMCAyNDMwIDAgUi9GbTAgMjQy NSAwIFI+Pi9Gb250PDwvVFQwIDI0MjEgMCBSL1RUMSAyNDE3IDAgUi9UVDIgMjQxMyAwIFIvQzJf MCAyNDA1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQ10vRXh0R1N0YXRlPDwvR1MwIDI0 MDQgMCBSL0dTMSAyNDAzIDAgUj4+Pj4vVHlwZS9QYWdlPj4NZW5kb2JqDTUgMCBvYmo8PC9Dcm9w Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1BhcmVudCAxMTYgMCBSL0NvbnRlbnRzIDI0ODkgMCBS L1JvdGF0ZSAwL0JsZWVkQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0FydEJveFswLjAgMC4wIDYx Mi4wIDc5Mi4wXS9NZWRpYUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9UcmltQm94WzAuMCAwLjAg NjEyLjAgNzkyLjBdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbTAgMjQ2NSAwIFIvRm0wIDI0NjIg MCBSPj4vQ29sb3JTcGFjZTw8L0NTMCAyNDU4IDAgUi9DUzEgMjQ1NyAwIFI+Pi9Gb250PDwvVFQw IDI0MjEgMCBSL1RUMSAyNDEzIDAgUi9UVDIgMjQ1MyAwIFIvVFQzIDI0NDkgMCBSL0MyXzAgMjQw NSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUNdL1Byb3BlcnRpZXM8PC9NQzA8PC9NZXRh ZGF0YSAyNDQ4IDAgUj4+Pj4vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBSL0dTMSAyNDAzIDAgUi9H UzIgMjQ3MSAwIFIvR1MzIDI0ODggMCBSPj4vUGF0dGVybjw8L1AwIDI0MzkgMCBSL1AxIDI0NDQg MCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTMgMCBvYmo8PC9Dcm9wQm94WzAuMCAwLjAgNjEy LjAgNzkyLjBdL1BhcmVudCAxMTYgMCBSL0NvbnRlbnRzIDI2MDUgMCBSL1JvdGF0ZSAwL0JsZWVk Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0FydEJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9NZWRp YUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9UcmltQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1Jl c291cmNlczw8L1hPYmplY3Q8PC9GbTAgMjQyNSAwIFI+Pi9Gb250PDwvVFQwIDI0MjEgMCBSL1RU MSAyNDE3IDAgUi9DMl8wIDI0MDUgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8 L0dTMCAyNDA0IDAgUi9HUzEgMjQwMyAwIFIvR1MyIDI0OTQgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1l bmRvYmoNMTUgMCBvYmo8PC9Dcm9wQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1BhcmVudCAxMTYg MCBSL0NvbnRlbnRzIDI3NDkgMCBSL1JvdGF0ZSAwL0JsZWVkQm94WzAuMCAwLjAgNjEyLjAgNzky LjBdL0FydEJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9NZWRpYUJveFswLjAgMC4wIDYxMi4wIDc5 Mi4wXS9UcmltQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9G bTAgMjYwNyAwIFI+Pi9Gb250PDwvVFQwIDI0MjEgMCBSL1RUMSAyNDE3IDAgUi9DMl8wIDI0MDUg MCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAyNDA0IDAgUi9HUzEgMjQw MyAwIFIvR1MyIDI2MTIgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTcgMCBvYmo8PC9Dcm9w Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1BhcmVudCAxMTYgMCBSL0NvbnRlbnRzIDI4NzcgMCBS L1JvdGF0ZSAwL0JsZWVkQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0FydEJveFswLjAgMC4wIDYx Mi4wIDc5Mi4wXS9NZWRpYUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9UcmltQm94WzAuMCAwLjAg NjEyLjAgNzkyLjBdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9GbTAgMjQyNSAwIFI+Pi9Gb250PDwv VFQwIDI0MjEgMCBSL1RUMSAyNDE3IDAgUi9DMl8wIDI0MDUgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHRdL0V4dEdTdGF0ZTw8L0dTMCAyNDA0IDAgUi9HUzEgMjQwMyAwIFIvR1MyIDI3NTMgMCBSPj4+ Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTkgMCBvYmo8PC9Dcm9wQm94WzAuMCAwLjAgNjEyLjAgNzky LjBdL1BhcmVudCAxMTYgMCBSL0NvbnRlbnRzIDI5OTIgMCBSL1JvdGF0ZSAwL0JsZWVkQm94WzAu MCAwLjAgNjEyLjAgNzkyLjBdL0FydEJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9NZWRpYUJveFsw LjAgMC4wIDYxMi4wIDc5Mi4wXS9UcmltQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1Jlc291cmNl czw8L1hPYmplY3Q8PC9GbTAgMjYwNyAwIFI+Pi9Gb250PDwvVFQwIDI0MjEgMCBSL1RUMSAyNDE3 IDAgUi9DMl8wIDI0MDUgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAy NDA0IDAgUi9HUzEgMjQwMyAwIFIvR1MyIDI4ODEgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoN MjEgMCBvYmo8PC9Dcm9wQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1BhcmVudCAxMTYgMCBSL0Nv bnRlbnRzIDMxMjAgMCBSL1JvdGF0ZSAwL0JsZWVkQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0Fy dEJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9NZWRpYUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9U cmltQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9GbTAgMjQy NSAwIFI+Pi9Gb250PDwvVFQwIDI0MjEgMCBSL1RUMSAyNDE3IDAgUi9DMl8wIDI0MDUgMCBSPj4v UHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAyNDA0IDAgUi9HUzEgMjQwMyAwIFIv R1MyIDI5OTYgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMjMgMCBvYmo8PC9Dcm9wQm94WzAu MCAwLjAgNjEyLjAgNzkyLjBdL1BhcmVudCAxMTYgMCBSL0NvbnRlbnRzIDMyNDMgMCBSL1JvdGF0 ZSAwL0JsZWVkQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0FydEJveFswLjAgMC4wIDYxMi4wIDc5 Mi4wXS9NZWRpYUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9UcmltQm94WzAuMCAwLjAgNjEyLjAg NzkyLjBdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9GbTAgMjYwNyAwIFI+Pi9Gb250PDwvVFQwIDI0 MTcgMCBSL1RUMSAyNDIxIDAgUi9DMl8wIDI0MDUgMCBSL0MyXzEgMzEyMiAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBSL0dTMSAyNDAzIDAgUi9HUzIgMzEz MiAwIFI+Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag0yNiAwIG9iajw8L0xlbmd0aCAxMS9GaWx0ZXIv RmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlqAAgwAACBAIENCmVuZHN0cmVhbQ1lbmRvYmoNMjcgMCBv Ymo8PC9TdGVtViAxMzYvRm9udE5hbWUvWkxOTVVNK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRm9u dEZpbGUyIDM2MDUgMCBSL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9DSURTZXQg MjYgMCBSL0ZsYWdzIDYvRGVzY2VudCAtMzA3L0ZvbnRCQm94Wy01NTggLTMwNyAyMDAwIDEwMjZd L0FzY2VudCAxMDI2L0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjYyL1hI ZWlnaHQgNDU3L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0yOCAw IG9iajw8L1N1cHBsZW1lbnQgMC9PcmRlcmluZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4N ZW5kb2JqDTI5IDAgb2JqPDwvU3VidHlwZS9DSURGb250VHlwZTIvRm9udERlc2NyaXB0b3IgMjcg MCBSL0Jhc2VGb250L1pMTk1VTStUaW1lc05ld1JvbWFuUFMtQm9sZE1UL1dbM1syNTBdOVs4MzNd NDJbNzc4XTQ5WzcyMl01MVs2MTFdNjhbNTAwXTcwWzQ0NF03Mls0NDRdNzVbNTU2IDI3OF04Mls1 MDBdODVbNDQ0IDM4OSAzMzNdOTBbNzIyXTE5MVs1NTZdXS9DSURUb0dJRE1hcC9JZGVudGl0eS9D SURTeXN0ZW1JbmZvIDI4IDAgUi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag0zMiAwIG9iajw8 L0Nyb3BCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNiAwIFIvQ29udGVudHMgMzM3 MSAwIFIvUm90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAw LjAgNjEyLjAgNzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1RyaW1Cb3hbMC4w IDAuMCA2MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ZtMCAyNDI1IDAgUj4+L0Zv bnQ8PC9UVDAgMjQyMSAwIFIvVFQxIDI0MTcgMCBSL0MyXzAgMjQwNSAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBSL0dTMSAyNDAzIDAgUi9HUzIgMzI0NyAw IFI+Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag0zNCAwIG9iajw8L0Nyb3BCb3hbMC4wIDAuMCA2MTIu MCA3OTIuMF0vUGFyZW50IDExNyAwIFIvQ29udGVudHMgMzQ5OSAwIFIvUm90YXRlIDAvQmxlZWRC b3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL01lZGlh Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1RyaW1Cb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUmVz b3VyY2VzPDwvWE9iamVjdDw8L0ZtMCAyNjA3IDAgUj4+L0ZvbnQ8PC9UVDAgMjQyMSAwIFIvVFQx IDI0MTcgMCBSL0MyXzAgMjQwNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwv R1MwIDI0MDQgMCBSL0dTMSAyNDAzIDAgUi9HUzIgMzM3NSAwIFI+Pj4+L1R5cGUvUGFnZT4+DWVu ZG9iag0zNiAwIG9iajw8L0Nyb3BCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNyAw IFIvQ29udGVudHMgMzU4NSAwIFIvUm90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2MTIuMCA3OTIu MF0vQXJ0Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzky LjBdL1RyaW1Cb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0Zt MCAyNDI1IDAgUj4+L0ZvbnQ8PC9UVDAgMjQyMSAwIFIvVFQxIDI0MTcgMCBSL0MyXzAgMjQwNSAw IFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBSL0dTMSAyNDAz IDAgUi9HUzIgMzUwMyAwIFI+Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag0zOCAwIG9iajw8L0Nyb3BC b3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNyAwIFIvQ29udGVudHMgMzU5OSAwIFIv Um90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAwLjAgNjEy LjAgNzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1RyaW1Cb3hbMC4wIDAuMCA2 MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ZtMCAyNjA3IDAgUj4+L0ZvbnQ8PC9U VDAgMjQyMSAwIFIvVFQxIDM1OTUgMCBSL0MyXzAgMzU4NyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBSL0dTMSAyNDAzIDAgUj4+Pj4vVHlwZS9QYWdlPj4N ZW5kb2JqDTQwIDAgb2JqPDwvQ3JvcEJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9QYXJlbnQgMTE3 IDAgUi9Db250ZW50cyAzNjAzIDAgUi9Sb3RhdGUgMC9CbGVlZEJveFswLjAgMC4wIDYxMi4wIDc5 Mi4wXS9BcnRCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vTWVkaWFCb3hbMC4wIDAuMCA2MTIuMCA3 OTIuMF0vVHJpbUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9SZXNvdXJjZXM8PC9YT2JqZWN0PDwv Rm0wIDI0MjUgMCBSPj4vRm9udDw8L1RUMCAyNDIxIDAgUi9UVDEgMzU5NSAwIFIvQzJfMCAzNTg3 IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgMjQwNCAwIFIvR1MxIDI0 MDMgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNNDIgMCBvYmo8PC9Dcm9wQm94WzAuMCAwLjAg NjEyLjAgNzkyLjBdL1BhcmVudCAxMTcgMCBSL1N0cnVjdFBhcmVudHMgMS9Db250ZW50cyA0MyAw IFIvUm90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAwLjAg NjEyLjAgNzkyLjBdL01lZGlhQm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL1RyaW1Cb3hbMC4wIDAu MCA2MTIuMCA3OTIuMF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA4MzYgMCBSL0NTMSA4 MzMgMCBSL0NTMiA4MzcgMCBSPj4vRm9udDw8L1QxXzAgODQ1IDAgUi9UMV8xIDkxIDAgUi9UMV8y IDkyIDAgUi9UMV8zIDkzIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9Qcm9wZXJ0aWVzPDwvTUMw PDwvTWV0YWRhdGEgNTMgMCBSPj4+Pi9FeHRHU3RhdGU8PC9HUzAgODM4IDAgUi9HUzEgNjAgMCBS Pj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNNDMgMCBvYmo8PC9MZW5ndGggMTI0NjIvRmlsdGVyL0Zs YXRlRGVjb2RlPj5zdHJlYW0NCkiJpFdbb9vKEX7Xr9hHCYjovS/ZBkFzHCdI0RycwkbzUBcFTdMS G4nyESm77q/vXJYipTiM1EKAyOHOzs71m9mL68e8Fm/fXny5/PxBKC3evfvlw6WY/HIzubi8lqJo hBKiKerJxScgF83k4kb9U8LHm4eJskLCDx7K6cRbEZRKpPLiZj35+/T93WbXinZZis9101btri3F w2YrrlZl0W6rQlw93EoTiqqsi5mS05fZP27+PLm6mVx9AQUuDhUzA8Uknyq+oU6q00lFnVTieB1f ol4+04nr9LpZzlQ6Ra3wudcMCdKOVo81xI8F/r2I2+nnq6vbmWjK7RPxNqIcbtq11apqK/ic07Z7 MWaYHXr8Z2aEtDeDdSq3+L94EY+bVcUKrvNv/QooQaoTsWkaiAdbX2x2JKDdvogcuMSWbdns6KXo PVLV8W2dt9WmfjNqjjvHHG97c6p7Oj9v8PFm77qqppcN/pG3SYeo7Cpvy3vREsNBDKr2RbC8dRSU CAiaeCYJjWB3lLR9zBp/jjVODqyphZYy7XRjBxY7jgjoz0Epos7baBiputiH6CCrHskFz8wvmPWe BUIIb7XWMdxNsymqMaPCKUbZ4BMb5IFZ0/ns5l8/kpqe4yrje1dREKo6llK7pienJlmEf4Pobbbf 2NDnql2+7iouwJfvnDQLBjKLQ7/YrfIxJ2UnOSmFf5u6oUFjTtLyHCfpAWZxHm33Dnnzw3o/LJ9N dNBWNG1kow8b8td9XItZSkl5z1VWRxCIOcscHJvtvInFOlY7Wp1jqxwAW7NZ7bDIOcwdCh3BHdQ1 qbvgKh8kTQx7sSLN77uiOtpfvoLsnB+HuDFqoj7DRJcNwC5i7WM0spwZjydXkKXV3Q4L4qDcWbFO o1dDcoAwCIplsaz7SG8W0I/2ldSjxZh15hzr0gH4UUw2+UpUzf+eWv9vFoxZdk7PdX6AVe2S++hu sYSOWWzWd1XNDYnC9dA10TLnJrqMHx432x7MhrUr7rZV+TBYKveN7hgDR/uuPqnvWmi4SmZhaNRU jODVOf3POT3sf/PHCEjgHA5M2TW4V3DqKYZ9A0WQx4zdxYwdM/ukXmZsmqSpDEMVR83+QS8jLmB6 X7S7fHVT/rt9+/Hq40cp38t3794J2vG6a0x6dC4e+oPDT+o8yvlEWpO9IvpVqeaczuO0/X5avgJ0 glB+RKiKo+M9p36F06OT6nZa3M5upwZG42KZb6s2v+OuLLhxLfK6+g9v4WDfV0XejkTXnNRCbApB TY0Zqj3WhM1ZqK0GuNbPmlC1nMrHI9tdBChsLm2c9hgZjsfT4WSYr2FgKWNJ3DEssuSyacqjUhlz 2DmQbTM/rNeDUQkvL3Ha4kHhOdYnRj8RH3fbbq7oHMBpslnDcP1+xTgfU6ZvNs1jBVnROaQb+eox g05CapvaxPjghiaNZsA5lxRKrz3+0/2nC/YrtXA4onY3E+548WY1aFhQN4v9TWQroqS+w8HMVh8M MdF1Yx47B7KtT4e9jXV65BbHuVCwxazTquKIdZN0l5Fx6Hgt04+uLQfXoQZtLgtu8Zs1MI/ZdRLS d3a5AYBFe6Kjm+aPh2FpOCoYiyZ/KPspi60AFcr6qWIZ9XDC6O2P8qp1PKpv4ftUGbPsnJuTtQM8 +h26EEJJ9PuqAvW7QSlfrcRjuXlcDcr251A+NCBWfCO+1fuPz6sxQ067MwWXqCzLhqaMFas9p3NZ 7Ydw3VcaD9hcRk21WB5FMMb6uPyW1ePBAFssq8F8JqqI8N28G4t+MCMej4OjM5w958Zk1QCWoIYe WOUINV3P4KTPv5skv78ebnbttncCDK55LP+nqq1GB7G/5PVC4MHRioP2+ulaikVD1ujOmmhLZ4nJ dCJ/PsHY4972Q3kh6z3zt9lcT6umwkcLQAUPmFZmDrwxT6d/GA3Hce8xxwdqqZNMpv7wyOfn55k2 06SczS0gd4MPiM9MSaihuZtCwcF3/Aoupo6S4JeyvahoSzmmkzt0ruqcO5YqWmaJ6rT7zCXQVi1c M/docTWE7KsHnF6KKuYS/r2M6XRSx9FZlnjp/VCb0XCfg/cqc72FQSrxG9Z7Wdf7lH+JM0ld5eI9 Lg6uWLuIDr8mX2eZHr1v2JOw2kiVKAflPNBr1NYTR362NVW9rV9nzk1zwCmeDxiroF9/SC4T8LSU dq595kcscifBq85MomWqhqePWeTOgTLlw14mlNTcyXTuoDuMiD9phNcqTbRx6cEBY0qfMz0rZ/ow MLSuq3b5p5J6K9fVsLUmPM4fXXcuoYIvr+EYcX3560SLZ2HFF7GHzd9FxJru1GB8kmHzLNYTXFhP DH7x8LqaXE/+ihK1KBqU2BT1RMsEdFQ2AYXhJpOmIjgvtuUELrMfq8VuW/bW7+Hu4rdVXpT3n7b5 4xLgAJYl321/nyirktSyQO0VTN0iqESnKPKrqEkn/H0bqp7ZRAKgQNQSnam0112KeZZoqJN5SKz0 Yq58EuDSh08HeN/RxWSuXeLTnsGYBHG32x5JiZzxHVdE3HYktpfKx0Za8h5JYh6+9+XAohAgCnCL MCDem6FF0MmMgOETgHo1gQ4NlxKXBIA9uKFA2ELiIcteJgbUggko0S6QzJfJHIYhB9mVJWnwIAlp g8iWZPAZKY3YCTlHlNeaKHBrgbxBBaIdOimRcBTs9MirEqtIjvUZ8qokQLyANhpWofWmRGmDhMs0 sTryORpHnDLDRQ8aACWzVDxNiBngAHLK4yLVWZr4LBAlNVJOBRakAc6BhmTFVQVMKoBbSCzkEVIW nES8BoIAtPKGVwMGyCrmRVD1kHBplKsofGQ2mEJ1mcRDwDVAAKB0rEhKS0YbeEASe8NWe64RFaWG lGgtSVDmKeEVmD2Hms+YsJRrsIcEKYgmUC5o2girQHlMPaQy5g0syEiHq2lqBmJDRmvSu8grYdUk mSFBMFMBkXqiLK8wn0Z9kI8ckGWKKPJViscBEWMZ0B9AKk2xNCQyeKbAcqCsjr7yfLpMyT0+wE6Q lzGFJ4K4EJ3lMHyYKiTJwmdcleRmK3mniXIx/kBnjhyLoYFTPOdsljHlbczS1DCdCcpZhxQAPxDe kpkAJszqQB6qiwjCBBwNGYdUIG1ZAdiJR2ICKjrSIKSHYDn1HS5JzheQpkl3GSiWVmfEm1LuQyxo qwPmOcQQA61IOcs5gEsUIZtkAAFAW4wzpKOiVawPpNB3gJ+BzoTM5VVtadUDEADlaaPNPKuXdazk aGNYbErKG3QWjByGQuJM2qkQOCgBFczYQSnEGCkoAQwJAyLQkhJKYlAs9hqkVEamBXKz7cQ6zRGC hoBOcJyXjijpqBKk9cwruW4kiEAKFYItQD3hqjJccLyqHZcj4AtSniR5p1mS5qpKLfEqxDLwBmIk UJi3DgwnYzwkMJ3qAoQbUMPFCCs8FWkOImrsoDDI25ICDM5HHwLOBvJoUETBVQWhGmnsMB7rAw4P RiBmOt4JmfpftsstN7IjB6L/tQptQJ58P769gsEsQYDhj+oBBgYMaPcTJ5hXdeVuNNC6rHwxmcFg cAfT6bt6Xo6RpqxgzwMF3UDWbiuCsMCmanQOGHEVjQp+Hi3JMMo1yGMYjnXamjHW6oGupafsFSnQ ApzOMseWdCpRN/b01J1jarVLdZloUvOl18qxbWYn2UIro8lz9TouBotqoKXTNLD4LpHms/leubRD LosAke5knWC8lVbB7vptmwo9kW4Bc8UtmLiy2QCWUVgDiNk0wwN4ooqmGozpeUtHqSaVi6r0iipC UbCGquIyuuw/BXQpvHZkioancjz813wVq37K00qY5CaGsK/SVSJeLvDQu8NVM5vktYLt/W2UhhA4 ZKscy6ELIuE8sS8TQPJRyACnfCo+jFfFWGcTpzQHj8M4S3iUyZMqWwXyYeS9myG7fT7Vfb9RLU3r Vadw4oyii2Bpp8ZRxwSqKkWjrIFcBGU9xzNSrBJGyERjE6NqaiTYIN4myWFuW3JnYnRPVGcSeboq b7GJt5SV4ZKYuLyjc9a+rGAZREtjFJLHUgT/ZnQG8LcmvZOD5n4Vfhm57Ch4lY02itS0IpZ/R3OZ RlAk2kjHz26d6GoJrCm6MySooEypmK6oH56d4e1p2Hh2tqLZX7t1Giff5R133RlqObOzK16JGsxu QrBgIuGqroU7Cgoy+rmgUCKrDV8fQYHC7euMTszV48J67DItaoj+W9HDhMSqpvWiKWIgpSknKCBa LF7I0vXWhB8SqaX7cAHBFa80F0AYWgdrGyOEitAxXe31wpmJ1SwrwhFOMQdDQgLLBrcJ7ilonomi RckUBFoETZO3XUG4q2LLdY3OagIWgW3ftTrNx/JgqrGyCFYFTTbYl6uqvjVHEHod2GVaRm8Br4gn 5jk0hU3lhErktazgnDmtv9fsR5/ouILwDkJqNq59io5jcrMLWULDu1bCPeOIBqsms6NNwVPozhjW N3prGyjMjwc3pqOVT4Kay1LJVkAEuQ+PFSVltobHa+8IR2J4C+qVjKRpRCCuo8kC7MYo5jhkxHT7 AHGLkU6noQywkmOiRVI2C2IqJkQ2AkLskiISzUzvUWh62Lzb91bn70ckDpJEO/yQWY+eU1ZprIUE 0Vt8PlA1O3Rss/JHKtEeiAg0OiylMvxPOq/te8zkpd2di1sd9rVuVVIKw586E1UgsygBlDTNrU0T 2D8fUZ7oiiwu4BiuKT7xpj0e0BVZfKJJgvi0O2IxYArjd5Gws46WAUaOjKlQ9rDoxBzdXG1j5nX2 OIkxQtuT882volHRMtgfrpUwn3hRSQ9WuJSfSwwM7SO2GFL6TsGGz8pzi+eDKaZC1/zoJbiLHSjG kMMwKU/VHu233cPCe1JLGl3K8eUusSqlHG15qADV7B40xLUMDrJy5Tsba0nnsYoRaklF4/Ak6I2C uUSzw9evdAke2qKaWg/w0Oa1+hqfpsFle1F5BYkhrClCsPU7faXwqT8hJ+k7l1UNO75bvxIFVxD6 V2grqhQXhN8UAhU+xVauUPOHpeWieqLRPkNZZvmVYmp150QN62GmXJ1XWBQ6qoJ/fD547Ww2FA6f zozCTtVyj2LF0w+jskpoNl+HO2a+ByPD1IlVQFOGsCsqUkbB4FZaUpnUr6dEDjXzK5J+kyFtGmPN coSwWncPpBddgoYoXoOqvhEjqzAtdVQKfKbvQR2ZfidZi12NlTyq4VWSkdPQL1QRalQPYIOt/Rs8 0a1UQLdX6UlZTjdRXaTdA8iztYMhSnavSGZTdE0tXO8bz3w8/nj8+/G/Nz2U/lGv3Zast46AQjH+ eDDygzfKeZxXwNCz6oH8PTKU3tvpWZmRLsU6RLPwe7MS9UCpoby8aibr6Lx44dptVHBT2xHczdtV jqquLYyFnJxMbKH4qgMjN9wv5eyckGj/jL7BNd4CFeX9Hhr9031CsT1zOBJ1eDanUXGjRcFs3RdI /qNAvAfZYaxIInePVL0UUrIfa1k+H8lej5pM0ZUIN3g0Xd1nvW4oY6+YuJanlBqD/j/PHK4PxFMx TSHDh7cp6bi+upuLGkf3sE520grFouY/eZ+IrhgN2bwkOLm86A8fhpNy1RWBipI2T5vUV8TNDhkW zc6NtGNidq+AEgo2J4KTFzPnHFjQIRW7q53QDD5ymMkBnc1usJR4qTYCOfa0Hj3RAqQlhqoB25b3 KMPPnWL/7D2SrgTMIx3+9ft/tMtfSoe3vz7+e8uOkiiKouy+4O96yw46wggoiuPpHxAQwh4l7Pn4 85+Z1iEiFcYmSmjttheZOZ1PRet+zs/c9RxTyAIG9/wclExD9GnkRqPaV5i9IW2rwPG0vu4rwtdB NFxkMQ3aLkt/V3Kufv2yrelsG97basp24XkjoqxQHaA5ZMbIPlK/0ODqlzp58W6Jip145S/7der5 RfxX3QTAy07CdnutW3CW7te0tyrpHELYPTi9UH1WjsexPlNM5gy4Up2b21L3AXzjQLXLMVSCBNSv ATXENPJKkik6WH6ghkLtZLwyAm2mGuDpMLnboVWi7+xav2J6cUFsbmaRVsU/oOshdJqvp/dvnVKW 6OT0O3SVorEJr49l1uiRqh4lx/3UdUUT0SJVcrN6JX8o5GX+CqUDPaJHmBT+fsdbdo0j5XWjp1Br MuoWbr+CuyJQ0HwCRBcyvgF3RvFfQLWZwSG+/Kt9lC6j6ESloJTk9wTIUXLKwKFuZXeapF85pAfr CmJ1xG+VzuCxP2V5H10c6JTxywDJfaHTPWa67aLl27wzBvlY/QgSlgbgT7uQzoUEpVKoPt22OTSX J7fIrpfdJfznbYoVjPxsm2bo252ysJtgzWKezqm/jFKXWfOYMwDSlrMtTUNrdQcz73Zof0dpaDVY ZNuH5H1q9sqp9+To1FwQ0bUc1kYUnKgRbV1WbDvuo7u4ZqEZL0vbxsxjBdB39ov1q165SiOFPdWa VzlivTHdjO45XkaZM7pQ/5g6//dkfZNRGDnUQ84vH8PkSO8wzaK/RYzGJQj6qXh29Ny7V0dhRq3G 8p63UXB8rSNAPmaDUD24EoxeR8NNXvzArlE/azbv09/1iKyFUI8Hyt3sVke5rA/ronIfpeXAF133 ZdWQddh+E5oY9p2hgcDKsXi2GnOPXbdHW31dXWe2282VF71/DUJcUUSn9YcZK1t/hBTcUQDyiB5i FDtBS4k4MtMGv9XwLKw4Z99Hd41z0t1KtRwlWfd1jgVi5PHNoNMJoi0HMZw/+oULVPR+YUYhWOM1 Zs2lqEOXaUYChZzqV5a0qOKi/8kJjn07AN3xWrPQluW544ShIIACnzDo0drrq8wzyVb3+45l4xIp /RieN72Zx7oFtnbGMTUhm1V15HBX3gnadQf0qFBhgktW5fX6TtciC/pNPLXEzeuAZLqlOIrO89RA XjiH6lBUdG4v6KszXf01Bbs7q6rbRtRMsAu6XCojVHbhqC+Laqqzji1y4cmlNEIzDrxX5aPp0wwX V/q5fkwdogJfL1NGM3mYLKfVfjLvfDCxuP3B9DqEbjzYkYv6utsUJ/qeco1765ftbgxekPfrclDf rfWXt3GxL2+3yD3uGdYaLZoCxF2KkiWTP5y4doRzmnv+UWzqUIUVFJtyy1n2VYn1IguJ9rw+3S/2 o7xCf7uhycbWe9z9soDrDgK1DWrP2rbzzRZezikT3Xf/fB04FKIvB2TNIGwfPxxN9347EGdbSRgq +dgjEny4wwWWUnLXObJ6vO4xeXMnrkP7s12O61ZLI4pDF2C8ONEsHiu8cL7YRvCftav2m02StXCv hp3S/9muktwKdhu49yl8ge9oHtY5QZAjGAn+4jlAkvsDqWKRUjs2DPh1sVsSxbH4C5ZZL4YNthc2 s1dhKQtDfZorNSisEoqS9Ykth+a5iR8gp60DOgRvFhMNAb0LCrVFNzJdr42FPi2gZzsCcv6xbJ0/ nS0dx4nQv42rz1Pdz4f6sOAX1+40HDKvh5U0TmGBqpEgS3PDyDAbTpAba1ohHnGKgMYEkvx42Y1P nJUOz8Yh8HOxeCoWzckPffnt5JzpO38ZPge9BAcJSuLoCTSyQp2tDnCnHdCHuNnve1Q5ckLXGlPZ ulfCsFNrjpcFsSa61xigAUFw1LVCgGSf2yalka3jm7U5AjYzbXOnLM4URgXszlC0WF53Tk4BO1p1 cSO4wCIVq2ur1+NbPea4PE7399DN2c3mYYC1W8frrvkQeOkaS64YxQWp/4bZnXnQbkoF1tSSbHJz KEVauu8zq/Q8jkZh9qwNT3d2IH87kPNqt3VdiCIiPhECDbTmrWX2H6VfiJuP401V4c4iRE1E8cuQ BWseAeUfo4Dxni3OdqvyVm1WpXftrnlaPQTWqTncphrV78uG1znqoxxegephQQq5LdmsAclAADNz IyByfsptLqA/tq+fGhkK84fbOZdlMYnToraFQB1Kyj6fb/eAIBX1KzLlAg8ot7l7IGnBbV0gPV9X gMpuc03XKBO3PGayHgLDVRAS7T/Bkb6eAus9FzItKxJwOSAZ5RQR+I+CrFOrG6Y50oQvoasVg7JA Oc2ClpuAeYhLPRBqVpv+tQlwD1aQ6nNaQLQWdcYk90CwH1+70t7eAiK25/Bro0us8YgXbJDWt3iZ 4nISEKZsCWFZ4AjqVqnrAjmG2o9NpsB9aflkSupQ83socPxeq3giTUq7VxSREX4PdPweguP3EDhz 4G7elshz7nWP31GdMHsY8bY2W7u1Cxe8TDC2NdrJgaF6dfPAqlNzniA1grvzvu8v7A+IPft6fi6H 87gprgWBuDUOHFmdnaMdYOs2OjW70TCSyCFRBhmqCYZfF0eNOAuegtZuCQPUWLgY4aGN4ENfCV5X kERsL6xkkHWhF5cnjCSStlMdRQIpk8djedfwmGw+IZzWMo0ff5pvmqYHCuSsnopCq6Fu5vnt+YZZ Q4u4bLixM8/DzAKeMAvBCbMQQF0qxt3aibI4LBjqxZ5TVDutK/hJ8PHBTvO92iQ4vhH8jJWcpbQT MvoHyookugh7YbQwf81sILEVf/TNCWhl9W2D5Bi5aqHjWS0ShhJ0WTzzCDKspHpjEHaqmp3AocpP rM9t56Llthfmm8cpNTQwjeo7Zw4mACytipLTNliM3H2D2SruRXuSMbLzFvsuMexkGPBrAbdZMub0 A7oNOZj12CQ29uMOU0cyJ9K5IaIuyJ0YMHvKeJqBRu6BNJj2g4GG5qUWz9rSPiRkxyjvvgo6lRlb CtjEwvP8nRTxVU8lP20qag+dBZFG25SujXvWnu8BBKbJMqvaO/DBdVYJnAMEmXDddF7Oi9I+dhAy rXlgvJUusfKpqA8rmWfOZm3aMaO8aibJ5ukqlOU99dKD3deg/BvV5yd25wN3nBq7ZWPRcZKQ9NC4 0xTqXRPsFTALYy/C/R4n3TwKwc0c6fpTcHLJ7xo7yg7nuAN78lYP5qrayQ2/bEAc/duRLrgngDT1 dk7AWKDXOuFAnRCC8tjOPXNwTc0xEYcMFIjp0ysGKZps+Vy3ZnX8Mrz7eHgKNKPPb1i7xffjY1tk XowBIA4bHzPto8iwaVBI11jjobXBh1sDhxF238dCsnA49c83jUA2ryJjvzQhmZrDNi8qL3pt/B0D gDn1emmFl8MpC6kkL2UbyRQUi3TWRhuVnh2DUC3b01UH9pQfGPG7db1dXbC0w9zL6HtSLVsjGzRu dMI2BCeGeOHUfhHcFpA1xUhA2NTwlw+JDseOAdcFpE9crAZiucCxcZh6SXwABtjrCF4SKNGUTRu1 v8RuF/lhV7B8Utyw1lE1WWF43N4FcVk6fBhtg1nRKL4Ophk5HJHdWKzNbUPI6g58hFnlvES2jGyh Mg86VdCxDUc+Di3pzUFRGzv6fItjz2vpRB8bRz+wVy8VhfS0PKKwkO4fP3PIG1WMgXTO4dVOGEYo 77FUqRo7C2leUFH1RD44OAwSfdYowVB1zxYl2NEpwY5vrl6BJavv5cnqJz286YKHNyvzU7wLs1Pe T6rFOWP/gl1xfL/bYV9AKx36VUmp8uVfji8BuwLjRoDT7zHGexz1IGEuOEnHKTD/xCcHsWHZD05X jD4/jnPobMwFQcg40e55+rUEVi7+XxC07OJt8QKUqrMqopr37dIHh2WZrOsXHJYmpz+7yWV+UACx tT9t3uijXPbg2AOKw844wQaUrV+5XgeHHphlyvoFh15gQNLTdlv47hxk4ASuoHrBK6B5Y5sacx9u hPlo1cOGNQGtcpmVDURW0Vh0hWifdqal65SAMhVHm3Gs2D72fFzdYdwU9WTvX3DcXDqVo5K18jjG gDziEArOmN6UoGzbNrqqyqwsOFoOKIeUne97+dJmxXEgrFqXnM8xbLYH5xUW4Qbo7XLxVsxol6pD sEq775Fy+6wVuNxa2Im3r3RO7hsfwu7nxlupFCufCmsKbflJ2oWdfzcygkPbzznO26FT64e4N/Kp dlYKPfXf4n1i4Fp66Lmb5oSgH3zeS6uz+qk0v8YsM+mXDld/GU5jO0YMNA4H2TFRS4yQxoIDVAnS ku2GdXXh18EgBT22qvU73EyHnZbt1TPRyoiWowXRU0vi18HZeNAT763VowZpJKK2h1HipF2Db0qP 0ub5Gkpnm1k55TYQSmOqDAquRSq17PglPPJNvbYs+H9iT0XgdmpQ40yWowg5OlXI8W2fV2DtU1t5 9+Q535hgCE7PgRVyL78ITheCoN9+7BY9px0YA8w/3/72VhB8vH5FbqvMjXc0t4Ft/vMPfPGXv/4d Qfbf9/z+/t/Pf739Gw8Jf1jRcesBX6K4oiAgfL7eknX28tFQIBIUQtQzut71i2hGL8DzYt/qi0UE rKtPRy+iQvtlGKl9lGWFDMVBzywNWmMIZpj8jEUWgAGh3f4o4Ef4TicJvQKRok0oUfcBLKQjwCcu 4Y8vPmJsshaNRwRSs9xgiUMWWdvbZKECPDGxVwjyOoukGEky38HS0LrwjJiEgKpgXuvsImxATGsj /i9AssY/uvkWgU0eMizA8J85y0mtyg6YRBySUBQDcImIpwOEEmlqwD9EuwLR7/XuGXhE8cAN+wwM tJKpU+Y8qMEtVj2EK4ZUDXoGO7TUqeifAEbe7BD0x97vmcjDKsaKKBiAToDS9OdknFvPn2/yuBDY 8S7+jBa8mm/2+SYEvyzeBja1er53lnsQpw0cY+J/snNKs06CjNAzw0FPL0+YZwaQdeEKlTMF3HQy IFlPYAaQDzIXUDIRBOcXZGLbHYgy05XqOVQ1QVJzWmGhwXPpi8+10kkHjrLtjL1t2Rrb5iSkWv0o xo7hYjw3axRYPhphr7xkZ42E5QrLbB8jAD8ccO95N7NWmekc1DHtQ0Ld5hUI1s4l2++wOmCZ6PbQ kzKZqJbIax3K58ZoTrkEoJ1qO+9wnBcDkpFTFX54Z2yUeMyyZDkTCj28o5XJ21Vp51FpLASnJmvZ dLFZksG4tp5Jqz9KHv5GMZU/jJhCXuze5McYBa3SdNHjj5q6CowlnyEW9PYen6L4Dg0xqAAkeOj2 doKam2oK9iOBEPr0Kzlke2YLxeZWoYzzoshv81hmVqGqzWkRV9mBOqLfogy9nmVuGBkpeQViO7Jq FW+RNeR2dPUBPGrpU2Lcw6pvTXTu7BqfzGLTGJS7/X/sV0lyHMkRvOMV+ACp3JeznqAn4KIDpMuc 9Hv5ElnVTYCymRFN0hhlNGOno6pyiYxw9yDA4dZQ+yaPa6+ja70gU/4Cdez45lw/Fi8R5k8qddG0 gmSrauYhF6SdOi35jyzVpLAbCcOgnTFO1b/2+xGM8uwnOQJZDPCmYQNlbgasIm4D3NQ4/0CIDUSY 836GIyZyfNv7AC0p/jZKbjHboO7NFG6hBdCEY51HtLycj58y07AZA93QRsHHM/ImGbAxvwxAmGX5 0IRQ5KKM0oki90wagbx26ddTXzV3XnQvVUTB/z8p1YUcHxDzWpm67aFUTx7SlyjFes9hJALw6lkw AaNMkNiLVdu6yzZ305U7vbKL+EoJZIXL8ns8VONq0jeDtytJjPFBs/rtvC8kiVUUCFswelz4NxAy tLYVclbCXTQfT0VpXY5bfp0ic2qQR+9SoxVk2/MzOKuka/Qx0DTOEOtPFKttezYHi0rFCF6/l2IR OSveAw2VIygt0a+0xVajFf59KIkOskmlQJXXqTBZhCYu4PC/x7oqWKTzZCGRp6rrjGf2W0spnvpQ FPDJAUh4uHyUFqwdqCufqS3mZ5lOAQ+EyKO8YJJbizG2PLcMmhGPZhM4aHlpNcqK8Zvc3nlyxs1G NseQSriuqYoaD2/YY5RlkB7RratCKMpS/TubdRWVvqyrHt26Osc4EmlpuoRV5u8W1tYedHW0X6Gr Gx5WSQ39G4/Fyi8Qr3RYydNeYJd215IzJ7hMvJ/8E7LgPyllsuyLx2eWg5hYSYyZ9E8FuMnMNFXc U7CSoCouixsJqcL1E5B39kb1BxarGr/AbDj6xW+4XPPSsK9duwcXGg9/uarkpDYeRKTrW7mIZtfu oydJva+fLuSLczyxSYsx32OtXY8mFR5z9HYAdDk5loJxqPcHzBDn1q+xKZRjaal6KsfsIDDkyrdn CBxbIWpcPtV5IQVxlPsPQb2Cpmzflaf6mGs1DTZqP1i325Nut2fdbt/V7fGT6nb9rm7XDDbcuNC6 yHrzvh4Ir9odGX5oLkmLv9Y4jBdzri/zZpX+EpHIKk1rNnEuLp5Xj/HhpEDsDflaFCSNrifjGav7 jrUCvR9E781IVRPh1OJ79gMotzGkln4xZWto8kfyMIeGiJLJkw/giomdiqFaTBoQZDGby0FDPNjQ 4Q9LXJJ1BwMEIR9dCmMwsN8h5ulUVPSZ/IxNIf6fytuk8/mDgHDaqBQCXCBus/YD3i4KMv4SXUAg tHa0U2fSg7ELWY4wSIGBVtJ+ik2QEJKQ1/8SGPqTsz8lhOYWr4qcBzA1chEWWb/XhJ1BIySfVPEF k3idazZANozzQERVdyAUPTLRYwjzajEbRZ4IN7N4HEQVyWz61QVV1tAs/D+lGQZBXV0PFksx+mio allICRBL3WAgZsCDc0WNyyXxNK1/xKCb+ozd/q1VbyBzKWA2bSPg+wUX96pgk2KXqdDNKVFRa5l4 TUYKtwxCPAU/8JP4Mi5oRZcb8KyJd506hqgpRDN2i0opysA65gNKa3vNZUqJKPgiPsFjFa80RFrN B4iP2RUGSuGpAubYQ2P+NSkiw4ppZnZq1qJkKVpFFbl9LzkfY0fJNGe70idTas1yhllnEaDlKqHS yH9Z4CT94Fi31VagM55h9NMBb7z9Utt55j0HORlAe1r2i4TpszSsnaU8/wBpmP+fhf+BLKz/nSxE XzbmdzqDdRqD/tgY9OfGoD82BuUHNAbrJ28M1mNjsJ4bg/tQ7y+PJ/53GoP5WxqD9fsbgzYRpvG9 xqD/6sYgP3UG/akz6M+dQX/sDPqP7gzKY2fQnzuD/L/aGrTvtwYd52jcw7/kgvbIBe2ZC9ojF+Qf wAX7J+eC/cgF+5kL9jdcsH8AF6zfwgXz93NBX8gDVGQdENnywAWuqxRBQhjbNXS3ZoTcSe1Uvow/ Lw4SW8J82MT4ia8Ex1MFllyVUH+l/JehDEG39jfCmqKlVItVg5SqbESxqxraBS+iy6o0r5CYCNE6 Ru0ZvcWRAiIi5CokW1IjaoIfmbrPFs/2Z86bm0E4iclQkIHsZofDnfdBIhIG8zwF8zABsMVyAS+l V4lteeALUDQF580n8Q2iWA1wuDVcuG4Hw0xpw4alr/tZHTu+MW8o70qE+RMLMhDbVZULeyAjH4ww LV2QMvNgjau1dARUkYY9apl1h72W9RpHSINlUAfP1nQhJJ4cyDYZY8x2xkW2z8jTv+OoveyYGJde W3xvk3hmHsxXA+sJFoZDvLQll623BJEQm91tQMgMUgKqlfINZp4HvL2sr6kf9H6hLdM7URD1QMzY 9R2t6IBg1QPeXjoOvw5EMox68qbhxXWmeHu5oJe7hOnA3a6nUNf8LfDpuJ4grTI+M6LOlAgdwtzp u0deMX57oe7NQM4kfDHPBSGPZrku6ApjQG8iWiEDXMgdROR0rfc5LugwRt4auiu6DP3sdxTt/L9c fYAK/kNxKo439opUjTWfcL1gehicCH4omLmhjIj+z2ek2h/DSC3KMrN64waoF7e6TX2dnOwMPZVV QtXKAUzSsfuBoEc2b5AFkqDKY5lpG2UcbNTNrpnkNZfiyDbqAnuarQWx7maMWz8eCIXYHxgCcO0D WbJpup4nw9+z5piz3ICSRlrrrnRsCx/THsS4rXZpgVES7yWrJaMBH9DmOfF0xZxoTKVBwHVFCl+t ryNi4tGJCYizjuNCQY3TYeDM9kaQ8ayQ7FnlU1qbKn/FPRdxJuSRaQJUmTNz5wNIPkWGSJAVbSdF ArgRT0quODg1Cdds8mBdDnlqA0Zvh38CW4qEdJ3dry4puVXoy/q6MxN8MS8nJLK//uPlhm0eSw6J XDKHZHz/2G8rbDPJmG7FudF1XTfm9P7Tn/+CDf6C9H795e3vD9leBtzHxH31Ip//qN69KvD0hgBN VyIC7zWcOIkV9WUarJSG2Uj3KYtz9Zcq0zx1avxeT7K03V9kVYEnkzQIcR0qQxKDd808e42dxdiz drHKkkUJCJMmsuDXAM09S5eparlc6wCOXLzQqgdek/Qt95r7AVwvtXGg2EQoUnieKSJEsZztzS5n L+nsMJ2df6Qi9HFQWehip2Ou31xPbVeRMMoqq6Hw1hGrGzIZtTw51WGV62v3tSYrc7PjTatdAS/z XDm/X693rs9lldp2WIKgzjkuiJ10Oqo+z65o6de1w4O8Qdq4GmuhlNfJOpQ5jNfZHa37eQId2Su+ gECWa3MBuAoptvQdCFKyI3QaipZcj0kNWtlLW5ESH4gPkm66jH1DEkx+hKRYgKWGIyX5npEPULka ltSdp0kNQ75TjADj3FuMdY35vHcMenzEG65nQl94Pcth/msb1nr/ZhHgh0yblEikR4PolfVo43Gj U4zPEhfB9KrrcPO1SiUt1TNmWU2rrB+tEaz0APLqenEpd3NVR6N80WRD8++tmFV9mJR60Qd6sItf sIEvV+bsQnIp5Yy5UM/terImc2rJndLSc5yjgVPLESmQ6rwQVtPcLZGsmNvIcLUURbPN2Mu6EO4i qTUZ8xrnbEUhwiyN6TJ1PB42q5QtTdwNZ6ZcaBZXAFLkjGWdDHglq53oIlaOGPPE4BBvQFyG03mL ArKt0cr908Sg70N8QEFT1/ZgV3t4gbCsScpkS528FZ4hXpQpazfWZ1X1T156t9XuH2FZdnDKgGK+ WopNaW4I+4V4U5aIIllZkg6P96oxue5ayu+l2Gbe28JXZsgL+mnaRbdG7sZJjvYMUo3KgyNUmHuR gFX2Gxt21ZIxIioG8iKG3Z/tZiQuHEUF3ZMI1AzRk3uYdD/78k/uqyTHrhsG7n2KvkB/aHia1kaW WeQMRnbtje+/MFlV1NNHG4gNJDFsGGio/L4kikMVSZ7WNhE/j9w6oAupQyQUx2nbGLZ/Kwkm8tRl qHjnccoQNI1Hev0yHVHBDnA9oYs2b6ek+PuYjg1/K8VK+dqPLwtK1CqKQyexidMt7re570zoD6Nx wVqRymLCtxst6IzCk1jSNda6xD1U5hmdUu7glFzv4Dg4glMYDgWHtNh4V+FMs7HfdwbH8Y5JUPg3 YjOdCVP9vwr0eg//vQKNw3/ZAu0/qUDn9VjLDvMKtTnhuUAHu1RUi0CLNTMQxIjG7ZXB8LYSKoM+ Si0mQnWhwYrWkl/mWtrh4p11mHuOyC+C5+LWXaHHOuV2Vmka7SxTl1xLscVS6a6ffeUAaEe9HyEU MAmFvANkWS4Y0wVhgtSwSYJRBX1suCjQpd6WCuzv1ZYL496CoF/qQHOLLxZHNAG+wUIOwqGDAtFB ijeQ7efaioprtJ86uqB2J7JF0B6SOuyBGyr81ZTHk6TUVgn43ByyMXmXVcttTuO30P5fnlp+lvav bv4yVb2m98f5OQnQQKaE+ooitmWnuKOiPb0QCXyzBCVISNNcO1wZy4f7wXMZjoNLG2oHsQ9A/RcM bd6wYZufUPE/OptgX1Wt8LsuW16jw+rVwGVF7IAktJYAM7jP+OaNeWxyn04dyHmNdNDk8cpRJKAP etWq4UKeYRJ1k32ymS8RN0vZpC9vgTxVp6qjzxuaLfMSfGWn7/zZb9CTLGsbYl8rMdRABdxqn4EE 7NaVQyGy5h7tyjH/+Ylmeqv84djw7YZj7AmDrKUXEOzXBqMJ2u4TVM4zA60X0sF4AWVNKnBHp4Mm CnKzQswS/s5GGixgkwkb36f7evQ61z/0uvN7e90k6HxzdrR4BXvdrJJgMHzexAZLZ+gJk93QQK3X NKRB+YRSDhyRWTGgrIseWmVrK9GWVtdoMF0l1QoNLxwg83/lGg04gO0Fq5NKBd2MzHGU+SiZcu7c wPzLfYQNaY1dDK1O5D3um3XDtxtesGUKJG8HZL+DT/fjrjTONqLV/tT8w8Nz9/v2SDUVav49kXdv viEJh8IXw8D4j2aB+QOzQE3tkWcuztW15XUk72N5Ikp/ErSRa8u+0bYUGRk2Dk1OfBfZLYOjHKBU 0/3NpdCJqJPAHHgRi8Eu1NlgzUyfD/EPD00VnGv69fkD5wiigrcWq86ldYZJnjPwgp3HGQ15p1pP swXCzZUiLtHwmCbyFQGVnNK0SNWF2R5GPVn46Z2bl0mBGdO8byzX6eauFiHlu/ngmm4hMgvBaR0B aHA5W4zWys4ZImWBAT15+v5WxDcOE4jslf0Dvfn5hl5ju3wbX0rWbqE1hCPEphR2O1CoRaA6r1rz 7p4FnW6rjkjHcZgB9pesB191aH27hciLmKVMhzhNXxHh+Nk2eA52G8tzpZKxJpoOQcuZTGIq7JFT 8t4+0QkLmbTonrVY8UN8g2/on7mLVKIT8ayEH9LuXoP2XF4Qpso5KdP+UjFOCShrSz2yNvHEW7/S jI0K8z41cD6GNmIVG+6hL3YPPTVfAYZjUjxPbYpezkhvrygL4iMTJDYyGNsxgXkh0skTQFhJ6Zb2 dSCOQ+Sz0q38bYi9htWlX2CzbYKWv3z5235R57SQ9/19tMci7fL7H39+fOGfvz58FWAAkSjAAg0K ZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iajw8L1N1YnR5cGUvVHlwZTFDL0xlbmd0aCA1MTIxL0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZyUbVQTVxrHZ4gzQYQoiaOY1JnoWo+KvPiuRUVR UI6KisgKKjZCgJSXUMBQKkIwQGYSZgIBglh1EU/RgtiCHHWtra+02LVIxHcOuqu2y9radd21z9DL nrMT7H7o15777d7nPvf5/57n/nFslBeG47g6ITZ6zZqNgRtTUw3JhmzdFn2uITUowmjM8JxqRQ0u UqOWIuGXj38JISZjWGOuH2SNhSP+7W+pVyk9MfwqY05hriEtPV87I3mmds6SJfO0K1OMu/XaLYV5 +fqsPG10drIxN8eYq8vXpwRrtSszM7Wxnvg8baw+T59rknaj41Zp/1+CdqQGrSFPq9Pm5+pS9Fm6 3AytMVXKk6/PzdblG4zZukxtXGGOPlWXrNeu+jW5tB2MYbi0MG8vzM8L8x+NvYVhU3BsmgybhWEh GDYHwxZg2GIMi/DG1vtiiTiWhWGLJBCYDCOwKIzDbuC++CI8Hm/C/+u12+uZLEHWN2rFKI4YQxQR t8gO+SZ5t3egd+fowNGFPm/5cD7/HNPpu8T3nB/ld8jvtcI01n9s9djX4+rHvfD/TLlUaVFRqsbx AePrqHFU9YSJE15MPBqgCPh6rmKuAu0Y0hXgdbBcBquHNlGVgiA41E6LvZwOIy0VrIVjNqHthI21 say6wmFzsvTRMkIQOEHj4B1VAqMoGkovwB8NyKBjKIXirSxv1ZhQONqBWtExCEfJjTWnDrmY4ygI fOGKGkKa+3tBSXfe/ch+UO2wCixPv0kBugHZY1RIcQ6Bc2gaIRx2QCscQ+GQbLKkf2hmjBCEfNEV NQrJCYtCSnr3ir32IrXVwQocrZiLxkIp/o1HRuGPv0PFe5B9F/8SBBlchlaqzuoopVEeaeYqzMxO eamDraMhl3QJfA2jmLsPtPgD0Mog+yrVkdmSos/ITElpzWzvaGnpoBX73OJxN35uAGwDsnPgptDm b9BU0MLsKxAIcRCxHYJRIJoSiaajeBr00EQ9P4YmoPEoJBf5zAzNAAKCYeopUPydUdhviHclMvZ7 MnHZJarG6rDQc8Rusp7jzXQCiSLROKLCynKsWqLOs7TLRJSNiBKESsHBAN1PDO97W26xWi3MbrnF Ya2hoZGscTgkFXa32ODGe59C3IBMjLhKuTjBTKMDZM1F17X7Pd79vS9OQIAa8Og+hKHJicg/q8LB Omz02WLCxgt24TAP2EvNty2JmwOjPoiMY9bER4SjpepSnnXR8JR08Xw9I7EAvgcy3Ep4dG/jgGrw P+LHFMcLNl6jetnQ1t2nudaZtjloZU4cYyDNLGtmkuVmnqun20jVYNeTIoQt35m4kFm+/aRFU8Gx rI0pSPI0URK859WeryBg4CGQ4D+/RV9Pq152Hr7e9oP6ZXh30B+iw8wszzpYWuE0QegNMV6CeFGC OAamUv1SGyvrmXZ5PStRDIP55Ij0NLLYxpYyxWgBgTaTUCeGETwvOAR1dRlfXknrnERlubWS1ZRz 1gqWQQeH1xKxb4oFJ5pKmgVJ9wVJtuAakX3aDfPdOID0L5aJbgr0nuFxMWfkUu9KPJzNHGe2MVno L4SV2+8ZSq6ao0+VEDZBgnuw+fpjTc+nicsC312HCCZGf2S/RupzhY0xewDYJQB77xR3w+yH/4IJ 4B31cHpM+vsf5nmGD3rcMKsHvz4AGVJjFw0RFF9tqy5zeFftT3HpNEi3BZWgBeidLxEOavC59xNM gsmRf5252LDFVMJwPNHt+hMshuCOI+ZaTTXPV/MMCh0+TkXrL//0/Sfu/lttUfMRlpAQwygaTOJ9 N35T9JKJUeIrqukNUfQ9WcJxJYxOXjJCx0WizOFLUtWc5+9Vc9U2+nwZYXNU2xyaKr6qipd49Yht PcrTA1sfQPKD+AHVM9VtiIFBSvUstnDuLjRKPeXhSggAxj349OfQ89saadX90423O16pH2y8g/wQ ERUxj1bdnnlHf7ZAOkqGeVTX+ZNXu8+kxYZFZmXto40NSz+9p1Y9gyL0HRW1KXnt2vWn7jz/sfXE Abq1+EXqHLVUQYYJdnngKS97yKkuqIqefETZyist1Zy36oK1rqP0tAaSLkAJLIB3tgGO1MgnfAaa hCa7F7541Ha1sZ7hOSLGXIAWo+CUD1z7NeVWtoKBUPE49W371hmhWZFhqw29TwD74otuyURgUHKR wREX+R1+BRPERqo9szUlJTNDn9KS2XH6k9Z2WiFeRau7IOzK1utwoAvCu5Q9vbCuD4IugeGG6rF5 yLWdqmFt9vIi5LUMbdSgtOkwGtZDGURDFOTDqn/MRtPQwlmBK3L2HTxVW1nD1zKfQz4hvSmoJadm 6STSYuesHFOaRxwq2tuUoEHKeBQRwqgumqNakq70nbnWepTmSektQ2X9lluaVzBN8rMkWI8CQIZ2 oQaUjvSoCaXDJDQNzNLpu10nBa7KzqBi+BslpeGK9/6xqMA7x/RehkGTVd58/KsWmN73WbOx3Mko wGS/IY0B9D63FygbYA/aI/YjE5hUt8WJ0EyhMFL1rBvedzbXnXUcm8STVcbatNpMb9VDaBqOeeOf km1uEF8TLitrt2g2kWabrVT6zjHDr4lE8jdGufONUXbKR66tI9uBIUBHdiCG2PDbyKRfLfUHaY7v 9Sgvfgemm+tvqgbFDRDmebSM3kmWeS4skFv2ZRbs0rydDH6wAZY1//tnRvXy87Y95XXMQk8yJ/1n 0unJBTK501a130m37tp+WGpU+DY0H8Wi5K9RKCxnVIPne4+eaGNqnXZnvVoB/+O8WoOiOs9wVtxz 1CoyHE8n7knPMRF1Eo1Rm9hEq0QT4g1NF0sW74CCAsodIjcve1/2fhFEEUQQTAMoCqKIOCqaru6s UjWLKQQ11dhEozPRvMd+25l+h10aV+O0k5n9w/Lt+3zP+zzfe5HqXQu7+Jauha5QIHth621qIyzr ovmWMyQMvRCL0lD4JjQYjeXQWh7R/Xenyv23v+A9FemjQ20cIBRFQKwHgkAOZ9Fv6xGHqQkIYO2C zAGQiEtLLlE5fDS8TduEBGFnaDVKbiqKBCvEkLj+l3CtZInQqVAM7p1ULkRgbz/N8RWyv/J6R/jx G56/Uo7/K54S6ifuKNexAcxdkPfzNah7sMxFg/l50Lz/idjzHOJACtIC1A+W4U58yiWCUFzPL/o7 8RT+1J2AU6g8IMYd76kpgUHL/UYRBBPCfXMVSq8G8dufvERfDIy0OuCHLu98Yqu5wJTL6nTyz7RV W2tGoww+UWzVakwKBo3Bh9VK7oVcAp28kJ9HVOkOKJpYo9GStiO5NGM05HvlYqXZrLUzZ4hy9Y5S YfKA7C5wDKQ5vldIMyAaHN1k5xUtCkIj52+ew+1F533JmAPZV4hHgCeeWRCBQi2zOZT//yZZcBff 1iWqvfS49/GlUe/yg/wZ/pBve4zEhMKEDw9IOIss0Zq2s94JeGBQKTk02xer1RcKxI+9bR8GTjzZ fhR+mN4T/nf+kCt0F6xH659sQgmQQB2gmp9EYAGOEjYLPtVCWnUWPPst8b3YOFJh1VrYC8QMb6Qq zRCnSxqtIw6qmjX72Xd5udiqw62ViSSUOoWGm+jNFlPpisTiRO26ITpCV6t1aveE8xEvuwiH0bqD ayTtxVYcWiqEVuFRR25UOdijBHUIhngfiVUG/NcVwmq0WQzcj/xRsZHo8x4VKwxGjY35krAbhO+D rxc5VzghwgmhuGF6YImHKuzjw2itAfcGx/HP3czf9qRIufXkYh1aqUWzJFT7tA7ZV1+3ny3BI1Jh gcWeWMPc8CWkyeeHlYS8Tuu4IIE/k33rziJy0Vup+WqD1qhmqXYoQNfpooJVK2TMspxjRx7Ba/pW Q3+/HuaGd5yiPg+sxS/ibX4EvX9/U/Vppsc+a/ZYOSLfXJNYtTub4/812Odn2id8woCfPyNSlNny AlaZr1CqJWqbxq5mawrEWrNFa2ZKdzeWWbh1R1q3n2FgdBOencNgZPxDNGJVdHZaOhfc3I8vausF mSuIH/oNbdIVm7QqWfxC5o287+8AceDq/ao6xbY9nJSUm7U2nGO7CRO+Sdr1eFtgq1MXVMQzaOTM cWgmGn95MvzmWl9ziUlnLMaLAEiK3J84eZHAL7SjFzbgDPPKkz5DRhGaKp35kITv9r/TUQG8LiIZ Ubt2rW0lg4Ytx7tKGEe1o5A2NBxE3W2N1XVYgS1Wc0oNc9unAP7vxAd0empsioz5o/y7vns77vcd a1JmNAo6uyHcCeOdopZe2IhzHAKH6ZOV3397q/xNGduBlj9FGhFZMOivHBwhSvT2spuFMB3zCpkz Bk1Ak66Ph9HF3FP8ZHon8NhBbhEM9gTBn5w08DCKtFrMeBLbeVhsMhiNEqvaoGJRWDdxztxylm2p yy1nTEaTyciV1YuNNmEq3rWochUKKZzyPjsrglTqcflJINV6pY3tQvzSgKQMtEe/3YJRohumuOGB W8hurOcjD8XzU+EBfdC801HDOqodFrvEqDdoTOzqOrFBpzVoGPm2vEw5t2PLuvoFDKKWhKGp6NUL M++4jx+s2MdtNcUvk0Rvi57MfvTxYQWj6d8TCpLEWlWxTi3ZfDfpS5Z6BEzzjTscxZ9WwtCzkvBI uiA7LknGzNvsfvzTQbfnSONmRTnWPlzvV170kwdW4IVhn1/4pdBIXFFcR0FzY9ZlpLCwn3TorHiO Dw6g+oX3dlQgd2kA96XQSVTVtB52MadLEmI5dMt/ari/Qo3xaUNCcGg3BE/2UHdhz8mBUjiBwJC4 r70WgPAV4j8IhPQXVerhgicv0/XpdUlJ6elJSbXpDQ21dfUs9jcGicuF953Sc/CBM/Sh5x4kUz28 FgNpMZCMQHNhuZj6AabDNHGHP9jXfgbIz28DBtPa8cKDpqHpYn7Jr0xHJAGrkVyssph1duau75UG jyly8j86Rb3YnTvP0KZivUml3Lwlg0mVV5foOF1pccdfJHzVCxDTiRT9e2Ub2bTS+k/bmUMnykqw 64uN/dVfSO4n7lAY5IHpwmfUK1TPk9SnFKba+zVeHp2Qs4mtL8qqncfELd6QlYF7WJVasy+HmRiA 1kmYc4yaRAk6HkUG0IwKoBmF44KHLCtvqDvGnPkl4f+bj26irPJA7YkX2EOw588UYjxUd4A/qWP9 tw+XxWUk4zVol0Z9OIeZ8CtvfAw6yaqa5hdaFWs0yinCL3gL3jKjQUPDq1IYhH6HxknRMMSisefw fsnA+PN4wRjDouVIRr+VcQOIH2pv3r5dO/V1RKbPmCZUW7Ra6GW8qJ/WSx5YI0waO9EkH69FMJvI rzmY3snAkA4YDrii9kBIKgxH1NwVcfk5LHVvp0rzeSYz9RmelmxDQZbEq3iG5zK/n3vCeRe9q+pY wwmmxzbpD28oXn9nVdK+ylQu2H8f3F9O9sJ6XAIKB+4SxSuIStNeayVrrSitsEnMuEea2A2VYqMG r0bM9m3JhXKuLG9Nw3y8FUlx+Q9BYcdx7R/W2da0t4ZDixf94l3QODhNZ6auTV7FzCi8f6+v4rtb rc3pWyu54OR+uT++JshNXYYyv9aRwsRQT+6vbjzVWOGQWxizwWI0cFUdYgMu0kaJI8OeLV2/NC2D pS5XaBQdac8k5zRhzbNk5T5vghi/tuYiFx/sCm1xxXiAc0mFMlQN/6b7DzX7ztwiLXrLNitbliHd ncRQV38fKZ3BoYmQuW+sZEViVixL/SM+cZd5C3eetAlVJda3HUwmc79N/eLmtRP/ZKmrMAVlboRB kuMNlUdY6m7dAbkGgxcWCWaA9z4VPcQF4O412qQ1adj/UF5+IU3FURxP5N5p/nnwNppe3F58sFAh Ak0lqTSICgUhH6b0stIgo2yls1zq2Hbvb7t3m9uMzZlNV7QidJt/iN78Q5JN66EUVlD4lNSTBL8r v5H97nY1ZvXQ++Hcc773/L7ncwyaGy10g3VqUgVDUPHXbVUMy8gBq8OMGdnC0k09hBFgzCpAhSdS 9tMqCpGt1ovBdqVuaOLuDD27+sRjwxZhx8NYIq5+LHneRuJ56QTv770fAJ7HBfCbZIM5e8aNeoFW ZDevNXe00WfvhGdUcF0KzE4JnEfjZO3945BemJ0Ywzigu+eyX31Kf949IH9UdAp12Jnz3PDCF9hI tVDtwhmhXB6U5nZ4x4erRUETPmzDPrxIHkajBi2jN2sxn5pHTGNG/1HoV8xjaLa5RPIUr1BUs3Po SeU8J2FpvJow8xzjpiOkm8O7Hcswrof70D6YfkSqxQfV8AGsp8pgoVAlj+JSdnLiQmqThVDlOKfI 6WFyM15FMBxvctGTpIt32DnVBow6HzkCtmA+T/K37G2OrhhaUogxg+Jn+QEcA7OEKmIyCflUfViq +FgSwxPrxokntw5FgIHttvTiNoEHeFhPJVxXOIDFYaAvkyYTMAIVZStBq0wvq2NEMYCPGWWGMzB2 vIbFQSFfbMgJNUiDH7Yaqqn31LrQiBUOSQrHwqmN7SpcgdaMWuZ2IqnZbx7tD2KH+6B4kyrHOUni r5LEkyQsipcSRhsH3PQE2XmeaO7Rtraq2yJ9NMsCjCpdGsICLAAU9Ly7sjA382z6oTK4FPjkm8vI fYWvsM1o2spyulAN0+S8w2a3Y9uxm3mlxkdwLMuxNMMCE1C11xCogYQ8/ElMyQYBj8+MObIfgH4V ykkWMp3s7y2slCE72iY0sj7OMqiEURKr7xJ/+6Vd+mjAVpy5BpsSDBKjvgsDW0V/ogQVW45v7qWT CGZG2/RLZSjQObSXGX2nRjqQTP//zHgaI6r2X6CTq/dunfSi6154yLvoJKHVVe+SKf213Qe3szOX 93/MEtgDglz+S4ABABEpmTkNCmVuZHN0cmVhbQ1lbmRvYmoNNDUgMCBvYmo8PC9TdGVtViA3Ni9G b250TmFtZS9ZUklHR08rT2ZmaWNpbmFTZXJpZi1Cb29rL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250 RmlsZTMgNDQgMCBSL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTI1MC9Gb250QkJv eFstNzkgLTI1MCAxMDQxIDkyM10vQXNjZW50IDkyMy9Gb250RmFtaWx5KElUQyBPZmZpY2luYSBT ZXJpZiBCb29rKS9DYXBIZWlnaHQgNjg1L1hIZWlnaHQgNDgwL1R5cGUvRm9udERlc2NyaXB0b3Iv SXRhbGljQW5nbGUgMC9DaGFyU2V0KC9maS9wYXJlbmxlZnQvcGFyZW5yaWdodC9jb21tYS9oeXBo ZW4vcGVyaW9kL3plcm8vb25lL3R3by90aHJlZS9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0L25p bmUvc2VtaWNvbG9uL2F0L0EvQy9EL0UvRi9JL04vUC9UL1cvYS9iL2MvZC9lL2YvZy9oL2kvay9s L20vbi9vL3AvcS9yL3MvdC91L3Yvdy95L3ovcXVvdGVyaWdodCk+Pg1lbmRvYmoNNDYgMCBvYmo8 PC9MZW5ndGggNDgxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyTy2rjQBBF9/qKXiaL oFerKgYhcOwEvJgkjGc+QJbaHsFYEm154b+fvn1NAiOQfYRUVaeornSz2+7GYTHpp5+6vVvMcRh7 7y7T1XfOHNxpGJO8MP3QLfen+Nud2zlJQ/D+dlnceTcep6SuTfozvLws/mYe1v10cI9J+uF754fx ZB5+b/aPJt1f5/mvO7txMZlpGtO7Y0j0o53f27MzaQx72vXh/bDcnkLM9xe/brMzRXzOKdNNvbvM bed8O55cUmfhakz9Fq4mcWP/3/vKMuxw7P60Pqnzt/BxlomEe9UkdZHF5/AX+Jn8DF6R4zcb8ga8 JW/Br+TXwCXzlMhT5uQcXJALcEkuwZZswRW5AgtZwEpWMN1KuJV0K+FWvpBfAls6WDhYOlg4WNa1 qGtZ16KuZV2LupZ1Lepa5rfIb9mjRY8V81fIXzFPhTwVPSt4CusK6gp7F/QudBA4CGMFsUIHgYPI fTZg5pSYk70Lehe6xdkJexf0LpyRYEbCGQlmJPQX+Mt99uGg1MpeFL0onRXOSmeFs9JZ4ax0Vjgr nRXOSmeFs9JZ4az0VHjqmrwOvEL+IstX8bDeTyWObdgu87UT3dX7sA5xBeMeYAOG0X1t6TzNJkTh Tv4JMADvVexNDQplbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqPDwvU3VidHlwZS9UeXBlMUMvTGVu Z3RoIDEyNzQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFJtTFNXGL63pVCd6Ta6ZuZe vPeaLEsWRZmLQzJmxogiZvED1DGNSqEX2ll64bYCLS2jXaD3qwWFlragUORDCp01WCgOVKIsKsvm MgxsGv6wZPtD4lzcKbskriXLsl87P96c53lynufNe14YSpFAMAxnfFZUWFBweFu+Vl2tpmm1/ghN ZRaRlef1ajqp43EUjm9OiWdsUonZ4g9/za6KMnDzVTD3+u0M2dZ0SALDc4v5VLWZ1lVqTcS7OTnZ 24ldWVlZRJ6GKiOJYrPRRFYZiUJDOUVXU7TaRGp2EHl6PbH+wEjQpJGka5Pkvy0QOiNB6kxakibU Cb1Sl7CgSQ1hotUaskpNnyOopPIfWPE/aYTOQCS8iOMGXRIVmxKkkVAbNDsTLtR6Sjl13mCidaRx x879xcfM1SSxh9CQFVDiwBAKZUMfQwehY9Bx6AS0ITE16BB0BGLgLXBIkiGJSQ9K50EePx1fmYYT 9a1pKZ8SZ1aPrjGpwC3OqsS9oF0GfksVCfGOCiTBWnvaWuqZ9TvYKyZwajypiO3iXrFDpiAUOQ4g BWoghb8HEilIj7+v0tTra/R9pvBo7+BQn3WUxMVHKeXmdW403DM4FLSFSVwBpu3PX8JrTdBLKKsJ guPbgEm6ujH+TCUE+G4/Qul4/amzPIlyVt5iRZYZmUtgGdz6aan4mrGA+lCXqdstb0n9/NeqFcMv lltqsKVpbMW9OSB0B5DTJfwJLclXoVauwYrMMjK3i2UFfDAnlDmcfZ24Kb4ZFWF5cEBoR2N/TAPV 2PPw8tjvI0tyhf0OyBgH73wDX30KChekYPIrla/O0+BxyCfudbT6cT/f1YkcYGXNTJsHF6IC2PQ1 AqSHb+XlFp0pVWOeRp/N2ySPhCeGo+iD/tKtTtxB8zpURIRDucVI0VzZ1LVrF68/xsT991WTkcjy cC/HtWHVvKYeaeFZhsVqyLM2A6qhgiFccUh4CW1PzAfObYLG++uA/EX6z39mLypjIGN1k6qijqYM fcZQKNgXCjYOV+DKeZ14RSU+TGM5lsEOMDIbb7UioxEhHInyI6jg5/0BZJ9bprzxwgX2AAni4gX2 y7frm0sx5Xwjb7Uhisf2SfBsEr47DzIfS5cBorKwZsbibNO0kW0auSM4YZ9Bp2IdXYN4tD8YmUAW ivvye7EPrtRfvIEMeLv8HszrD7YPoFeCLXYf7mbdTqHF/8nmbtdld8DFRJwR5zX5Bbu28wR6stxh qcLPmfXaU0jxyLmnNLZEDzeXIFSjxdqE2WprWAqlqj1eG97cyrnZNrki5JgB81OnbqWvLO77URkB px2qyL327ps462e7GZ/coSWbTai26tL4FD8r3MBH+G8DyL0ZPoYKAdflS4jyKldyjC9Bo8KMEMZc nMBiyvuM2mKpwTkDV8lRcqcz8QHKR1ztea42sXacuQHpG+B7UJo7rDdyuSWIXjANGDFlhB4a4npR BThtvwsWp+GlRXBmQRqXjKu8tNfssctjd72tnbjg47t8yAFO1sK2enCwwQWUQIYkgjmscRdb8c9i z7GyjwQxjduD6dVl9VqUMnYMWvCGAWEoiiwJT1wL661+8R7DaTFufZ/vc7J8Lns3UvBg/3djva7b y5iirmd1i19k+8FRf8wrlvlSRa4nLUGmdyXJwp6HHtHil4udvRtiG396JX7yDfBE9bcAAwDxrWej DQplbmRzdHJlYW0NZW5kb2JqDTQ4IDAgb2JqPDwvU3RlbVYgNzYvRm9udE5hbWUvWVJJR0dPK0No YXBhcnJhbFByby1SZWd1bGFyL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250RmlsZTMgNDcgMCBSL0Zv bnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTMxNy9Gb250QkJveFstMTYzIC0zMTcgMTA3 MyA4NzFdL0FzY2VudCA4NzEvRm9udEZhbWlseShDaGFwYXJyYWwgUHJvKS9DYXBIZWlnaHQgNjUw L1hIZWlnaHQgNDIwL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMC9DaGFyU2V0KC9z cGFjZS9jb2xvbi9WL2EvaS9zL3QvdSk+Pg1lbmRvYmoNNDkgMCBvYmo8PC9MZW5ndGggMjY4L0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyQz2rDMAzG734KHdtDcZI23QomUFoKOewPy/YA jq1khsU2jnPI209xSgcz2N9PyJ8tiV/qa21NBP4enGowQmesDji6KSiEFntjWV6ANireo3SqQXrG ydzMY8Shtp1jQgD/oOQYwwybs3Ytbhl/CxqDsT1svi7NFngzef+DA9oIGVQVaOzooRfpX+WAwJNt V2vKmzjvyPN343P2CEWK87UY5TSOXioM0vbIREarAnGjVTG0+l/+eXW1nfqWgYliuZtlJEzsz4lJ mCiPiUmYOOaJSYhPK5+In/aJSYgPKx8WLlcu0//3n5ZKaGDwaFNNIVCHaaqptaUpY/ExeO88kGvZ 7FeAAQApTH+VDQplbmRzdHJlYW0NZW5kb2JqDTUwIDAgb2JqPDwvU3VidHlwZS9UeXBlMUMvTGVu Z3RoIDIxNDEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFR5UBTZHe4BBrqSrbFCZ1La 7XZPbWXjrifG+wiuko3r6CIGREA5RhhgFoY5ZYabAWam+3XPwADD7YwIDDcGQQ5ZFg9YjbK6Jqvl UeUuK24Z3YpHduth2irTY7Kp/JX3R9f7vd/7fd/33vv6J0KCAhCRSLQk/o97du/evyIiU6FV6PWK 7Ci9ZtUuTXaaPylbIEQLvwxaWPqWlP8d/2xp0Ol/vi2GY4vgtV9cXIpeCEUCRKKrtyM02jy9KiPT KFu7ZcumlbLfhoWFyXamaY4qZdF5BqNSbZDtyUnV6LUavcKoTFst25mdLXtTYJDplQalPte/+F8B MpVBplQZM5V6mULIZ6gECL0yTWbUK9KUaoU+S6bxZ/4nTP8/bDJVjkzAkh3MUfmjaKOwaJApctLW CCiaNyypmmM5Rr1KaVi95g/RMXlapWyzLE2ZjiAiZJEI2YUgHwYgcgTZL0JiApA4BJEIF4d8jKiR LlFEQGAAHfheYFPQvqBpsTY4OLghJPMJO7nwZFIkfH89GcgGLdAv97+ig6GTn5Hy4bBGDB8F8zL+ nBT6g1eukFfBSW/mMJwX4uCFz6T+GR/OV4slMgvcKroCPwiEK2GYNEaVmhI/8snw1Km+qdHsPx2i JJUvV5hE7ML7gfNy6diL6zBsHAaM/3ANrh59qmrIcqtqEnlRNE8e5oMT+J8f4hcd5EN7SrrLOstQ CfyZ5cmKZ9tyYezNuzA4tBWugyFwDbYVXuiXNpkbCtxl6L2/NLqaKSyJ6wDdHXgsI7YB1uHCuRHu 8Rf4Nztmw1fsTI2KIJsNx3XHc1Hf0LmuPmLMo06gKUs+m0vw6/asiNl7O3aKwrYOTjR2X6IwD48+ lPZ2dn5RXcMCF6ljzQYcsDTDkGWFumIdYdI1naQklhdbcheQ7y2mbhNc+02HKbQbfgCXwA2YvBS+ GJC6zXWFTaXo9blGVyPVwfaAdjKOFtuZShcF5ZXCRa7HHQwHSvltubYoEosp1YIcTkPeYrh4Lo5L WlJBi7G9pS5zdnUGkXzAlJpBxcXoPgrH5R0xAyoy49SZktNEW6vzzDyFtZWW/01aCmw0Qxbp8uwm Is/cWF9OFbVau4bwS7V9TW2kt95T7RH2l1sbKSBnt8pxyWPL8/l7P34t6obboAQuD+yG8VL+nedy uHjigdc3Q9rbK3rLO9CSLHlBMqHXOVqNVHF9iZfpQ+efs04fVcONjXCN6Kz5XNYg2a09cvJjgl/+ Lh/Ev0PBQhgubW0qyauhagortbl4BW23kiAnAWQSYKjaU+9FWxtbqpoJSS73GokuRV6LgkqRR2se wFX/CP0abuY3wPXYNGTnpDc5GHIDH5xi+wlHFzfQhWO304+AFOIx53F5yMaqOmcz0T1hpGspb0PX 5UG89lha7WEiIapUvpfCupITi9LX4VYG2AGJtYN8AzATWpCtxts62RaC28Ku2oYzwgBkAi0GWlar wU9/xg1fvMZ+Svi4Th8u2fiTvpxSxHQH7gidhR/x64VHfgbXvtwujUk/qogbTR+ZHDl1flg9dIDC HkXw30t5NoQBDE3GCqg6Vq3Dh85xIyPT7CDhYwXUGKf4qQOu4qCIdLAcU85vNNoPkkBQpsElUPET pVqgPGEKnYMboBRuxsbm4EMpz/0bWdCrAwLw6SlueGiSHSC4DrbLh6c4xdOOx9znpKetv7mVaGqg zW7hCVjDEVzJRYOjpP+0ZOp/igfOCqomBFVCsfDrxDvFjquO+9O4z95j7iH7TEdPpxCJx8qjllM2 Tozdtp2we20nUL9kK79MR8eTeqDWCorfsdyB03cFI0XAt+GuQNhkkc5MNrQPUpcGJ249wOfTrh7q JduUiQ2xRNT+gqwUKjIp8/fb8fDOg+NppGroUtEM0XBHai6s9pZQhSfK+m/hl92DLW3k8fpmVwtx 3GPJdVNuY012JL7bnmrWkeaSAlsBIRmxzMEzc0WmUN+C9FUIDJuBa7EvhfawTqq2q60aa1VSVaIr EbX0TVnPEtjslfPupl7qvK//7EX8XkJXhJcMP5Ff1Yp7at21LtJV2+KoJ+qb6fI6qpJx2Dh7U+zi nsreKl8VirXbR21jtlEUm63OP1wdQ8gTiwuyKIUpOWk/vm80+aGOvJ5XX6HH8y2WEitpKylmi4g8 U5U7n7JWgkrgRCVeyw+bciF8NG8KvQ838u/DlZgZxlqkN7+q9d2gsDG6w95j86Hl2cqKVOKYoaVz jD3FDVMXWG8NPv5ncIZwdvvdfyQaxBGcj/uOa0WdgGNIzEivzNHHUYyBzmK0qM1O0yRmNgE9bQIo owE5GrytS/B6GfhNbgk4HI1rnMZeDWls76joICSWp8tgIKx8GHpF8FiQ4Goz/PuQ9Lih0d+5Zh80 VrkFaZzPb45oRkwDRyUMccC3uB8pDjhBIb+WBkpS57ftp4wYM0dy74HdZJFZX1FAFBVxnhKquNWv +ivHA+4G6QAOoT8BfpldwaA6kKPFRxmxHGzfgUfe2nZ5yOs8e5+UwO8s8Fe8KBe+Hk/8dsO3oVWw BXpgOhb7sgC+lGKRwtl7OvBj2UCXGscqCawOvKEfZ8RODtCU7ZOKo1Z1eYo12xKHlgdj6UWXMuC7 5pto9D7AFFOFibH89oIDFY7F1n7rcMUEikVWTNC9dNu0YzHXxXb78OQD7BFlIqsmsNg3wAO0uNLB MBzlTqlL8uxq3lOXfHIdOjXDcf1U55f9c62fo67gtk2evd7d6F/HOK6H6rzbMnHyWtuNlqmmfwE7 AMT/uggOdqD5HZz7eKT3QJbAkPtKmAb7lp8Hd5/5Epv7iaT3SZ/Klft6mQj7l6AJ4Ar3OQuMDA74 zRT4KBUCDADS4CIrDQplbmRzdHJlYW0NZW5kb2JqDTUxIDAgb2JqPDwvU3RlbVYgMTYwL0ZvbnRO YW1lL1lSSUdHTytDaGFwYXJyYWxQcm8tQm9sZC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUz IDUwIDAgUi9Gb250V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNjZW50IC0zNDgvRm9udEJCb3hbLTE2 OSAtMzQ4IDEyMDIgOTA1XS9Bc2NlbnQgOTA1L0ZvbnRGYW1pbHkoQ2hhcGFycmFsIFBybykvQ2Fw SGVpZ2h0IDY1MC9YSGVpZ2h0IDQ0MS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDAv Q2hhclNldCgvcGVyaW9kL3NsYXNoL2EvZC9lL2YvaS9uL28vcy90L3Uvdyk+Pg1lbmRvYmoNNTIg MCBvYmo8PC9MZW5ndGggMjk3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyRz2rEIBDG 7z7FHHcPi0majSyEQNl2IYf+oWkfINFJKjRGjHvI23fUZQsVdH4yfh8zIz+3T63RHvi7W2SHHkZt lMN1uTqJMOCkDcsLUFr62y2ecu4t4yTuttXj3JpxYXUN/IOSq3cb7B7VMuCe8Ten0Gkzwe7r3O2B d1drf3BG4yGDpgGFIxm99Pa1nxF4lB1aRXnttwNp/l58bhahiPc8FSMXhavtJbreTMjqjFYD9YVW w9Cof/m8TLJhlN+9Y3XxTI+zjALxJTEJ6yqPTIG4TFwGPiY+Bq4SV4FPiU+Bk2cVPKvkWQVP8RCZ AnHyFMFTJE8RPIVILJrQSpGlirLYyq3m0BTNHu4Tk1fnaFjxg+KUwny0wfsf2sUCqcJmvwIMAHYZ joINCmVuZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmo8PC9TdWJ0eXBlL1hNTC9MZW5ndGggMTgxMzYv VHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjItYzAwMyA2MS4xNDE5ODcsIDIwMTEvMDIvMjItMTI6 MDM6NTEgICAgICAgICI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMv MS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcG9zdHNjcmlwdDwvZGM6Zm9y bWF0PgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvIgogICAgICAgICAgICB4bWxuczp4bXBHSW1nPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvZy9pbWcvIj4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5BZG9iZSBJbGx1c3RyYXRvciBD UzUuMTwveG1wOkNyZWF0b3JUb29sPgogICAgICAgICA8eG1wOkNyZWF0ZURhdGU+MjAxMS0xMC0y NFQxMDo1MDowMS0wNDowMDwveG1wOkNyZWF0ZURhdGU+CiAgICAgICAgIDx4bXA6TW9kaWZ5RGF0 ZT4yMDExLTEwLTI0VDEwOjUwOjAxLTA0OjAwPC94bXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHht cDpNZXRhZGF0YURhdGU+MjAxMS0xMC0yNFQxMDo1MDowMS0wNDowMDwveG1wOk1ldGFkYXRhRGF0 ZT4KICAgICAgICAgPHhtcDpUaHVtYm5haWxzPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAg ICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAg ICAgIDx4bXBHSW1nOndpZHRoPjI1NjwveG1wR0ltZzp3aWR0aD4KICAgICAgICAgICAgICAgICAg PHhtcEdJbWc6aGVpZ2h0PjY0PC94bXBHSW1nOmhlaWdodD4KICAgICAgICAgICAgICAgICAgPHht cEdJbWc6Zm9ybWF0PkpQRUc8L3htcEdJbWc6Zm9ybWF0PgogICAgICAgICAgICAgICAgICA8eG1w R0ltZzppbWFnZT4vOWovNEFBUVNrWkpSZ0FCQWdFQVNBQklBQUQvN1FBc1VHaHZkRzl6YUc5d0lE TXVNQUE0UWtsTkErMEFBQUFBQUJBQVNBQUFBQUVBJiN4QTtBUUJJQUFBQUFRQUIvKzRBRGtGa2Iy SmxBR1RBQUFBQUFmL2JBSVFBQmdRRUJBVUVCZ1VGQmdrR0JRWUpDd2dHQmdnTERBb0tDd29LJiN4 QTtEQkFNREF3TURBd1FEQTRQRUE4T0RCTVRGQlFURXh3Ykd4c2NIeDhmSHg4Zkh4OGZId0VIQndj TkRBMFlFQkFZR2hVUkZSb2ZIeDhmJiN4QTtIeDhmSHg4Zkh4OGZIeDhmSHg4Zkh4OGZIeDhmSHg4 Zkh4OGZIeDhmSHg4Zkh4OGZIeDhmSHg4Zkh4OGYvOEFBRVFnQVFBRUFBd0VSJiN4QTtBQUlSQVFN UkFmL0VBYUlBQUFBSEFRRUJBUUVBQUFBQUFBQUFBQVFGQXdJR0FRQUhDQWtLQ3dFQUFnSURBUUVC QVFFQUFBQUFBQUFBJiN4QTtBUUFDQXdRRkJnY0lDUW9MRUFBQ0FRTURBZ1FDQmdjREJBSUdBbk1C QWdNUkJBQUZJUkl4UVZFR0UyRWljWUVVTXBHaEJ4V3hRaVBCJiN4QTtVdEhoTXhaaThDUnlndkVs UXpSVGtxS3lZM1BDTlVRbms2T3pOaGRVWkhURDB1SUlKb01KQ2hnWmhKUkZScVMwVnROVktCcnk0 L1BFJiN4QTsxT1QwWlhXRmxhVzF4ZFhsOVdaMmhwYW10c2JXNXZZM1IxZG5kNGVYcDdmSDErZjNP RWhZYUhpSW1LaTR5TmpvK0NrNVNWbHBlWW1aJiN4QTtxYm5KMmVuNUtqcEtXbXA2aXBxcXVzcmE2 dm9SQUFJQ0FRSURCUVVFQlFZRUNBTURiUUVBQWhFREJDRVNNVUVGVVJOaElnWnhnWkV5JiN4QTtv Ykh3Rk1IUjRTTkNGVkppY3ZFekpEUkRnaGFTVXlXaVk3TENCM1BTTmVKRWd4ZFVrd2dKQ2hnWkpq WkZHaWRrZEZVMzhxT3p3eWdwJiN4QTswK1B6aEpTa3RNVFU1UFJsZFlXVnBiWEYxZVgxUmxabWRv YVdwcmJHMXViMlIxZG5kNGVYcDdmSDErZjNPRWhZYUhpSW1LaTR5TmpvJiN4QTsrRGxKV1dsNWla bXB1Y25aNmZrcU9rcGFhbnFLbXFxNnl0cnErdi9hQUF3REFRQUNFUU1SQUQ4QTlVNHFsbm1QVTc3 UzlKbHY3T3pOJiN4QTs4MXVVZWEzVmlIOUVNUFZaQUFlVEtsU0Y3NFFFRTBtRnZQRGNRUjNFRGlT R1pWa2lrWG95c0txUjh4Z1N4ejh2OWFiVmRJdkhrcDYxJiN4QTtycVYvYnkwNlZGeTdxUG9TUmNs SU1ZbGsyUlpPeFYyS3V4VjJLdXhWMkt1eFYyS3V4VjJLdXhWMkt1eFYyS3V4VjJLdXhWMkt1eFYy JiN4QTtLdXhWMkt1eFYyS3V4VjJLdXhWSzlkOHcybWlyYnkza1U1dFpuS1MzY1VaZUszRktoNXlO MFFuYmxTbmpoQXRCTksrcWExcGVsNlZOJiN4QTtxdDljSkZwOENlbzg5YXJ4UFRqU3ZMbFhhblhF QlNYakV2bkx6OTUzZWEyOG5vdmwzeXZha3BKcWNqQ0dpLzVVdS9EMlNMN1BjMHlVJiN4QTtqR0F1 Ull4RXBtb2hQZklXb2VXUEk5amRXTXV1U2F4TGR6ZldaNUk0R0NMS1ZDdlJtSjVjcURldWF6TDJ2 Z0I1MzduYllleE5TUmRWJiN4QTs3eXp2UnZPbmwvVjVQU3RKMkVwL1lramRQK0dJNC9qazhHdnha VFVUdTFhbnMzTmhGeUczdlR6TTF3WFlxN0ZYWXE3RlhZcTdGWFlxJiN4QTs3RlhZcTdGWFlxN0ZY WXE3RlhZcTdGWFlxN0ZYWXE3RlhZcTdGWFlxN0ZYWXE3RlhZcThMODl5RHpmNTdoOGsyTGl5OHRh RUh1dFdlJiN4QTtFQlVVcDhjNzBBcFZlZnBydDlvbkptUWhFeUxBUU01Q01VVmFXdDU1b3ZiZlI5 SXR6WStYTEVxa1VFWS9kd3hWUDd5U3BIS1J0enVhJiN4QTtrL1RuSnp5WmRibG9mUjkzbjczczhl UEYyZmhzMGNoSHpQY1BKbEdxL2x4NVAwelRmWHU3aTdqUU1xUGRBcXdRdWVJWmxDZlo1Wm1aJiN4 QTt1eThHT0Z5TXZmOEFnT0RnN1kxT1dkUkVUNWZnODNuK3Q2S05LMUQwRW1qdjdlUWNyYTRoWUZY SFRmaVdvUWVxMXpTNThIaHlvRVNIJiN4QTtRaDZEVGFueFlXUVlIcUQwWnorWDNtclZFbGgwcTl0 V1d5YXFRVG5uOERkbC9lRmp4N2UyYmZzM1dUQkVKRDAvYzZMdGJRNHlEa2pMJiN4QTsxZFJ0djh1 cjBuT2dlYWRpcnNWZGlyc1ZkaXJzVmRpcnNWZGlyc1ZkaXJzVmRpcnNWZGlyc1ZkaXJzVmRpcnNW ZGlyc1ZkaXJzVmRpJiN4QTtxVDZUNVUwblNHWDlHbTV0NGxKUDFjM1Z4TENhL3dERmN6eUl2K3hB d2syZ1JwNFA1TXVKSnZMWG16WG5xMXpxMS9GYnRNZnRjV1o3JiN4QTtpUVZyKzBTSzVyKzJwbU9D aDFOT3o3QXhpV29zOUFTOUMvS2JWVWl0TlVzd2dOd2kvVzR5emNGWUtPSkRQUThRRFRlbmZOWjJO bW9UJiN4QTtqMTV1Mjdld0V5aExwOUtycmZubVRVUEs5NzljMHQ0WS9yS1dqb0phVkpEUzBxMGRk aEhSdHE3OXNscU8wRGt3eTRvMTZxNS9IdThtJiN4QTtHbTdNR1BQSGhuZnBNdVh3Ny9ONXBLeVBJ eklucG9UVlVCSkE5cW5mTkNUdTlORUVEZmRFUWpUNHlIa21sWjFOZU1LaFJ0MHBJeHFQJiN4QTsr QXlRNFJ6Si9INDdtdVhHZVFIeC9WKzE2cnJWMytaT29wcEI4ckN6dHJHOXRFbnZMNjhIT1NKMkFi aUFEUnFxZTBmWHVNN3JUekVzJiN4QTtZa2VvRDUzcWNaaGtsRWRDUjlxYjZKNVoxRzJaTG5XZGJ1 OVd2bG9hMUZyYktSL0xid2NGSS8xK1dXRXRRRElNaXlkaXJzVmRpcUEvJiN4QTtTcS9wMzlFK21l WDFYNjM2MWRxZXA2ZkdsUHByWERXeUwzcEg0RXV4VkJmcG5UdjBxMmxHUmx2a2lXY28wY2lwd2Rp aTBrSyttU1dVJiN4QTsvQ0dyc2RzTkl0V2JVTEJPUE81aVhrQ3kxZFJVQnVKSTMvbU5QbmpTMnQv U21tZjh0Y085UVAzaWR1dmZHbHRzNmhwNFVPYm1JSXhvJiN4QTtyYzFvVDdHdnZqUzJ1aHZMT1p1 TU04Y3JiN0k2c2R0ajBPQ2sydGJVZFBXTnBHdVlsalFnTzVkUXFrN0NwcnRYRFNMVlZuaGQyalNS JiN4QTtXZGQyUUVFaXZpTUNWK0t1eFYyS3V4VjJLdXhWMkt1eFYyS3V4Vml1dStiUE5Galg5SCtV TDIvQUIrTTNGcEdwcDRDT1NkL3ZYSkFEJiN4QTt2WWtudWViMm5tdTY4eDZici9sNjQwYTMwUzkw ajA3Mkd3dGs0SGpFeFM0NWpZRW9yTDBHYS90ZkNaWUNSMDNkbjJKbkVOUUwydmI4JiN4QTtmRkIr VU5ZVFIvTU5wZXkxTUNzVW5BTlBna1VvU2ZIalhsVDJ6bU5GbjhMS0pIazlmMmhwem13eWlPZlQ0 TW04NjJsOHVqWEZ4TXNuJiN4QTtvVDZoTE1ySXc5QTFZckd5cXFuWmszNUZoVWs5Y3p0ZENYQVNl Um1UNWVYMmRYV2RtNUllS0lpckVBUFB6NjkvU3Rnd0hOTzlBbTJrJiN4QTsyOTVMTkV0cGJ3eE5J d1dPNnVhRVZKcHQ2bFVKOE9LRnZETWpER1JJb0QzbjhmdGNQUE9JQjRpVDVEOW0vd0F6VDNRMmNw MFkyVWplJiN4QTt2TjlXOUYyTWp4RjI0Y1NUS254cHlQN1M3anJuYTQ0bU1RRHpEd09XUWxJa0Nn U3hYVC9LUG1hd2s4dk5iNmdBTEpXT3RCNXBaZnJFJiN4QTtzb2lFdkQxVWFpZnVqeEh3MHIyM3Ji eEJwNFN5ZlI0OVpSTGx0VmtqZVY3aVJyZFlmc0pCc0kxK3lyVm9LdFV0dWV0TmhFc2hhUHdKJiN4 QTtkaXJzVlNEL0FLYjcvdDFmOWpPUzZNZXFOdkY4eG00YzJjbG10dHQ2WW1qbForZ3JVcTZqcjdZ QlNUYWd3ODNLcFpwOU9DZ1ZKTWN3JiN4QTtBQS81NllraFFDa1dxZVRMM3pIT3Q3ZGFwYXRielIy OGNpVzBEdFVXMDd5aG9wdlgrRnZqNjhkampESUNMRzRXZU9RTlMySzJIOHN3JiN4QTtsdGN3dmZw S1o3Q1d3RWoycWtscFhaeFBJT2RDeUZ0dUhEM0oycExqWThDclArWGhsZVdRWEZvclNIVG1UL1Fx aFcwK1VUdi9BTHVIJiN4QTs5KzllWGdOdCt1UEV2QzNOK1hhU0xxTVF1YmNRWE1kOGxpaldnWTI3 YWcwYnlNVDZnRDhERjhGQXRQZkhpWGhWOUg4anZwdm1adGFqJiN4QTt1b1BUZTNXQjdXTzJhUGNJ Z2R3M3JNZ0xPbkw3RmUxZXBJTXJDUkdpaExiOHRZNEpWdWpkeFRYcTMwOThSTGJzOXFST1ptRVp0 ek1mJiN4QTs3czNMY0dEaW5oV3VIalJ3THRHL0x5ZlJ0VmoxR3oxQ04ydDdVV2tFTTBERUZWaFNP cnNKZnRjb1ZOVlVmRFZkOWlFeXRSR2s4NGViJiN4QTsvd0RmMm4vOGlwLytxbURaTzZ5ZVR6VEJF MDA5MXBzVUtDcnlPa3lxQjRrbVNneU1wUmlMT3daUmpLUm9ibFRrdmZNRVVNVTBsL3BTJiN4QTtR ekZSREl5eUJYTGZaQ2t5ME5lMU1pY3VNQUVuWStiSVljaEpBRzQ1N0ZYNGViLzkvYWYvQU1pcC93 RHFwbG16WHU3aDV2OEE5L2FmJiN4QTsvd0FpcC84QXFwanN1N3VIbS84QTM5cC8vSXFmL3FwanN1 N3VIbS8vQUg5cC93RHlLbi82cVk3THU3aDV2LzM5cC84QXlLbi9BT3FtJiN4QTtPeTd1NGViL0FQ ZjJuLzhBSXFmL0FLcVk3THU3aDV2L0FOL2FmL3lLbi82cVk3THVtMHNzY1ViU3l1STQwQlozWWdL QU55U1QweUxKJiN4QTs0dCtaMWhjYWJyZG4rWnZsaFJjMjhaRVdxS0ZZUnlvQjZZazNIeHhTUm5n V1hib1JsZzNIQ1dzN0hpQ0FHajIydlFSNnQ1VnJkMkZ5JiN4QTs2cExhRGVhMG1mOEEzVkt2WGlE OWwrbFB2emxOZDJWUEhQMEM0bjdIcyt6dTJvWklWa05UQStmN1VUcjkwMXhwMWpwN1IzQ1NhZE0x JiN4QTtsSkx5WnJSekg4SVpBZGxrcDFBN1ppNmlmRkNNZC9TZUgrai9BR3VYcFljTTVUdU5USEYv U0Yvb1FHdjJHbTJlcERUZE9kcm8yLzd1JiN4QTtlNkFxWkppZmlDS0Q5bGVnSGpYZkt0UmpoR2ZC RTNYWHZMZnBNczV3NDVqaHZrTzRlYjBIeUI1RlMyNDZycWx1NHV3UTFxa3piclQ5JiN4QTt0b3dQ aFBoVmo5R2JyczNzL2g5Y3h2MC9zZWU3VjdVTXYzZU0rbnJYNjB1ODVSV0QrZUw0ajZpa242S2pW MzFDMmtuaU14a2FuRmwrJiN4QTt6SUlxYmdNYVVGTTZDUEo1cVhOVEsrVUp0ZTE4eVc4eUxOcG1u L280eHdUdGRMS1lwZVgxZWdMaVlJWXVYRTE4ZStPNjdJZXkrc1FhJiN4QTsvcDhtdkNiOU14K1Y1 L3JzMEtNWnhkRGlWNHQ5azNBdHcvZkQwMjcxNjc5eWhhV3VxMitnNjlwbW1RdFA5VlRUbzVkVjA2 T2FCN3EwJiN4QTtXVXRNb2lJMnVsaGR2VUtFMXJUN1dQVmVpYWEzRnB6VDZvZERpQzZGK2dybGI4 Um9WdG11dmgrcGhWcHhNNjc5UGlHMWQ2WUI1cFBrJiN4QTtqZEIwM1ViUHpYcGRsZEora2RNdHJh NGwwVFhHQWR6YnZ3NFFUUDE5U0lINFcvYVUrTmNTZGxBM1pILzAzMy9icS83R2NqMFpkVXM4JiN4 QTs4VytuSnEraFhGekdvU1M0WkxscWZiakMxbzFOMnAyelRkb3hnTW1Na2RkM2Q5bVRtY2VRUlA4 QUR0NzBYcHRwNWR1Sk5VbjB5T2tTJiN4QTt3L1ZiaUlxUkU1NGlTb1J2WnFIYkxNVU1VdU13RzFV ZTd2YXMyVE5FUUV6dmZFTy91VytWOVVnc2ZLZWlveVBOY1hLZW5iMjhRQmtkJiN4QTtoVmpUa1ZV QlFLa2tnRERvOHdoZ2dPWlBJQk91d0dlb3lIa0k4eWVRVEtIelRwc2x2SkpTUko0cmo2bTltd0hy ZldPMFlDbGxOZkVOJiN4QTtUM3k4YXlCQk85ZzhOZGI3bkdsb1ppUUcxR1BGZlN1Lzhib1BWZk9C c2ROdjdnNmJkUjNGa0VIcFRJdkFtU3ZGdlVqWjBLZzlhTlhLJiN4QTtzMnU0SVNQREs0OS9uNWh1 d2RuOGM0amppUkx1OHZJZ0cxZTc4M1dWbkJCTGQybDVBMXpONkVNVFExY3RRR3RGTERldXdyVTcw R1RuJiN4QTtyb3dBTW95Rm11VFhqMEVwa2lNb25oRm5kVGJYZEt1cnJSL3JGcGR3M056SkliSkpr YUlvNkt5dDZnNVUrejBHK1JPcGhLVUxqSUVrJiN4QTsxZTN6WkRTNUlSeWNNb21NUUxvM2Z1Uk4z NWt0NFBYYUsxdWJ5RzFmMHJtYTJSWFZIMnF0R1pXYmpYNHVDbW1XejFZRjBKU0VlZGYyJiN4QTsv YzE0OUdaVmNveE10eGY5bTN4cE5KWW9aNFRIS2draWtGR2pjVkJIdURtUVlpUW84bkZqSXhOZzBY bXZsd2VXVHBGNURxTWZPNmt2JiN4QTtaTGVFaFdNaXE3S2ljWDZEaVQ0NXoybDhId3lKajFjVlBT Nnp4L0VpWUgwOEFKN3U4cDc1anZQcXVzK1h0S2UybHZMVUNaNVlsUlg5JiN4QTtZeFFGVW9yRUJp dkxrZkRiTTdWVDRjbU9CQmxIZnB6b09CbzhmSGp5NUFSR1czWGxjdjA4blEzMFZ4NXhtdDV0T21r Z3RMZUNLMmpNJiN4QTtTRklTekZqSnhKK0hvb0JIOHVDT1FTMUJCaWFpQUJ0eTgweXhHT21CRXhj cFNKMzUrWDQ3MHkwblhORFRTWmIyMVNXSzNlNmtUMDVBJiN4QTt4bGt1SGZkVlVsbXF6SFlmcXpJ d2FqRU1abEd3T0w0a3VObjAyVTVCR1ZFOEk5d2pUV3A2L1pmby9VbzlUc0x5Q0NDSWZXRktBODQ1 JiN4QTtmaCtCNG5aZm44UXBqbTFNZUdRbkdRQUcvd0FmTUZjT2tseHdNSlFKSjI5NDd3UitoRkhX YlMzU3p0cmFDYTVtbmdFc0ZwRnhNZ2hVJiN4QTtBY25hUjFVQVZBM2JjK09XZm1JeEVZeEJKSXNE eStKL1MxZmw1U01wU0lBQm9rOHIrQS9RaEc4OGFLSUxHWkV1SlJmc3lRcEhFek1IJiN4QTtRMFpX QS9hQjdDdjNaVWUwY2RSTzU0dkp1SFptVzVEMGpnNTdvbXc4ejJGMDE4a3NjdGpKcHdWN3FPNlZV S295bGcvd3M0SzBHVzQ5JiN4QTtYR1hGZHg0ZWR0V1hSVGp3a0VTRStYRDl6aDVqQmtpVWFiZThK NDJsdDVmVFFxNFJlVk5uNUlTT2djTGcvTjdqMHkzNWJmdCs5ZnllJiN4QTt4OWNOalIzL0FHYi9B QXREeGVjN0NiVFlkUWh0YnFTRzRuTnRFaW9oa01nL3llZlNvSXlBMThUQVRBbFJOZmpkc2wyZE1U TURLSUlGJiN4QTs4OXErU1lheG9XbGF6RERCcWNBdVlJSlZuU0ZpZUJkQVF2TlFRSEFyOWx0c3p3 YWRjUmF2ZnkyRnZwODhsOFkwc0k0bU55WmFlbUlnJiN4QTt2eGNnZHVOTUFTWGt1cC9rL3FWdGRK NWsvTDYrazBhN21VU25UWnlVV2ovRnhCK0tnLzRyY0VlNHl6ajZGcjRPb1FOejVrL09DMDArJiN4 QTtUU3RaOG14NmxCdVM5dkM1cTFlUmV0c3pweUpOYXFBY3FucHNVNDhKSHBic2VxeXdueEErcGtu NVUrWlgxTFdOVjB6VVBMMEdoYWxwJiN4QTs4Y01pUkpFeVRGSkFlWE15ZkYwS0VmUElSMG1QSHZB QU1wNnpMbDJuSWxrRU90ZWREYmF0Y1MyVVFTQzdqZzAwTEJQNmpRZldqSE5NJiN4QTs4UmZsSndn SWtVSlRsdlQydW9OTmxTazh3ZWNsaTBvL1VBSHZsblNiamFUeUJKVXVJMGdad0pWOUZKWUdlUStv ZmhJb1RYYkRRUlpSJiN4QTtjT3NlYUc4eTNObEpacXVqSVpUYjZnTGVZazhJa1BCZ1hHNGQ5bVVF U0NvSEVqY1VLVFp0THJmelY1Mi93N2NYY3VqR2JWUkhiRzJ0JiN4QTswZ25nVnBwWXZVdUltUjJk K01OQ0JKV2pHZ0crR2hhT0kwblVlbzY5TjVodElvNDFqMGE0dFRkT1piYVpaa2I0UXNUUytvSTBj bGkzJiN4QTtFcFVCYWQ2NEtGSnMybEQrWmZPaTZacDh3MDBOZDNFVTdUSjlWdUFETWs2cEZDVjU4 b09jUlp2VWtKWGJEUVJaVEcyMWJ6Ty9tdVd3JiN4QTtsczBHaUswbm8zd2lsVm00UlJuZ3hacUE4 M05IQUt1QVFLRmR4UXBObTFUL0FLYjcvdDFmOWpPUFJlcUc4MXg2bExxK2pTMmxoTmN4JiN4QTtX TTVtdUpFS0FjU0FLTHlZVk9hdldpWnlRTVlraUpzdTMwSmdNZVFTa0ltVWFITkZ5WDk5SkxLTGZT SjRvNUkzZTZra0VZZDJWT0VhJiN4QTtSaFpEOFI4VHRRWlpMSklrMUFpeHZ5K0ZidE1jVUFCY3dh SXFyMjd5ZG1PUjZQcTBlbGVYcmlYU2pjblNQV2h2ZFBrRWJNNlRBRDFJJiN4QTt3U1ZialRNRVlK aUdNbUY4Rmd4MjY5UTdJNmpHY21VQ2ZENGxFUzM2ZENqdFMwN1VuaXNkVzByU1Z0WHNMajFocDM3 dU9TYU5rNHNXJiN4QTtDVlZYRy9FY2p0NzdaYmx4VElqa2hEaDRUZkRzQ1EwWWMwQVpZOGsrTGpq WEZ1UUQ4ZW40ODBUcnphenJmbFhVWVYweVMya2tSUFFoJiN4QTtsZERLNURobStGZGdBQnRWcW53 eXpVSEptd3lIQVIzZC9OcTBveFlOUkE4WWtPdGN1VFd1emFucUVlanl4YVZkTDlYdm83cVpHOUxr JiN4QTtzY2FzRFVjK3BMN0RIVVNuTVFJaExhUVBUa1BpblN4aGpPUUdjZDRHUFhtZmdpTmZqdnB0 WDBLNGdzcHBZcmFWcGJobDREZ3JvVW9hJiN4QTtzTnhYZW1UMUlrY21NaUpJQnN0ZWtNQmp5QXlB TWhRNTk5OXlDMFZ2TWVpeVhXbHRwYjNzVFhFazFuZVJ5SWtaV1Z1WDcwdHV0Q2QrJiN4QTtwOXZH clRuTGhKaHdjVzVJUHY3MjdVakRuQXljZkNlRUFpamUzY3l1V1ZvNFdrOU5wR1VWTWNkQ3hQZ3Rl T2JPVXFGMDZtTWJOV3cvJiN4QTt5dEhxT25hWGRXdC9vMTA3VFhVbHdxSjZMQ2pGV1hjeUx1Q3Vh blJpV09CaktFamNyNmZyZHpyakRKa0VvWkk3UkE2L3FWcnNhM2NhJiN4QTs3NWUxQ2JUcFFMTVhM WFlqNEVJTGxPTWE3djhBRXlqN2Y0ZUdXVE9TV1RISXhQcDRyK1BMcjgydkg0VWNXV0FtUFZ3MWQv d25mcDhrJiN4QTtWWkxmUmVidFN1M3NaeGEzRVVVVVU5RTRsb2VWVDlxdERYYmJKNCtJWjVTNFR3 a0Q3R3JJWUhUd2lKRGlCSnJmcjhFa2owcnpGK2loJiN4QTtMYjJMcGUyR3FQcUVkdE1VQW1qa0xm Q3BWbUhJQnY2WmhqRGw0TEVmVkdmRlI2dWNjK0h4S01od3l4OEZpOWlFNDFTNzFuVmZMbW9SJiN4 QTtEU0pyZDVvVEZERzd4bVJuZlkvRFdnUmZFbXZ0bVhteVpNdUtRNENMSHgvc2NQQmp4WXMwVHhn MGJQT3Y3ZnhhWDNOaGZSNmpwbXF6JiN4QTs2TzEvYS9VRnNycXpaWW5taGVOeXdjS3g0bXZUWTlN b2xqa0pRbVljVWVEaEkyc09SRExFd25qR1RnbHg4UU85RytpSzFPMXZqSm9qJiN4QTsyMmp0QkZi M2YxbWFDRDBxUng4U281VUtyelBLcEMxK2VXWm9TdUZRb0NWMEsvRnRXR2NLeWNXU3lZMVp2Yy9x UW1wYUpxdW82cDVrJiN4QTtqUzJraGkxRzNpanRibCtBUm50K29OR0xBT1JRR21WNWRQUEpQSUtJ NGdLUHUvVzNZZFRqeDQ4UkpCTUpFa2UvOVNlYUZxMnUzSWlnJiN4QTt2dEplMGVOZU4xTzdvSXlR S1ZpQzhpMVQ4Z1BIeHpOTm15eW9TaFZjeitwd05WZ3hSc3dueFh5RmIvRkFhSG96dythTlQ0dURw dHROJiN4QTs5WmdoSDdOMWN4ajFQK0JRbWc4R3lqVDRLelMvbUEyUDYwaCtyNzNJMU9vRXNFUDU4 aFIvcXhPM3pQM01yemFPcFFHczZKWTZ4YncyJiN4QTs5NkhhQ0dlSzU5SldLcTdRdHlWWkIwZEs3 bFR0aEJwQkZvL0FsSi9LbDVlWHVseVhsM0hMRExQZFhaU0NkV2pkSWt1SGpoQlZxRVZqJiN4QTtS VDlPRW9paHJ2UVRGNTJzUE1GcWg1VDIwdW5hang2R1BhZUdSdjhBVmFNcFgvS0dHOXFSVzlzaHlM SjJLdXhWMkt1eFYyS3V4VktQJiN4QTtxRjMvQUl1L1NIcC82SitqL3EvcTFYKzg5Ym54NDE1Zlo3 MHBodlpqVzZiNEdUc1ZkaXJzVmRpcnNWZGlyc1ZkaXJzVmRpcnNWZGlyJiN4QTtzVmRpcnNWZGly aUtnang4TnNWUW1sNlhhNlphQzJ0dVhDcFpua1l1N00zVm1ZN2s1Vmh3eHh4NFEzWjg4c3N1S1Qv LzJRPT08L3htcEdJbWc6aW1hZ2U+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAg ICA8L3JkZjpBbHQ+CiAgICAgICAgIDwveG1wOlRodW1ibmFpbHM+CiAgICAgIDwvcmRmOkRlc2Ny aXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4 bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIKICAgICAgICAgICAg eG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJl ZiMiCiAgICAgICAgICAgIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv c1R5cGUvUmVzb3VyY2VFdmVudCMiPgogICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD54bXAuZGlk OjAxODAxMTc0MDcyMDY4MTE4QTZEOTgzMkJDNDYyOTFDPC94bXBNTTpEb2N1bWVudElEPgogICAg ICAgICA8eG1wTU06SW5zdGFuY2VJRD54bXAuaWlkOjAxODAxMTc0MDcyMDY4MTE4QTZEOTgzMkJD NDYyOTFDPC94bXBNTTpJbnN0YW5jZUlEPgogICAgICAgICA8eG1wTU06T3JpZ2luYWxEb2N1bWVu dElEPnV1aWQ6NjMyQjY1Nzc0NDMzMTFERDkzNUZDQkU3OUExMEFGOTk8L3htcE1NOk9yaWdpbmFs RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkRlcml2ZWRGcm9tIHJkZjpwYXJzZVR5cGU9IlJl c291cmNlIj4KICAgICAgICAgICAgPHN0UmVmOmluc3RhbmNlSUQ+eG1wLmlpZDowNjgwMTE3NDA3 MjA2ODExOEE2REQ5N0Y1M0ZGOUQzNzwvc3RSZWY6aW5zdGFuY2VJRD4KICAgICAgICAgICAgPHN0 UmVmOmRvY3VtZW50SUQ+eG1wLmRpZDowNjgwMTE3NDA3MjA2ODExOEE2REQ5N0Y1M0ZGOUQzNzwv c3RSZWY6ZG9jdW1lbnRJRD4KICAgICAgICAgICAgPHN0UmVmOm9yaWdpbmFsRG9jdW1lbnRJRD51 dWlkOjYzMkI2NTc3NDQzMzExREQ5MzVGQ0JFNzlBMTBBRjk5PC9zdFJlZjpvcmlnaW5hbERvY3Vt ZW50SUQ+CiAgICAgICAgIDwveG1wTU06RGVyaXZlZEZyb20+CiAgICAgICAgIDx4bXBNTTpIaXN0 b3J5PgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFy c2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+Y29udmVy dGVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpwYXJhbWV0ZXJzPmZy b20gYXBwbGljYXRpb24vcG9zdHNjcmlwdCB0byBhcHBsaWNhdGlvbi92bmQuYWRvYmUuaWxsdXN0 cmF0b3I8L3N0RXZ0OnBhcmFtZXRlcnM+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAg ICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjVFQzM5MjZDMjgyMDY4MTE4QzE0QjFFN0UwMTQ4NTlG PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTEw LTExVDEyOjI5OjUyLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 c29mdHdhcmVBZ2VudD5BZG9iZSBJbGx1c3RyYXRvciBDUzUuMTwvc3RFdnQ6c29mdHdhcmVBZ2Vu dD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPmNvbnZlcnRlZDwv c3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6cGFyYW1ldGVycz5mcm9tIGFw cGxpY2F0aW9uL3Bvc3RzY3JpcHQgdG8gYXBwbGljYXRpb24vdm5kLmFkb2JlLmlsbHVzdHJhdG9y PC9zdEV2dDpwYXJhbWV0ZXJzPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDowNDgwMTE3NDA3MjA2ODExOEE2REQ5N0Y1M0ZGOUQzNzwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0xMC0xOVQx MzowMDowOS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSWxsdXN0cmF0b3IgQ1M1LjE8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAg ICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJl c291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5jb252ZXJ0ZWQ8L3N0RXZ0 OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnBhcmFtZXRlcnM+ZnJvbSBhcHBsaWNh dGlvbi9wb3N0c2NyaXB0IHRvIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5pbGx1c3RyYXRvcjwvc3RF dnQ6cGFyYW1ldGVycz4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxy ZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0 YW5jZUlEPnhtcC5paWQ6MDU4MDExNzQwNzIwNjgxMThBNkREOTdGNTNGRjlEMzc8L3N0RXZ0Omlu c3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMTAtMTlUMTM6MTc6 MTEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFn ZW50PkFkb2JlIElsbHVzdHJhdG9yIENTNS4xPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowNjgwMTE3NDA3MjA2 ODExOEE2REQ5N0Y1M0ZGOUQzNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAxMS0xMC0xOVQxMzoxOToyNS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSWxsdXN0cmF0b3IgQ1M1LjE8 L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88 L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8 cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OmFjdGlvbj5jb252ZXJ0ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OnBhcmFtZXRlcnM+ZnJvbSBhcHBsaWNhdGlvbi9wb3N0c2NyaXB0IHRvIGFwcGxpY2F0aW9uL3Zu ZC5hZG9iZS5pbGx1c3RyYXRvcjwvc3RFdnQ6cGFyYW1ldGVycz4KICAgICAgICAgICAgICAgPC9y ZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MDE4MDExNzQwNzIwNjgxMThB NkQ5ODMyQkM0NjI5MUM8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDp3aGVuPjIwMTEtMTAtMjRUMTA6NTA6MDEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIElsbHVzdHJhdG9yIENTNS4xPC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vPC9zdEV2 dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2Vx PgogICAgICAgICA8L3htcE1NOkhpc3Rvcnk+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAg ICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXBUUGc9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC90L3BnLyIKICAgICAgICAgICAgeG1sbnM6c3RE aW09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9EaW1lbnNpb25zIyIKICAgICAg ICAgICAgeG1sbnM6eG1wRz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL2cvIj4KICAgICAg ICAgPHhtcFRQZzpOUGFnZXM+MTwveG1wVFBnOk5QYWdlcz4KICAgICAgICAgPHhtcFRQZzpIYXNW aXNpYmxlVHJhbnNwYXJlbmN5PkZhbHNlPC94bXBUUGc6SGFzVmlzaWJsZVRyYW5zcGFyZW5jeT4K ICAgICAgICAgPHhtcFRQZzpIYXNWaXNpYmxlT3ZlcnByaW50PkZhbHNlPC94bXBUUGc6SGFzVmlz aWJsZU92ZXJwcmludD4KICAgICAgICAgPHhtcFRQZzpNYXhQYWdlU2l6ZSByZGY6cGFyc2VUeXBl PSJSZXNvdXJjZSI+CiAgICAgICAgICAgIDxzdERpbTp3PjguNTAwMDAwPC9zdERpbTp3PgogICAg ICAgICAgICA8c3REaW06aD4xMS4wMDAwMDA8L3N0RGltOmg+CiAgICAgICAgICAgIDxzdERpbTp1 bml0PkluY2hlczwvc3REaW06dW5pdD4KICAgICAgICAgPC94bXBUUGc6TWF4UGFnZVNpemU+CiAg ICAgICAgIDx4bXBUUGc6UGxhdGVOYW1lcz4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAg ICAgICAgIDxyZGY6bGk+UEFOVE9ORSAxNjY1IEM8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJk ZjpsaT5QQU5UT05FIDQzMiBDPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAg ICAgPC94bXBUUGc6UGxhdGVOYW1lcz4KICAgICAgICAgPHhtcFRQZzpTd2F0Y2hHcm91cHM+CiAg ICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9 IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHhtcEc6Z3JvdXBOYW1lPkRlZmF1bHQgU3dh dGNoIEdyb3VwPC94bXBHOmdyb3VwTmFtZT4KICAgICAgICAgICAgICAgICAgPHhtcEc6Z3JvdXBU eXBlPjA8L3htcEc6Z3JvdXBUeXBlPgogICAgICAgICAgICAgICAgICA8eG1wRzpDb2xvcmFudHM+ CiAgICAgICAgICAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICAgICAgICAgICA8 cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHhtcEc6c3dhdGNoTmFtZT5XaGl0ZTwveG1wRzpzd2F0Y2hOYW1lPgogICAgICAgICAgICAg ICAgICAgICAgICAgICA8eG1wRzptb2RlPkNNWUs8L3htcEc6bW9kZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6dHlwZT5QUk9DRVNTPC94bXBHOnR5cGU+CiAgICAgICAgICAgICAg ICAgICAgICAgICAgIDx4bXBHOmN5YW4+MC4wMDAwMDA8L3htcEc6Y3lhbj4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHhtcEc6bWFnZW50YT4wLjAwMDAwMDwveG1wRzptYWdlbnRhPgogICAg ICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp5ZWxsb3c+MC4wMDAwMDA8L3htcEc6eWVsbG93 PgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpibGFjaz4wLjAwMDAwMDwveG1wRzpi bGFjaz4KICAgICAgICAgICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgICAg ICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAg ICAgICAgICAgICA8eG1wRzpzd2F0Y2hOYW1lPkJsYWNrPC94bXBHOnN3YXRjaE5hbWU+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOm1vZGU+Q01ZSzwveG1wRzptb2RlPgogICAgICAg ICAgICAgICAgICAgICAgICAgICA8eG1wRzp0eXBlPlBST0NFU1M8L3htcEc6dHlwZT4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHhtcEc6Y3lhbj4wLjAwMDAwMDwveG1wRzpjeWFuPgogICAg ICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzptYWdlbnRhPjAuMDAwMDAwPC94bXBHOm1hZ2Vu dGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnllbGxvdz4wLjAwMDAwMDwveG1w Rzp5ZWxsb3c+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOmJsYWNrPjEwMC4wMDAw MDA8L3htcEc6YmxhY2s+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAg ICAgICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHhtcEc6c3dhdGNoTmFtZT5TbW9rZTwveG1wRzpzd2F0Y2hO YW1lPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzptb2RlPkNNWUs8L3htcEc6bW9k ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6dHlwZT5QUk9DRVNTPC94bXBHOnR5 cGU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOmN5YW4+MC4wMDAwMDA8L3htcEc6 Y3lhbj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6bWFnZW50YT4wLjAwMDAwMDwv eG1wRzptYWdlbnRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp5ZWxsb3c+MC4w MDAwMDA8L3htcEc6eWVsbG93PgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpibGFj az4zMC4wMDAwMDI8L3htcEc6YmxhY2s+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvcmRmOmxp PgogICAgICAgICAgICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNl Ij4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6c3dhdGNoTmFtZT5QQU5UT05FIDQz MiBDPC94bXBHOnN3YXRjaE5hbWU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnR5 cGU+U1BPVDwveG1wRzp0eXBlPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp0aW50 PjEwMC4wMDAwMDA8L3htcEc6dGludD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6 bW9kZT5DTVlLPC94bXBHOm1vZGU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOmN5 YW4+MjIuOTk5OTk4PC94bXBHOmN5YW4+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBH Om1hZ2VudGE+Mi4wMDAwMDA8L3htcEc6bWFnZW50YT4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHhtcEc6eWVsbG93PjAuMDAwMDAwPC94bXBHOnllbGxvdz4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHhtcEc6YmxhY2s+NzcuMDAwMDAwPC94bXBHOmJsYWNrPgogICAgICAgICAgICAg ICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6 cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnN3 YXRjaE5hbWU+UEFOVE9ORSAxNjY1IEM8L3htcEc6c3dhdGNoTmFtZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6dHlwZT5TUE9UPC94bXBHOnR5cGU+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx4bXBHOnRpbnQ+MTAwLjAwMDAwMDwveG1wRzp0aW50PgogICAgICAgICAgICAg ICAgICAgICAgICAgICA8eG1wRzptb2RlPkNNWUs8L3htcEc6bW9kZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6Y3lhbj4wLjAwMDAwMDwveG1wRzpjeWFuPgogICAgICAgICAgICAg ICAgICAgICAgICAgICA8eG1wRzptYWdlbnRhPjY4LjAwMDAwMDwveG1wRzptYWdlbnRhPgogICAg ICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp5ZWxsb3c+MTAwLjAwMDAwMDwveG1wRzp5ZWxs b3c+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOmJsYWNrPjAuMDAwMDAwPC94bXBH OmJsYWNrPgogICAgICAgICAgICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAg ICAgICAgPC9yZGY6U2VxPgogICAgICAgICAgICAgICAgICA8L3htcEc6Q29sb3JhbnRzPgogICAg ICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L3ht cFRQZzpTd2F0Y2hHcm91cHM+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+ CjwveDp4bXBtZXRhPgo8P3hwYWNrZXQgZW5kPSJyIj8+DQplbmRzdHJlYW0NZW5kb2JqDTU4IDAg b2JqPDwvU3RlbVYgODAvRm9udE5hbWUvWkxOTVVNK1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRGaWxl MiAzNjA0IDAgUi9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvQ0lEU2V0IDYzIDAg Ui9GbGFncyA2L0Rlc2NlbnQgLTMwNy9Gb250QkJveFstNTY4IC0zMDcgMjAwMCAxMDA3XS9Bc2Nl bnQgMTAwNy9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0 IDQ0OC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNNjAgMCBvYmo8 PC9PUE0gMS9CTS9Ob3JtYWwvQ0EgMS4wL09QIHRydWUvU01hc2svTm9uZS9jYSAxLjAvQUlTIGZh bHNlL29wIHRydWUvVHlwZS9FeHRHU3RhdGUvU0EgdHJ1ZT4+DWVuZG9iag02MyAwIG9iajw8L0xl bmd0aCAxMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlqAAgwAACBAIENCmVuZHN0cmVh bQ1lbmRvYmoNNjUgMCBvYmo8PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciA1 OCAwIFIvQmFzZUZvbnQvWkxOTVVNK1RpbWVzTmV3Um9tYW5QU01UL1dbM1syNTBdN1s1MDBdOVs3 NzhdMTFbMzMzIDMzMyA1MDBdMTVbMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4XTM1WzkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1 NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgNzIyIDY2NyA1NTYgNjEx IDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExXTY4WzQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1 MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUw MCA3MjIgNTAwIDUwMCA0NDRdMTc5WzQ0NCA0NDQgMzMzIDMzM10xOTFbNTU2XV0vQ0lEVG9HSURN YXAvSWRlbnRpdHkvQ0lEU3lzdGVtSW5mbyA2OSAwIFIvRFcgMTAwMC9UeXBlL0ZvbnQ+Pg1lbmRv YmoNNjYgMCBvYmo8PC9TdGVtViA3Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDk4L0Rlc2NlbnQgLTMwNy9G b250QkJveFstNDk4IC0zMDcgMTMzMyAxMDIzXS9Bc2NlbnQgMTAyMy9Gb250RmFtaWx5KFRpbWVz IE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0IDQ0Mi9UeXBlL0ZvbnREZXNjcmlwdG9y L0l0YWxpY0FuZ2xlIC0xNz4+DWVuZG9iag02OSAwIG9iajw8L1N1cHBsZW1lbnQgMC9PcmRlcmlu ZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4NZW5kb2JqDTgxIDAgb2JqPDwvU3RlbVYgNzIv Rm9udE5hbWUvWkxOTVVNK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9Gb250RmlsZTIgMzYwNiAw IFIvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0NJRFNldCA4NiAwIFIvRmxhZ3Mg NzAvRGVzY2VudCAtMzA3L0ZvbnRCQm94Wy00OTggLTMwNyAxMzMzIDEwMjNdL0FzY2VudCAxMDIz L0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjYyL1hIZWlnaHQgNDQyL1R5 cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgLTE3Pj4NZW5kb2JqDTgzIDAgb2JqPDwvU3Vi dHlwZS9DSURGb250VHlwZTIvRm9udERlc2NyaXB0b3IgODEgMCBSL0Jhc2VGb250L1pMTk1VTStU aW1lc05ld1JvbWFuUFMtSXRhbGljTVQvV1szWzI1MF04WzgzMyA3NzhdMTFbMzMzIDMzM10xNFs2 NzUgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCAzMzMgMzMzXTMyWzY3NV0zNFs1MDBdMzZbNjExIDYxMSA2NjcgNzIyIDYxMSA2MTEgNzIyIDcy MiAzMzMgNDQ0IDY2NyA1NTYgODMzIDY2NyA3MjIgNjExIDcyMiA2MTEgNTAwIDU1NiA3MjIgNjEx IDgzMyA2MTEgNTU2XTY2WzUwMF02OFs1MDAgNTAwIDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3 OF03OFs0NDQgMjc4IDcyMiA1MDAgNTAwIDUwMF04NVszODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0 NDQgNDQ0XTE5MVs1MDAgNTAwXV0vQ0lEVG9HSURNYXAvSWRlbnRpdHkvQ0lEU3lzdGVtSW5mbyA4 NyAwIFIvRFcgMTAwMC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNODYgMCBvYmo8PC9MZW5ndGggMTEvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJagAIMAAAgQCBDQplbmRzdHJlYW0NZW5kb2JqDTg3 IDAgb2JqPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSk+ Pg1lbmRvYmoNOTEgMCBvYmo8PC9TdWJ0eXBlL1R5cGUxL0ZvbnREZXNjcmlwdG9yIDQ1IDAgUi9M YXN0Q2hhciAxNDYvV2lkdGhzWzU5MyAyOTYgMCAwIDAgMCAwIDAgMCAzNzAgMzcwIDAgMCAyOTYg MzUyIDI5NiAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAwIDI5NiAw IDAgMCAwIDk0NCA2MTEgMCA0ODEgNTc0IDQ4MSA0NjMgMCAwIDMzMyAwIDAgMCAwIDU3NCAwIDUw MCAwIDAgMCA0ODEgMCAwIDc1OSAwIDAgMCAwIDAgMCAwIDAgMCA0NjMgNTAwIDQyNiA1MTkgNDYz IDMzMyA1MDAgNTU2IDI3OCAwIDUxOSAyNzggNzU5IDU1NiA1MDAgNTE5IDUwMCAzNTIgMzg5IDM3 MCA1MzcgNDgxIDY2NyAwIDUwMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDE4NV0vQmFzZUZvbnQvWVJJR0dPK09mZmljaW5hU2VyaWYtQm9vay9GaXJz dENoYXIgMzEvVG9Vbmljb2RlIDQ2IDAgUi9FbmNvZGluZyA4NDggMCBSL1R5cGUvRm9udD4+DWVu ZG9iag05MiAwIG9iajw8L1N1YnR5cGUvVHlwZTEvRm9udERlc2NyaXB0b3IgNDggMCBSL0xhc3RD aGFyIDExNy9XaWR0aHNbMjIwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMjQ1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDYyNCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ1NCAwIDAgMCAwIDAgMCAwIDI2 NiAwIDAgMCAwIDAgMCAwIDAgMCA0MDEgMzU4IDUyOF0vQmFzZUZvbnQvWVJJR0dPK0NoYXBhcnJh bFByby1SZWd1bGFyL0ZpcnN0Q2hhciAzMi9Ub1VuaWNvZGUgNDkgMCBSL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNOTMgMCBvYmo8PC9TdWJ0eXBlL1R5cGUxL0Zv bnREZXNjcmlwdG9yIDUxIDAgUi9MYXN0Q2hhciAxMTkvV2lkdGhzWzI5NyA0MDggMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MjIgMCAwIDU2OSA0OTkgMzgzIDAgMCAz MTkgMCAwIDAgMCA2MDkgNTQ2IDAgMCAwIDQ0NyA0MjQgNTY5IDAgNzQyXS9CYXNlRm9udC9ZUklH R08rQ2hhcGFycmFsUHJvLUJvbGQvRmlyc3RDaGFyIDQ2L1RvVW5pY29kZSA1MiAwIFIvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag05NCAwIG9iajw8L0ZpcnN0IDk1 IDAgUi9Db3VudCAxL0xhc3QgOTUgMCBSL1R5cGUvT3V0bGluZXM+Pg1lbmRvYmoNOTUgMCBvYmo8 PC9QYXJlbnQgOTQgMCBSL0EgOTYgMCBSL1RpdGxlKEJsYW5rIFBhZ2UpPj4NZW5kb2JqDTk2IDAg b2JqPDwvRFsxIDAgUi9YWVogMCA3OTIgbnVsbF0vUy9Hb1RvPj4NZW5kb2JqDTk3IDAgb2JqPDwv U3VidHlwZS9Gb3JtL0xlbmd0aCAxNjYvU3RydWN0UGFyZW50cyAyL0ZpbHRlci9GbGF0ZURlY29k ZS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDAg NTEwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgNTA5IDAgUj4+Pj4v QkJveFswLjAgNzkyLjAgNjEyLjAgMC4wXT4+c3RyZWFtDQpIiRSOywqDMBRE9/mKu9RFk5v4oiAu 1CCWuvLuShdSH0hpLNUS6Nc32cxhZhgY0b8HA3kuroNZIJjMqSlD0VVtDZGEoijrClhJDLmKADkq QIcsgycTTY+w7EwQIUigmSHQw/VknQDtINHz56OPM37qESeKS5WAOnNM0hToxW6BtTbM4oBP47pv Zt6+ZhyOdTPcTIdotQ7vdGGamO7cob8AAwBN2yypDQplbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2Jq PDwvTGVuZ3RoIDMwNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckc1qwzAMx+9+Ch3X Q3GSdQ6FEBjdCjnsg2V7gNRWOsPiGMc95O0nW6WDGRL9jPSXLEkeuqfO2QjyPcy6xwijdSbgMl+C Rjjh2TpRVmCsjtdb/utp8EKSuF+XiFPnxlk0DcgPci4xrHD3aOYTboR8CwaDdWe4+zr0G5D9xfsf nNBFKKBtweBIiV4G/zpMCDLLtp0hv43rljR/EZ+rR6jyveTH6Nng4geNYXBnFE1Bp4XmSKcV6Mw/ f6lYdhr19xBEUz1TcFGQIT4yk7DZPWQmQ7xn3hOrMjMZ4h3zLjHHqxSvFLNKzFqVtVxLpVqKa6lU q77PTIaYc9YpZ80565SzrpnrNrVYFfzSIrd47SU1SzuB2yT1JQQaYl5cnl6am3V4262fPZAqfeJX gAEA6duTLA0KZW5kc3RyZWFtDWVuZG9iag05OSAwIG9iajw8L1N1YnR5cGUvRm9ybS9MZW5ndGgg MTY2L1N0cnVjdFBhcmVudHMgMC9GaWx0ZXIvRmxhdGVEZWNvZGUvTWF0cml4WzEuMCAwLjAgMC4w IDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQwIDUxMyAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDUwOSAwIFI+Pj4+L0JCb3hbMC4wIDc5Mi4wIDYxMi4w IDAuMF0+PnN0cmVhbQ0KSIkUjr0Kg0AQhPt9ii21yN2e0RwBsVAPMcTK7UIKiT9IyBmi4SBPn7OZ Yb5hYGT77iymqbx2dsJgsIcqD2VT1CUSZlleFgg5A4noiCQo8pSE1vgEWbWE0wqSmVAhj0DID9+z 84K8oqLdfzv6+LBPd4sTJXSsFUZnQcnphPyCW+CcC3UciKGf18WOy9f23TYvVthhk7Ux4Z0vYBhM 4x/9BRgAT8gsrw0KZW5kc3RyZWFtDWVuZG9iag0xMDAgMCBvYmo8PC9MZW5ndGggMzA3L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyRzWrDMAzH734KHddDcZJ1DoUQGN0KOeyDZXuA1FY6 w+IYxz3k7SdbpYMZEv2M9JcsSR66p87ZCPI9zLrHCKN1JuAyX4JGOOHZOlFWYKyO11v+62nwQpK4 X5eIU+fGWTQNyA9yLjGscPdo5hNuhHwLBoN1Z7j7OvQbkP3F+x+c0EUooG3B4EiJXgb/OkwIMsu2 nSG/jeuWNH8Rn6tHqPK95Mfo2eDiB41hcGcUTUGnheZIpxXozD9/qVh2GvX3EERTPVNwUZAhPjKT sNk9ZCZDvGfeE6syMxniHfMuMcerFK8Us0rMWpW1XEulWoprqVSrvs9Mhphz1ilnzTnrlLOumes2 tVgV/NIit3jtJTVLO4HbJPUlBBpiXlyeXpqbdXjbrZ89kCp94leAAQDp25MsDQplbmRzdHJlYW0N ZW5kb2JqDTEwMSAwIG9iajw8L1N1YnR5cGUvRm9ybS9MZW5ndGggMTY2L1N0cnVjdFBhcmVudHMg Mi9GaWx0ZXIvRmxhdGVEZWNvZGUvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNv dXJjZXM8PC9Gb250PDwvVFQwIDgyNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRl PDwvR1MwIDgyMyAwIFI+Pj4+L0JCb3hbMC4wIDc5Mi4wIDYxMi4wIDAuMF0+PnN0cmVhbQ0KSIkU jr0Kg0AQhPt9ii21yN160UhALNRDDLFyu5BC4g8ScoZoOMjT566Zj51hlpHduzeYZfLamxmD0Rzq IpRt2VSoEszzoioRCgYS6ogkSCE5pCk+QdYd4byBZCaMkCcg5IfL2TpB3jAiz5+3Pu7wVY84USJy 39VZUHI6Ib/gFlhrwzQOxDgs22qm9WuGfl9WI8y4y0br8M4X0Ay6dYP+AgwAT6gsrA0KZW5kc3Ry ZWFtDWVuZG9iag0xMDIgMCBvYmo8PC9MZW5ndGggMzA3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiVyRzWrDMAzH734KHddDcZJ1DoUQGN0KOeyDZXuA1FY6w+IYxz3k7SdbpYMZEv2M9Jcs SR66p87ZCPI9zLrHCKN1JuAyX4JGOOHZOlFWYKyO11v+62nwQpK4X5eIU+fGWTQNyA9yLjGscPdo 5hNuhHwLBoN1Z7j7OvQbkP3F+x+c0EUooG3B4EiJXgb/OkwIMsu2nSG/jeuWNH8Rn6tHqPK95Mfo 2eDiB41hcGcUTUGnheZIpxXozD9/qVh2GvX3EERTPVNwUZAhPjKTsNk9ZCZDvGfeE6syMxniHfMu McerFK8Us0rMWpW1XEulWoprqVSrvs9Mhphz1ilnzTnrlLOumes2tVgV/NIit3jtJTVLO4HbJPUl BBpiXlyeXpqbdXjbrZ89kCp94leAAQDp25MsDQplbmRzdHJlYW0NZW5kb2JqDTEwMyAwIG9iajw8 L0xlbmd0aCAzMzI0MS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA1ODA2OD4+c3RyZWFtDQpI iUxWfVST1xl/nnvzvvl48/ESkrxJDJCACWhEkI+gEuS1KCIK1q9KqXEyPq2gUBGcHRb1KGunqD1H 7ba2m7W1K3ajJeICaGVnbB3b7OY/uHPm7DxF61Zz3FmBOTVkN1jPdpL73I/cj+f53d/zuwEEAB10 AoVn16zPyPpabP8uwJl/stGt1U1VzWO2e48Buv8EoIfqtlYnp/7pJoB3ngVQnqprrm/CyqHXAT64 C8BdrW/8Tt3xt+psbO0NgLrKhtqqmrGgRgfQG2JjvgY2oF+gHWX92P6zG5pa9xzTfvpzgI9MAKnd jTurq+iNw6UA9QtZ/42mqj3Nhm00CnD9XTbfuaOqqXasyNUC8Cbzh0to3rmrdVdXOpt7fST2e/NL tc2Bxn0W1h8H0ISBoIPNc3DAolNC4QWCD3hliNTJ8cApHlDQKBUPEGwqnntAaAhLg+p3bli94pQ/ 4i8XJ/xlET8Usrb4mJkFma44V5ybGXQo4LGTDj+WOXgETsUw2/3b0VvcX7ntkAF+KIE/Byu9iCHs lZM5UoBwcV5GAWQ6CtIUhuTiucoMMo83AqIhb00yNQ7RH4AZtCjLVvUSQ9ESs9mgLu3ML8gplSQ7 5mvPyUII9weV55xzQ9jSn7Y203iuOITu/oK1DndRziUshUyiAgft6Vu8JSmEKlmQy60y28BqW9k2 gLlg9bJovGXhifBEZCosTk7cFidtU/aIlZXx8uW1y+54WZxlYliMjIvjhWHjogy/UVoUx4oYRnES ZuyCTAygy8zzSl5pyc7Ky+b5lGRP6ozNzcnzuT2s8mVnWcwmXmmUfLk5nlS3Ly9WpyTzZpNFycds dpYvz0MUuXiyYseq6qXtr21cnu4/vHnrkeU7R/f2//p0NWZy3NjpuvYPb5Zs+5EnOwpv5K4sXlhS ozn5y54z+1e0VMvt5FOPtqTx+MbRletWrtiwvuTS6eD3Kuo9RY4/3GvZuH2kZHpsdKjZ6qRXl+av q5JL951I3thXcq1533ve4hp8BgCjX01HUYQLYIIMWQsm0/1CPb6iR33cILaCgvT/ApYINnPT5Ax0 ZffGw5ARaAmLowsylTMhpXo8qf8XrnlVxmxekUmV+WlzCo8cupWck+Y2GlSZ6jiLd8kzWc9fzAIE H+4ltRhlbHEE4SDBEI27yBGboqk7dsp4mTgOGRGGstKVR2rnRB7OweihQ2zd8ujfma9BECBxgDH5 RB8vMLK29qtt2qcOhqGQrcybcWbmOnw93nz/3Ln5+cH8mGUlFvVQ9BbVcd3Mg2I5uR720PeBUkbE OYSaCIk1CQo0AHYOA8yxQbzH0PjmhHJxKnaMv9Dfxc33dnWMzPABU5DqInwFiXLdD9dzPwMgsDd6 l37NNYARZsMRuTzXku8s4UuVKxPXJK12bpAqnTWWGmlH4o6k7c42wy5Lq7Qv6WXnAcsh6ajzpOWE 9LbzrPldyxnpfGKvc4BcMPdZLkiXE684Z8f/h+VyCOtlu0ZnO9+pQ53NnXy+k/6Rfk7v0yjlqN0z iAlomXF5KhDzeSIQczpcGJ7xNoYPYfT9hrLGPJ+UzBMlmaFlni/eGJfjISOdvQfattT71xzoraj/ ybaDi9tfWbyqUi7w7lp3qJJrGPvyN9M1p9tzE8fu3v4S9Uc257ww/bcvpq9fa6hPa0QOz6Owcxu7 tQ52VZsYCrPgd7JdacfnSD1pI630so5TgUqUUDIoVAZ1CBcGVUrklwq4kGmUHc+CSPSQBjbWt2OE SZVoQAqqNNFguINgQiZYgzgBdqqT1bNmAadSagGHaBqIYCdCMMmAhhBNlQURHWwMJXRoBkkafsFQ 8Yp+r9fvFYfROxUY90/6Z+5TnAh36ed7O8QRbyzlrSBOhr2P8UnaDz+xMfgC0IIYS2GJMdQ384l/ mt/KVDfdNP2JI3uLJhLRr7PPNbuS75oJ9bjseTpcyzU8+nH1PHeq0u0mgjFxfjt1rxRM8Slp2tlb GFZOhtUwwyoB+mXXMdVh4U3VKc2HqvPaK6pB7Weqz6ya+/Qfiq8s9yWFoE24zDCyMXzawYELZXMC lawKC8cuMZ4aeSopLAoUQoTIWvV5A2ez3mHM12qvEIk9B/+GRODRBQmE9BntSYM4hfefsKVsPCxO jTM8xIi/MDLOcMAYGOw7P3wPxAiKox/zpGhDhaw2UEGRRGcpFBB4fkEmBDDgcuVC/FMgfE9EIUYz dDGxyya/igSI4lxZZ93RF1KyR17a/1FS5v6R6QHcsO5FKc2NI4jtBxsOdon7j328r2LV7hM3pz9f toh5DctYJp1huMyHqwNgig7LxXGOwkB6U3qrpyO9O/2H6e9pPrD2pg+RIWW/ZsB6JV2/Bb6FpNa0 20Q4ojZo51CeWuhs01vpPemfpE+alQqTyURMg7SbbT8RRNQnD1LGNmzsm6UTLuFp0BACKtbVc95L DCiJ6oBD10U5DjPiMO4Kvg2ZoGH0E6iBqYUUzEjCpEtMMjLgt3QzxB7PwMQEg5Kp5URMlSbYexJ7 UMLjgRhWLS3YEvBi7v9443uqoZaYZZn5ja5KiYQ9FWySBxf9q/25mhXNm9w5Z6vaXn/1/YYXjz96 bd9Sb7bbbhc7it2Vu9f0kNsJ7u2rt62p/77Q2n60cXNPkfdMS8ejV+clpqVkqbhi6Vrb1lMBpk4y w/Q2txo0oMNy2asX8GUBDUSlzQafIk/Ypeniuvjf079QjVpQa2s1uzWKDRqs0yAXit4MSrYcntWy nzVQS9jfCBUFTqmiAq/TEoEHjrvDCywOQaNWP9QKJq1apRVU/+W7WoObuM7ovXt3tVqtZMlrrd4r aXclv6SxBBb22FaweLbhZYaBTByilGTCK9gYx0BSoISQuEyhCZDAhGd5mEKKaEljbORHnaQtebUJ M52kTOi0hZaktNRDH65boBL9dmUc8qfWSHf1ybOz99zzne8czsSbLSxNQF6tRdwA3gcPYqa6eojR yCAg65GUyVRuQrShnLGQAeoU/ExRVDfiTKYsvt3LcwhxDJMl5T0c3Jrj+gF9I4V7zBaLmecHSAXi 4H58ijcUlfM2g9NQZHq/D9/4SsuPRDZcwa4YnAWMeSjjWGTD36EQ0a9s2m+w/A0WaIOIJg0R2zAq 1sxALvm53g3bjFURBnRiW5VLkwsr/IEwRCJPt7en4WwxrmZVopbItZhgmXyezx0PnVj56lN5RyWJ vZLrw7uZOf99cVN+D275LmnJ53PfBo4/COfxKZyHgt5JtRkUoY6Gt8xGgnE2GZzPLDDMZx9nnjA8 wbbT7YYOdiu91fAiu5vebThKdxl66L6gYzONjT6Xbzp73PAvAyO7HMQvYCpkdHllRSQ0fVtBdkVB Ck0Q7RdooihFFAEppb1Z3HK+yCK4VX/GOEhxMK/e16eHbRRGB6Awd1izf4CAUFADTSa1/Wuo6KU6 3SRp4tiO0pEIllmZdTh1IrP3URlKY1wuo2z4QlV+5ezjj+xYvnfR2vVLG8oTpZOmlHtEqX1o6aGt zJzvn/LMXverHVf3RZNRf1WoepLMc1fPfeuNrxcBK56/e51OgCLYAa+f9hgFl0C5ND7Ocdb5FWed ItaQanEqmSo+5dvg28pvce8MvMLvcR/wnyBnLcccGf850s32OAZ9PxcdRq9TdHnJdLq5mAI0RKfo oYOEQoYsPtgdDJrBwC7vRYznltkiZbGc4mNcI0dZuQBHcZq+chcxxp6QM2MdpBBSYfIm72EHw3ck nS5MXoAvVwxA6YhVVyPNRIEIAFwgnaIBsQUBQPpMFlBtDS7MY6FgHOlEJj/0zZbpz3Xnf/nm8VND eMbZFXmys2Vmx3trF6iNzIqy8vzdD6qyh27mf3Tz8Ed4J/ZPL88dy1+8uGojbvrt+i1OTUmvA25x vetP9CH67tvdk+cnoKH1ldZW9QH9e8oCF3VUPainiaHpLD6cMhPKTghFExOFTPq+GYPGHlDGfpi6 HF7RGzBhk5unB/Ed8FOliCEbz+EAhalBaFMzJRRwGUknQRILlgS4pTHrmgD8GWcV1pEBXDQiibgM y4qBVfFLVFfOOJ/anx/qfDxVwcxRbg+F6aOxxeDi5kHv/BnY4ATmxtGFPhQGKqy01bHFq8ydzk43 7WbqLXVlD1pmlS3ET+I1zLrQxvgLuNP1Qqizcnv0CH/QcsB3sHRv5ffip20ZX1foB+Gz8TfwoHnQ 0m97y3cjGgy7zLBTq75E/LcEJnLLYJEzyGqzUtZ+OPZyfDzFFzjhnlCVIf34H8gLNUujuETcIl4R adEzEbRo3JTlRgsY5EbH+FE8Nmq1vUMTYceXJrb2/khRM54knF9GCShR3Uua/9Pb9dGp682N7722 q/fVD1ue6Ug3r5Yqpb37t61++tBi6t8rehd3/fPdF9svL219eWbn2yfbVp+zhV9vXbZuTfO0uoXX Jt/Y1tp5tG1hH3RYA2A6rGMaRu/0IRkQneus80Jz0cq0SfX0EP+hm7B+l8vhJw3MbGZZYJNrfWC7 d6ty2HXQu0c5w5zhTxdnXBnfSWWA6QkIizTLZnB5XJJBZWgEju/geVVF0i0ro3VYSkAWT6ZNuCJQ gqfMigOYCkK3dV8xYzOwracNmswNvnb/GIQjWmsNpwtY/t8G05jk1CZtTe1YSEM6lBQCZ1LorkKn 1TQsn7Pt0sIHple+dhTXnj1yejA/9OOVOPfSqq+t/1nbwtKUK+ionHV5l1/4+Ds38UM3j/4ivzb/ hxkVVDP2X219Nt/7x2c3OgvOf5hyk+2QVJyotg8ZIKsg1pyFRdAjy5tchxUWIIwYECnR7Vo9f2xL wIp7Nv2+EEPuu8bdlUlINMnk6cr6hgrINGR7Q6VeashFGyorGrQiPEMY/4Z+lHRAd7Ao0YOhkiZZ ciBVxNBpAxhtD4dYt7G/D08qwJm0jSZRLDk3lxwdTtqSE+Ilsqi/wnTtnQ+0N+lYMLIA7vMupKcM swqUtwqdTRWzbtbr9H5s/MzLMNEiW4Jk737SbStOKPoqaOvvUqV2V+It+jLzWYAcok+RM9xJhXYH HyXL5B0cHWQl+zFTnYcAD9pTojqvgmMfi0mNUpNEJE+8+ELRNGcWp7qj6CT8R1uKL50XizZFqag7 dmT8+UFNwG+N5K4VIg9Yri/Av2qzSffsupyA0Ko1Neie59J6ZxzXMbNKG74C9orSosewEA2seXjR JL8cV9UJmT0HfhKtzw9uWFw4hwY897ksVpsbpzW1huySfaZTqZpY8fCuH7Y1T33o96fzlxoiWvCM wJncPYQQvURHLox3p54nInLQLiIbFZNqCLFmFcfURrVJ/Ybapm5WX1YPqAPqn4KjQZ6RGZUJxeVq JR6aIc1QFimt0pPKstB6+zrldeUT8VP5kvrrUEmpErfHxQkSXYGi3pgvJtFlKXd9ojRVUp8oCauC PaSqkEeUoEngJZMky1nKm5qlyH5J4rBR4nyiV/KpoqjKil2WFVVQRcFfiFqhsD2slpRwCiKSz2cy cUaiFCuUglRZtIdooTQuYlGbH3x9QsySqefVzUrK7dUOX68pWTK5B2kVNFZBWTw1ZcEpW33CimO4 CaxSlszrKd2hKijYTx4hi3XXNpKOjEQio5HIyBeRtCaPcKBpLZ7Aq1GzJBpZtclh1PxYERgyGi5c 92c2+DT+dfwbW2RLsowtmWSTSd20ATeQFunaMdE11VENsa56op7rauWCwupJr0a3c3RgudFaMmUu n/sL75xSIdl4ky2/aXvMlUjy+TZ+VvsaUtmVfwYvYlbd2dfkLhclXzjsK4kGOs4MNNa6glVUOPw/ tqsFuInriu7btSTrL+2uLGk/sj67+nillVeWLYsAWuOSwIChLUkIHyUD2JBpO5QEcBsTahMS40An mdDyyVDK0CRQh0lqMDLGkOBC6EzTNkM/k07TNqWty6dgcKZuZjpgue+tZAacyOO9u1dv1+t7zzn3 PCK/v2JRsX/iOkZM/hZi4jScyAEsjmXAAbXdADduOBmvzYm52sW1K9LfqNtStyH7/do9poPRQ7Vv mt6NHavtryiYzornaqnH4x9U4MFMIhGnGJqnAIvxIJ5I+BiWZhjWWC8kZapGBhk5CA2UnAy+CnsW pABOVQYz8QTTGGUZh9EYSaQGic7+HJTaITAHixCdBb3qJJHFH+53eGAE7kI2/l7in+wgMVe1kQzq ZB8zzFxiCAYuKjjraxnADIKNA41Gxs00mobARuCa8t2InlJeal75xGmMgY/knDl0V3/YjWJXf9Sj XQ8k4LXqzCKqSstAy4hGZklquT7+zHUvcuDoadDCI8OJeXI5mMlPjDq0H2QgdLI0vfkGh9bm/IK+ 6JIFfZu/tvyJE2mvODh5tbFxGbagT4LJ2TBZEKKhaDDaCLMgD99TtdQGXdlUMJCNwF/tdfIgE0hV 3bdFg842oKGkIVPe9FLlUQy1Bdx3mrSBkY5zT/We27Lp6Tc2fv3dot26iIs6PdH/VGdanGeb+Eu/ er5HaCz+5FuzfvTZniN+WRcRF/Ys3PxeQt6/om1wrccp4lYnF+4h6p+uEaWJj/BCz7qNljsrbGcP b9lJIF+3c/LvusNQWSLYq6ogOJrNzY6V+nXmTaZ283d83Y69jqPYAHbSYj1C/oLE9XaAD4IW1Vgp 7K6si/gJ1yBOnXK2eowYYjHhO4H3QKGdcyLSg9h6ks5i4zYIEJXk1EcWpDmVzh7iANcWbdtakl7U ogkJ6u8IpObESG7m6E3HiLbNhVUjQhGZQGprKHuVTJ2+IhQUkMsV0KYApXSH24QKnTBvfXN/97FV X70yuOtP+eT64viZI5NY9y1w6PdrtjR4PEKN7pvF+etnPjk3snrryNmfX7zx/LafvbXr7mufgjfH kjSdhBp7AcN0b0A+MVgC+9tpjJu8ptY5IXKWss9FOqRdkYJPb6VtvBWikwcsx/loF03TrpBsjcsA t1bSctRFO2JDRCemL0FUPwTcWBJ6YiOV3ZAESfYP3BABMBcx9yRppwGNUC8baTctfwH1z2iQpyHE 4XPoMtRRVM0Q67TqydLT8Z6HYtdyvQR06I4hsqd88QO41hwyRKS/gnTRNrxiGhR1QJMtWFsh01Dy OCBuAccBBYw/XrHxVvHflybOWxezUYoXxrj0QtBS/CTgIpkZB4H18Y7dl/9YDzH4veJnB166s29g qYhbnHxNJ5FelYnUhO8an2UdPp2xSc2Dhy/d+BfE3+TvYNXtsOoZ0KseUb0nvfhL3j3et7zEDq47 spfblzjKHk2cqSiQBe5UwrSOa+e6MUJnp+3zvUSdykJP6cp6g5RrNsMCux0DdocDM8RttqcqeQMv wAElpzOZ95O8rJ+H46t0vJ590e0eY3i2Ig7iosTHMYfDB4eUIIgZOY7LNrvdFcfdMl8pNEZFwaHv NaghMpc0AAPXy6puT5qFyD7FP5Jmd8u7E2jHU8Vw6UOJ2wk8wWTxtyFp37b3Yq87UKtFrdUCENA6 M+1OC7BrXehaEzzBLZQEb8YDgieVui+UBE8YLKFAKKMARSR4AgTBfQAYvzJ+BTkYqWX8riSNJPPS yBQWRpHezfwiIPLy6E3M8V/wQNC+KZ1q027HvY2VVB55kJkaGYkQQkw4FCqNv7pS8kE4hTIBbVkk HAmH8H0HOns64uKuKBmatXrbdsrr/Mp3L9zIi113rlkXsVGSFW9x9S0uC/HRo6KBCTbVvqMjJq4t 2VCkZ8eltLeYawoytG3nseIOCCySi20nUmvSYUksnpar6wXZQyJFe2Xysu7XUNEasAvqQgpKjmDN 0lllvrKcXFu9ybjJ+lxNu/SiZW/1AFYwDrk+MX0cdbIBjmcZ0gtNYwo3k06nLxigg057MMAyTFK0 49U4jg8SuGox1NXtbkgStlbRyCKlKwteQw92BpK9ETNDtbPH4F+NIcWLtWXaVmpSh5TO8TlSOtSP mTcnruTRXJq5o1KWbKjEaDRNIyqGmFqqcshP6J00iUpMaeVElTWgUWIg0N5EwKEowrLfk8XzbWHj O/uLv7x48PyHqWXL17iYmic5M542tTzsdYZbX/5p/uPi550//OsL/Rdf25ys8oY4qJCPLRBW7yv+ 5WrxH+8Xb5LVID9PEig+EgHBGPtCsfehyGFg3N4HZv05t7SWcscRfz/EMP1WyN8m6AgtpCdop2bH 0MEOzXs/jDlk4l+BJ3SQzg6IV1N4t6lADzDEkly7qT1GPGrf0IyDgN+PY8GmppDRBExO6DG9fob3 1igSX2OcAWY0PcTPMOLQaHpIN++JhaJ8LJtq5KGlI31+nIY3N4VCPiVFK0oKYMFAKAlxgHlmZLPQ cOI1sZjX66lU/HOiuD+lOMgmC6QmjlOYH7yMheB5ipiLkZgCeV3XkFZUsV5BJkOS01qMxrQI9xf1 CrIvXUqfMqxcUi4rY4pegUxWTXOMfrfi9itzTPDy+Lc1MkM2l+mMPpDRBUWtEnPao4yQ14rqI9GV Rm6lTO7St3ZfTumye7XsKUh1pcuT1V7FrN0xPEBSs5Up/S9/kAqMjo+MSsjgQtoP3/O66KgZnrLh tU0ZXtuXGN5px/yXpAxlVfigtD/Kg6l/8DRmn/z0hCOLeg6DGYbjVMkDBaiSVkDQhg0l1E6545Ja BKYnpq0H/8OfXcN50wtNeNAyN1jrDgRv++pbzRNjtkVMlGTCHRO7tvDp1sqJm9bFTJRiwmO8t77F grvNzf5klU/Ab4PFqxsYkRRFYHcFku13f7M2Ho4YRE1KItvBoeKqVvleIraNqGtNl5fTgXgHxPow hhHzINZ94AcnQdCerULYViG2sWq7H3/M/TrVzxJdfoAbCR43koD0UDwJvNAu/J/yso9t4rzj+D13 jn3PnZP47jmf7fM9Pr+dfXbsJHacRGZZcqiUMBJaVmh5GaGFAmXQqo0q3kqBbNAXhgYaq4babVJF abeu2xDkhRTx0k3Qbv9stOs00UoTaFRa1UVbV2lbRWL2PGfnpaytNCl6njvf+c55vp/n9/3+JMGH pWAoFIGCAqEgSywLeGhYAvQFzxEQQwRCgUUkOjdCA7bAffAIrINEdUjUPt3UTqczbe3QTqVL9NgO WO1D8A14BV6D/yB3Ehag3Sh1Q+orBoQBaDi+gub4CqnejlDUXGw/tGWxB9qKlwxqPRkCDT1wGk1I 0aRnw1FEZwdRWEPU+ZwQ6vy0dLn6JX+iB1JiYY3S2tztzAnnfMiGBGVoW4pz9ZTyGXznUDw1Y1wE 3mlgP4fTgdlAMzDY1GR+Pjs11FTwqTj1TsPycM4fS/wtolE0vKJt5FvMj6KhTpOqLkVadnHFTSUt iRzVF++b/N2gEUogov0F0m21EO0tAO02iIIWK9+rHkkdSh+yTjBnmLGwJ20BnsVV0SVY05uHCs/D RNQaB247Fm0GRHrAW+kE48ryGQvyPuZVxvJZUYuzLmVD5wkH0ClGPBEyA/kAn3FKyqVZHZ2Nxlc1 4Z36FKSzkwn4oWomcIoBSQODS2prCeRAmYTCLt/EhFT+kjV1jJ72MaMkqSjdofFbfz0tlf21Yk6B P03m6isGYrd1MWmy4vHpze0EAucqCQWvTaKGpeGsYiT+HunslwQvm+EH7tLkzEfhsNS1/8jy7pLe qxENRBk37+TKm1pTWWCayUz4u5N/XJMMqo3JcEdkR546znmG8WwgShRYfTjEAkD56yIc3wdWR1g5 zrfj3vBCvFJfgR9iRmJ/wv/GQlp/E7Ob8NN4DHMpDPJxn9TNtJIhQo9Oudk7lq+000KurRjGBS/Q AXl5xAUiea4VS0oyjVOuVlxAOMVzBdbBsss3dZn8Xb4skYWlTu74d9j+ZiFP7uSgC3NIUzBK5ciX ZUHCsmkksckAEMERBQMWk1IgRLSwomlh8k8k9LCi6+F8LpcwIophRGSE9JRpYqzzBYZjWYbFOuA0 QytaYS1i+AgVJ0Zoz6vRbXnHT0oaRSGIS855ZJ5zflpp15zk2SCVoto+7UWN086zh5g2so5LmBxx LtGwfVLJsL31JaP2AKP2QDrbEnmSsbeoBYyAZhSFrhlr8005+3XixozDzToPkChsc9zHN9d5XMR5 6uZaEIlAwf/tU75oXDWTRCmmdqMeJNrjOBkYOlAyGRKbBkjDEvO7p/c/pZHUB0okwRUkuBm7cSAF qVS6kz24h0Og72EU64zeVMOpe4Jw6rIQ7reMQu7a5IfWvn8aHZvFynwx/GAumgDpWNfXhbr+m+dc C0yPp/6uRydP9DWlFWyaqm/V85x885Tr7snXt5omtZRicif3STzoMSnBb9267g4SgjNgvb3NgwKy pXTI81ILmTvlXv9mdhd7IiguR9uDI0FuPwCi7MWi08pkTBJ8BBZiQVfDWKcw0R4UsIqfIoRkBQEG yWYymVBpyfNnRFEQKDm8gqCKspaM/KoPtKBxrttWFLtTJ61kMdRjK48pQ8qLiksZ5/LDkHme9ie2 qNIbVHqDSmFC1PDeGM7kS86Mk85sh7T2HvVudZ96RD2p1ql7sxAF1ABSs3MKF81CM6CAiRtNpE9p ApUbc8NKTw2WGVD4/5OP6j4eAVHYUGKaCCfMAHEGAOZUp1qWSIDb0kZV/z7w0l/0Uq+3XgQj3gWx lkA0VvlVsvLVj8OFNULlPlLBMgpOgvr0qrUiEf4qp63vMGmdcgLFtpvHXTsnhx9om84QOLeXO9mV 54jmLPPEret1F0hX4mPizC9Ho3FisAEaHxaRg1Jonj4vviC0SO+LL2dXNCxT7vWvxmsjG/1b9C3G dvSE/qTxlHIYH3M/h36kv4BH/Bfx+UjY08AjVmpjOK2Nh4Fx0nhIXtJ4eO017V67d0PJuzERpZ8G XXZsfo+L5FcyrGl30WsuO9TuGgeBscdIM0pbFN/AvxxxSJNCR9qkTJCdNkh1KhKUFNaViKdStMtI BuK08SALSDuNDpmsLvfxM1e2T1U2v/fjP2w8UwHRoQ0Xz/WtOXrsGyfv33H8aN3WbR/sfq8Smzx0 Y+sF8PinT9sPXh+79tbh91c/chC8Ov7s2wx76/fEX/9D9oROHLZkh9ysyvbGnjWfi/3QfNnzSnTM MxoT3ALIUuLuD80r8cFM7CuxhXUrrN3mS+xrsbH6s7ELpqjGfWUp3ujrxpYgYMsSZZXYMRPQMSOJ xJMtUYyoAbI3AgKPjVQzw7cZhsSwssQLOKFmrIDqS5zl9jEuEBjOWu+KZ4kjB1g0Ig+pQB13TFkN qFVT/tasKQ84rqxWXVmtubJai++qHXS2zqhcVmdSezXpEI9e8uG0RZdp1ewhUX3CR1xadnz6C7j3 NJBN5WnocorhQBMzOABiRaKSm6iUnoG71i2m0ohKVd0GHmCz6jtXDlQmj6393sOpjk3C1AfilmWt 16zyujcH73xkeOOTexesq+sf/fZDv94Vrxw+kI1m3ab5tZc516GWRHPd1C/w6pF1G7dLhOpbbxPV jhPVUkwBfMfew6sw3ZVdxPRnFzetZrYwu5kdxq78D9wv5H+WfT1wMXuxWXrFPeJh3bqqH8xzXLpQ cHlRPfaKLgGLmhLCWipu4lTB5YogRUFIicXjEQYopGrGQKalWcs0A8BobMrrFUWGj8cA48qhoqUg X46qFqELny9FqAB6pDqjIJkp6W2grfCuiwqqsGgU0QCMatkWOfGUSIbsxlA3qoVXVNMPzQ+WkdN2 lUlEdw7pW1DtLc4l8pYhBBAlpEgKICreHtsG5sbcmvbOnpvVf9Y1awzI5c/0a19aA5/xde25VKt5 pJlKV13vtobK01mlxIPIDvAASkUVCm7Z1f6l2wJYXQ+nPhEXaxkUTUwE+xZ6wdk/X/rtyQOtD2wV p1baxZ//Zs+eaI79PvBVNi3tzAZl3jQ5r4RbdnBt9+SbbWD+9OD+q7jy+NGVbpN9H148/Oh2nqjH NPyX7qqPbeK8w+97d/72nc+XO9vx1/nO8Ud8uTs7tpOYmPgKlJUEmoTwzUI1NQKalqYEdYIyBoyv wAatYNEQpTCk7ksFAaGUUMoQgv2xif2xqZrUaZNAQi2dFrE/sk4bxNn7np123TTf+X6/9733LOt+ z/v8nmf2AbUK8V8nXGkcONCyVyc20BuYDZ5heoQZ8Yywu+jdzG7PTnaPukc7Tb/DnPawaZChC+oK dZM0pH7HvpMZ1Q7bD2YOqm+7TzGn2PH8z8EF90Xmouc8+xPtF/p1+Ev3R8wt9or2gT6tRX1av6vP PUCvV1foVivv57vdzzHd7H7N6lFpjbKlI5Nk1HCmh4T4Y0kSSOIG1AAAJTTpteULBeBgFc55PpbN ZoksWno1PibHxuRJuOCqKN2XCKnWEXG40hgq4GiE5FRBlyrSHomUgvOV85yhFbl7xBjsHIP4wbPg PuoE2MqhhcDwF8GHsA2UYdvlXYG6Q0OynZ2aVrB2x4CpjwcxFDA2pv7KTuGAEiw8cblH4SDYCrf6 G/J1Ri4WUkl8FAtt+VaEAHRgns6T8Vqt8TKAQWBFhJ7CxWdek20Xj+4bE/V7L4a1j3/a0Soun2dl vJFMOLlZpn68b/P3BqCyZsu9HeXNo6lgpyTCfyzJHj5/7qVFHQO/G8r1rz32G5dV9hNkNFftKid2 nHqjb/Hu6oNz6zfdHvYpnj5U/zcBsLQippCgYsRJvPdoRNVXaWjKZM6FFLKFHCNiYxLBQiuEN0g7 cAIJi1dvSWJBFryG3x1pN9gQ60QsXpPOjrAzNAlPGzwgpJsQEM4Gzh6U0yHW9XvOVMSolGZUtFqM N9diNFaoSeNAsLA7eDZ4EUnjSSJ6TXYE/UHZuek62Q3qm7dWCkXBrihoII1pSmt/KVj3tjhe4xq6 glgp1bl9Sqk7WKVSforMQrlcnmNz5Q32b4MwoCs4u4+SDuUuRCWdKf3ndsY2DPGEZFYNVSkOzfJ+ JWJhHHfhOGyhrCPJBlU++nJ1Om/0a+6ZCVfw+UxEz8DG/tffXBNOWJZWT/Z2LUmEn6671JzMJRKN 3rVvkXfKoy+huvwRadF9qC6tcOA6EGs2z4KFyRaUjMffd1+lb/ioActycRt9IE7ZNbte4jpTlCOs pAhoRYY3FAtHQkBtjQCTwK0ORzSj8pmMGpPlOMfzHMeHgkFE2wQzlHB4WG9T3MJluHxazfCsPMYZ iHY5k6gbu3A0aG8pyxlcH0eyHOQ+Ip8HDsTZGfTOG4sZs3bpghkV1YwGl5tXiGVgZnvekfFzfvTb zkmycnnkK+lZqyBEO2nQdCpfMypT/6U753zJ/6XaumH08gGHt8DhC8/JMYppBHhTKlh6QuxPcP1s DIEMSF0tdRH1foykKK4eyRBoDxYLc/Scgm5ivmtNTzHy/YTN/f6PXjw98s34dnX+oAtedC1d2Cqe +MZ3H1++9y+XXTwYLm2zLE0Qke6hamxP2mjf8bOeQ599G555W5d0CzKOPa9UHX///J3PxjsXtrwC fzukJ5qtqN7/nH1gO4rqnYP3Da+1BdKUy0N7mQYPb9WsNH6raGuafdPlKeCx4UUJpGFWdnsKjIEu Dgx/V9GOb065ig0GWsDjiz3qEB0xT8KpWjRLTk/YBU3I9Uq9cm+qV+lVN4gb1B3MTvlIwxH+TMMZ /ofKhOKtqL1ib4yspCpKpYWsyJVEJUlWxEqsIpGaqmUJf1hnNJH08CJP8ExDhGft0O52ROysAIWQ LyKk1HQkZYPWiM2T1JNEUkQCQoxG45rKa5oaikajepbXo6KeZWg6nsvyuVzWTdOmrKAZZKLcdJYJ hSNRUXWBVDIpIEtlt9uInK4BR5aJhkTVqqNFJMhPkqsmtDF9khibyI0Bkz4amwseICJqamz9EG43 ScNs9sumpqceev15dCIWKNe9DT4QRJCjUXaxlruHKAQ1M7HPJXMzdfAN/i/6Br8e6lir4Q1/wFYM 9a1g0PIl1pIIanBugMCITgJNfDlTM0UNEAqv2xascsGnro09TA9asmCLnUi4XpACkpNEP3phcVN2 nh0edxaXd8SGZlYnXp1ZLVLDz8TnlQnkgnqOzzSRIZ7pKNuwJ3LlOr3V5dVjxA9eXhUNK0hEUi1d TaeefEoFn3yKNMHs4+piiqueAiQIGm6iGYCgBTZSlSJ+hQ/ZL4C+DFsQqShR3JM/U/Hq4hXYSWVn H5G3ycNIcxbhJ0bAEbNLRbgf7s+Mw5OhE5mT2vn8B4oriznM7+Yr7/rezRFtme4Y4ZYbi25GThcY fK+Ekoq/1/+Cn5yfhW4DDd3IFF33fZJ8lCQhQVEAaaQEwoOb9qX01mTCR+WElnwkOUmOGw0g1STL wJYGFCUKSV4Qkvrk7J+uIDenT5KaQQeDrEtoSycFlj7ivgkXAooggYD+P3kteUEw0DoB44eJJwpA YIWsQL6F8IwE58RAUbhJjIMWci/gQARtRK1QiOC1/mSqENkzUDwbeRwhIq1tgl9oc7beqXWpusI0 bQh+qC9dwQ9dQS3JjIH6GJlAM3rq8+iPRGrka8bL/tKcRl277PNpZRCBaRr1pi+maiLVFCHKHFUq gQrAauQh9JaQQvGW0Ik4sATZXx/C9+2IVNm7dzFEARIzoxBLGtBzKTPQc2le/7o1t0Bx9mNQQN/0 7COQmn3UgT5rwaACByFpMwUsbnbtflOrIJ5sR0g1M64diRufv90mIyib3NqO0UzevuMjnXY3LaSe kZ893qUoPmHfq71LlwzfOrFt4/x+oelXxnMbzy5q2bLnvQXk4Zl162kH63awkfWBzVuU5lxfz3uL cjuGz8JvDa8wukfD5ZXViUOLes/94cHKpRh7bRh7lmPAD5qgxWDXh6DdCW2OfrDaciNMJeuGAEfD aAwWvBYI402BAPA/y/wl7cv6lwVoKAUhA0AaoNmASDM8TTNSU7QkpSgb/TDY5HLRiTRDs9FJcq/h saF6/5vvso9t4y7j+P3uLj77nLPPPjt2cokdv53P8VtefJc6cexr0nR5qfv+srTNWvr+tq4eHSP0 ZZtGCaSjFe3CtDLalbIO6LoNd51c9kIpHVI10CqBhBiITiJI6yarSOsQA2J4fmdnL/yBlLvHdnzn n+77fL6/73OceYchvQxiNrlfhyZyoSDBwQ+1tev+XJQVvUh6wT/PVY2pKXWVu8n9jaO4Euq9HOJc XIgtkd6f1hpmLtXMlGfBOW7PyVsu56r6Gqv6wlSKFbWnPy5H/40+nsRzJ54zUAFLCZJSKlbC6SDx 5ImqYcXPKBQOnfZq4GTIJW9tPL547xOlygeTT51B7QHeFXdGI1sW3fvG0XXZ8aJUd2w2v2XkxKGz lV8UC7RrwtnE2Rnpn//ofgx1PrN+x/QR2Lky8Oz3APcy4rSFkJ4tORmfEkQMRcMJOUtkUU9dNpyV nyCP+r4VvkD+MHjZeynIe2FebKIb65rCXtlwREJfC0+Fz/uohjqEw0PRpmeKYoNegEfljPySTMqg ENdoKyH6lZYgy4TAMS6JfA7qnzS/Jx0KU2bihmNfY5gDgZJcjlvCbeBoK+flSK6pzY+18xjgXznD EsMGwwMG+lHDs4aXDVcNNw11hsZIdHV1myjA9LeYr+BaLs/A049GQQEEDzzN38DWDgIVMDE+ICYB xLwGGe19GHPfx5xA7AcNQzU47EFdhxogWbKqxFz0ULspccfvvnLszAXkO3r/Hqk54o1Yk6zQomy6 umD5/i35p+5799BDz04+jeQr6/qzMb/sEVrjDrPT4ph65NSpbQ/nt0L/A6L0Suj/JMxx17TTjAc5 /I3WnBmMk4XDrKmZFItPZndKSZm1zi5426mkRLbJvJPdab7F/tlsyDmXODc4V3XRn13m70mpyrBn uHdVYlL5Lvqe45TzPPEqKrGXW15JXVIsKwkkIfSRgurd8FUWf1+/qE8LKX1aIAgvmhWHwxkISpKw h0WsOVmRSugjTZIT7cl8wNGVbpfEHjXgoATMHkUkKa8gOQRB6gq2MunSf94tetJp7Nxmt9tiFjKy JPAwblCXpJcEM+4MVoV1dp5OmadYnPdVWPnA6RRbQgMaS80kpwmBF0ihauDCz8DAVegBiwg9IMIi Ra0lmBKruIp6qgJXvyMisTEjuIQM2/n8F6kE6y3MzP4dZ9Uof/cL5psrfx5P3Cp2bL6Y0hqk0Do6 p0Yd1KqbFyAfgAdHH0QPzhk8MY6qQ8X/tVhB7f4MaowzoV9C0CsrP2q2mTi7f6l/6KTmj3nC33l4 +eiiwpvPHNiuLpY2mZl6q9PnUsSR9OHKnf7EDsDz2L+2bPSwds690bnlYHssvfHge6t7J/dPo+W7 VsW60PpQg9zktNiY0OyXtcWVjW+OLkHXsO9qwH4B2G8iQkRFU628OeTm3SGaMPJG0r7CuMxEyqa2 0DxTr2eIGTYOm4bYdcY1/KrQSfoH9HNCkX41xIfxY++TFJO/2ZYz+iHmGk1GU51IGE3OVmJK1Ixs lhNbxKRIiaI5ELQzdWGzubXH6vQ6SWdTmBgmMdYuC0hqeVRemrNocKMzFmRplKK/dM/twPlPZhaD ivkyHizK9nRyPFquqUTYMNZVScA79b3aBMYCSzFhg7GxOWOtMria6rP4fRFqdUcGxcaFOZ5d/4M9 YwiDVGrVcu8yh9cOHXncWf79iSdLqOHkrm39a3687/qT4wcOKB3b/oomOn1jh3q3tnxYemAazbu4 unfFos19kSZbpPvpwbbUHyCdVc5UFlI3gPUBtO0KQcFy1sZzFH6GwqpozqC55rv60wRtH9TkSCqA P29qDKQIDU6DgPyg1gCHGw4LnxrEyYJTanNTvY+mBxeggAb3CZTQbo0PBglD13RfME7w02LQZCVy szP4L8PPRjP44SV/I2pRnz8c9lLkQD8dCNJeciDcD9nLG3bAAZdVr//cXQV8V3w37wI57OXVnnRH e4msFF0dXImkNL5d0ADYiwu8Lu8CtvOPNf7ujs+WZ8ufAleurgEWw8/MpR6Ecw4IOnn9uuX6ZB1/ 3ZIZ+5SzWgSj4XnBQkicNEV4QfsznhypZRw5vz++NufDp0FNmAtbYwgPi0yAIhkdvzAIq9Z0raYg VcVDYqC7+qK251Y7YA5PnOLJzfYTe4dHdk6sX59p83aFxJCTZ0xCdMOIz9L34ouWFf3dsV515NzQ ovWJoDfcZOIac50DijhEFforo5Vbp2+tmh9slFuT/oYGwcKY6hh199a2D8nn+l3zx77aPzaWjwfa g4180mhhWFkp9H4ArXEDcnwU6EwSfcQixGrpEwNn7T8RLjScG7h4z8v2n3te814aYO27+F2jE/zE 6KnRF0YNNqvVmx1xZLMjVlt2hM763FJ6yliiuooxAjg7qXmTv+oKxpjBoNtqtzmGyCRtlNrVrK8+ gKbpoQ7HG1Qn0Uy0Q0qmqQ7NFKnvCeyJzO9pfh3iEVgvEQGvbVMiuDGtkpziI+hmBEWu5N9e5MYu W8AeW+Zxtr3Nz0KExYrqR7Xo9N4tg/plIDcNM1tN/Y52ndzLo36uIWfFmM5VK5/lMa5Qa5qCojU0 9V3Y5WpwYdWwbFg3EFIvUk1tF6Ozq/OdJZFhTno8pkl0tOV5YV/hrV2KIzh87Wyqa+L2tw/++t50 VDycWPb43sc+eWd0Yzw/NlQ4ed+AsnmBXPEtW5FZff7426N7eqnRHWry69u3m1tjvM3hs8WllDK4 /Jv53i1KdNwj3BOMymtV57E1x97ztH5/6fq/HMhv6tl2evah0P55/dHsl/LhhQ31kMAi4MIvgCOo aIl2v30lszpyLkLtNOw07fbsCU+YJjwHpANh4wpit0SuUHAyUAQ4ECLborEYITjUwcRaWWlX8ygQ RwmCYOrrvWKrQxRbiRihxrzxhCMeTwQ6aCYeY91msVtuFRNx3jElwC57qZ4JtZZQsFgfEvH2GiOp ovrbOM68EHVxLbrSemlW9E8hFei1LaVXzd6j3ImjeGO36Iq7xG628xtV5OeMG3v3DEgOLaFPOzUH yGVgw62rbrjQA+7/8l31sU2cZ/xenxNj+84+n893vji5s325850/sOP4kvgujQ9IICakQJLCEjCU SVUZo3yW8tUKtVpXQru1+2g7rTA00W0aFWMFkrmwD/5AlZg2adKmStOkbX9kUGlEbBJDmlTM3vtI 4g42y+89fl+fz3fv8zy/jwyMyKIuXiDc14jASzeg37FwAFLtyE+LULH1QMX2YTzZB0sBlozhBVGs vBwOqCD+PBumBqikjQCTAJBOu6NLjBxw2YwctjHdLiOPRwC91tSjuiYbt2d/UysY7ceYkB8Plfv4 5NHNSTEvHKRZqkMcnIyeTMeMd0BVyPCkGGn5+mcqIK+s7F25rVFbtyxA4tknw+qJrryYPQLeGslQ UTp9gP/T6vHfuo+82Ca3oimTe7/w8FPX8hYa8SMK6DRSzB5NpV/QVDJjkGrGYGOlSQywAqAZZSgx JcsFZRRD9rXW0dNGG+aRsSCmBHkuQXFcIubn0nKCI5hTNEzolaB3H4rVwZpL6NPBOhB+puwmOSOm cmbSNL3EOckzo+GF2eQMPm7PwmG6VODe5Fwcm+YYLu077ORyKZXmfvs5k6E5A4cH82I0bkXH406O zj2Yu0U42bZy3SSskPvzxEJyTbdTsy45wxgYVcGt9JUZmD3z40ywzBjBsgPkEMeboDnclM8FYbWY UBX8Oq3piqJrvR9TYTwYKWvC4NbBAaXEvhLnY/RQC62lFV1X0lrj4INVawIEReTGmZ1r1C5R3ASu 72mn2/1mjhrvN1a7BloiMEcF5PYsWTSCRKloPnIsZUWjA1e349vFLdKW1LcKLW0KKAxJU3K+UFhM VgLzYDhWwHlRokRRouvJTiIowucSu2RJJGCuLH+UVt9CgYFuQF3o5iJWRzOX10sASu2zMxI3F9ba 6qhq+KW/d4mM2LXYYsT9+ybE1uYty+Nsd8Zk+YUdhx21uOHOdlsppHB4BwHzLuDA4JCWdrp5m4Ej X2EXMTZrMrSlkpaaRwV/TOt6Gg6t8WDon29UVnTFO2iSDbhQDNt4MPfXRCaBh3C2JWKdBEfj+c9e /scfNJnPh4PhtrDf0+J2P/tdFNmPRSUU+l2okhAKYuJtiIndYMYoYEmqrBp4sKQaEVU1CNXn92FR P4uNIa+GfkB4epmKuprZxLhjIiu15VBHEPEgBT2JzENLBqkcSJRbxoqF7lEEwVplX9IPQahS+dd8 iGTKlpLM3+k2Q8xIwbtwgzBFRSFBdKZCALhTciokIxyPhwIFHHP7C1h3I1MH7UZEti5JRaN8p0R1 dkrADRC3KZSKoRQVCqVACv4xlgIyYjqkbng7GUpRMjjWqsg+7u22VNKfUQi8TeVO8XXw0Wx0rrNO zUm/RPOwAr+GyC4UyYBrl4q/VyxMjpUUG4ytKdSIitPPFiX7NFVhSwpj+R7YtQ78zj24dR8C8IP5 J4lbsEqQyqipAiv9CwBsAy9EXpuPFzHZJOYo4tQPQswD2M3WkbjpWUb0L+t/zTy+ZOq1AHHjxqRV YhZSANBrGRxJEoTehKfVgljaJOolW5SSUA8KYXehbV1rG3MHrvWRmJAV/GDGN/Jc9zPxTXS8Jxym QkxJF557vpBm5Nr0s6fBuvYWUWCKEHqVHd9bx+JewidJ7pQ00rFu+OVPZDkkjbPTmxM6eOdw44z7 0A42HI37rMpaD3F3B6ysDqAYa70IIBEe8EabOoFMtN/l/824fXF/wW/4N/jd/o6hyJTcXuiAJQO9 bQfKkxGKJCNBP8nJEZJYOnG37yq4Bi/ZaWCoSCIkuE7+jnSRdaAbPs5LMiTnO7zO4UVTJVliloSJ YwIV0gLiIlshDZmyZpdF2l4NCxG4moCrhnmiQcTs74Os86sAA1dx++yZaJk06AXpuyCA5+fu3an9 NxDDfC/ktGbCcC0D9lvI7jf/x2ceAETgD4WyI7jAY+AWLOZtR+M8Gw5A8ihz2zfoqtQdB8GEJDN5 aEynJqkgFVI28V9VpVKycx96/mAoyntEmAnh4acte6C+HXcNGV9hIVf35cCkdwu2Hd9Mbe2raTV9 W/9TYzvDX6J3ZY9iR+lj2SP90+jr2df7p1edQd8LvNdzZtWPwAf493t/3HexfFG7qP+k//zguaGZ vlltdlj8cs/O3l2D6BgyOTg2hk73nBz8zhD6TPlYzyHt+OALw+fKrTIQy6k1+af2TrQkkuONEbOf J+SxwvgogmseUF2B+zSAjJS6QqEVXR7P+MeIh2JZXinABi74NI3XByhdH0CGkfFhvjpCVasjkr86 PAyh0KdMQMoe0EeqRPJUwtRZLCUW6maBsKJiBNSnlb8oLqXuKs3u1cBFDWimeYrohqDqRqy9tFcH +gYf8IkDF/Sr4Doy7EKvjFwYu1m1BZkVBNUKvBUuwx9ZU9aeprPW1GDypdLe6t2qq8pOKIzOVBll YkmjNTG7CRPz9+7N1wio4edr++F6k2ZzCsj6VFnUbS0ORjQJuLl+Aqr7eRNQQ7aWg+9myq9ZL7ve QjhUbf1wIEmsvBbGHvMJguWgpffLbjsg9uK4HRhH5CWT4eZan0RqALU8nC34PGRvk/RjHtF+vc32 TlikM2gUUSG8AEkp8PNXNj+xfUrViiuZNee+uXH9cp3c0+lt9fnYcjHBnpiShLyyhXehfiyYzp86 sn7o3Q/aaSIh9v+ixG779kdRj8zjuhedbjxxdsOLfXGj2LW+AbqOD1ZWaisax08EAj5PODsckd8o FoTCN8CKvVgYUmcgc+Jv795x1b6YiLVFUw+RQ72NT1wnJ8JeWsDMzklBdrwAO6cHvGmr35yjfo3T jvxdlqeRmCuWd2/0jHnHuI3xo+B4bpr7Yep9+arrquTfCrbKvwLolHeKm4pbZmMXZ1uN1k3pjepu CfbN561GxnIaOdtpIEDIAiR3VgDQVrgRT5PlyCA9GT6bo7LZXDazYDdy2cfYDTOfW9VY3fX2JfVm zjSYGUh2WavAs/aXVtCsYHJc1jEgWZsCsxZGQptyNwuypgHJ/g8Dkhmdn5u7l3nUgzzGgcDiPQCc 0iU+50P+jw2BxQcVmMl76GMcxyMK1abDxaqDdfYftqs2tonzjj/PPbbPbzmfffbd+S723fk9MXYc vyRxcMhBQiCEQCCEKYUQWih0LLQFjaKijZcJWMnKqIoCZQKRrkBVSGCFsSYZWpmgbKyahrR9mvZh H6J2TMqoJqDbqpg9d2fepFp67vE9PtvS//f//15uHvj179Zm5wd2+Wib011olQZ6m9PROaHvswJT HV8y2l8nZY/9Sg4LzmDMgtupCLlfLCiUNpbXdNIUU1W7mjlQjKdimR3w3a5ar59P/en9vpfPEtu3 caxiskRw3ijhnrmCe6YK+MG4Ot9K2JDFjs4wF/lR8bLnMvsb3rKG7/cfYN7mR5hT/FkP2cA0+xcx nf7vWFd7VjGk3el0RxwkMpu5iMnhnUD7VA+5t6s3T+5tKxwhT5ME6Rco7TgONAUBKv4MqG0FoGbx ChYAkLGPVsEoMIMbYvIGjxF6aCDUfdcAq/suaJ3RKEa7GGSBS+vFplCrnyeCS0tqJSP02nrQldPl 6YOHxj+C4v79F86tWXz06/Wdh78meo6V/zp26SdHYWLsYsfAhvKaO4Ob4QfYTz0Klpeg3+MqhEEW 9qpdffCw85Rz3Hmtylz0dYEOqsO3uLbP8jK1g3pTGEtMWq/VTNbeFqi2UA9YTaEMyIdUgGBVpD5L UYAVuAzro7wZX3ihOAE/VKlEKBPuBhFYF4NArJtAh9WQNh4JQIEwJQmiVxDEWMTuwN9yCVDIJUSB njOF9gESN3S6QGp9XWNscX1TfXKBVKXCchKqZA/5OjlKXifN5BSaix1J8pdiODwh4Mc+yRYENehp 1d6rnmp8Iwby9wQo+nMCJ+TsE6j549WV0GAMxa5/8HX0zKzRtcm7hkPYhhm+debZuFahcm0Yit/i A7HtK+HXD28+wYpsMPofYMTi+gywOVJpbHgaGQoMhm4e0m8sJPxs4dYL/f27yz/7V7Y708ly+W5b ucY+MD8yy0lyIP/qvO/mhzavnN9ZP/TnenToi72bDm/7W7nIVpfLSzlWckejpqY9aKjXKwbJ+Cyz pHn7yB829PT95xxGG6Qw2p9jtBVQBztUu0W0VLeklqRMca1MA9hNWcU88QY87/7IMx46FzsTP5+6 kL4ad4zETqYviGgT3Bd7O40W+5eIqyEqpubWdUCUsqfqGuLoOIB1skLbaUfGboPWjM0tR5Oymw4p fDpFJ5QJNKIyIBoJBDT4IZRoxUvTSnICpVWnz2G3UXQmodA0uIY5T4FvgQQeHOZT+h5N0Ht7C7Qa w0sK5WmD6rRNlQV8JmBgechraPPYtvKqWOCHMjRHZ+zZSfgFeBwNMaoV9hu4e3/msQOswEs9hZee 1sOPJtTFCs7P4mtgu81Q7SSoWEHOAFWH9TG7GYLLNeoDCirk50GflydZzitl7WXF/hIfqw8O79++ omPjpqn33li/aC0nLVpW3FX+d1umpXvHKXTom2PLWE6xOqNRq83VvhXO/HZZ4weDx+HSLb0Ll77+ c3Vlee1U17L2zbBN8/K1eAhaML414L/qfAJroILXCtiH1tnW2VfWnEdjrvP8WcF2QBgRHiXRIdMJ ExGUJAgWKv9M1GRANyS8MiERUKmrglUT8LQa8kYtFkgmIH5IkmTFK8uKLNkTikxnbKqtx4ZsU4QK sOJfrrkta6CkuaKs5lvysjqnIKsRvEJ4STI+qA7kgQyBfFr+VL4j35MfyRasfW9dTcpcVk8D9yvj l0xOz07rLv2pJBnw4GPdSj0rRz/W0KvPaJqDEWai6InV0YCIx57Ymqcqox99D/a/c+nIipwSC/Ep TjERpNXhdgmF3hdrg7UW+cSk7PIqvia0oqkswOTO9nh0QSkVlBiL1UqpL51c0Lud201sHUp7nLQN V//RDE5SX+LqZ8AnaiQLIRcS6Varw+TiHT5Xc9yccIRdJxCqg61wORyEJjgBTao9fQtkSHOkhvRP wKtq3neL5xyBiNtBDINbUPU4WnsghLep5jvy3+WvZLRHPoLrd102yaPW5tiIMOy/xeuyn8etn8FL CeVH+es8wf+gfgq2w414AOgHWuffx3J/f2BgFvPd9AyWldbS9IxxHdDZSmtmFI5pLKR3NC6gHkpx pcJMDtNWVitcmijkcXU57b6R+LIlan6le15noP5HS8f3L16neFJctCVq2b5haT9dfSV3+DVZoDa7 kwEs0X88uKs9o5QafvqO+sr7IWcatr+3u29eIlT6y5bCiwfNKF6HO3gVruEG0z4QhJZJYMYGbht2 v6qreMZ8j/iGQn3iMHgIUSTQDNZQyCUHZGIPbiQiCCgXNJlJEgSqgyIUqgNB3uw3QSvWJL/fZEJH wSgBLYwDWzOJ9WMS9rNSws/SRKcLSYh4hCAaksEl0jVMTUEISBw+nB5WbSjmr7N3WILVk6tkw2WR nkuuSc22u1gtqbJqtRtfMA/pIXH2IaYSraOnDa7RaMZsWCpc81k9OeBW5oxMUCzqXWwulSB928gF GsdoBipHhr/VO4U1tiG8y065T45V0w5/Dd+rrF3ZVJzTJH943P7quy+Y9pW/ap29PFjt9oS9m/0H G2ONyYbXiLZ4cOdRjS00B3QT92sJHlf3W5v9zYSnUL+oflVpC/umbxc75vsM/M9n60uvmrvFhrp8 q8ALPtQASj5CSdQUiQs2WIy1JpYnBhMPfA/ZB0XSO7dUYmz2WLyp2Mxy5pyvxMTiYks6l6t44SRZ AhaAkMSUvAxT4imHyLRgN1xiaPuwbT3SIp9YGmewR2JU3p9nVF9BYpYzg8wR5jRjZnA6VJ25qKim YToqj3hEww1r2xX8uL57fcY+J6/vqj+cyGdEVRwVkehvsYkcw+E/te+8oWP4XOTDUF4V1bCnVf8B PHna/jFb1OHs1pLgjP4kjoVPTLMmIc8gi7NgRU0eiwgGWANUMwYGRxnSobUN7+MdRV8l7c3FK4NX EK9KgoN4Hg3gn8UdY/68e7aQ8YbG5032PKKxEd28GK/6P9nVH9vGVcfvveff9jk+/zrf2bHv/Ntn xz/in0kc+6XrjzjJmrKOtmHLWtaVtaOiatdOjHVS2TpEjVQqoEKoKxTGytimjbQpNdXQ+seUqe2m FgkJjUmjjLRiUqKAKDDB7PDeOWkR6HL37r2zz/m+z/f7+Xy+Zi6x2T+5uZyPpVjb+Ku3Hk3j1FaJ M7mUscD4g7gUycQfiQku+YmZJ0fcaH/79RdCdi6wl392KJoKBStjn3Y++S3OjZ8CxX1eC+ff4T5Y TmYipW91fn005ODX/OndDyZoJqVIJjVJJkWZf+ORiwDEsa0YxxZyWotTcBv6peYDWZPwDfkaEFWC wGA0AQtr1Xv0eiCFCc+5gD4gmQP2jL1uR3aiOxd7Yh7qmSm1nVOKKsN5o8Ulz7IHSh7sOeI54bnu 0XrEeKApMY0ofW5xFuvRyej26NtRTfQtFKJFzEg0FdIFqfseVaCESIJoEXn5JumIdEI6Q6hUykpY QlIL+s7H+j/y0MJWU2KRFPi8bXHjyvx+oj7UMlTvLAoE2gwg4HbNAHnITDsihB7IUSqrBwFHpUpV iKj0hKBKpikgBxxezmB91nPUKbPm6XxIwTbx+A+dVyOeCWFQSKPx2tj9+09t/Kwpnw8U436vuFaR +tfl85mJD1v8b+DTp/NGsuuh5T9rx8muJ8E+bPa4BC80uIxeqNC+N2Zha1vFzcoucYdyU9Qqroy3 6h71bvc+rHzFuzewJ/lybDZptvfRTM8OFuhI/HZfd5vUIaAO5/3dhzjL+wqicgUADxNsRuaS0Sgx /Hqf1ysIHjNEGq1OywnepOgLmDPmuhmZCYoXtM/1cIBroTK2gFtC0/OcmGwyt8QWPI5N3qYvMhne HobhFsqcU2756K8RGqXjuWSRDrgnXSr4sFzM+rBvkw/5LhFUU6gy04VoBSHi2drtRRs529MEoG7d EVqtqxTbva4ANu/JzOjgfQ9uw2YL8IEUiHpTipaZnlIb2RUOmPWSEuTJJp7jBkjifXSBGxCDPWpR ThFHnyRSCRwqvqtiqCKs10FC1ICCrMJcjLgdbh6gL6x7Y/ewSVN2p8OJgR7/1if+WI6MdHam9OGe kJDv7QOBql2nAafQsbb9vfN7Mm7OGIq4AsnhfKFvyzdf6nxSgbPtCfDaPx+XeF34vp91zj4fhGep 33iLVN1Rgv96YMA7WWoV9IxeYYZBzcm4QZgJAerTjwkvgZ8LryqvDL9Zt42SwrTxO+Un5SvCNVlr DFmUB0JII4giVJRkDdeqOC4HoSgG4tgZj+OaQsSTK65prp9jOGrhA65Bk4nRF+cGYul01KxRhJrc /FHwehAGr7Bwft0lsIHBIHxOfC5O7WOvMF/DQ+OFGu4t1mobJBaz32bfZDWsONovbGgBJ4VyI9HJ 29MEHlJh1KPcXiSMvEhxpBi259WL7c4iRfUuvdqu6A22qoGQr+0dlVinAfH3gNYf1cV7BnDF/Tnc /y2gsSiC3XHFzdBnpTJBToUOPJ4T7Iltoceint5kvscXdpHm0CPXtjzgEFmXrxwL1b9YjlZk15oX HxkeiMuelCSFRavFkfmJUNPyY6O8Hx0rFMI/OJrdajOl5ahVMNp8hZOdVyYDfHrM/tTGVD0GEp2/ buzvdUfklMTbop9V/mYdKcEwRXZHZz36BkG2Ahz4oVM5kPMMFo2CKCSEYeEsnIWXxNl4q38OzWmu CldFtuGd8u7xIk0um8loe5N+MSdymmwm3ZeM+7wGOafV6Qnlmi0GXlNsVuacjD58JRnz98gtcBmX cxw22ws9XICDXNxyiKfUeII/w8NN/BH+FzyS+CxZQ3xjsNJ4uwzq5cny9jIqt1AIs5pbOep6ctT1 5GjF8oRcT+TO5JZyaFPuSA5KuWwO51COUuvAKrVOdwt3mtojMlGt/jxTby9QZlU9UfccYOz0qjoj zTvVrksFB4DbzTvukuy9GtQxhGdVaewa1C6q5EAqqjEwHhTZVPVA+XM5s846FMuGU7W9nfc+/P53 CoHMSNTJGhwGrV7XU27sSFeslTWukhEdG9z1vY5z9MWJ5zdJNs5sdeTlRH8DT17rPPzpa1OZQAwb tRmD1hQce7QGv3Z6rS5C8XuX9GExtJ9xguMzdra1/DG2BwcLFlqiyE/uWJ1cRK3lBazIxRK8Bq7D a+j36F9Il0JDqMFus2xj98Avoa/Cp9Bpy2n2ZfhjxK4QF2t0ul0WycgXLMgMW8s3MU/uIcsgs+ky e4OFN1hwkzRvxGjV35/ef6D+PtnBJD1VR+LFbmNHo1kwZI3OdVbrgiPrZO3WAANbQMBG4nx1GjsK WMjsvMlsIi1gCFuNLQgabudJpP7/dMliMWOvVKibgfm7LlrFFwiw7elkdZHI5Z0qbS+qt9uES3/F IMLqxFIh1ZtZuqP6muXLFwnbI8w5a127Q6n6to1+C7us1IZZMfmClf6olfprKxWGe58G6cUFxvb3 lWFK1eFVCsd2RHoGhHtDNYRd9OLs8rdDdgG5n1R6HslFIAepMIdeh88Qgo3srmR6I1vbh+Bs5+ZD Dl+5N4r2C+2srbC285deeEOryw8xDARNNKN5Wvtlxs0ozOcxyyuMO7ykjFiX3IhvAXxxUtwu7hOR OMLBC4wMDjIx0CA5gRkNmZvJnANfZ5JwGPyBdmb/aM8vkHN6gTRkdxZXrD+hKJdTTWC1BaMJTbJY q/v/VfjGREnUoj6dvqokhmrDym7w8a6KHvVpyYIydPikdiJQ8yedrL7IcpxSHykOHc6HyoFKI+jq MRRMnD1Vr5e2/HQtjewQiewx7V4SWYLZjK18gnEnlsLuJetIGDEjjtUQGJ7ciTQ4EspBElKDhHiQ kWGKUWBj5hk1Ktr8LJA/pk6iWo2rK5rRaOyuMaK2KFL631UtwuMlrw726QzD3bD2dAKrYSWSQ50l 9Dt/zZ8gYRUsnD1RGylWD/eHKpHy6H/Yq8/gJo42DuD/R8/KPoEBYwyYIt1J5kRz6B1jegvNBEJC 74ROIBBKQgsGjDGd0CGmG0LvvZreTC8StukCE1p4aSJ21pgheZlh+PTO++V25re3J92edv+j3XUE pk3LP6BwWOWyh4bhQ+n6eaagT4iW4uSKziz1B8QQwCwPYJ89gBIAWBYBGeIBP0VKADKXALL0lp79 w79+uqxj0mWbA2RPAnI8AILaAbk3pMurAaofYFf+4ZgK6E2B/HWAAnKchWzpQuR9EamofE/x+HSl Wn3G1HRl5VzKRQEV5DVUjqfSG6CKPHqqyd+uYQJqyvnVlmOpK+daTwANw4DwfkDjQUCTLsDXtYBm MpNv5fiay0xayixalwLaSu3lOzucBjqtNPwvdI4AurQwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwG g8FgMBgMhv8fmEBIK4HgtBbllnzw/kN5NZnSnvnvIr9kYfbxVSwZMvplypzFP2tAtsDsOXIG5cqd J6/Vpmp2R3A+3Zm/QMFChUO+KFK0WPESJUuVLlO2XPkKFUMrhVWuUrVa9Ro1a9WuU/fLevUbNGwU 3virJk2/bvbNt81btGzVuk3bdu3RoWOnzl2+69qte4+evXr3+b5vvx/6D/hx4KDBQ376eeiw4SNG /jIqYvSYsZHjosZHT5g4afKUqdOm/zpj5qzZczBv/oLfYhYuWrxk6bLlsStW/s6rVq9Zu279ho2b Nm/Zum37jp27du/Zu2//gYNxhw4fOXrs+ImTp06ficfZc+cvXLx0GVevudzXExIh/O7KieaQU/VF DgyjVJNmam5azcHciPvwAB7GURzNC/k0vxCZRCNzNrPVfMT8wPzc2t3aw3rQetyaahtum2tbYHtq e61mV61qTbWB+o3aXG2ptlaHqpvUOPW86lIfq8/VFC2L5tCcWjGtlFZBC9XCtBpaG224Nl3brD2x m+3Z7DnsDrvTXsTe0N7U3sYeYf/VHuswOXwcWRwBjuyO3A7VUdBR2FHH0d7ROdgU7B9s16GbdD/d Xw/Ug/S8ej49RC+lh+o99RF6hB6pR+vT9IX6Kn2DvkPfpcfpJ/Uz+lX9rjPUWcVZzdnO2dHZxdnD 2SekV8jAIjmX25dHe03eMt5Qb5i3qreGt1FKcOrb1FT5T9AQY4LJbmphWsP5OJz78xCOkLlM5MUc zy9FZhFuzm2eYo43P7FC5tLTGmdNscE2QuYSY3umQg1SNbWOGv4+l7bqCHWLeli9pF5Xn6kvNGgB MpeiWgmt/L9ymazFfJRLA3sTe0uZy+QPuWSVueRy2N7n0s7R6V0u2idyCf+Qy2Q9Rl/5IZfjMpcr MpcKH3Lp7Owuc2kX0lfmknN5pJe8Vm85mUsVb3VvrRQtLZfUW3LJZJf/nlfy2lFqlLZoUrq9Wzov ZKsQILYCb+PfnkhuBSRPT3YBnqWyVfZ2pGxV9JT3lPWU9pT0lPAU9xTzFPV84QnxFPYU9BTwOD16 2nuSRr+rI5Je34hNGuh5k7TVc0z2vJsUlTT0xoDE7omDk3Z4Wt5YlzTR40yMTZyRMCNhUcJ4IGFZ Wr/EnAl9E9rKu2IJVRJKJuRz13LXdIe6y7vLuEu6i7kLuh3uPO5AN7keuZJdHtcd1820Xq7Drr2u PS45ctch11LXWldNVzVXVVc+l8Nld9lu7H33TL202rxHLpt5vnN95/jO9p2Vwd/09N3eEij3jXg5 9zD5hFPqYO4u6/7mObJ+BPgEpfVK32KUd3uOb0o6eV8MnymKTQmVdQul1Ueff/XZnq3SKG3e37X4 3PP/6llCKfWh/YkRynGVk3U1pVn6L31UGIsRgdGmh5iBuxiDiRiP+ViBJfBHlAxtFKbhCZ5iAmYi EgfgxmMswEr8iWd4jkVYhaM4jNXogI6YjE44js44gmM4jRM4iVO4hy44izOIxxp8h0eYggs4h/Po ivtIxjh0Rzf0QC/0RG/EoA/64nv0ww8YgP74EQPhwSAMwWD8hKH4GVuxEMMxDCMwEg/wENtpBs0k EzEJMsOLtzSLZtMcmou/kEI+5EsKUmkezacF9BvF0EKyUAbKSH60iBbjBV7SElpKy2g5xdIKWkm/ 0ypaTWtoLa2j9bSBNuIVLlIUjadNtJm20FbaRpkoM22nHZSF/CkrBSAJNygbBdJO2kXZ5Y4dTbtp D+2lfbSfDlBOCsJarKNclJsOUhzlobxkJRsdosN4jTe4iVukkkZ2ctAROkrH6DidoJN0ik5TMOUj nZx0huLpLJ2j83QBOyg/FaCCVAi3cYcu8jpezxt4I2/izbyFt/I23s47eCfv4t28h2N5L+/DMt7P B/ggx/EhPsxH+Cgf4+N8gk/yKdMj02N5hpyRu+VZPsfn+QJf5Et8ma/wVb5memJ6yi5283VO4ERO 4ht8k2/xbb7Dd/kee/g+P+Bkfsh/8CN+zE/4KT/jP/k5/4df8Ageyb/wKLkfj+YxPJYjeZw8s8bL 3XmC3J8n8Ut+xa/Zy2/5L07hVAFBwiRYCGEWPsJXKMIiMoiMwk+eb5lFFuEvsooAkU0E0iW6TFfo Kl0jl1JOlBFlRTlRXlQQFUWoqCTCRGVRVVQT1UUNUVPUErVFHaW8UkGpqJRW7ir3FI9yX3mgJCsP lT+UR8pjyyhLhGW0ZYxlrCXSMs4SZRlvibZMsEy0TLJMFnXFl6KeqC8aiIaikQgXjXmFEqpUEsvE chErVoi/ua/S6CqKLHzrdtXtKkAGQVkUoQXCFrKQQBIVAkzYJQgkCAyO8oY8woPkvZA89rBvKhDW AAmLzqIOm8i+Q1DZwqoICfvqiONxZF8E8ubmkTkzf+bPeM7MOdN9quururdu3+6qrv6+FXKlXCVX y0/lGvmZXCvXyfVyg9woN8nNcovcKrfJ7XAKLsodUCx3yl1ytyyQe+Tn8gv5pdwr98n98oA8KAvh NJyBs3ABiuC8PCQPyyPyqDwmj8uv5NfyhPxGnpSnZJEslqflGXlWx+tWurVuw990gm6r2+n2uoPu qDvpzvp13UUn6q5WVauaGoglyqMGqcEqTaXjA+VVPpWhhqhMlcV73lA1TA1XI9RINUqNVtlqjBqr xqnxaoKaqCapyWqKmmrV0G/obrq77qGTdLLuqd/UN/RNfUvf1nd0L91b91Hr1Qa1UW1Sm9UWtVVt U9vVDrVT7VK7VYHaoz5Xe80cM9fMg1riJ3FD3BTnxC1xW9wR98R98UA8FD+LUPFIPBZPRIlowhwH kAkfWihRIaGNGg2WE2FYHivgM1gRf4WV8FmsjFXwORGOz2NVESEisRpWxxr4Ar6INfElrIW1mSvN YFZQRzQVUVhXRGM9DMH62AAbYiNsjKG8S/fVV/RVfU3f1ff0ff1A/YhNMAzDMQIjsSlGYTQ2w+YY g7Hqb+onHIWjMRvH4Fgch+NxAk7ESTgZp6gbOBWnqZvqlrqt7qi76p66rx6oh+pn9Ug9Vk9UiQoQ kCAkiyQpIrJJk6FyVJ4q0DNUkSrRs1SZqtBz9DxVpWpU3RynGvQCvUg16SWqRbXJwXfxPWu+lUsv Ux1rgbWQ6lI9a5GVZ+VbiymE6lMDamgtsZZSI2pModSEwiicIiiSmlKUtcz6wPqQeeIfrD9SNDWj 5hRj/cn6yPrY+oRiKY5eoVfpNWpBLSmeWlFrakO/pgRqS+2oPXWgjtTJzKfXqQslUld6g7pRd+rB u8pySqJk6klvUi/qTX3oN9SX3qLf0tv0DvWzVlgryUW/o/6UQm4aQKk0kDw0iAZTmn6of6Z08ppc s8AsNItMnsknH2XQEMqkLPLTUBpGw2kEjaRRNJqyaQyNNYvNErPULKNxNJ4m0ESaRJNpCk2lafQu vUfv03SaQTMph2bpRzSb5tBcmkfzKZcW0EJaRHmUT4tpCc7EHJyFs3EOzsV5OB9zcYF+jAtxEeZh Pi7GJbgUl+EHtFQ/0SU6oL81H5tPxHlxQVwUl8RlccUOsevbDeyGdiO7sR1qN7HD7HA7wo60m9pR drTdzG5ux9ixdpz9iv2quCquMRcdbWVbY5irj9OndJEu1qf1GX1Wn9Pn9QV9UV/Sl/E6fo9/xR/0 CVgL6/B96wfRDDbCJvhCfAvrYQN8qb+BibAHpumLsFfMFDn6pK6nQ3R9uCu+0w10QxGrG+nGWGAh 7NChuokO0zE61rxt3jH9jAvy4Ef+a38Ec0UrmCXaiGFijpgr5onhsEVk6wiz0qwyq82nZo35zKw1 68x6s8FsNJvMZlNkis1pc8ZsMVvNNrPd7DA7zS6z21w0l8xlc8VcNQVmj7lmzppz5ry5YK2yVltr cJ/erw/og7pQH9KH9RF9VB/D/XgAD2IhHsLDeASP4jE8jl/h13iC+UdF5gWlLKT0GFTGSEo1z1Fu /UMENhdxZdiC2iK9DEvGM8owMV5Zhm1IFYWlalKa0pjYtAwLiMfFZRihIp4uwxb3f1eGJcRbIWWY GPcvw5yP9XtmRQ5EQSSfcYySmcO4uU5k1uLl4meWkhHsSeBWJuPSq4v7PUGPcLa0YZ6TxnUP7kvl 8X5mOqUtN9du9h7G1xT2TGZ7erDXga5cDw96+bjPxZEctpZaXFz8wXuksE+pLZO5lMN+A/6D/Eqj eoMRn47ryS0Pt0ozciCJkSvYenpnL/dGBCM4wdgDg/k7zAJ9zN28wbw8Qe/w5U5UZGSckzzQ7ST6 vD7/yAy3k+DLzPBluvwenzfcaZOW5vTwpA70Zzk93FnuzGHulPC2vTr37NMuNNmT7s7q6h7ew5fu 8nZLCuvkd6V5+icm/zJzsN9hgxO0OJ4sx+X4M10p7nRX5mDHN+DfJut4vI6fbT29Hr87xUnyu/wc yeVNifBlOj62ZDr9fUO9/kyPOyv8v7hg2kIv6MxT1gfaQei/LJ+ni+efS6cbT2QYdApOZhp79eds koPxUnna0oJL6JfF+l+O/r/6bIL7nRUrZoMCrfJVNDQRIcG6i/UhDMDKQiEqS0llLHkJygUARiTw mOAumJyY4DByAo9VTkl7EW2/LLa3BrH74n0OOkR1YRcHpMoBYFybS01rCFQHCFzmcr20lHTmsYOh bsnAwBUrnv1zy8rTIwT+DDmiPKuyiTxVUawXC/klZkB3Vjst4IYogg68m4bwFDSC1qzGqgoXtBex 3MqBaoFCtvQNfI9/4Z04j7XcLX74U/wS9vGumy+ioR5/MIehZSAVqqhiiGFdmhs4C7Zsxn+y4sC5 QAl0ZO1ZLFqIJGu8iudFM4rV4QxWW41FnMiG+pzDCNgJBVjJbIQKPJldeWJ78yLfIAXfU/ECWsPq KYHv1Bumi+aiILCK30gIjwyDNiIGQwPboBY0hmbwGrSCKTAfFkGRCBctraZyK1TjZ3Kx+qzIeq+O 2B1YArX5TIS3ONMZsABWwCE4xLouGSOsfmp5yXX+z/k4wzEwHU7CTdagvcQI3GKtLmkV+Dvj1R4c VXXGv++ce3eXPMhigLxA7nJJwDwAAQcSIKTsbohNGZMQZDeluEkIhmBtmCoCo22QTgk3WBCVCvgc pkKDlrvhFWitDEJBLcNQigJ1KLQFRR4ilkoh2dvfvQmR9I9O79nHd77vnHu+x++c830N1nbrAGaP xzoBgH8xRv0S1m1GFrAPN/8fYOdgLkOde1V5Qh3TuSx2LHbWGmh9RUnQdSYg9Dj9lFYiNq/hpj+N uvAmK+xBbbofuexp2Vd5TU2xyFrhxHwUjpRZWGMFNaPtwYyDqD5H8Fh+gj92MuzHkOVuFZdRrUXl 35XPLL+1xXofPr+IW1BHy8KWego6LqPViN3buL93Ujsdpi/oGv0TnmzgFo7yTv5G9BfviBNKh3pS vWa9anVQPLydSbnOgTgWHpyGDTwL2m9ApD6gI/Qp3aJbnMH5/BNewQb/gl/idci+/oUs+6g4g9z3 16h3D6NOHKM0qC3qWVe5uzq2LrbBKoV1yXj3OOCmED6sAxZ/DEy8Aj+20W56D7p9Q7fhl2RYO4wn cgUv5qd5Ga/mN/iUKBEN4keiUbIcLHU5XDYrQ1DZHVNOozpqiWXFwtZIsnETBzRMhN4htEdwXCzA GksR0/VA/e8QrUNA7UWg+QbdxmoCcY7nAezj4RxEm4moh3gOV3M9P8ObeCsq2KuoaFLFUGSmL4pN yIk+kwvlC3Kj3C6Py5hiqfHqGLRSNQx7t6rXkXOvdE9117g3e/7Ymd15uPNMLCE2IDY8NiP2s9hv rZC1yHrKetPabL1jbbP2dedML9Jg4EtDG45jpYRK6Xs0B/ovoIXApEFr6Hm0zbDByTiBuGP0J1Sj f0W7QJ8jspccm25QB2xKZR111Vgez7O5hudxIy912rP8Mq/njWzye7yPP+Tj/AmfROZ8tqvac6q2 UWK8CIhp4iFRIWpFnWhEPfUycu+3xG6xVxxElD8Wn4jzIiYHIRJBWSJ/IOfAI0vkMtQwu+Wf5Ql5 Up6TN+EbBTHyKbqSqRQojyrLlbPqCPhpLire19H2o8JqcG1zbXd95Prc7ULWXuIuc7/lbnNb2Cnb aC126V0PELeF7xPfh5aS3xc7kCEfEW3KFdGXw7xUkshTcoHx6XQBtVgmF8rFnIF9/Bw9KCR82Be1 wzSg234qsIvHAoeV6nFlAG8mEj/nepw3R4GfUoxppr2UaZ2kfvS8tYB2cgp2VJ21HnuhiUt5H/bQ o2Kh+ELpkF4g9Jw8BdxcwN4fx+tcH9FskQO0TabXaSDlI55naAlrYiRV0XrZjEj7KI2ylcdUnOF8 XbZRq1gnVood1geC6DLOvSplGhOuC1KzkTNfot9Atw/FcbGSdyoufpMfgg6DpAf4OETDxKtUJ59k BTXv18pJOiXyRZXM5evK/VJSGeK0nMJ8iT30Nq8TN9lHL3ETrD/Pl8R5XGVfsyU65WpRz4f5EA8U OTxVjqaYOMc10GYYXVVT2CPGYx+5gKsLolXO4410XN0vP1Wmy12k8O95vOiQmgjwdDnBukKZrpsy MXbC8lNAWNZaJb7zS3hnIZ2yDsg8pVr57u2dt4+KFF4rf6iGrOuxZ9TlopDmqRfdk2mJ8OOEOIq7 aBtl85ciHX4fAk4BPJWirLl9W5TTYHGNb9BiXo3dMQyWVOLk2IZ6YgvGqribpuAWuCW24tScLp/E ObOLDgDtT+NsTxa1uGfquYIEbgnFuQ82AA1fKfORQDQh/u/iNt0K6l71V7Ei1DeP08PYi3/hFuy6 EpGvhJAsPIs2lKjoO5VFUwonT5pYkD9h/APjxo65f/SokXm5Odn3jRielTlMH+rThtw7eFBGelpq ysAB/ZPv6edN6puYEB/Xx+N2qYoUTLlBvTiimVkRU8nSS0ry7L5eDUb1XYyIibzXLO49xtQizjCt 98gijJz3XyOLukYW9YxkrzaJJuXlakFdM48EdK2dq8pDoJ8L6GHNvOLQ0x16jUMngvb5MEELptYH NJMjWtAsXlRvBCMBvC4aH+fX/XVxebkUjYsHGQ/KTNEbo5xSyA4hUoIFUUGeRChlpuuBoJmmB2wN TJkZrJ5rlpWHgoEMny+cl2uyv1avMUmfaiblOEPI7yxjuvym21lGm29bQy1aNHefsardSzWRnIS5 +tzq2SFTVoftNfrlYN2AmbL0H6nfdvHye/yhFXdLM6QRTJ2v2V3DWKGZb5SH7pb67N9wGO/AXJFZ HDGKsfQq24mpo6CIrb5tSpdRdXrQ5kQaNLOPPlWvNxoiiEe6YVLFEl9benrRHusspQc1ozKk+8wp GXq4OjAo2p+MiiXb04q0tN6SvNyot1+XN6N9k7qJhMS7iboemUM5w22qtKLHnWxrpD8IFJharQZN QjoMmWD/1E0go3YChuEJM2aZcxGG+WYff8TwFth8e76pZnp1zbhBCLt+5XJvTnU3x5XpvUE2aYOj B1+Q36HNnBwzO9vGhduPQELHQqf/QF7uonZxVW/0aviD+6gshGnhglHwuc9nR7WlvYhq0DGbykNd fY1qMtqoaFRO2BQRW7LvjmTATFvSdEfSMz2iA747nKx7gOnJ6vkkeQcmB+sLTB74P8R1XfLSGXpp eVVICxqRbt+WVvbqdckn9Mi6KTPZH5IZopsSGdKRAomzewbbnVCCqWTi43KQPLfd7QEUHQ5rxaY3 UtL1G47z+f7PSe3WNXuW8/fttG41zYKc3v2Jvfq91EswJBRWskRpZZVhxPWSFePYMYxiXSs2IkZ1 u9VUo2te3diDHNA0GoOROxFtt/a2ZJjFq8Iwop4LgFZBU6M6N5dHi7h5RlVojxeZb3NlqE2w8Eem hqPDIAvt0XDQOlzRw7V7mt2jUgbS24THEWXsKSJqcqSKw3D6te1MDs9zh8dU2y66eF6HhyePumsy NeHI0f6vVD+SNOmGJ83jpAqbhrS/a/8fjP77cIfauSqu1TMaWUIfjGfqnuf2xYI0K66gQ71VFteK Gs19d97S52+ufB5kU+LOt5U2yNmcpRC9gO/DrlZa48qnGt7FiZCtEq2WTyH+D+3lH1xFdcXxs3vv 7nsTfhcKFZqAYJIijZBmCATDEGiDgUgjNQmQBoqUImPAoCmFokFsoFacEEIJ5acDgmgTdWxgIGoT fgTyoDZQooEpCk4LKpSJUIqgNr7b77lv9/HYEJFO+8dnzu7Z++Pcu+eec25/axbVmaQuQJeMfulm inoL7ReBYtAP/ACkgXHgaXAO/BDciz6LwF0YYw04xBL6Bl8+PSTPqI3gmJVLy62AqsdzEzhiBWgF 3v+E+feKUvWmlasOyyJVZ1eqWjwH8H0R2h2F5DGOYbzOsojK8H5SnjEI6/gc+gXQ1aBfq4imTmYK nRTRKklMp+GS1EWz0piNfkNAsihlHcVDppkpwQ34fhjvA9FnMt43Q98Dz1kYfwC3A6loEwOZgLHv xrgt+J7NerT9LtYzAHbXgHx8C4gkKjWTqEUkqYdlNvVw1v08r5vX7K5J2x+yqQ0Yl8dOiyRk33Wu 23ZLTsGmdyEfB4lYS6vZSK/KwTRHUnC33YOeY3wn8N8rjXWgo5xJd/ii1WrYmGHtpKF4Z6aBPPS/ LDeqJnGF0vBtkL2GVkGfYSbCx4ZStfkEnbVj6cdYbwLms9hPsG8rtS/M1PtmQsbID9UBPPN7rC/a iHL2aSPvja+UEtA/GXN9AjtaZJGxHMyHbdWgnO3B/IOx59Px33cbucEqjNMNvvdzcA/WVRxCnYEP N0E3Gu1icLqecuZpipBN7HuROP/H5aSL3vtKVKqV1ACuwpY4sA8Uo997kIOhhx3Gj+CLDWifxP4K v7gU8k0VYN+Av/8F+mFsu14D/Jt9LHRujEXmLNoKCsFSm2iLw6/QRp8X9lm20xm7hX2LfcaVjm8c NKtwP+B1sl85Up+90xSvbcDa2bfCEueOfV/L8zjTLCtoHPssjxmWAR0PUvk88pkIS8cePp+IG7Va nqdcx9dTXenuRViWql34Vmz3ok0yCb5fgzMQTz3FZcSgU9jDuTSez7GsoPXmMurhu0CD8S+zMNY6 j1zL+JqNRzDeXuxng2ykdZBrZbPZXzYbllWlzssWY69VZS7m57bSi9uWJRP57Xb1/w3mcasKd5Uq 9Q+rWSnZTKs4S/guGENAP1dCXw2WgLv9g4y1/gKjxpdDXeE3V0ChTKMRVhp8bi+Nkt/U8TsW+hyb 4A8GZcrnqcjYa3QSOUacXUVzRA7OKOYyj1MJw+NDzgv7UcjXRriyjS850vVXjzzEMZ/jriv12UNc deTkG99VA+cGjs+cHzhGMyF/VS+E/XIVcsh71/3T46e9Ivzzt+YISvT6pVdybuH4zrkF80/D/Jsw 1ou8fh0fEeM4RnKcw5mf4Lb3ynD/SqMW8WG3jsONlOeea8Dn/By+3e/EEcRh2qnjYSFNtXNpihhG E3Q8yqBp1lHqp3OQk1NltXpJxzKcJzeX6jzarMrCeTRaXQ7FM3VQx5t96g0+nzpvIn9am43u1mHq o+NKEf1Rn0M+g5/RCMyVI15BzG1VC6BLFCMRe6EXn1Ce/naC+ooF6CfVas6JYi7F6vx4QhWKUTRK 912m0uRnyNvb+VYbGk+3gbQq4JOoBezptE/Hgjz2EersxmP+974C9ZZvmtpvz6QG6wGsZwb9DWtp 1HtQoxr0PnDfXiqB98KXrVaKqyqINn/WcJ8C9YbeD+xR5F7o3Mw1Bca0C6lC7wf3KaGP/ZPVWcaa Tb+wv8A8mMsaiVwyRtVZY1S5jq02ctwvsc6+yG0daST7ve8xpURfdcTNw6KOYkWxetHqo7Zh7wY6 +niO+1yTcL3BNYT1Gud+VaP7HEOdFkVpjIyHXxbQLLENPENdrG2oRWrUUl0rNNN3hFSVohj1Tag+ 4RohR5+XQrXdqtaxeaC2AXPw2cf/qEcszUUsGe17Tr0sTfoewspQIpUFfgbSnff9DvUhjKOhNgaX ldnmNWrBcz789SdE4knohnEdKN5RzeIpddAsV4vFJKoVR9Qx89u0x/TDjgPqC/EOTTEuUoNYQvvE ONRN8yggDqmzol6dNjvQeDNVbRJ/oAJRohrF45QlHsV4K+mg+J26JFaoMlEBH/2U9ou31TI5nPbI DhjrNDUYv6YN5j9pg30/dcV8o/X4S6gM4/fUlMBP0C8SbatLW5tnmLHU0bE37wZ72VbXTtdG174V yGWOfbxuHlf3QxuZQeOxh++D2JAMTsQ/yeO4rmNWOmKPHzFoKqXie2+iLy+DnXguR9ur4CyeF4Ll eP4N+Dd4ATyKdldC/4364v0+2ZsWOnGmEO0HQTcHoN+XTXiPwfNwPDeCO4haP4Z8DIzC8+cA+lbL IQd0QR+0UzxXoqO7iPYbwUk8b4F8MKRr3YHnTo58E6wGi8EQXb966pL/g7xpPvq60pOHEr055bZk +teSN+Ye5//fSjq5Jb+NdPbBXUeEPV+Z81wJ/6mLhGMrxzeOqxzbOJ5yPAlLxFQd1zifIBCEpPqA YynHM46lHM+sEifvlyFGlFIf1y6crdf5viqSwWlayHc1K5NSdGzHsysRq5OcmmM417D2SG5DcfpO V0N+zPeRuEr3yjPBRn233Io7Ymd9v8ty86JzxxvPOctOp2es3GAj5zN995iFPrOxDxMwLt/7dG1O 3VE/9OScafbHOClqWqjGRQ4uokbkzUXI0yflJjole/I/cOraB9VUcArrfxVcwjj9RDVyRTe1w1yD OuQeFWOspy3mKNpiBCkKcXN91AhV7z+r6n3RFO8nVWe/ouokYov/IxXwlamAnaLvrn3c/4st+5f7 HFGTcI01N1xzOWtuUxfBPtj1COeJyHndfr7V+FcBNdqtr251xhxfu/MmPnfT+0Kbe8GN94d35WXU E3eqceFacSzujB/iPjCRHgjvsccWdy7sy472zqRzRqaLZ3XtNsQhGf27Qb/LuT9hn+G/tdRH10Gc yx9WR8QeroeCm7E/jYz4FPn3KE0WL9F8Zw0DdT2bQh10/IjT98Cx2v9SyJYFlAE7Uh0G4J66VM/X RZ3TNv4UoEaSuRg3Wr0fQRVoNT+geFCOHNMgjoNo9bKZGdyskfDrzOAh7N01PReuCXIg6pELqL9K 6Rvwje4shUXDee80+P+gTownH3gSkHgW9w7slZiH8feQzWuU3+J1BDeiba2I0Wcxwe1jd6R4Ox9E YR1PIEdW4K4STdnW0eAGmY97WW8QTWPFX+EX6bjXAmOi+r0RgAzQSMa8j9LgE0+bUeQ3duEekm/E oQ6uBuWhutk4pUmgt8HfcaeLB7HgAGNWmr5Q3WzMxjnaCh+cAhS4ir14yEwxkqC/5rA9Aj8QorNh mZOo0ugFm16nXHMMalvMI7rSGi9oPyME7h+V9JosMubLSbTGw/e9oC/LwV6gZxnrxdH39gI9yzFe oB9zEzvaa9eeHe3p47xAH/c/sKO9cQd4gX7AV9iX6QX6zNuwo719vssL9P9hvcyju6iuOH5n3swv C9BQSUlJ0AhSEgJhCSD7OQnIZl2ohwYEWooCR6FliREtKQ0QKJspBIoohCZl0xNE8JcSE7IIVbAU WXJaURQBQXpaDxoKsjQlc/u9b2Z+WcDwR/s753PuzPu9fd6793s7NTOPx5qC8seazgMaaiNYAR0F vcb/gL/KgIW2pjjYOtgIsNrVcTzDraPrjQFJIBPg3dkPttbD81G+C89fNS6vQ58ONDr/DbYf2AEw B2cVyqABeRDq1OK9GxCdBi3ojPPatQSReIZedXoAB1wEMUDa5Lnj6fYydnv0h/9pmre+y3iWvOJV d+4M3ejchJ2ENt+vX4PeE8kvcvEe8OaN9dMIF4a25JngecBgIvgZyPT2aALaHPP6wVz4BTDM9Qu8 CXc1Td2CP8RM7RjaG7iHpoq1OmmfG29lk/JiRDJ8ZSE0fDfJS9Vefs3qSI+qfJRvphIrGXp6ONch Lt2wtqN+Am0I9IT++TVvhd9O0VxHHEuBr99E83SM6AjfXUItZQwrCn4zjwbDn27TfnYA/h/Af5AY JnmnjqmIBRFtoStiaBP8WybmkxAWhH6ZivxzHa+20vnl8ATol1Q+FDjFmXZbXhKxiPeHRcNnX+d0 xKtku5A+tW7SnFD8m2SQNZe6+Tb8M+idOGjJofSElU+JMl5gnsROp19obE9rIc8px17OA2/iW0wl HWNvIZ+49YjMWcc+aDTJT13NxPdhTiWIU0WYj4P5bAtpRaZ5yNkGB64grtdSl/COfNBeBn+eTr/F WAPdMfkbxOk1EiN1/0Mwf09DBpZgfyaT4VvRG010aWt7JpepBbzd1aVc4evTUB9FXGnH8TZrlHG0 qa7xdVRIU3ha1R/DW88xbRE//fXX2ya6Ywjdp5ZRlP0UfS664zbrz6kW33Ym9q+URoomCDxLI+0t sP3oSzuZFluJ9CU0+OKwgVxmd+btos/sNVgT9JqcMXsWHQ2bQA/g+yHf4nXed1pLWidyOuwo9/7z r9y74QRRBt1tQHXzdTc3pDOub3HETxxw69RVwJ5CeSrs++BP7n2msWgHX+asxzP8joE7TVs9il2M h0ArKWuwz9Va0ze2HbyzJvv4rqy/iW3V5F3dOXfTmlDeqUH5Mdy1gpAe9vXkHS0X+O84V8uhpTJD etbX0U0stGgV/m/T2PLjrnVYnzWc46bW19WNLf/be1ffpl8b6Onj9TmKto30dWPLESF9fTdbn9us dtdDfbGeJ2FjsJ5rTXR7omfVbXr+gkHYH/hQKhYbKCKsTdbvWi83rAhZT5eHtH1juwhrvCjzkra6 nuS3A5zNVm+M1Rxy7oA9En5/pD4X+Q3R+v4O2DspF2wMfETZoMy3kis2R2A15YK1YeWUDcoa2BOC zgtchjV4DqEyaLlg/Z6yQVkDe0Lj5hm3gTEPg2v+eIGrmO9VzPcN6P9msAdRXuAI6ruckPyjOQJ5 GCePLoRVYpxKtLmGca5pe0Lw9z20l96++Ovz5xsa3+v3f/6ON/k/zXG37/L/Wndzc2+Im9tQmmcP wbZsPGfZN8w7CmIoiqrxLa+DavFPqH/BxejT4OwM9nDfxW8BdZIugWrUvdejz23n4COerfHe5S4K AWVYAYUxd9IGjPdHF+OZO+7PVcMS3xS4BnuY4gQvJ6u0amif+HeN5/vC53I1fMGT4kfF14QTV+GO 77IO0PR6zeeC9bTAXS/E/++5/o4S4JNSPVtiPcwXBKy3DjiYZyfQB5hgPYgGHfDfz2GRFxoF3r5H oqxGdecdYBueEQ+pN3gGsa3E08mipUUPx7rl/rycSN/3qp68xsrjNaIb1DBokM345t/lQwK0goAY RBEqjJLUTryn8CfWB6AF6shd+DPqJ3lsgA9NpwfVUpR/7TECbWpAP4pWkfSQukRLoOFm2AtoIfb2 bfVTegm+4SXVj/9lVvNphYhuTed9KhltemFuClb6uE5r1RauUGPpaet39LSaSCvUBHASpGlWQ8Od MT/lWjOGVphl9Lq6QjkqBfpjOS3B2ViprtJSdRR1grRL9IjKQnkMXVGO0d9aZTyqekLP+CTSUjOB ZphZ6KsdLQO/Mb6gF8EcczT1hTqYaKbSbJVOs8wkMJqyzGjKgM0BL5rD+BNjPL1ijkc/qygPfnGp OYRWmqfoWXMEKeNjWmgOQt25tMBM4JvoL9K4yefN8fxPcwg09wjOMD7mc7CHzbl8GnV+Ykfwh1YO VVq10B3PI77k0/vWN/yFdYQqrBu8FP8hz6krAvj2dQfwfb+2njNWqknQ0/jw4cC35k4Aa/zYLdPP yD4I5fKT8y7xHt96sn0cPtqGngvX2jJf/kObDNEJYLvEXsRrS12kKegFeZAj5y/a1dp8BPezT+gO Sdtc6Ot4GdIpRR3kdNzKnMN/xftOrav03XA24b61wHO0hVwNY7xpnuUCGQv35riOr8insL+J6iAX 2Rv5XbMzH5L7ps/1JepidcHd8vs76Wyyyl3dg/ZvyF2Wcl33Xo7V/VY7hRLvEaNL3f6h+VwSRI/p mBDP00RT63iXyzvMHzrv6XuQy7vk3JixOAex1MN8grLkrBhT+WWw21yO8vGUi+88E6wDo1x4g1fW 1TiIsbvSNJBhJvEUnKvZoA/O03ycwyzsbC/0lY9zZaCvGeZTus8ikIOztciooXQwzowTy1fQDvkt /whA7zqfwxbCb8w3x2Gt7eBzRkOXjOAjeD6nNaarc9vIN4I/+epuce1OGqCRHrhL/L5r/QXUXzQg 5jbd+hC5o6eLsdf7xKfaRaKL9ZkUvfg9+OIt+G8SctRoyVPFot/H/fPm6bVS38KnDMIYMX7Ohf2p AnvBabDe3TeGT3WQR9AY8aNh36H7cQbOSN+ebu6r74H40wv0iKvt4E99bV6vtbUmlDwRd+ovajjO 5y/oYfQ7A+C+UgKIxHivYZxZWrev5f0Sb+y1NAtlH+C/9rDnwQ3wGfg7OAhqwUXvOYj9miL74utV +5f8Ftrm2FXQ35mung1MowdwFvaoIfSCUUJbwGW0eVVAfFlkZBmRnClOgSjiIl3BTV5MNu5sa+pB 4jNO4dRZeFfouaZyKnfQOdttv7fGUlpLVUE9QSooBHuAjfBeXjx8eEpqKWzX7toGE7uklOk/Yjun LExro8qpAOwGx4Fo9XKKB6YqN3djw+JRuSzYNk63Kg0OHeo9PNjffShOSk45mxapSqkGmKpUlVGi 26o4sXvK5bQoFGCF6m0ygIJnjFdV6h3qqiu9E+yUlFKmStSi4MD4qLQYVUytVRAHIEhjwBxwDgQw u2I6C2oAA4vuUa8Hz6+Ir1IFxkz41Xj1Cq0LN1Jbxmdb2baZbWYrc3K5uYcM3m/EBNtNTynl/cXT Yqdj3guN56SgUi0xYmRCEEO7g716p5bCdNemGPukbecE13b4gWvb3/9fVqs+Nooiis/sXm+3H0uv RwtXSm+ut7crdKHldg9aDsvtlbtWPaGUgrmD0qKiUiFSOUokfBRUEm2C/KHR+AVqNGl6le5t+bhC AyYmJv5BMP5nYpRorcYEgsYY/MDzzVwDSoz+48zN++2893vvzcy92zmGtlxgVxtvTcI5WTCucGOn eZOvWwiJfhwPqy36JP807SgsotPEVLoNbw722b0VCNfGlQajEqb0i+m7wB+GMxpichbVNeouauvc pJdRXNOp+ym2r9Zn0RBtRgmAWay2625lVZKRbN2gPna94abUphbdfR4CtiAj/5NZpbQYHmXpJt2l qCHdqdQbZZA/l//DDCiLjbJwo6G/qowo55SPFUeRsgyserNeHV4Ybg7zHmUuBDy1QGlWHJP8YdqR IiLTRcoJXTx5inClZIkBu/phnLBtH6IdESBVkaZeYUzgep1jTs4/Cvzi0UZI/LlZMkr8ul/W1tEt DdoLDQZ+eiiDttcH0b4969UM3QuHQStt8Mz9HbquLjKiJflr/CBaDhu7AagBfg8uYcMHnuORNt1L sTGsu2mkBoNNoUpZfNVw0Om994UowkEyqDM8AGZZreFXl+i6XzWaIf8Ns0SF5MVqTZ0+dAFSYX6Q dqTCxhpIE3E2OiNO/gQ3xl3kLnOOE/wYf5G/zDt2AusYzxO+kY/wHXwvX1QeXcpdhS+3F+QJGF/C 4OEKu4oiMHay2RjUEEYdICEi/OwbQUbYU4RWMbP03mGhvw/M27zNXYVuQYco5rwmjJZgE3MYo2LM wb+RuXPhReGuEM1oKbePk1EISbiFySYma8x5IelYSHo2JG0LSamQtD4k3ROSFoWkBSEp6uKWIh+S 4NIDiX9n8kMm1zK5yJznk677pAs+6SWftNcnPe6THvRJvT4p5pOiEl6Jm5GEWphcwmQtlfjmqfLV 5aj4Ir6JViOJz8LRViHCVdlqiOS4SluNAIi29zyJVnNO5BUxWItgZGA4ZpBHxEH1GG5ueAvg35CM HwA8aav1JIffL0CGxoxW4WGkUi/8HvJiBfBdlGHzd1CQ4dsz+KYt7wC3NyhEi/Hr8FcGkkACgyXZ Y6sNYN5hB3eRaAXeDjmpehsKMFocSoRiZMZNtr3HySSuQ16OTtEpdS+5Cf6KTX41ciK2yS+BHJex yXdqDsPsG7C9ZpOpIMzMUvJ1cIp8FXyefKrmOHyGfKJeIpeUnAOIZ4OMeFJlQUa9oAT+8WAPeUU9 Tl4sxB4KMNIzcJgZczZ5GrY0IE+RfgizVd5FegqhNstsBRum2awL1gPQYTDlGpUGnk3ag4+RNjVD VgUvkZVyDwkT0J8hywNTpElmuRpk5l7vhc3BShbKGXJXMEM2NE3ij5CAh2BoZoMwKDwp9AmPCgnB FJqFZcJiwS/UCZWiW3SJs8QysUQURafoEDkRiZW5/BVTo9dkpdNFwemg0sGeXRyVXOEW5bDIwX1v zeYTXKKr1WrSEjkhv85q1hJW8dpNySzGL6RwwvrgYZR4yGf93CXncEnnRqtIbsWWO4ES61s9QLa4 53IYrU/mcJ56HKmx3KuScIlh88jRGoqpI0dTKTRnT8QTca+sWN4W+wexZUZqt5tH+3vz1FovJ7qS 1khtytLpQ742lbDau3zdyQnuALcvHpvg9lNIJSdwG3cgvo7qcVssdYsGBbUfaFDU+wu0QeSlNKju QUbrKdAIeANNoUBpw4gwGsHDlAZlRnnZDInHsoQwjqMfZRgn4+gvcBTGmf4Lp8iFphlnusjF0s1l lEAAKMEApWT9ASBkA35m7rxtlgvmAwXzAWZ+4rbZKJhHCuYRMGv/U3uk9b8Y8b6uVpxYm8yKqDW1 qruAc1z9K1kdVJxuOVRzDs/nP0OlWsoqkVutUrkVRSIezXU3btzsLLOcoBNgUPqKOs/BmnMOBEdO 6WWglmZMi6OLo9QE5UxNs0BdPmPyHFxRB0mGZ0wuUFdAEqjjhi6oy+1xq34LgBxLIU+8LwafGUhD GxgYSKd3D9AGDmpXwmrp3JjMqmrcqt4SS2lxT19s97/sHyWsenCKUCdBiFsmOKXTGvPTtIHCA8Sm j3e23QUdoyItfUuPadw0jaJhONJc/otx73x2657WDI+qGRP56/zhrNug5BRO0/WBP0QrxEizuGl4 DaA/BwBs3AbPDQplbmRzdHJlYW0NZW5kb2JqDTEwNCAwIG9iajw8L1N1YnR5cGUvRm9ybS9MZW5n dGggMTY2L1N0cnVjdFBhcmVudHMgMC9GaWx0ZXIvRmxhdGVEZWNvZGUvTWF0cml4WzEuMCAwLjAg MC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQwIDgyOCAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDgyMyAwIFI+Pj4+L0JCb3hbMC4wIDc5Mi4wIDYx Mi4wIDAuMF0+PnN0cmVhbQ0KSIkUjr0Kg0AQhPt9ii21yN2e0RwBsVAPMcTK7UIKiT9IyBmi4SBP n7OZYb5hYGT77iymqbx2dsJgsIcqD2VT1CUSZlleFgg5A4noiCQo8pSE1vgEWbWE0wqSmVAhj0DI D9+z84K8oqLdfzv6+LBPd4sTJXSsFUZnQcnphPyCW+CcC3UciKGf18WOy9f23TYvVthhk7Ux4Z0v YBhM4x/9BRgAT8gsrw0KZW5kc3RyZWFtDWVuZG9iag0xMDUgMCBvYmo8PC9MZW5ndGggMzA3L0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyRzWrDMAzH734KHddDcZJ1DoUQGN0KOeyDZXuA 1FY6w+IYxz3k7SdbpYMZEv2M9JcsSR66p87ZCPI9zLrHCKN1JuAyX4JGOOHZOlFWYKyO11v+62nw QpK4X5eIU+fGWTQNyA9yLjGscPdo5hNuhHwLBoN1Z7j7OvQbkP3F+x+c0EUooG3B4EiJXgb/OkwI Msu2nSG/jeuWNH8Rn6tHqPK95Mfo2eDiB41hcGcUTUGnheZIpxXozD9/qVh2GvX3EERTPVNwUZAh PjKTsNk9ZCZDvGfeE6syMxniHfMuMcerFK8Us0rMWpW1XEulWoprqVSrvs9Mhphz1ilnzTnrlLOu mes2tVgV/NIit3jtJTVLO4HbJPUlBBpiXlyeXpqbdXjbrZ89kCp94leAAQDp25MsDQplbmRzdHJl YW0NZW5kb2JqDTExNCAwIG9iajw8L0NvdW50IDE2L1R5cGUvUGFnZXMvS2lkc1sxMTUgMCBSIDEx NiAwIFIgMTE3IDAgUl0+Pg1lbmRvYmoNMTE1IDAgb2JqPDwvUGFyZW50IDExNCAwIFIvQ291bnQg MS9UeXBlL1BhZ2VzL0tpZHNbODMxIDAgUl0+Pg1lbmRvYmoNMTE2IDAgb2JqPDwvUGFyZW50IDEx NCAwIFIvQ291bnQgMTAvVHlwZS9QYWdlcy9LaWRzWzEgMCBSIDIgMCBSIDUgMCBSIDEzIDAgUiAx NSAwIFIgMTcgMCBSIDE5IDAgUiAyMSAwIFIgMjMgMCBSIDMyIDAgUl0+Pg1lbmRvYmoNMTE3IDAg b2JqPDwvUGFyZW50IDExNCAwIFIvQ291bnQgNS9UeXBlL1BhZ2VzL0tpZHNbMzQgMCBSIDM2IDAg UiAzOCAwIFIgNDAgMCBSIDQyIDAgUl0+Pg1lbmRvYmoNMTE5IDAgb2JqPDwvQ3JlYXRpb25EYXRl KEQ6MjAxMjA1MTYxMTI3NTgtMDQnMDAnKS9DcmVhdG9yKEFkb2JlIEluRGVzaWduIENTNS41IFwo Ny41XCkpL1Byb2R1Y2VyKEFkb2JlIFBERiBMaWJyYXJ5IDkuOSkvTW9kRGF0ZShEOjIwMTIwODA3 MTM0MzM4LTA0JzAwJykvVHJhcHBlZC9GYWxzZT4+DWVuZG9iag0xMjIgMCBvYmo8PC9zdWJoZWFk L1AvU3RvcnkvU2VjdC90eHQvUC9FeGhpYml0X1RleHQvUC9Ob3JtYWxQYXJhZ3JhcGhTdHlsZS9Q L1RpdGxlL1AvQXJ0aWNsZS9BcnQ+Pg1lbmRvYmoNMTIzIDAgb2JqPDwvUGEwPDwvVGV4dEFsaWdu L0VuZC9PL0xheW91dC9MaW5lSGVpZ2h0IDEyLjA+Pi9QYTE8PC9PL0xheW91dC9MaW5lSGVpZ2h0 IDEyLjA+Pi9BNysxPDwvTy9MYXlvdXQvTGluZUhlaWdodCAxMC4wL0Jhc2VsaW5lU2hpZnQgMy4z Mz4+L1BhMjw8L08vTGF5b3V0L0xpbmVIZWlnaHQgMjEuMD4+L1BhMzw8L1RleHRBbGlnbi9KdXN0 aWZ5L08vTGF5b3V0L0VuZEluZGVudCAyMi4wL1N0YXJ0SW5kZW50IDIyLjAvTGluZUhlaWdodCAx Mi4wPj4vUGE0PDwvU3BhY2VBZnRlciA4LjAvTy9MYXlvdXQvTGluZUhlaWdodCAxMi4wPj4vUGE1 PDwvU3BhY2VBZnRlciAxNC4wL1RleHRBbGlnbi9KdXN0aWZ5L08vTGF5b3V0L0xpbmVIZWlnaHQg MTEuMD4+L1BhNjw8L08vTGF5b3V0L1N0YXJ0SW5kZW50IDUuMC9MaW5lSGVpZ2h0IDEyLjA+Pi9Q YTc8PC9PL0xheW91dC9TdGFydEluZGVudCAxOC4wL1RleHRJbmRlbnQgLTE4LjAvTGluZUhlaWdo dCAxMi4wPj4vUGE4PDwvTy9MYXlvdXQvU3RhcnRJbmRlbnQgMTguMC9UZXh0SW5kZW50IC0xOC4w L0xpbmVIZWlnaHQgMTIuMD4+L1BhOTw8L1RleHRBbGlnbi9DZW50ZXIvTy9MYXlvdXQvTGluZUhl aWdodCAxMi4wPj4vQTQrMTw8L08vTGF5b3V0L0xpbmVIZWlnaHQgOS4wPj4vQTQrMjw8L08vTGF5 b3V0L0xpbmVIZWlnaHQgMTEuMD4+L1BhMisxPDwvVGV4dEFsaWduL0NlbnRlci9PL0xheW91dC9T cGFjZUJlZm9yZSAyLjAvTGluZUhlaWdodCAxMi4wPj4vUGEyKzI8PC9UZXh0QWxpZ24vSnVzdGlm eS9PL0xheW91dC9FbmRJbmRlbnQgMjIuMC9TdGFydEluZGVudCAyMi4wL0xpbmVIZWlnaHQgMTIu MD4+L0E4KzE8PC9PL0xheW91dC9MaW5lSGVpZ2h0IDAuMD4+L0EyKzE8PC9PL0xheW91dC9MaW5l SGVpZ2h0IDE0LjA+Pi9QYTArMTw8L1RleHRBbGlnbi9FbmQvTy9MYXlvdXQvTGluZUhlaWdodCAx Mi4wPj4vQTYrMTw8L1RleHREZWNvcmF0aW9uVHlwZS9VbmRlcmxpbmUvTy9MYXlvdXQvTGluZUhl aWdodCAxMi4wPj4vQTA8PC9PL0xheW91dC9MaW5lSGVpZ2h0IDEwLjA+Pi9BMTw8L08vTGF5b3V0 L0xpbmVIZWlnaHQgMzYuMD4+L0EyPDwvTy9MYXlvdXQvTGluZUhlaWdodCAyNi4wPj4vQTM8PC9P L0xheW91dC9MaW5lSGVpZ2h0IDkuMD4+L0E0PDwvTy9MYXlvdXQvTGluZUhlaWdodCAxMS41Pj4v QTY8PC9UZXh0RGVjb3JhdGlvblR5cGUvVW5kZXJsaW5lL08vTGF5b3V0L0xpbmVIZWlnaHQgMTAu MD4+L0E3PDwvTy9MYXlvdXQvTGluZUhlaWdodCAxMC4wL0Jhc2VsaW5lU2hpZnQgMy4zMz4+L0E4 PDwvTy9MYXlvdXQvTGluZUhlaWdodCAwLjA+Pi9QYTcrMTw8L08vTGF5b3V0L1N0YXJ0SW5kZW50 IDUuMC9MaW5lSGVpZ2h0IDEyLjA+Pi9BMCsxPDwvTy9MYXlvdXQvTGluZUhlaWdodCAxMC4wPj4v UGE0KzE8PC9UZXh0QWxpZ24vQ2VudGVyL08vTGF5b3V0L0xpbmVIZWlnaHQgMTIuMD4+L1BhMSsx PDwvTy9MYXlvdXQvTGluZUhlaWdodCAxMi4wPj4+Pg1lbmRvYmoNMjExIDAgb2JqPDwvTy9MYXlv dXQvRW5kSW5kZW50IDguMC9MaW5lSGVpZ2h0IDEyLjA+Pg1lbmRvYmoNMjgyIDAgb2JqPDwvTy9U YWJsZS9Db2xTcGFuIDI+Pg1lbmRvYmoNMjg0IDAgb2JqPDwvTy9UYWJsZS9Db2xTcGFuIDI+Pg1l bmRvYmoNNTA5IDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDEuMC9PUCBmYWxzZS9TTWFzay9O b25lL2NhIDEuMC9BSVMgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgdHJ1ZT4+DWVu ZG9iag01MTAgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDY2IDAgUi9M YXN0Q2hhciAxMTkvV2lkdGhzWzI1MCAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNjExIDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgNTAwIDAgMCA1MDAgNDQ0IDI3OCAwIDAgMjc4IDAgMCAwIDAgNTAwIDUw MCAwIDAgMCAzODkgMjc4IDUwMCAwIDY2N10vQmFzZUZvbnQvQVRYU0lLK1RpbWVzTmV3Um9tYW5Q Uy1JdGFsaWNNVC9GaXJzdENoYXIgNDYvVG9Vbmljb2RlIDk4IDAgUi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTUxMyAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUv Rm9udERlc2NyaXB0b3IgNjYgMCBSL0xhc3RDaGFyIDExOS9XaWR0aHNbMjUwIDI3OCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMzMzIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDUwMCA0NDQgMjc4 IDAgMCAyNzggMCAwIDAgMCA1MDAgNTAwIDAgMCAwIDM4OSAyNzggNTAwIDAgNjY3XS9CYXNlRm9u dC9BVFhTSUsrVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZpcnN0Q2hhciA0Ni9Ub1VuaWNvZGUg MTAwIDAgUi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTUyNyAw IG9iajw8L08vTGF5b3V0L0VuZEluZGVudCA4LjAvTGluZUhlaWdodCAxMi4wPj4NZW5kb2JqDTU5 OCAwIG9iajw8L08vVGFibGUvQ29sU3BhbiAyPj4NZW5kb2JqDTYwMCAwIG9iajw8L08vVGFibGUv Q29sU3BhbiAyPj4NZW5kb2JqDTgyMyAwIG9iajw8L09QTSAxL0JNL05vcm1hbC9DQSAxLjAvT1Ag ZmFsc2UvU01hc2svTm9uZS9jYSAxLjAvQUlTIGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0YXRl L1NBIHRydWU+Pg1lbmRvYmoNODI0IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3Jp cHRvciA4MjUgMCBSL0xhc3RDaGFyIDExOS9XaWR0aHNbMjUwIDI3OCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDUwMCA0NDQgMjc4IDAgMCAyNzgg MCAwIDAgMCA1MDAgNTAwIDAgMCAwIDM4OSAyNzggNTAwIDAgNjY3XS9CYXNlRm9udC9EV0pVWUUr VGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZpcnN0Q2hhciA0Ni9Ub1VuaWNvZGUgMTAyIDAgUi9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTgyNSAwIG9iajw8L1N0 ZW1WIDcyL0ZvbnROYW1lL0RXSlVZRStUaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRm9udEZpbGUy IDEwMyAwIFIvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDk4L0Rlc2Nl bnQgLTMwNy9Gb250QkJveFstNDk4IC0zMDcgMTMzMyAxMDIzXS9Bc2NlbnQgMTAyMy9Gb250RmFt aWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0IDQ0Mi9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNz4+DWVuZG9iag04MjggMCBvYmo8PC9TdWJ0eXBlL1Ry dWVUeXBlL0ZvbnREZXNjcmlwdG9yIDgyNSAwIFIvTGFzdENoYXIgMTE5L1dpZHRoc1syNTAgMjc4 IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgMCAzMzMg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgNTAw IDQ0NCAyNzggMCAwIDI3OCAwIDAgMCAwIDUwMCA1MDAgMCAwIDAgMzg5IDI3OCA1MDAgMCA2Njdd L0Jhc2VGb250L0RXSlVZRStUaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRmlyc3RDaGFyIDQ2L1Rv VW5pY29kZSAxMDUgMCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRv YmoNODMwIDAgb2JqPDwvTWFya0luZm88PC9NYXJrZWQgdHJ1ZT4+L1ZpZXdlclByZWZlcmVuY2Vz PDwvRGlyZWN0aW9uL0wyUj4+L091dGxpbmVzIDk0IDAgUi9NZXRhZGF0YSAzNjEwIDAgUi9QYWdl cyAxMTQgMCBSL1N0cnVjdFRyZWVSb290IDEyMCAwIFIvVHlwZS9DYXRhbG9nPj4NZW5kb2JqDTgz MSAwIG9iajw8L0Nyb3BCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vUGFyZW50IDExNSAwIFIvU3Ry dWN0UGFyZW50cyAwL0NvbnRlbnRzWzgzOSAwIFIgODQwIDAgUiA4NDEgMCBSIDg0MiAwIFIgODQz IDAgUiA4NDQgMCBSIDg0OSAwIFIgODUwIDAgUl0vUm90YXRlIDAvQmxlZWRCb3hbMC4wIDAuMCA2 MTIuMCA3OTIuMF0vQXJ0Qm94WzAuMCAwLjAgNjEyLjAgNzkyLjBdL0dyb3VwIDg2NiAwIFIvTWVk aWFCb3hbMC4wIDAuMCA2MTIuMCA3OTIuMF0vVHJpbUJveFswLjAgMC4wIDYxMi4wIDc5Mi4wXS9S ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW0wIDg1MyAwIFIvSW0xIDg1NSAwIFIvSW0yIDg1NiAwIFIv SW0zIDg1NyAwIFIvRm0wIDg2MCAwIFI+Pi9Db2xvclNwYWNlPDwvQ1MwIDgzMyAwIFIvQ1MxIDgz NCAwIFIvQ1MyIDgzNSAwIFIvQ1MzIDgzNiAwIFIvQ1M0IDgzNyAwIFI+Pi9Gb250PDwvVDFfMCA4 MzIgMCBSL1QxXzEgODQ1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQ10vUHJvcGVydGll czw8L01DMDw8L01ldGFkYXRhIDg2NCAwIFI+Pj4+L0V4dEdTdGF0ZTw8L0dTMCA4MzggMCBSL0dT MSA4NjUgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNODMyIDAgb2JqPDwvU3VidHlwZS9UeXBl MS9Gb250RGVzY3JpcHRvciA4NjIgMCBSL0xhc3RDaGFyIDg5L1dpZHRoc1syNDAgMCAwIDAgMCAw IDU3NCAwIDAgMCAwIDAgMjQwIDM1MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDUxOSAwIDUxOSA1NTYgNDgxIDAgMCAwIDIyMiAwIDAgNDQ0IDcyMiA1NzQgNTU2IDUwMCAw IDUzNyA1MTkgNDYzIDUzNyAwIDAgMCA0ODFdL0Jhc2VGb250L1lSSUdHTytIZWx2ZXRpY2FOZXVl LU1lZGl1bUNvbmQvRmlyc3RDaGFyIDMyL1RvVW5pY29kZSA4NjMgMCBSL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNODMzIDAgb2JqWy9TZXBhcmF0aW9uL1BBTlRP TkUjMjA0MzIjMjBDL0RldmljZUNNWUs8PC9DMFswLjAgMC4wIDAuMCAwLjBdL0MxWzAuMjI5OTk2 IDAuMDIwMDA0MyAwLjAgMC43NzAwMDRdL0Z1bmN0aW9uVHlwZSAyL04gMS4wL0RvbWFpblswIDFd L1JhbmdlWzAuMCAxLjAgMC4wIDEuMCAwLjAgMS4wIDAuMCAxLjBdPj5dDWVuZG9iag04MzQgMCBv YmpbL0lDQ0Jhc2VkIDg1MiAwIFJdDWVuZG9iag04MzUgMCBvYmpbL0lDQ0Jhc2VkIDg1NCAwIFJd DWVuZG9iag04MzYgMCBvYmpbL1NlcGFyYXRpb24vUEFOVE9ORSMyMDI4OCMyMEMvRGV2aWNlQ01Z Szw8L0MwWzAuMCAwLjAgMC4wIDAuMF0vQzFbMS4wIDAuNjY5OTk4IDAuMCAwLjIyOTk5Nl0vRnVu Y3Rpb25UeXBlIDIvTiAxLjAvRG9tYWluWzAgMV0vUmFuZ2VbMC4wIDEuMCAwLjAgMS4wIDAuMCAx LjAgMC4wIDEuMF0+Pl0NZW5kb2JqDTgzNyAwIG9ialsvU2VwYXJhdGlvbi9QQU5UT05FIzIwMTY2 NSMyMEMvRGV2aWNlQ01ZSzw8L0MwWzAuMCAwLjAgMC4wIDAuMF0vQzFbMC4wIDAuNjc5OTkzIDEu MCAwLjBdL0Z1bmN0aW9uVHlwZSAyL04gMS4wL0RvbWFpblswIDFdL1JhbmdlWzAuMCAxLjAgMC4w IDEuMCAwLjAgMS4wIDAuMCAxLjBdPj5dDWVuZG9iag04MzggMCBvYmo8PC9PUE0gMS9CTS9Ob3Jt YWwvQ0EgMS4wL09QIGZhbHNlL1NNYXNrL05vbmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9U eXBlL0V4dEdTdGF0ZS9TQSB0cnVlPj4NZW5kb2JqDTgzOSAwIG9iajw8L0xlbmd0aCAxOTMyL0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiYxXa29cxRL8fn7FfEK2dPd4puctIaTgGBRkExMv QgghFJmEV5JLEt1c8e+pqj7LGgMRRMJbOz3dPd3Vjz07v4nh9m1IIby9fbWcfQr4w9ulWA4xpDFD S3FNI7x5tjxfzj756Yf/vXkWPvzw7Or80UNIfPTRxw/Pw/JaF0pNa8pV11Iuay2V974KryCQZlpj zKVPXIPq3NaaWip5hGJpnbWXZB06YK7XammG25fL2aOXMTz87/LFcnEFO/cdSAcHvnAX1txCjjAE B8ZYW9n8aHf84Pd54r9ydKSPmmGbCuqcoxZogR9ptIp3uR/pPX7YPT9CQihi+cdQxHX2ZLH1ows1 4avisejDesJlxCIiSBbr5oO9x4d834e4Wa9/to78Lon2wv8D852Y77NP3hvncld3DA3BKQPUsMC0 Vjtqbymvo6fZwAO9bea1Mqi1hh1iMmKMoBO+WFuqc1janpbvmr/59emrP4zXo/GP98vZ+U2+S9h9 +g5Wwv750rIs4g+CPxDKWdZpw8L+5XISTvc/Lxf7v9PfDvqp/ahuh+Djw20Ap6gXfza99aj3m5Mv 948uH+2/Pu3lZHdz/uDyItxcPXhymsbJ/nSXIgx/u//sHyz3v7f8F4PprsGri/3Fk/Dw4vry8WmJ J19fXXy+vznN8eQ/p9bfa278O3O53zV3ffng8019hvoPwvWTx9ePbx5c3vzZ0j3GzIOts+sXT2+f ff/pm6e//vjTbcBpDDrQtddLtmBtLSg/a51UaqjPmA+MisH//bK8hrdiVBi2DoslNFstNfUJHvD/ iPhqI4XdWC1PQCgDS/m3QOkB3y47G2tt4yiBGhyxHRVsOFJ2+8wjtK/D1Xu6j6rd9obj4VqUrudg MShc7lD4+LBW0SLnDCWvKKF852GgYgk4rS28WPD8VgOCxn6xDjQyOITPvy1lTZHf9S2nv5HFLSG2 hm4GRYB1VkHYIRpCuXeiNhNRiXpHXPscwqbiNTQVtKfBN6NnCrQ6KIqm5YcFN3bQ5yjjEUADrKIs kszIr+gOkpXoNCMw9Kh3i4QTMQLB00ZFdESotkSE7uGKCj4A59l5WgqyMNfehCo76ASzXLSORhin 6RBGkSBDHKVG6duIsZYG0Y42rEODcqA4pDV3JL6t8w/ZOol71mmLOnWWrJwjQMgIObQmNHTwCBHJ rrTiWYWoIhJEY7okXytceTp7IZpIyq6scThQKJHvIUUzZR6imKS1EphAw/BzySSlZTapqXKnGKm/ jtSEWnYH6tBpjXIgm2zUJtfTkGxNw2U15nC3N8+m/MuePYaJzSsnj9aAceCKwPAUYQLKJbtsITKk zWWLTuNQFnrtRJilinMXsr7JkhDAJUmTO5Sce+ZPs42lIwup0mFSIUGCdqR1pQ4GXaIdTtNXYxtx hECVLoQ6BOqxbbKoCeDaRK4EIaDopTCGUK7J45WbcMlb5LmjIDmZ7MeTwPCE53qWGuoYaCAmO/g5 HDmhKueqyyaeslaBajciLDRCebrs5EoEzIe3NdMqQs4QNRiXD7ltoskfZzI6mCSgJhtkHxhZxsGD 5lnRacUjmBXmE4QYylH2eJJcWzy7ZB0112vOi1k2b2MW/9hwGAURuTqoXgDNqtO6dImyD/E0K9ug h6LZohcdGzq7otfjUHlg3yTKrqYzZ1pJpQZdQjWvexVdAsi6Xo1iR+tjlZPjaAV1en5pktCTVBXa SmKwHTY/Na6kSUFlGpgktNLGRk04OSy6Z3CS41F19o4xGfQXvW4oYmIrG7brjSw0EDqKCsNpk/r0 q7nIi4ja3GnEEFk8BKmLOJkNDvmKokarClIy3eypO3ln1t3eh8ogiWTDVEDswqR98Zpg8ACtesXQ qK+drIGhi+nQGpVUOOjtMBcPEmj5To1z6Cp+KRCwrWN2SE/UZ2tbM54skCQRFl5UwIZPjuqfm0sa iwVbuFzjvh41wIAajSMJtnUMJR9pwKK643iTTsMw3dHfHibIMlxpRzlN5NpbH5400YSSvyEaz2JV Q41g/VBQCdC7sCrY1k4TDGGcKxAGHcMjiIYBhnJGNZdrYwTMKO8TGbTtXs6HhcDqVs4FdOJ+MFV2 hcYKuyhrkCCPtBXzEDQXhC5XQhBlem5VX+RikotkZYdXelfhUqafW9uYn9hZZtNgqPAUmnw0Q0ER l1R7eCWYhb7wglRGxYDPaA9CHOZTr+aRgM28lRpSgwHPyketQidAFMgoB/zA6Crurn1yriTXAKuS OILw7XwdUPGKiMDem9nB5oHQWXUynSc+uncqRNV9HVkwVXWenBTNxI2t+S5gOp8Ux4KLUoQ21mrT CkKWE7IzYz9p2klRTKz2qbFzK3HjOORyYzpX25vS6uoaXmJR425Hp6dWrkkisdODcYaZ2Fwd6hux M1Km86UD8cJWy9HkTy2OTaeYslx5S94O8VLgzrjz4Tlk1Ac7D7LAXLLMt6WjYFJkLpD4baapA5Az 8x2h2xBw1RnojCKnxUhmcAjCuQrD7Nr6heDLIwiHPANGNiLcKhSMma4haKAaIbcBdlVeazphMzJ2 7sI1lxMKctyi3y3hdwEGADwkW/ENCmVuZHN0cmVhbQ1lbmRvYmoNODQwIDAgb2JqPDwvTGVuZ3Ro IDE4ODYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJbJdbbmTJDUT/tYq7AV0n853fswLD SxBgzIfagDHAAN69TwSrpJrpRgOtimImk88g67qu6z3uMddV933Gvt7r3csRmnVc/3tDeo5x7UNn 95pXXffu/fpT0t7rVed9ypQ0Slx13IO7SAtfo7nfax1JSztCjT++G+Oq7T6+2fcSGKsKnWVRrfX6 0Ml9jEvbks4uEDFSTdsWBm+Uuz6UjnGVu5XHCw015d51Gq644q5btpTV+Xz6lmBXnZPHtmU1ndvT srn1Wtyrh2FbyNYyGOjiIMYC+qpWsldC2eOAyB9sBBCNyp/WOVhRhTuc17kqg+vdZIC9BfSVVm25 zTV7dopjQHjxWe8jKXsrWuXOgwVvBGIJRWA+WUVn9LuOfv0Axm6CnXAr4yEwo5F4PhQ+BMkMQrTv Qhz4U0kXUq6WKrMbMY1FeOzEIQZI5704JumR4s7jtfBYR7juhZ3AuhBVpb24ArlHivbRvUnU0DrC 8S1+cvG2y4eLvCAwXX7ISGerqsvAP70wJSyULLdIo8BSuOc91xIMAsjx6upVBVlL9KxuMiTPlRm0 nZB0EMPuPiE70SjjejUyIQP2vQhWU0XUa9yLTkK08WJg7zEgbx9vncyF4ZEsSBW3pFhKJvXUSD9x r/pQy354R7s1SnzX6yQgDltmDTqHl6VKtbWJJ7Ix6qPQAB17VWhV2oGq4LuFD84mzylhYoySHvMi eQQVMLZe5yGC0hblMCm8TvgAMeX2+8Fh43nUmZtSJLp826m9OGSOPB4scBvzAUgtNklFE3Gpvi70 dNKDxBUsF2VjwcPPt3eCK68wHAaCao4ifPQ8YDSMKnjIQVGL7lH4IDLkKFQK9VNtUYZZKKoOA4mx CAPvPt0Z6qtCbLHwkHks64+qbBhHrFwyDU+7m1a1TNYFVEo6sunEP/X1kGel+sJWphUJp3KT03FX Ek8EVLWbXDy6RnxH8KYLnBbluLoYGSatfSmAjQuLGhJfH10+6qMDLX/gRTmSnyN5ObpRXCYguIfA bslVCQd2nNnogyN4OTGXLiN1qu4svXUfCQcdKdkhLzJt2ijKhnYVZdjucrpAsU8vRPPx9u+3f779 94qr8C+uyVN8PYcYC7L88abvfyhFQa8oCWYuVT+xf9AYJ/m/jBwIMVSMqnZNB5JRHHvGl3gJkAep 8wVa+EA9DB1rx59TX1uuTFG/58VkFmF08UHKXyVVpEGl+qEK6zZqjiXZWALDPQScS9bXYSXleB51 sykviBrBC76QKenVtlDzoQsSQEApnnJVhoJydrZ4OBTdUg1RkIhSiLJFa6lG48z0qhMYxafb2rLz UFtPJ9UjqbdnnJvvgqS2uZvtWUn9rdh40ZAWhdHTtWBCvSfd8NrikqU19wcVqw5NG+wm5jUzniyX ym6SVgCO35lKJahlrNJEorWsqRdHcqfBGkCagcXROqXm2Vi5zDglpWYot8liOYAnlpeCaN4/Fh2r 7SGTtJQXVaCtml1prieHbWQVOX9tW0ffO6nERXSsQ9RuHRC9yMdvh28V+FUln43xj9/+xcc/aIzr j4//vPTJWaICCJmGVvl99QlsUGAtVfcRtUETQ5QKn2Dp59vvf2u4LhqBvQfNfUSxT01kxa0zixjz py5dHXWbtWUhf23TKToO0yppp1xDky+hmpEvobtPW7pPpkf2KqJTbL/HC+RvJuP7m/AWKhyKptaj kycV1netSNm5MbNmai5cenJlA/HN0CvCquaqHWG94K9Xn9+IAvXq8TB3I66XPL2ERg6Q+gaTzvnX 0IhLm4vq08uzo7EJ2HtuDJX+cIctbWkGMgG8n/hdy+wWW7sP2Kf78Qp2mg9rwdYydjw+BE22x3ug 4TEUIer4JifVx6utYlzvkVTv8uFAaDBP07m+6J4n8zHVmbbF9d3neFr+QGaZM+NLqj53m/RqLtPw U594A2CvEzdofq1flenSVoLfovfxOhgiKUa0Lg80n0OrQIlfqMG9po1zqys0fl6ys5I8q+6xMpWZ XPSrpvEeRnJJ9lRuXtVU/0jpNmZ6EXv8TvqlNSwD5+r8niAWX1pKsrJWzm5jxFxEr7dfRUYpCC9z 1N1LwckV09+SEmh0aTnSEvyzEnX/1u+zI4/7qxI3m3pNaVGv4bYn189a+IWn3wDsMEcLfX/1KKZP eehLXaxvUF0tX3DXJNMk30jKPMNxbfXxO2bvnIptJ/GmDcV6WkbvULF6unTTvbZaPbZ6zhrHpp/9 RKl21C+pmNFMqmHyAApA5JrxwPoFIBQep3OlWSeH7eypVjWnqqjyes/Ut+cTFK9U/hk6PYamFhDd xl7vno94tfFtZkJZ0NxHu3+BJDxbaaxZZwPa9vzdsfPGF7LWR2iENe7ieVFh8vrU9fzv2q1r+Kh2 eap++DenHJxer6GZ7PShwVOGXYzlab6/kXcL88iXdORmVNn1vpHL2meLozsJj/TaqKLfCE/QHe8n Ev9y62QI7DQMFa9O0xZ7f0nhq5VeV28Xa0aujaqO6/8CDABuej00DQplbmRzdHJlYW0NZW5kb2Jq DTg0MSAwIG9iajw8L0xlbmd0aCAxNTMzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWyX SXJsOQhF57mK3IBfCFC7jFpDRlT8QXpQ+5/UvaDmpb/DA+dBDQgQ4j2fz+eXXb2X55deSZ/vx1e+ khlRNT9B0irJOCdf2tqiF+ea6W3UujhluZHWOTUQWqByCBakq3HmJhOfGpyuVNUN6AOg5hqKtQm+ 59hD5bKRuYmIkGo2Uq7GmeDiKnIRHrJgI8FSKbFU7CnQZwQtDWCisVCVmMvgmIwCKJhxoPeYGEib sUgyf1tALhN8nllfY/VKnROLDUKMFKzFRGClVdYGLcbUWidikzEc1A4I/OsKAlMrroAearnzt+QK KGKxfx+dAWnw1Pvx5/ElsCrJEn0/vsZVyplBFI926Rrcs2cK3SGI1/DFRT9Q86C6JZBrwCSsbYgk MwCnAsEbcrmD+jVawJtgPQA/FQFO1ygBzAOTEkvEj0nEonYNtRmztx8rN/ngOozTS5+MLe9oydOB EYLZY0hYgN8ltWXnPNA0FNSt8nh9yBSM5t7JNBi7qrq7SxFHTyL6ku758/j38c/jvydyEn/Y1WhP Hc8C73fm8PeDIwgKBOBEHfETTtRUXec1qt8BZbYyx5ws103QG+EIRHKmMBcXpN8YybK0wLvt4+dR 2K6WNoMKLvBS36KOwC/UNwn3rvZY6VwjDdqlnqAd93kpqYi0zeiSGy5rj7ubecV/csx307X6dRrq YjeqXrXbpjDDL4EzQl401uZI0smsA2Ffi+RAefmF3asH4XLNUd7U/dEZ1+mmlweSkw0XchuKyEpG rtRtubBoeYyGX7CJhpTxCE6mTiYYCix3Yznk7Ll54MvTepQznFAgb4sn7r0nL9XIauIy7MPw1zlJ w80ZfhLxMh/M25089n3oJqgavngyLPF/vCdRmY+moDhzguPXKAwY+SyduHdegqkYi/31mlZ9Gs3p A4lT5ubfzqx3we9gYwGNwgCaDvUMGl50JmI35a++x4G9rM2+lNf/di7Vq0rbo4Zk7fFa5YO4oj22 ngJcf68heg3zc6s/3OKa+KynNi0RmpZx16al5ndAUr5j0+kFZzw/HMbinE5OYnPL7Rb6pXyNw/lR V/iKEVuUlZTCdHQXOpbgHWdpXjtsYpbfULT4dlEY/NmxKxVdOJ04xhnXOPYMNyw/FOcs+ZYNfT2S 2vRg8ULA6VOApKF3qCv6ImbWIqgYfZnSvBRWjQilQPXpeIoivsSZK8X2OE1LXoWYj0R/RyTKIZC+ mwJ/uLVfnR1UlES+EbBb9VYjl2AXSUWBHyHwDg6FL/qFTi8txP1v7q0lwFWLwrcEfHSzL5jJzuqy tK2CtwTxaIWx99/nQdGGZzTKFr0NrC3esHbDsOL12IKw830ENaLF7aL6xymnuvW0wHWGKtpdQ4eB 33dBTZh6MDsI2kYH9qnI3aixHFNvFLhumGPWcFjxW2i4vuK2d751wNk6+wu6EDtG37kENS6QofPW ckceeOLLrS7Zzvi0er56B6Nh4rnRJMm4pQy2LPTxThlLoSMExOQZkRifSeYN4+uxOAJD4wejzU3Z OyafEho97kv7jjsESeIGNH4RIA/7ifvCHfcl2HFfgtlPcDuNqsTLvdTd445UiJbevNW14d8ZwW/n ltzhmZmck3efK6+yoPPayC8R1D3pZ/wgzTnITW7TI9z86MKGvNTmbRkFaB5YKC0eYmAp/mo2PjrA LP5xVKv7HwLJW/A+glUl9pK7oMSMEQesrl8Y82OOxP0/Bks4fAlg5k+Bd2NAi5K3MMJLevl5S5Yl CGvUznzjK0QqjCqDEa1Oyd7wQ5CjxaUgwpX5deBb4Sn7+HnSLPOLcewWFdhu/drCnWZLsNNsCZBt PA63622n2dS2G9fJ50ahkPdxBH81/erfPvrExORfabem33BQfC1Ecvqr+JO4t6PgBQOaX9DkYxq1 pqMaqItYPB3p8Si9C7t4bzG6O2pUT7scbfJ8xjcLnlBfm/RXXq88wlX2burNz9E0KU+riCiWlfeA rUs8rH4tU3zxfiKbU92Es6KPynh21T982He16R203pPCc0gvs0XP/wUYANkaNUQNCmVuZHN0cmVh bQ1lbmRvYmoNODQyIDAgb2JqPDwvTGVuZ3RoIDE0NjgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJbJdbjiwnDIbfaxW1gSZcDTyfFURZQilRHvpESs7+pfy+YBj1aKQePsDGYGxc933frxha KXcOZcz7fQFTbIyV7oj/Gb8pjJrv54poYwqFXNodA818/1wIwVrxjwLVwTRHvV89lDYXPddrhNiT j45QR3JJJVUrUxmxdKbb5GAV9aVU4blsRRtTY0zqNBQTWyhzmy2UQmuwoIWJ7eZAqW31DGJHl6Vl bIaS+5JScPWKfIA0bxN7JZhQ/ByUxBRecI2KKUvwsBITUwpo4Acn9HMh9ppZG7Yph9KLQKnJ/KiC yq2wz1IJebRPNK+nDFXDdeXQI/kySmrDcy3mi0PFhK1j1n4vXYwsrSthqxFznuvoSJj9dku/62AR 7dB7MnXXOAJfbBHb8lx/Y/LAnTVlfGIUSvyi3TuWdgq9kqunMFrf+h11gdWBwGhzqTsRnk3FmKlL cMVBQiQH2cxFLVSMKqtsy4ePRpj9wBkizWP2CGPWL9yJfK2B/u52jOBG8cIdIVMOo5UPj3qHHkIP vRU/ITtg9SdOPBc2Ede3S2DlHKaEFmU5X3BpzcbfIhBDT4ePnM0jWVvckbAUo/p/zCKY1dgqFypr bOqvrjciHVxDruJCIuNSJWENnBBj7ZqjmmLP47ivu8MuELZbe/+2Y9lfcF6LmcbQ0+ND3Ni75MTd QTnLeI+COXVBanI745y23Vzy6tD9pkFbABEx21bnuJbzDjUH0mVuY3OoKZ/b9w7dLbtvYiV28Ozq PmXYxfkPlKKk58TqcSsbGbE63Kzhgz1whifejrQ97QnxjtptImyvzFOFhs+11vNxNYa9W+uJba7r itAodF6/HvJ0h74yno2hIsVpW6acJMyXaNapqlgAMwsUxB2/jpZywSn1lXJBMfaVco085RrvAN0d EqCmywLUVto+3B3uw8J3FkHL+y8N6bVvQ0kC4wOX3fzeyj741QfVIb7nwwdxqCMHJV1YmV94Mllj eSFYWF1J5V4LHWZ7hwUaDK1zfNthkYeOqY/wUqmhtJZTqkt95OxLVEW0aFrQN1k7Uh2fHVoNbeYa idtRUirXTa/CyYf2Y+xsR1phb/vEdcLIp51cl3pqrcLtVY/BjzWFPtouEIztHoFInhC5Y6DcD6uc 1YyKLYz8iWZVxR5GcV2YJlbpOkp+X425liSTZWZHcE4CxurVT43yzu3iqEw8sdnHgbVJAiB+JQyR G2K12czbK8p6XqjJ2vYKHtSYD68stg1DJc1PXF5Rq5auiaJhr9L9XqhFzNj9XJJda2J5JqA4cvWL bXPeAnZKC9Ut9RxXj3Ls8z9D6PArgPDFUXhha7zK6oqElchrbuCKEC3JK9JrmXscpXbbRbmhpz9j K7BN1mpvU+2Fua28RtWsJXkazXMrnqOjOje2Shuzmz/xex2r0GFTqT7IZRG5oNJpPvOqtVXSL6Id jV9EW9bH1SYXPk3mmh4BU/jSU5FnpfHGszGuQUtygZSZZLBxbQFoUvXHKScHLmPx2xm/sxq38pUp 8dlyYQvolb9LZmTVywqm00rmtzMisn/BnJMIT/nekCqycWF/lJHgnI7aFwvX6jUnKE/2WcpKSaK0 J5Xlp4qMVTbKB4gGX0ONFvsnWizCyln80wc0clq5yMhzkfF+O3eHvJ2my95OXimd5d/usDcHu66t ftthjxCfWs6uUU/0WM5wfbH8df1+JX7rcNKFk44Wh3hd8Zpl3M///sSc3378gXD9daf7/vX8c/2L RsQfNoogrBFvGK5vIZRqz88rysOOzzJghEnYAzJsvPU/OwbT8fHBJUaXYK1IXot4/pDyoySe16lJ um3WlsqoipAgTmImjA0u0+BvlNGq7sUXRifyWobvhVESJsrdsdoQng4PtmHNNzdhfKnaJLnuUR6o F0pFqUASZzmF5ypyVQzfF+qEKFP544g/ABsrGbh7mMGFVEU0Jsjd/wswAPOvOqoNCmVuZHN0cmVh bQ1lbmRvYmoNODQzIDAgb2JqPDwvTGVuZ3RoIDE1MzQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJ3FdLriQpDNznKfICiTAGA8eYM5Q06kX1Yu6/mQgbqNefxSx6NXrSKyKTn004grzv++7J 7qemnvV+Xz2VLvfTUle5LU3T+7HU+wDobdxPT6Pa/bo4oG5YktXpILc7pzb7Bq/ryWmWuvFTUq0f pFihfib9YJWC3aC39L4xUBbfzxx6UE1zCscGrknKiKGELQ3xvlqFYJ5FW5qtf9a0hAh8WBsMtqKj JJkS7ZxktGi+LuwKQx1guby6G5oS87yuAJoqk9qSTbS1dAc6ClYvyGbFuM5tqSKHNdfVfl15td7X t+vv66/rn1vujD+5pWHnGRnWmXKd9X59v/gG/5NONN5oTGvsnBTZO7/JcIyvK5AgCGGiFsRWm6Jn xlYJMHFOZfibXrijQBWLxjDJk1DFMGyiD4AhSQxECaYWT5YVdGwpN77rUwkE0Zc08GgBdpzY34KK 04tR2jaoafDAAkU0742Y6s4UcX+MmQzV2Twf0QIRm1YfYiRowFgVoE6eQUEKF2Cm6jwwp24+SJCZ Pfr16/GYISxko2K74NyX04mR+O3kU7F+2nzDDBNJaiacP1tZuQQRi2zgTK+28/wEr7DVPglaV4/+ G4lt6mEbSPbdcYTAfW2Ec/SS8K6CVyNqorHgNA3WTmmTklBz8dlw4Au9VlQLgkpMLKTBacAiAcgl aqaypMgXdfo0jmpmCF9RsahqQ0KxBQUpFsJOwKki5y3KhqcVh70RV3L1CIwgwGEWsjmPmE1Eqavt e8ZcgSAMhf+pFRQJj1Cs+o4XJO8PqLIHHQpgfbWd598UbB+pFchpRaSV1b0pgW3lHGfAcDBt6Jpo JC70kgjBQVGqnLcjZXDSWSIbsaI9DwFRO9NTNpGdnlrzVE0wOsCL688m+x0CxUnBAHS3Y0mXcELI mM0oAc5euI+IIIBPyNyfd6NQG2d2utE+AvhRNV/A30EzIZoQDAjFAmC1jQibEAUAdXrajto5GPqx UCye+3nrR86dV3+mlZqhLs6/nNDg8cI7EE0F7z81u/mI4ndu9sICLfMAisSg9wVctQJ2U1k6BDD2 4arlg6qSI4tBYW94KN3DUYqu5rHB61AkMJDVRZF2UBis9yVGLbrrrMP+Bfbu1oqzVxxAi1gYEn21 RsrsHpiruxFFC67C3q2E5pr8hPYy+bR+zbKlAkr/xrdaqy7UyFWZblj+IH6ObTV3abdpBz3lQfno gxwumQdcERxuCz30NJCN4kMmimxAf8ayoQH+lGUA0eYx0bcDoW3s1edptmHRyZi77mepWLp+QR2H iZJS2nvbM4eb71UMdLOFEAWGY2qIebQ7nIb734iRQf/ElwS1DaY4V/t1UXploWjHCJqxrraboe65 sP2xtx9tVKPf1QJ9rNUR+pAktFax6eaCO4zEVSNax1rRZcztkuFMx1prcHVbq2X5Yq06/4u3Tpw/ d914T6lflZRDuNdVLzHvAvhfxqeWnDtLxUL48/rd1hCIvVmcbZTTjokCkV7ce6M++J9bs9AChVO0 kHgXpfXA6664LMQDujGV4GcI2QlFXQ9YtsLhC+NyYX2LHAy3ehUz9zxpXXI4t428zzWc/By8fhTb d4clOeCxtSib5t4fXOCd5AnGBzEWYEdW3nk3io8qXpML1JjQ0YrpfXCEjHy4tm4UahrIvXWOL+n7 4LaF4KC1H6LMEHP9IM+k7aEMN6TYYfHrwj649luPKLmzXO2Pu3j5wcXLjy5e/q8uXv+8ixcZFAHc syCv9tXGIfci+0uAF+47fsP28BGmVIVu3YVy1L4Q+w9XDBX26+YX99xW+wjVgvG9uEoz7r8xHYOU 6Mi1FnxvyBs57ab3ucGiYwC68GrSYJ8Qc2/SF+iRGSL1dFdfEqhtQE1X6kDA97Wu8eGdSFT2y/YQ 8klI47hw030c9EwvB5/iwt2VXjNR8BjVO7lARmC+US0ywY+SgPj0q770yP6VM9sGr6NHgZ/1ebCQ YoX6mfSDVUpcZXhvWvgJuX54fdGDwMMpocjEMKYyYmh23g/xvlp5dRnzLMpCIw/ufwUYAEw2Ns8N CmVuZHN0cmVhbQ1lbmRvYmoNODQ0IDAgb2JqPDwvTGVuZ3RoIDEyMTAvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJ7FdJjhw5DLznK/SBFiSR1PKMeUMCAx/Kh/n/ZYKLVFVuj0+GMYdGA9WK kpLJJRhipZTSB+XVOfXMKz2uj5ZlTkWSPmquq/q65DrFl/fVcpXugHMtcbzn6lbuS5eUmWBQcp8L gNowRLMmyU0mHmUZWE+i1DIXivV9lVg9rm/X39df1z+ppoK/mhq1vKhS4pFlUUv390t39FPdLRFD x+ITnrlIfcPCnIDKkoNq7vA70H19lDzqOfs4eOUypmKcL80wQoIt7mKIhmaWeG4EW0jWOpuCJ+g8 iICXbLM4Gvi8VnKtr5gzCR+nGQltiqo+FGjkObu/1vBJh5fkE0ZkErjVoZhHO9ZAgH7eVLKQPE3X PPvScOdsyT8jx3B7WegVxhboQd0tV+VKr2yGGwdA6XNrEqjkWfSYUIu15AGX9JQj25ChNFwDHMkF r/a1lU6IAwZw5sGbRhTgVj4wMhV77jjlcdZKuTinsPyUlwtJRBa/ePnFy/8TL7nlAUmWmovy59Ay 3mvsLGXARV60AT7b9Ow4FMuHIHaQEupb4r9GrGYcndOzpXdD5x2DNDEi5l5x37USH1VNiDqGopXn F8ZkqP75An7MVj/DmsnJHF9oSao3hmEGF4aRixQM7ynlFyhrt86BpYg/uEAAsGfUmbT+3TqnaSCE Sw+gdbEcsDKRcEVS1F1BV9DH3EAPDtx+Z8/8ghHU+AB2g68xPa73kJGPwS9o8jrI7uY1X9L3xGIX PAi/1sHhkaKiQRZ+Istl3w8XoyeTl0baSi+lE7v1P5FPICwN7cVIGNMr+5wQWg3tgYapgMyemvcC BIITGCa4nV2IpRIVrva6EbaqKYpDKNhiZcDCfAE99u5ZCNuBlXqhZLHntR2g2V7rK6NVFUKI+tod gHa0JFgEDpw7fT33ZtOhaBWrqcqXAxNQMSGxPYxLyByUQNPpAAzr08NWiGKrGkdIqAcCRTBTZKP7 tEzsOsXhOdt3ZGWm/6jQgOSp/vxaH/qrPvR3fegv+kBf+vBb9aG96kN704f2gz6036YP8ofUoXeN sydG6rXbzsRkbVYiU0hsH2ctcRkrgqe9uhK0+AGhXKgb+AWKCsSe1mYmv/ABZLAx7NsF0Mn7CYLx 3fCw3lG/NgIzrG52VLNqOYCdaoUxjWnodDCLS/NuHBvdEVVAFG6Z0o2p7umvKeVV8wKxj076M+fo NWSjKw00BEhDJ6Mn6YOObOjpSoPYhRZ5oDzqQf4ukyHFMSChRMgxuaRaB/h6t68jqHSr0cpYc93D l/ocsM3x3NNhyh8KNTH2oeKR6Z+MK0PfjtkI81nXAe05RYOL3eVZ2bB6/Dy1XEqooMPBw9tTmxDu kjWdqRBBdEEbZcjQIV3ZPmsgn7AxS6161tKGnVKk9qt1zHShI83T3MZ0pOzHMASe945fMygkPs+V U22MDwhWsBY7IBqjJdxl9SwFPPH1fU3cXRs9nqgLG2zUN4Q5paBOrYQrZ4y5gTpY6ECwYa3NHIYT a5u4rwPtdeeuMgRWFg6E67bK+9rDuq+AOlGTPbVMmAqPyBoSjB3vAF/fl1+EjpRF+sBcURkQiPqp zMlfQPMhfj7Fuo+TP7CZTwTpXwEGAICbMOQNCmVuZHN0cmVhbQ1lbmRvYmoNODQ1IDAgb2JqPDwv U3VidHlwZS9UeXBlMS9Gb250RGVzY3JpcHRvciA4NDYgMCBSL0xhc3RDaGFyIDEyMS9XaWR0aHNb NTM3IDI0MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0ODAgNDgwIDQ4MCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgMCAwIDQ4MSAwIDAgMCAyNTggMCAwIDAgNzQwIDAg MCAwIDAgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0ODEgNTAwIDQ2MyAwIDQ2MyAy OTYgMCA1MDAgMjQwIDAgMCAyNDAgMCA1MDAgNDgwIDUwMCAwIDMzMyA0NDQgMjk2IDUwMCAwIDAg MCA0NDRdL0Jhc2VGb250L1lSSUdHTytIZWx2ZXRpY2FOZXVlLUJvbGRDb25kL0ZpcnN0Q2hhciAz MS9Ub1VuaWNvZGUgODQ3IDAgUi9FbmNvZGluZyA4NDggMCBSL1R5cGUvRm9udD4+DWVuZG9iag04 NDYgMCBvYmo8PC9TdGVtViAxNDAvRm9udE5hbWUvWVJJR0dPK0hlbHZldGljYU5ldWUtQm9sZENv bmQvRm9udFN0cmV0Y2gvQ29uZGVuc2VkL0ZvbnRGaWxlMyA4NTEgMCBSL0ZvbnRXZWlnaHQgNzAw L0ZsYWdzIDMyL0Rlc2NlbnQgLTIyNC9Gb250QkJveFstMTY0IC0yMjQgMTA2NiA5NjFdL0FzY2Vu dCA5NjEvRm9udEZhbWlseShIZWx2ZXRpY2FOZXVlIENvbmRlbnNlZCkvQ2FwSGVpZ2h0IDcxNC9Y SGVpZ2h0IDUzOC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDAvQ2hhclNldCgvZmkv emVyby9vbmUvdHdvL0EvRS9JL00vUi9hL2IvYy9lL2YvaC9pL2wvbi9vL3Avci9zL3QvdS95KT4+ DWVuZG9iag04NDcgMCBvYmo8PC9MZW5ndGggMzUzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiVySzW6DMAzH73mKHNdDxXfSShHSRFuJwz40tgegYDqkEVCgB95+dow6aUghvzj5246doChP pe0XGby7salgkV1vWwfzeHcNyCvceiuiWLZ9s2wr/2+GehIBiqt1XmAobTcKY2TwgZvz4lb59NyO V9iJ4M214Hp7k09fRbWTQXWfph8YwC4ylHkuW+jQ0Us9vdYDyMDL9mWL+/2y7lHzd+JznUDGfh1x Ms3YwjzVDbja3kCYEL9cmgt+uQDb/tuPFcuuXfNdO2GiCx4OQ6VwHHNh4tCvcRImYU48R8wRccwc I6dsT8meZswZ8ZGZfKYn5hNyxtqMtIq1irSK7crbE+aEmH0q8qnUlivxgflAzLF8/qpgLojPzGfi 7Z5YFKP5XprupTmupria42qKq1PmlJhz0JSD5lg4UXG3KlKZ8TXIRw+bu3PYPv9kfN+oY72Fx6ua xkmiiob4FWAAi/GqrQ0KZW5kc3RyZWFtDWVuZG9iag04NDggMCBvYmo8PC9EaWZmZXJlbmNlc1sz MS9maV0vQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0VuY29kaW5nPj4NZW5kb2Jq DTg0OSAwIG9iajw8L0xlbmd0aCAxNDYzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIidRX SY4kNwy81yvyA52WRFESz36B4ScUYPjQY8CYk3/vCJJSFcZ9N+aSrShlcg0ufV3XJXfp18e4h/br 89FuaRvVe5QAVa5yr3HA81Hu2mTDj4I/05FAVr1FxxbyfLxwbdCAl23Nd9hrTVhef/XunYr+fPzx +O3x91XxY8GzLbvrWO3q5ZYueOXbgzffqKeUSfV1QiA8WcI/VfBjx51uBJugprdzu+5i7kYZdSNc 1cFXAyqenWaZzmveqotfm1kC99O07btytzYAmuwzVVa+F1DvMYx3WjtAEzedHgRwgWu+rlYzyLAC C+WeugHe01ub7ruBwNnVb8PrCeSWscJrwno3FbriHjF3g74s1Y1CN4OZt4hp+NH9N4GUeH6dIOur Xh2RMLDpJAgUooGIcoMNuuLcr8yUn5+PCGoggXbFtx0xoPznI06MmpCucq8ecCreruQrgPYNENFF 1w8cQxgcpf8TPFGwZbx4jWgnkwE/AQecJBkbM9u0UobhuwPEGK+EYdeg4y9Qy7l5PgIWyB73lJnh mBDT02nwTeoJx7q17xu7S1ALXxhcbh6SOJ2QLFTtCF4JZEk1jwIIMJEXB6tHSMTLpcGOKH0PfJW7 K+mvCBzRRE3AZ3qU6PmA24xaYlZ0ICl2EOQiKWwVG7fFxHcGuNZ7wgrGsh309PZTD4YNbQRaBrRq dzlFp9u/+C7Y1kgQ9cqd8PCfxws20l29Kc0xSH1zwD90o0Ss5oLZQz0d3eN6Ehb8/uXX3xHr7+D3 9f351xvd6wCtJ/g74K/xi0N3iNSgsqA8IT8Kak7GKMtswyUrmiHjSohHQaCKOwmjSBo/M6DTNBEK c634oLrMEEXXAvH5CVSHpAnxRtiWZxfKE/pkMxL/wGWuBF8DWCrhsby0oD68WhDWoolSAM4OOodH AOoqTE9A+pyotR2fkHHik/oiQIilm1K2eWWb/d9mBLtR8SiaAdva+iE7snQXCiPs2gdeCuDaA47W c1Sd3LEZrghplOTSBO6f9UTQ4s/IRl8zxZG/xbzxdrSBzw0xWG0cWLwvgPljW9V8XG4LNwoDG8zV 1IVqXtsGQTmsY53cWsa5mds4TMj2Mm4jqqExwxlMhPbg9GHw4uzNqblkhwz58q8al4kNOTA8xA3E O5B9pr0g+rRRem8uCBP+YvOyDbxmA+pQ/25ymwDUuXkG0CnE94AAnsxabWNfO/ZnZFmMVcoM1gWm SujYxxIzPw8y55eUW0gzBzc6sWHIvc2/atNbf/GB/LFrcIjHxao3qDDIvD+gP1bdEI0vG1Q951aG 08Druna9uDOQljImzk7QMZ2ToizfqmRFrazqYDPPWHb6iLXO0WxBC03uQNLIoxf96omgGa4iazzK 4K5RZzIT1uC3nC1tjDfEd8DWSYfNhRUZPhsszz43fKgTFX8XdnU9Z3YNvpVS6NYq3FrnpMFkbIwp GqPiY0qodoLF3BjknIvE5jGzB2jGl2vP8h5rG+z2m7D4sPQBSwW1eb+38iUzJksPjEAz0mlvzKBO rlRsMrG+Fh9SMyY/uRKxCeN8PRt92+ofaWveXwIxNj8iyUXOCZCiGeEATOtUScRebvuKA7edcyvR yGJaz7n14MbqsajFKv1CDqpvftY5YGGy1Rw9kymOYsaJxVbXOxysvdtGAGOSo1mMHOOBLGcdzSWM xsvFBbuCV5roPnuXbmPDj+jT+VU2/hR5BkEq9EnQZMNyLNyWf5X6iYBgweYc0l5/mEPNa7x53c7Y umWD0O5QvXF+7JGi9Ig+FO+h7l0cvSxMEtXMn9c/G09I8i3OEdUw2gxwyZxOFxaLi58zUbpb4OeG 4fNJD5tACE6w9bC9IuNvCdIYoJEgnf0kSJ2QJ0EaZM0EafyzwJCkyBOi1PiWIMKTl9O+v0jQ4uTD 6PvJa3O+1+b6yWqz/k/FuToXGGPuBVsic3/9K8AApgQ2eg0KZW5kc3RyZWFtDWVuZG9iag04NTAg MCBvYmo8PC9MZW5ndGggMTU5MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlsV8+PlDcM vX9/RY7tYb+Nnd8S4gDsgVZ7oIzUA6oqNAVVaKAUKlX97+tnO/lmWbSCyZskjmM/P2dCCCHK38dN /t9T7OFGPso4wBqft4lKChcAbgmISf6PVWcI36SefXze4l4XIl9NOw82O+dtAhxxERRTcRT39mgc qalRoBuWqSGbHKY9jgrjnAAysYDeaYLzJivamNAB77nPMe2Vy7FOfKcq9g3KfdMIvI+R3CnZyis4 DjQ2vLfIftm5AQFIErKyQpPks6yZlqvvSPvoZYZnAgtP2uvIjuQWDYdwLT5GSgbpJoW8Rzb/Fco1 YDxGjUirkpC9lTSB5qqMCSMGKetAAl1g98/t/fZq+xuJlD9J5Ig7SbQr7aXhZKWRkAmhyxIy8IR2 atggA24ZTsbagTJZjBFxhD6zQ91UGJfL3RDO/xYlSQ6sF0TETQ+NLwCYhdsZArPGnJK4FF5jjs1M I4ep9XkOazCnR7KnPkAKKIJjA5mXzzJwT6Nn1cvbCIGkfg0r4rqPakBSSmCPj+G5oaH0I3UXUAuh Dk1ZH1qYZY5xLNLt8MYL2HbdWBm6Sa1kxzjQijlNGJeH0/PvZb7uOWUKpe218niYegKVY9SKQjVa 3QroaawiBqt6nXNsUbRdQtg+NJRzKGYYfgp9e3Moe3qpwXRogaKxcJg0J5cD4vpuREDt8ywD67y8 07DjKBYgqIhUNemUHZdScWD0TWnOSWY5z12ILJlBjTuhcrm7hKZ6jXKFLHWhGKIY23RY+NB7WMlj KToKkx4OxSErjkwLiCNiGkCGTcTRFHMB4w1kvSWHuqt0Flhb9QYg2paPMVNZzUDI37XwsEUKLhto 0JYSfV1TWQa8HBCVCgfllqZTy3WA83Et0zCHsrv1a4gtsnNQmUQQysXJCj0+ZZ5zUWONDqXNRGVk ZCse6KihyyO6c5Q9KTGUjku+Ujptm1xmngW0ptlLyYFVm8IyAxxbC95Ms440epGLjyEB6qhlIqUc PPg9LY4LqBpuXBCapMpwQOwVr7I2KiJ3lHa9Z9JGt1osl6OPkgofdKekcQ1VrwxK+IstVQcVyPa6 RNQQ3EhVGedMNAuU1zjnYpsUVWGFb7GkujU7Auv0KPu4bMsNSI5QBfQTtyuu6c6XelzU4eV4QHSV lfWAsPY8TAvhBVlyDSArYLHDywGLRwidDlCz1EnNlJaXUBdtTEuoizUtF2rscqq4yUWddaLTzPES aO3ReGc8Vmophj0PEVpR6i48WswVvqHZBWvEYL4PSXmlXYigjGh8UUtbtClraqkmB6p9pAqqc6Tk ZDTbNY7cbF3RntVNFvvo6mK0a0aTU8kHXEOHNyR6U6B9EFMbk5esIdjTPJlazSfGyBPZybGsWamG hKKriSeASTLRAYQkZ6M6uxsPPDx/G2OSpVXyUIYIWupX8iA9w4JMPFyF5niojhqSWOtbpRWVUYZ/ 9rho3BZlDDkHBGgc8QyScXS6AEaVsBt7OCCY6MsTocS0cNO0J9/1so5a0KQQzy3Vaw2IeTGSBgRn GtCToQsGo8qCWZjdwHI2zwUynhkrbHzExFDm5oVs0TB59vTOZe6v0KyrhHRQriZNdCQjikPOpKKR m7ZzTkqvru2cGZqEpuIA9odRBNDfyrbLdMQt6q2StiFzu9njcOgPHy7Gy2JpJEsaV335PKAs1yvK ykp7HvusHmD7PMnL6M16CldV/gMPawg4xmLhMzMwC1pg4rye/wb0m3umV1icBnNW+TE3Wi5WYA4c ycnk4QZ2SsLR2q4QrjGFjKSkpEOIeCWVlLprzaMjfnknK3jIfExrQc/SUcb1irv752G7ff357afw 5Mnt/fOXLwLF8PTpsxfy/avt2Wm7ff5a7vVVCjl8PX/abk/0uzA5nN5LRE7nwFXLXD6KvLmQz8T2 I/f0cfvh5d1d+OXd57++/PPj6cN2d/rueTTPw2mH+ceWeRyW79/+J+pNfG3XBFMqY4SftxL+DTnc i60P8u+n8EZ0JosMl99i+CNcv9YlOBLEVCUv9RCnREOUvKlcvIag6feVODTRPQner+HT9uZbY/Kw eGQpqg35PYAfBWZ7jc32K0Q5XkU5htKr1KyeJ2kVkmq6Qgj/CzAA91AlOQ0KZW5kc3RyZWFtDWVu ZG9iag04NTEgMCBvYmo8PC9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMTc3NS9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSIl8VH1QE2ca3yXZXch5W8wSmibXzUKjtVA+zlNHaq0jKogDhA+p0AIj mABRIJjQBaoU6sdUQgJWqTYqFagI0pZTBq3ggfLRUr0T7HkKp7R3vWvH48rJ/XH0WXzjzL2LtHP/ XCeTeXfe5/k9H7/n97wkofQhSJLkM1LiYmNNoZsthaKl1LojJ9HyhiUs2lZo3mArNsseQZKelAKU aDUqfdT/KI16liDevv5L2PkUvL+481fMQ7XsdHCDraTCbs0vKBWW7XhB+HVUVKSw3mzLtQipFY5S S5FDiCveYbOX2Ow5pRZzuCCsLywUUmR/h5BicVjsIr79qQbB6hByhFJ7jtlSlGPfJdjyhHhrsa20 osQirI8VcorNETa7YMVYxxu5DqvZmmO3WhzhBEHiH7HYhwgmiKUEEUIQ+O43BBHtQ8SQRBxJJBCE yYdIVRCvEUQRQegxBYQPoSBMRDkxSvqSK8l40knO+JT6jCk4RYGiUTGuQMqnlAnKY8pZKoJqpO7T WjqDPs+yE5VTUscU2QhGiASjAlZJizSw5cTQjesnc1EM/wqDtuxNjU/Y0w0xPDJ2aFB9fzisg/xj EAcZUJ/+D7QO5VejLSidZyeaROnQVBiY1bAFjNwtuBfInZ9LD2K4W2srk/PD9G+FQZD3EM1O1IJS cspZeQjBWaXXQKlBp+kjZz/sunjh/h3t5J/aRx7ogN30RxSMQmPWo6f5EuCZu64jN27rL58pToqu 3hWfYkhOo4JD0lcgtU7aTLMQ1iRCKKjgDviTtdI1Ra0SQuiPIZSCFPpjhI8QGiXPZVMohv478te4 6VvoDoUEmv1zLUZtxf+XQUX24YL65rI1j7OlMFChRmw4gM8D2HgUVAyLljSJc9ll5LBMV1bgXDYy Ps5mWPgOdz8KRvIaaCUatIprgfhj1E0D5x2lQIlPaZRye0dBiyFW2uh1UTX0EslFoZ0LtQ/OQO6s nB+nwrFflf6jGaP/0Lkz7hVzUYzBRCOjd6kGWwcn6M/OWFPdhnr0rMtWV+IpewYi36VLPO90Oe/W QOjegRfe93Uzk6cu/P6fmMQN15GKRx/gNiun1tyHUfGvU+o20CIG/CEAtFwvdwnWSn6aE8zF5raL PY323PzKPbnV/FqR4npf3J2bu1S34ZOo7292eYY+4t00J9ZX1IsNb/qClq7sONTSp4PfMtOFY2j1 c6tykD//FsP1wmGUp0l63ZGXt/eT7ivNZ4eO86fqWxo+8Piy05WzEQ/gh1lYVabuwfNfAjy3F+Kh WQN+x0e+GDluQn7Ir8pkSqwaAT8e8QhbtDT3u2E3k3HugjigB+rq15AJmdu+RtS2AnF7saEGRMTT 7AjWsu8M2YqjBuEBSHEwrQEubhJxiItMQLtR4dhmbFv6+T0I4pGWXiGasxKqBuEZ8D82Mnb1vdRt vBwDXv4KAqb+N4xL08FAVD4QaCVKtCEdMiLdURSOiwgc+RIWH+aRPx23v7wgS5/+5vUbhkvMV8om pu/k8ODwe1lRdTwrYGkkTX03Q44DrxgPBF5Kuj+1ppfu8BzvamiodTbw/2LcdofLrl++dVeIIXFT 2JcMO41BKTJNpEyTFiN7MBLm6JHW9t7uRjGN9zI40nPMbHrvyuTM0qzdfA3skXnAwM6yb0Cl7gf+ 6X45XSe+5iJvKhcROILqiY+sYeygkB2wIvHdfMYHEbPqhYTcxP/JyF2ez5nheLWYr6G5iRtIy8y/ JOwU2YYRy3DYNjxRZOpZBi/V8bB84CEesSnrIXrpkAEtT1uG4g3AB4LPu/fGhhq3YkZ1FVtTYw/e Ax+enUYRIqyahR9+LEWWyPTPScSbrMFuopve3t4pXl0QiIGbfKKRNIuYUSTXOT0s17kJd7kak6AC rRydOz/f5Dh9e+DMFc8Jp9ODe2dc+/e59utTzNZtNgNG3rotI7vnO1S3gD9ahPlRPzm5b1tgo6ac MV6KhQjw/csQUJO7Pl3Rjulb3UZlnahsbtVdOHe68/LJkjQe/Jvp6aQhtBgFp0YvX9eVOV7Cc99O F1Bn327ZU6DbbhNzMu0dvXwjwwoHZ6Jl2aixaLiScalTg2WBvqC584g8vROIj9rq6s7x3zPOfdXO av2OfacuGuBTLCsIRzzzZM2klLKfZlkOd+UHCSsBzdGm3cWZuRVNA7zEYPbkgQb1Z37zWd+H19rx hrPdaOOM9KiMPCzFKHrQRs0QDQEdrZB4xQCBkpPCWtnk9cWv1xrJl0JGGkK9ndTr75Tb0vVVVS53 lYEF3bzib4IqbEauH3TzI/z3j1q8qVzQITrzOE+zsA80N9nL/OxKVHrmsj0oxQPBHhpaj/ztiHfw KDOrAv4XrkUsHAiQntf8V4ABAPDJw/QNCmVuZHN0cmVhbQ1lbmRvYmoNODUyIDAgb2JqPDwvTGVu Z3RoIDI4Ni9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzPj5zdHJlYW0NCkiJYmBgMnB0cXJlEmBgyM0r KQpyd1KIiIxSYL/AwMHAzSDMYMxgnZhcXOAYEODDAAR5+XmpDBjg2zUGRhB9WRdkFqY8XsCVXFBU AqT/ALFRSmpxMgMDowGQnV1eUgAUZ5wDZIskZYPZG0DsopAgZyD7CJDNlw5hXwGxkyDsJyB2EdAT QPYXkPp0MJuJA2wOhC0DYpekVoDsZXDOL6gsykzPKFEwMjAwUHBMyU9KVQiuLC5JzS1W8MxLzi8q yC9KLElNAaqFuA8MBCEKQSGmYWhpaaFJor8JAlA8QFifA8Hhyyh2BiGGAMmlRWVQJiOTMWE+wow5 EgwM/ksZGFj+IMRMehkYFugwMPBPRYipGTIwCOgzMOybAxBgAMOvUG8NCmVuZHN0cmVhbQ1lbmRv YmoNODUzIDAgb2JqPDwvSW50ZW50L1JlbGF0aXZlQ29sb3JpbWV0cmljL1N1YnR5cGUvSW1hZ2Uv TGVuZ3RoIDE0Nzc5L0ZpbHRlci9EQ1REZWNvZGUvTmFtZS9YL0JpdHNQZXJDb21wb25lbnQgOC9D b2xvclNwYWNlIDgzNCAwIFIvV2lkdGggMzk4L0hlaWdodCAyODUvVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCv/Y/+AAEEpGSUYAAQIAAY4BHQAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAgIDAgIDBAL CwsQFA4NDQ4UGBITExMSGBQSFBQUFBIUFBseHh4bFCQnJycnJDI1NTUyOzs7Ozs7Ozs7OwENCgoM CgwODAwOEQ4ODhEUDw8PDxQUEBESERAUFBMUFRUUExQVFRUVFRUVGhoaGhoaHh4eHh4jIyMjJycn LCws/8AAEQgBHQGOAwEiAAIRAQMRAf/EAUIAAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEA AQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFh EyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPT dePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYH BwYCOwEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLS RJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3 x9fn9//aAAwDAQACEQMRAD8A6FLukmQWr8JJJJKUkkkkpSdMkkpdLyTJ0lK4SCScJKXCkmCdJSgm cQASTAHJRMfGys123FZuA0NjtGD59/gFr4vQcSqH5R+1WDUbh7AfJnH3yimrcWivJzDGFS64fv8A 0ax/bdoflKv1fV3Ks1zMkVD9zHGv/bj5/wCpRutfWz6v/V5uzqOWxlgHtx6/faf7DZI+a4zqH+Nb OyXGvoPTwwcC/LMn4+lX/FyBmOiRF7mn6u9HpcLDji+wf4S8m13/AE5Vy3Iw8Nk32VUNH77msA+8 heM5nXPrl1Yn7V1aypp09LH/AEQj4VR+VZdvTKh7866yxx5NjtT/AJ5JS9RTQD7Rf9cPqvjki3qm KCOwsDv+plVXfX/6oDT9p1H4B5/76vGzX0yvRrSfgT/5FNOLHtocfmf7keA9/wAEWH1rI+uP1XyT +h6jQT/KLm/laqg6jg2uDsfJoeT9EsuZI8wHESvLi7H4+zuH9o/3JWW02bQ9jhtG0EETA+QR4Zd1 aPqw9UyXNcW/vRII+UhPV0zpuaQ6yitx/fZLHj5theV0Zd2M4Ow8q6gjjaXN/wCoctzpn1z+sGHu ByGZoj2NtAJnzPtcgYy81aPev+q5icPLe3wZePUb9+jln5PSeq4UutoL2D/CUHePm3lA6b/jKxHO FXVsOzGd/pKjvb/mugrs+l9Y6X1Vk9Oya74EuYDD2/1mGHBC63CiA8UzIcJ2umORwR8QiszBw7Rd lndF6b1ETfUA/tYz2vHzC5vqP1WzsSbMU/aqh+bxYB8OHJ2h2WkNduQHIofKyJcxxAlpaYLSIIPm CiV5bmaO+9JDqh6cOlU68gOHKM2xKlWnS7IQshOHyhSrZlIappT8JKUUxTppSUsmJ1TqPdJS86JJ dkkkrEpE+CcqIGqCFTCYmU5HdMkpiZSSToqTpJJIJUkkkkpdJJJJS6ZOEySlJ0ycJKXCcJk7GPte K62lznGGtHJSUrvA1J0AHJK1cHoheBbn6N5FI7/1yPyK303pTMMC62H3nv2b5N/vXJfXH/GXV061 /SPq2G5nUNW2XAbqqT34+k4fcEiaXAPTdd+svRPqviC3qVzatP0OOwTY+OzGD8vC806x/jA+sv1j L6elz0rBOksM3vH8qz835LFZ0/Jzsh/Uut3OyMizVz7Xa/ASr1Zx5DHX14tbdPaQ5/y26BCid1wD Rx+l4mKfVyz6t79SXkuJJ/k/SPzWtjdNzsoD0McMr7Ou9o+TArnT8r6u4jpqAts72WOY0k/Fzlpj q9lvtw2UGeIyKd34vThE+SiQPFo/82sm5jRkXuYwfm1xWD/aKnX9Wei0a2bHHuXbrD/AKeZb1bbu dhucP3xYHD72vWY/qPUqz7cVrT47dx+/eSngUtJt1xh9Hp+gB/ZYwf3p/wDJzdAHfh/csGzq/VR9 KsNHnWQoDq2WT7m1u+UJyHfc7p0c/fH9yG7E6beNWVu+IaVjjqNjh76Wkd4RGZONYYdU5vmClSG3 b9W+l3aioNJ7sJb+Qqo76qV1Wb6nuj914Dh98KzX2NFxb5FO/quZiPDXtFje54/1+5GlW42R0nqN L3udW6yqZmr36ebDqrWBl3VsY3e2w0/RbY0nZ/Vc0tur+RhbWP1jByB+lb6Z8Tp/0hIVqzpmFmgO IFh5a4e14+DglsrdtdI+uluOG157iazo03uDgf6mS0R/24P7S7HEz8bNaDS7WNxY7RwB7+Y8xovO Leh5NQc7HJtaeQYD/wC0Pov/ACqviZud0eycR/ptYZNTwfSk+U7qz5gpphGW2hVZD6P1PoeD1Nu6 xvp3Ae25mjh8fEfFcb1To+Z0t8Xt3VEw25v0T8f3Sui6F9bcXqRGLkzRlxrU/k+bDw8fDXyW9ZXV kVmuxoex4gg6ggphsaSCaB2fLxY6s6fcrVOWHaFa/Xfqs/GDsnpwL6eXVcub/V8R5LmnSDI0IR/E LSKdhtgciNsWTTlFvtdyrjLgUkN0WKQdKpiyERliFKtsgpFDDlIlJKp1TTCSYlBTI8JDwTJwkpRT ccJyU09klK8kjwm5KRSUt4pp1STd0lNlMkkgldJN3TpKXSS0hMipdJKUkFKTqPdZmb12ql7qMJv2 m5ujiDFbP67/AOARUNXULgBLiAPEmB95UR9buidIa5uC1/VMw6ONA/RN/k+q7T7pXNtwupdcs3Wl 2SAePoY7fg3875ytzD+qbA0Oy37g0Tsb7GBKu64ADdz+pfW36x9YrfisNWDTYC11dAdZYWnsX6fg sfH+rlsQ1tgB7CKx9zAu2x6On1ezEoNgHLgAxn3nX8Fca81j9HUxn4n8UQQNvwTr2eJr+prnjd6E +ZDnf9UQr/T/AKpdNaScuhljh+btgD4rpLbbLCK3mS7txoFSOS1l9ldgNbmGWnsZ4KcL8ftQS53U Pqp0y7Ctya8ZlbqII9Jv0gTBED4rmcnonTahueyxnwY/+ErvsOycB9r7TvuO1tYiCS7+4KTq6wYh G+9/ai68XzT7Pi1GMTPfSf3XEgfjtRAOrVRYw15bOxB1K9Avx8Q1my6pjwIA3NB1KG/oWA4bW1io /wAj2pX4/aq/B4mrrOLuFWbXZiu8Y3N/gVpVYtOYz1MayvIb3jkfEFauX9WA9paIe0/mvAP4rAyv qvlYT/XwnPoeOC0kt/DUI6FTYd0usaOYWf1TH5ZCG/pjmmKnB/hOh+/UKGN9YcvCcKOs0lzeBczn +4rboGJnVeviPD2nu3sfMJahDi/ZrqXQ9jh+PHh2UhaYh0EeC2vQcPaSQou6JXe3cw7HeLePuRBU 4xxqbDub7H+LdFexGOx2AB2vO5gA+9n0Sg5HT8rDdLxLf3hqE9V8CHfinWguxT1B7BN0OYNPUbwP 606t+f3o9+LjZzN5+lGj2/SHx8QsllhB31uIP4/7Uei4sdupIrd+5wxx8v3D+HwQMQdtCi6c7P6Z djRI3VgzW5pgA9tjuWO8uFtfV/653YTm4fWXGyidrcsiHMP7t4/799/ii13V5LXVubD/AKNlTx+B CyOpdMFe66kSwCHAyS0eDv3m/iECL0kEg9Q+m12V3MFlZDmOEgjUEFc39Yfqw28OzentAs+k+ocO 8x5rkOj/AFpzvq7azEY4W4rzu+z2alo/OFb+wPK9L6d1HF6piMzMR++p/wB7T3a4eIUUgYGtwV3z B8wsYQSCIc3kcEFSpyC07XLsvrN9XRktdn4LYubrYwfnjx+K4h7TJEajlEd+i0h0WW7kZrlmY9xB 2lXWPkSkhusfpCIDKqVuVhplIqSFJIHRIIJXSBTJSgpSSaUxSUy+CaUgUxSUpNOqdN3SU2EkyQQS ukmThJS/ZJMkipSjbdXRU665wZWwS5zjAAUbr6sep11zgytglzisiunM6/kjc010MMsrOob/ACn+ L/LskkC2N+ZmdXf9nxGvrodw1ulto8XH8xn4rUwfq7i4rGv6gWuj6FDdGD5d1bZ9k6TX6OMA+4/T edTPmVPD/TOOVkkuaD7R+85Imtlw8HTx66qqhZYBWyPawaaeaFdb9oOxsiv90abvihW3Oc4WX/QO gjhpU/WZS2SIH7w1CXD1Oqr7MmAep6PG1u4orgxo05WRV1vplmY8My6SXANA3iSfBXvtVRGj2/eE lWwcSc9vgKz+JT34tGSB6zNxHBGhHzCCLJzC4EH9GO/mrBsdCOqGqymrHvopqaGtBc7uTIHiUSwE uJKiSftdU/uuKITJJRUguB9JrfGxg/FGeSXHXuh3aeiP+EH4IrtST5pIXrvdWx7iZa1pMFFpFORU 0wGOcJ2HjVVbvbj2n+SQp1kbWx2A/Ilamv1D6v4uWxwcwNJ5EaFcfndF6j0C/wC1dOeWCfo/mny1 0+RXodF5+jZ7m/iEz8WrIreCG2McSCOR8CnCaqeS6R9YMbqRGNkt+z5Y0LHaBx/kz38lrQ+sy3RZ XXvqgHk34Mhw1A/Ob8D3HkqvSPrBbj2jpfW5Dx7a7z38A7+9Oq9R9iHoxcywbbAATpPYqhmdHY+b Mf2u7t7H+5XbKtJHdNXa5ntdq38iAKHBiylxY8EEcgorSH+R8f71s5OHTl1z+d+a4crGtotxrNjx HgexCcCjdOy0SGWktc0Qywalo8D+83y+5XWWG0+ldDLmgFrgZDh2IPcFZrSHiD/uRK7dsU3EhoMs cNSwn85vl4hO0KNml1fo7Xy5jdomXNHLD++zy8QhfV/r2V9XeoGtx9Vhj1mNPttZ+83+UF0DT6w9 G2Ba0SCNQ4Hgg9wVzvWelBk21jY2f+23+P8AVKYY3oVwL6tiZWPn41eXivFlVo3NP8D5hcr9bOg7 C7qmG3283sH/AFX96wfqV9Zn9KyjhZh241jttrTxW/tYPI916Y5rLWEGHNePiCCodYGjsv8AmD5G 7T3BWsa/cIPIV76y9FPSsyax+r3Ems+Hi1YoJrdI7Jywh2GO0R63qhRbuaFZa5Ja3Gu0UgdEBjkQ FBLMJKIKfskpdMUpTcpKXnRIpkkkqUe6lwFGO6SmyUySSaldKUySSl5TFwaC5xAA1JPAASWZnWOz cj9m1E+m2DkuHefo1j490lAXowrZd13La5oLcWs/oge5/wBIf4eC2LLqsGn7JiQI0e8fwUZr6fQM er2vI9xHbyWfZaXu2N1J0RGq46aBLWHZFgY3WfyeK28bHAaJ0a0QAq/TsIVMBdydXFaD3hg0+SKl O2RtcAQeyD6DIc2qwsa4EbTqNUiSdUklPP1fUTGqzq81uU5xrtFuxzRBIO6F0LsVrtTVWf8AX4JS n3kJKRHCq/0DfkR/chnp9P8Aonj+q7/ajmxwS9VySmscGoHcPVa4aAyf70M4tgPtutHx1/grT3ly jJBRQ1jj3EtJvJ2mRIHP3Jy3LnS1h+Lf9qs7j4ptxSU1nszXsdWTWQ4QSJ/vTzmNgCtjoETJH8FY nyH3JwGnloSU1/Wy280T8Hf7Fin68YPRcu/CyqrW3McS6AHNM6gTK6PazwI+BKz8z6t9Dz7XZGVi tfa76T5IJ+MJaJbvTOrM69gNz8Kkta4lrm2aQR8OQs/rn1br6nQXODReNQWrSwaMfp9FeNiNLK6h DGzIAJnutAObc3QQRyAiJUUU8F0Xq9/Tr/2N1gkAHbTc7t4NcT2XRWVwh/WT6vVdUoc5o23t1a7x WT9Xuq27z0XqZLcirSl7vzgPzT5+CeQJDiH1CHWY91TvEHkIt1FWVVB1B4PcFRsrhNVYanfyTyEA UU5N+PZjWFjvkexCQh7YP+5bmVjV5VMeUtPgsR1b6XljxBbynAoSUP3RQ8hrmmannhpPY/yXfhyr T2DJqcHsh7ZZbW7y0IKouALdw5CtUXGxgvaZtpEWfyqxoHfFnfyTtwjZ5fqmDZhXi2mTAlv8pg5Y fNq7r6ifWJudjjpd791lTd2O4/nV/u/Fv5FldRxK8ukhum7Vh/deFymNkZHR+pMtpmpzX76/5Njf pM+BUU48Q8QviX2Dq/TauqYVmLZyRLHd2uHBXmOTj2411mPcNtlTi1w8wvUOldSp6t0+nPo4tbq3 91w+k0/Armfrt0r6PVaW8Qy6PD8138FHE3p9iZDq8lj2lj9p47LSreCFkPkcdtQruLduAT1hDoVu R2uVRjkdjkFJgdYTqAKeUlMgU4KiCnB7oKXCYJTqlKSldkk3KSSmxKZJNKaldJIFJJTXzsv7HjOt A3PMMqb+8930Qh9Nx/sON69p3WuJduPLrD9J3yQxUepdT2/4HE9gPY2kS4/2WouVaHO2s0Yz2sHk ELs123ZAOGN9ShvuJJcTJOqP0vHD3jIuMCSGeZ7qlDrrW1N5cYW7djtowAG6GuHBPWt9rmtZI4HC GSXGTyhU2b6WO8kUFBKbHHtJ80UtB5AUKPoH4oqSmGxvcBN6TD2U9EoB4RUiNLfMKJoB4KPEJiYG qSms7HPYhQNFnkfmrCUooaxqsHZMWPHLT9ytpQippwRyD9ycFWwE8BBTVTqztZ4D7k3p1n81JNtZ Hot268EJzTX5/eq4KCnROy5m5vPceC5b61dAdksHUMMbcmn3DboTGv3rfptLHT2PIVixrXjxDgnR kYlBDzPROqN6vhy/TJp9tzfE/vfNWXtgrF6vjWfVvrLOqYw/Vsg7bmDjXn7+fitxttWUA+g7mOAc HdjPgnyHUbFazxrdp9N3B4+Kh1LC9Wv1GD3t/EeCiR+CvUPF1UH6Q0P96Fqea7QlRc7GvbY3x4PE +B8irnU8X7PdvaPY/X4HuFQe3c1PBQXTDGMcGM/mLm7qiew42nzYdFgfWLp+9puHtJIa4/uvH0Hf wWz0+w5OO/GP84ybKvNzR72/2mj7wnyqmZNB3atsbscf+pchLuqJa/8Ai7696OUel3nazK+i0/m3 N5H9oLvMqqnLpsxbhLLWlrvmvGX+t07qDbGnY8P5HaxmoPzC9Vweqt6lg4+dXzcwOcB2e3Rw+9V8 nokJDqzR1FPA5+I/CyrcS3R9Li34xwfmgY9mx8LqPrliNf6HVaho/wDRW+TgJYT8tFybva6fBPBv XuxSFaOvW6QjsdxKo41m5oVthRWtoFSKEwokoJZSlKgSnlJTKdUpUZTykpdJKUyCmwmSTJqV5Qsr IGLjWXnXY2QPFx0aPvRQs7qry92PijXc42uHkz6P/SKSYiyA2sRgwumDWbbpBd4yZsd83Kra7RGu efbXOlbQwfJU7nJQFDXc6rpmz4DRvdJpJtOQW7g3QLRy7XWY9jQx0keUflS6bWcfEYPznCT81Hqt rv2ffHO2BHKchfp9lduJW+twe3USNdQYKshyzPq81zOkY7Xgtd7yQdDq5y0HkhhLeR4oqbNeRsEE Sifaa44Kxn9QsqMWVfMHRRHV296z8igaS7gvpP50fFOHsP0XD71iDq9Hdrgpt6pin84j4hLRTtA/ BM4yNQskZ+KeHj8iI3MpP0bR/nJKb6ZUxkE8WT8wVIZFviD8kUNpOCqwyH9wCpDJ8W/cUlNgJSgD IZ3BCmL6/GPkUlJUpUBbWeHBSDmnggpKZToqgVl0hpPkVVEgJJSt4RqXFzfTJ15afPwVcHSEzrfS abD+agpHn4lfWMW7Ht+gQWgdw4d/kVz31ZybabLuh5hi3GJNZPdvcfxXVYjm2fpm6C3QjweOfvXM /W3Ff03OxuvYwgscGWx3B4n8ilgeK499vNaQ6lgLXaqVFvo2g9u/wSL2ZFLMivVlrQ4HyKF28wmo b+fijKx3NHMS0+fZcxq1xadOxXVYdnq0bTy3T5dlg9Zxvs+UXge233fPujE9FFp0WvxspljDBkEH +UNQtTIY3c4V6VXtFtQ8A/t/ZdIWRb7mAjn+5aeM8ZHTg/8AOx3z/Yt9rvueB96edQjZ5HrjXWWB 50c8bfhZXx94Wr9UOtGrGvxXn2VluQwHs13ssHyMKr9YqHFtu36WlrfJzef4rD6XlCjOptJiuw+m /wAmXe0/c5RZIcUSF8ZUQX1K01dWwcjp7Ycbay+n+uz3NXCvB7/ctvpWY/FdXaHAvx3gug8hpgj8 FV+sGK3D6rk11j9G53q1+Gywbx+VMhoK+qpa6tLDfHtPZaTCsep2274rUqdIBT2MtxhRAUCsooKC mSSZJJK4TpkpSUyBTqI4TykpPKZLvqkUxKpWYX+r1ax51bSGsH9kbz+LlpLGwH+o+26dbHOd/nOP 8AkV8Op7BuOPJ7oLW+rcxni4SpvKJ0xu7Naf3QSnLXaFtYaGyBHyQM5zXYrwCDwrRLDy0KvmekzH e9rBu4115RSzxdKGfBTs+gVCgzSw+Sk/6JSU0M9odiWg/ulcZ0vc/qFlL7HloLtNx/vXbZn9Gs/q lcb0dk9Rvs8Hlv5UzL8qce7p3Mx6CGm69p8juj7wVFwe2sWsyyGnQeowH/yKFmip2U4OMHTvHYca FDLR6FYDjqTx5x4woQT3LKQOwTsfmPE1XU2gfySPyOKicnPZ/gqn/wBV5H5WoA9SvGyHNcSdunjr HA18VSzMHGpwDlgObcACCHEDcT4J4J7rSB2dQdQyx9LGf/Ye0/lIUh1d7NXV5LP7O4f9ElZBfkZV 9OKLn1D0g8uZoZMolNuRiZr8Wy52Q1tfqEvgRoTGidZ8EaOw36wsbzc9n9dj2/laj1/WSs6DKrPk XD+K5+nJ6rfScqt9Qq1O17TIA+Cf9otsxarDS2y24lrWkAAkfelxFFB6qvrj3DRzH/Ag/kRm9Yf3 YPkVxnqVC1jM3AZT6h2teC0yfLaE91vTce11TWXS3RzqS+AfDRyPEeyuEd3tm9Yr/OYR8EVvVMV3 Mj4hcVjPqvY5+Pl5NYbyHu4+TwUmZ8mK+qA+VjWH+DUuPzVwvdt6hiuGlkfGQi131WGGODvgVxPr 9UrYbBdTaAN2rC2QP6riutwa2MaxzRq5ocT31EoggoIIb4VfPeK8V7j5I4VPq+44Za0EkkAAfApw 3UUHQ+vUdSufi4dVz2AS60s2sY9vAnxK1Op49XVem2Y7wR6rCBI4P+9Y/wBT678Xoja7mOqs9axx a4QdXaEro6LBY5zD39w+fKQNFBeQ+q+Xa/Et6ZcCbcR5bzqGz/etVw2u+Kycxn7H+tzbB7ac8QfD cdD+MLYyGwZ+aklvffVal6fb6d4YeHaff/tT9exvUwzYB7qiHfLgqmHFrw4Lbe1uVjEHUWNj/OCY TRBSBdh41urCD2/irnQnNdkPxH/RuBrM/wAsaf8AShUoNdjqzyCWn5KGPeaM1jwYng+Y1CfaKZ9Z qmpth5Gjh+BXE3NZXupYCHMc+t3z9zCF33XLaX3XsrIIefUaB2Fg3hcF1T9Dnu00ta13zBhI7JDu 9OyRZkNeTpkVtsdr3I2O/FbXVz9p6d07O5d6TsSw991DoE/2SuPwb3NqpLfpVWWVE/yT72/lXUUX jI6NmUTJxsmvIaPBtzdrvxCi2/JJ6uW4kODvNaWM+WrNt0B+9XcR3tHmnBYXRqKOCq1RVhqCAzCk AohTlJK0JipA6KJSUuE090kklJydSl2SmSkYTUosl/p49rx+axx+4FZPS2ltfwa0fgtHqRjAyCP9 GR9+ipYQ21v+MfgEhuFw2KV5MK30fab3nuAFTsOit9CYx5uLxOoRU65KrZ/9Ef8AEI7qavzS5v8A r8VXzKwzGeX2FzfDz7IqTY/8wz+qFJ59pUaY9FkcQE7/AKJSV0auV/R7P6pXGdItIzr2di4uPx1X aZI/V7P6pXBdOyK8fLutukNcTBALu/km5BYVA0XVzWufaXNredNS1ocDp8R4qGUyquitpkGDy0nn +rKK3qmAdPWDf6wLfyhNZc25wOPkMEDsQfwlQ0WW0Fhdj4LrqnQbXBo2+B+ICp9RxMbForvpafUc 5oguJbrz7VpPrusosZYBcT9ETtB+Y4WbVgEXt9XDLGzJIt3NH9kp0dEErFtmZnPrZYcc1MA31ASd BoUE+nVdkjKa/KdU2HWztMRH8Vfu6cXWm6i9+O530tgBB+Mof7LfstY6wWG8fpHn2mREaCUbCKLX b+0KsBzmGoYpadCDvDTp96TxVWzDGPutsaC5lZ9pcCeZ+SI/F6q7HOGfRNRG2WyHAfNPbjZGNkU3 1VnIFVeza0gfPVKx4KYXWX5uVQLqxiOqlzW2mQ4mOITY2bRg5F5yXbjY6d1bS5v3hO42ZOYzJyaH U1sbs22CZdqRCj0/MxsGp1OSSx+4kjaSPvhLp/BXVYV224+bktaSL3ew9y2efuU8g9PPTXej6T7w wAFsF+4/igN9VvT51HrXST/J1/BHz24VWOy3EFQu3tAeyJHjwndvNH8G/Q1zOmw6ZFRmeeF2mMID B4NA/ALkLJOI4Ey4sAPzXZVe2PIJQ3KpdE4KBn/zIH8oIoMlBzT+jbP7wTxutOyWj+aA+KNTZsua e3B+ar1UtfWHby0nwn+9J2OeW2kEHnX+MpKaX18xS/pjM2sRZiWNs3DkAna78oRar25eFTktM+ox rvvGv4q91aluZ0i+mx499RHhqRH5Vzf1VuF/Rmh7zuoc5hb+I/KnjWPkfzQW890CO4V2jqbaMUNI 3OEgLPu0cVXc8gEIEWoFq5tgdkWWN03nf96z73HR3gVayT7gfJU7/oFOClmWE5ABPLS37jp+BWB9 YmbbKrP6zf4rZDovYfE/lA/uWX9ZGj0mO8LPygpHZXVp4lsMuAMQ6uwfi3+K6LoeT6hzae12LP8A aqcHBctivaHP3CQ6rsY1BELY6Hc1ucz3SbWWscPMtKil1XN63UFWcJ3tCrPRcElEMZdWkq01U6Sr bUUJQnUQU8oJZKJKUppSQul2TSl2SSnBTSn4CjOqalB1M/qF/wDVH5Qq2P8AzZ+X5ArXUROBeP5B P3aqnjCatf8AWEhuuGxXs4V3oJ1uHmFSeBBVroYJutaHbTA+CKnacqvUP6I/4hHcy8cbXf6/FAzG 3Oxntc3b3knw+SKktH8xX/VCJtL9Ao0D9AwfyQpQQkpkKQBDhu8Z4VazpnTrf5zGqP8AZCsBzhwU jeRo4j5wjaKc2z6udHf/ANpw2f3SR/FUr/qb0+3WpxrPmN35Sug9UH80FLezwIStVPJWfUm5snHy W+Wjmf8AUlVn/VP6wV60ZIPlvP8A34Lt/wBGe5HxCUN7OCFRPROvd4B/SfrdR+YLQPDYf7kM3ddx /wCk4DzHJDXfwaV6HtPYj70tro4S4I9lcUnzr9slhi/FsrI5/wBTCkOuYJ+lvb8Wz+SV6A6pjtHs Dh5iVWt6R0y/+dxanT4sCBxRTxl41nVenP4vaP60j8qMMjFt0bbW/wAtwK6C36p9Bt/7TBk/uEt/ iqlv1E6I/wCh6tfwdP5Qm+14p4/Byshhsx3MrYyw6Qx/0SqGPhube024FbIP02PkD+ytt31Bpbrj ZttfxH9xCq5H1V6tiEGnqG8eDjB/6RIRGOQ0BCuMFe36AA0lzR97gF2LRC409N6rjiu3ItbZUx7X WQyTDSDoWlddj5ePmUDJxn763aT3BHYjxRjAx3RKQKdpQM/6NY/lIrXIGaSfS/rJy1s1GKmjyTuO iCy0NY0EHjkCU7r645I+RSSzuO6hw8QVyv1Wd6WR1HDOmyzcB5Sf710wuqewgOH3rlemvbR9Z8yu Ybazd+DT/BOjsQgu1fyqdpjhWrz3WRn9XwMJ229295MemzU/NAmlBe0OedBKr2NYGw8yfAf3ouTe SBt0adQB5qlY5EHRVNfeXXNPmB+VUvrHrjHye1WWH9I3+sP4qp9YXfqzv67UehV2cfHcNwnvW5aX RtMyqyOHfS8JBCysc+9v/Fv/ACLQ6TZF9QJ5doopbFcHesMEqeCUKw+4ouCiGMupSTKuNVKnkK4z hFCQFPKgDonlJTIlN3TSkEFMk6ZLskpP2UTypJu6auYZTN+Naz96tw/ArNwH76B/rzqtfQiPHRYn T/YX0nlsj/NJakN1w2LYeOUbpDtmYR+81De1x44T4pNeRW4czH3ood95VfqBP2N3yRXOcPpNKBmP D8V7QDPhCKU+M79BX/VCLKBj/wAxX/VUnWMZo9wb8SkpJKr00Nyr3v2hxnaCeABymfc672Y8682E QAPLxKv4VApq00nj4JKQHpo/Nj5Ej8iicG4fRc75On8q0UklOYaMtn5xPxbP5FGcpvIafvb/AHrU TpKcr1bhzX9zgf7kzMl7STYHgdtJ/ItQsYeWg/JQNFJ/NHy0SU0ftlfd8fGR+VTbktdw9p+YVk4l J7EfNCf06h3YfMAoqY+r5BP6jfBQPS2D6JA+Ej8hTHp9o+jY4f2v/JJKZ2XMrrL41HE+Ky7g522t sPyskkMLxIrYPp2EeX5YCne6xu8vM10iXPcNPwUsOuwF+TkN222gad2MH0WfxPmjspIOnY1Vbxju duc2CHHcHfEHxUMOyljPs2jHiSAIBc3x+I4KzvrLn5eLjMGI81F5O6xvIA7Aqni57+qYIvqcBmUn Vw/0oH5HgfeiDeiPF6hiBmug1DzK4ln1r6rTcLXWlwmHVvAj4eS6r7a3Nx8bJboLGl0eCFKdeuw+ m0aGGjkJF4j6LfuQangsb8AiE6IKUDWRqxq4+p/p/XAED6THCP8APH8F1oOhXHk/9l9R/kv/AC2J 0evkpufWnIsq6eTW4tL3taSNDHJ4+C4a0+4eZXY/W1w+xVt8bB+AK41+t9bByXAfiEyWyhu9Ze7R o8Gj8gVWx35EXId7/hoqlr9CnDZJY1a2s+Mql9YHTTt8Xj8AVboM3/1Vmdes/m2juXH+CPRHVzqD D/hU78dFe6YP1mmP3pVGmP0h7hjW/eQtDpDScusTpqVHLqudu06lHwuJVW08q5hiGBEMZdGhXG8K nj9lcaihfsnSjRPCSlk4TJBJTIFPOiiE86IKTpikmOqauZdlkEej1V7T9F7t3yeP71rlZfV2FltW QO4LSfNvub/FJdHd0fSBahmkAyESl4sqa8dwncnIdahxfS1wPIVfqQeMC8t0dsMEcqXTrh6ZY783 +KJmbX47xoUktTo9ZHSsUHn09fvKsV4wfkOMe4xqewRcYAY7ANAAjY4/Tu+CSF2YzGan3Hz4R9ql Cr5bmsewtsDLIO0EmCCQJI4SSl2pbSq7f2gWPDjWXwPTjkGddyJWcl1nubtYGmZGu6Tx5Qkq2cFL VVG51wtZVfQWl4kEHQaOJn4QPvU8fNbeSA0ghu/sZH8mDqlSrTpIJzccND3uLQ4SJB+EfFTrvot/ m3h2k6GdJiUlNHI63jY12TRY0mzGDXbG6ucwta5z/IN3d0zuv9OaLS8vApssqcdsz6Td7nCPzY4K Jb0jByL7sr3CzJrdVa5p+kwt2beDxEjzVW36tUPr2V3OAGIcX3gGXE62uiNSNEVOs1zXgOYQ4Hgg yPwQMzIFLWMAl1rtrU2BhfYq7awW7bLrLWNaIDWvMhseSB1nfTVTmNaXtotaX7dSGuMF0eSQ3Uiq 9HMznYYO6vBLbLh+9a6SwH+rEqzmNiLPk4rIDMzpPWb+o0VPyen9QANvpDc+t47wOy0n9V6ZY012 XBk8iwOYf+kAiQfNTk9cofldMyaK27rDWSwd9w10XF9Czjh5YNhIpt/R2+Wujvi0rvHX0b9rbWWD s5jgfyFVrOidJy7DfZQxzyZcWkgOP8oNIBQ2Knnur9Duyskvx2tAeNzzIADho6Pit7EpbiYmNjHX 02Ea91G9wpv36ei0hojXUAt0+cBWclsWMH8hOPfuht1U+1sXOaY4/wBZR/StjS0H4/7lBoiAiTAT VMW13wdz2Dzj+4rj6CbfrYyCJbW4yeNd5/iutueGVOd4CVx/SR6n1hyLOfSqAnzho/inR6+Smf1s eBXTXI1cXfGBC5bEb63VKGeDgT8tV0H1lNl+S1jASK2/iVl9GxnsuuzLWlorBa0nu4+HyTJKi6dz 9z3FVLHTHmfyJW3hoJ5VQZddkjcN30Q34ohLaxDo+w9/46rG6xbvyhWPzQB9+q2azto/ralc7ff6 t9lkDkkHyROyhuvWB6bnd3vj5NH+1avSG/rDj+43T5rMrBDKmHmC4/2j/ctjpLYrtt/eMBMS23mS B4laOMIaFnMG60DwWpQOE4MZb1GgCttVakcKyEkMwEimBSJQSsUySUpIXCfsojhS7IqT8Jkkkxcv KrdRr9XEfAlzP0jf7P8AsVpMklpYF49IN+5Wi8LGyquq4zjX06oWBr/pRuhp+j3Cusr6hRS1+dsD zo5rSJ+bdYThskujh5IquE8O9plaWSWChzwBMLmXWEO0V92e67FZS3Wx52n4BJTsYxmhnwRsf+kE eSqUvNdbG9wEbGtnJPmEUN9Ruppsh1gkjQGSDr8EtyZ49QPZMHaWg+BcDqglGcan1heA5rgZPgT5 pNxNlhsZY4h24kHg7v7uyrYGNm4/TG0fafWua14bdZqZk7Z+lwi9N+2tw6/2g9tl7p3uYIB19ukD tyipkyq5j2guJrDNuriZd4kFCtrymiKWVmS4OkASyPa32q4UySnKviqus2YsCHMcxhdIaNZG3RTo +yY1L+oGt7C0Fjml27ghu0AwNHaBaSYgFK0OOzHxbHer674Y/wBMgtAa4l30mNYdOeeEeu6l1IqG UHWtsBcZdX+dGz7hEK6MehsxW0bjJgRJQXdNxHOD9pBB3A7jzM95StKFzOqMqqh/qPaXCwtAgg6g +6OPBGxH5bw8ZVewyNnGoIgzBOsqzCSCkBxa925oLSe7SR+RDsxLD9GwuHg8g/laVbTI8RVTjZPS WX/ztFT/AD2CfvBaqf7FbjuDm1FrO+174/KuiPJQsj+Yf8EeIqpxx09rrWPtjZUZbWBpI4J+Cr9Y zsXAurflOLWkQCAXak+S141XOfWfEyMrLxhQw2Bj63PjsA7UoWVO8LDAcWOAIB+9J1zIgyPkVZL3 yYJ5Q7H+IB+ICSHP6jd+qvayfcNswY93t/iua+rhFl+dmfvv2t+Ek/3LY+see6vFfroxrnwPECG/ 9JwWZ0NhxujMB0NpLz89B+RO6FS+cyrc+1/uLuAeFmZNznNDCfa3QNGgVjPvl+wdlm2vkx4Jh1K4 Cg1sy4V1kBVcKsvsE8/xKJkVuvO4EbW6uHwR8CvY3efj96IQUnUcgY+M4DkjaPiVz7Wl7gwcvcAr vVsg2XCkahnPxKr4zZe6zswQ34nRCRSEzjFji3UDQfAaLbw2elh1t7uG4/NZFVBfYykcvcAVsvIH tbwNAmjUoknxWy4uWrjt4VDFZtaAtPHbAlPWFs1o4QqwiBJDPukmCSSlJJkklMuyXZMn7JKT904C ZSTFyuySXZNKSXL6o3JovZm473MaPphvE9pWjjYlDegHOyMgPyMh01UscHTLvpPAk8KT2te0tcJa 4QR4grOxafQL8OADWZYQI3NKIPRI2piQi4lopyGvPHB+aZ5IMILklPRTOo7qeMf1kfD+9Z3TMwWM 9Gw+5vHmFqUhoeH9xz8E4ILdBScXNlzdSW6fEcJJ5EQUktDpmXmu6UcrqWMcfIr9Qvp7w0kiJ8VP pHUK+p9NxsulrmNs4a6ARsJB4+CuAHs7TzEp21huo5SUuklCSClJvJOql3Tq7cj7UHuY+AIH0ZGg MIqbSSrjFsaNLCXNa9rDJH0volwmDCWLXl1gDJsD4bGnjJ1n4QkpA37ffk5PpZIrZTYK21uqDxGx judzXcuT2XdRxtjr/QtrdYyslgexw3uDZgl47qWMzfb1Bh4daBoY5qr7hNlMNeHj1uMlluO0nxIe wJKbiSSSCmBGqFkfzL/h/FGPKFkfzLvl+VFTW7qlkj9cH9UflV3uql8HMAPcAJIbeir3vABPgj2V UweW+Y/1CyOrZVOPjkVtL7X+xm4k+46DRIKed+sWQ7JLcasy7ItDB/VrOv8A0j+Ct5NjMahtTdG1 NDR8gs7H25HVXXTuqwm+mw9i4cn5uJKH1HL9R/pg8coy0ChqWvdcSS88lU7bD9EclPbb/sQmkNm1 3yHiU0Lmb9A2gcnV3w8EW+1uLjl3cDjxJQ6GkTa/k6/NZvUMo5Fuxn0W8eZ7lHZDWc8uJedSe/mr 2PX6dTWnk+53xP8AsVfFqFlm4/QZqfNXNTxq4mAPElRyOtLg2sBk2PyDwwbG/E8/grtbS+wHwQWM 9GptI1jk+LjyruLXEJ0RQWSNlu47OFo1NgKrjs4V1o0TlqRvCmojhP3SQyCSXdJJSkkkklLp+yYp dkFNgHVT7KEKTTpBTVyuyZSmUx0SUxHCr5dTiBfUP0lWoju3uFY4ToJaT9t1Yvr4dz5FAcNFYe37 HcXx+gtMOH7rj/eo21QZbq08FO3T4tRr31PD2GHNOi38DNbkMBBhw5HmsN1JKJji3HsFjfmPFEKe spskQePyI4as3DyGWtBB1WjVYCIP+5FTLaQmkohUDzwkph6jZgOE+E6qUlZmb0VuXcb2WmtxaWxE jufEeKjZgdSba+yi7Rxc4N3ERNe1uh0+kkh1ZKUrG9Tr1DNW+oQ3wDpIZ5fylN3Vsqp+y7H0FBtJ 1b7gJLe6VKt1twS0KyWdfxzRXdbW9gscGACHQTPw8FYHVsAsrsdZsbbozcCJgx5+CVKTWdPx7LHX A2V2PILnVWPZJAiSA7bwPBDd057nM3Zd762Pa/037HAlh3D3bA7keKM3Ix3glljSGktMOGhBiPvR Ae4OiSmSSbfHKRd5JJYnkoWR/NO+X5QioWT/ADR+I/KkpqysrK6r085IDbm72e1w1mR4QrXU3XNw L3Y/84GHb8VVwcLCxKWubS31nNG941l3c6ohDZyMxjqg9hBDhMhcl1XqRc63JaZFP6OnztdpP9kL e6ljXZbLPsn6KWmZOmg58lx9llVlwgzjYchp/fefpO+ZSH5KTMeOnYDa/wDCWe53xKzLLSZJPPJT 5WUbX7nnngKsXEn8qaTZSBTMe47naAfgE7AbnA8NHAUGg2kAfRH4p8rJbjM9Nn0z+Hmkljn5Yrb6 FfJEHyHgs1oc4wNS5IkvMnUnxV7Ex/Tb6z/pH6M/lQkaUGbK/RYKRzy7zKs4dfuN7uGaM83dz8kK ut1jwxvLtSf3R3crzWjSusQxugTYizapGhTOlhe+fuWpj1aKvjVRC0qGQApAxlPS0iEccKLQpwkh mE4SCQSUyCSZOElKSCSQSUuUkydJTZhMOVLlKITFykxUlE8pJVodEoSKcFBTB7GvaWPEtcIIKzXO twbfTsl9Tvok9x/eFqlCvprvrNdgkH7wfEIg0pCzY9u5hkdkiFmWOyul3cb63dhw4eLfPyWhRfTl VC2l25p+8fFOSzrufS7cw/EeK18TOZcBrDgsZwUGudWdzTBSQ9XXkdnI8hwkLnsXqXDbdFpVZIIl pkIqbp0CZDbktOjkQFrvon5JJXSI7dkkpSUisxca1oFlTHAGQC0aHxVe7pGBc1jDXtFZlgaSI1lX UklOZf0Oiym2pljm+s7eSYdBLt/krmHj/ZcWrG3b/SaG7uJhGS1StDEtlMBCmdreTCDZksZo3lJS QkNEuVS+/doOAh25BdyVUtymtnVJSWyxrWkFZOb9YcTCr9OwOIn27IMx5FZ/WOv11TTUd7+4H8Vh F5A+35nvc4xRV++R/wB9CQS7HW/rE+7EGFh1mizJb+kLj7m1n4cbly+RexjBUz6LfojxP7xUcnKd ucXO322GXu8T/cqsFxl2pKUj0UAvJcdx791Out1hgCAkGNaN9x2jsO/yQr8okbK/Y38Sm2lNflsx 2+nT7n9z2H+1Z7ibDrJJ1+KYwBqreJi+oPUfO3sO7v8AYkTSlsbGE+pbq0cD97/YrRJJBiSTAaO/ kpuZtG53wa0cnyARKqi07jrYdNOGjwHn4pnzFN8LKqv0wWDV7vpuHH9UeQV7GoOkqOPjzGi0qKQA pAKYyWdFMAK5WyIUK2hHaNQitZtCkEwClykpkkEgkEkLpJJBJKk6ZOkpQKdMkkpudkyQKSYuXTHl OSokpUpRTpSoSSUksvNOQkExQUitorurNdg3NP5fELEyMTK6bd9pxToTr+67yd4Fb44TFocCCAQd CDwUgaU5mH1GjMGz+buH0q3aGfJGcIlVOodFa79LjSHN4AMOb/VP8CqtXU8jG/RZ7S9g09Zo1H9c dk+7S6R0CnVm20HQyPBDZbVcwPqcHNPBGoQrDqeySnZx+q12aOMHz5V1mS1w9rlx9r3g6JM6hk1f RcSPA6pWqntWZbx3lFbm+IC42n6wurMXNIHiNQr1X1gxnx7x89Pyo2p6cZlfgkcuvwWA3q9DuHA/ NTPVKfEJKdo5jewQ3ZjzxosV3VqhwQqt3XamTL2t+JCSqd2zIJ+k5VLs2tk6rm8n6yUCQ15efBgn 8Ss1/W8i10trhvi4pWqnpcnqjQ0uc4NaNS46ALnOo9ftyCacKW18OsPJ+CpXWZfULA15L9fbW3QS ne/G6cCXbbr2/m/4Os/yj3PklurZZlNeMwZOZLi7Wur86w+J8GqllZd2RaXTuedCR9Fg/daq2Vn2 3vc8uLnO+k88ny8gqxuedCTH4IGQGgUB1LY2sZrY4AnmNSmOQ1gitu3+U7UqqbAO6h6hJhokptpS vtc47pkn84ockuho3OPYI1eFfZ7rT6bfDv8AcrlVNVIisR4uPJ+JQMgE018fCAIfke53ZnYfFaLb hU3Y1u57uAP9dAhNDn/Q0H7x/gO6tU43gOeSeT8UKMt1EgI6qnF28nc86buzR4NV6jGRacWIV2uk AJ4FLCbY0UgBW2M0TMZAR2N0TlqmNRRoVFoRANUkLhOkAnhJS6QSTgJKUkl2SCSlwE6QSKSlk6SS Sm0Ekgl3TVyimKd0pjwkpZIJ0ySl0yfsmMwgpiVIJJgglThIVW7FpvEWCHcB40KtnhDfEIqcS/o9 2O424by0+Nff+tXx9yEM7IrEZVO8DmynX72HULeQMn7HP6eN3aPpfKNUbPUKcuu/FyR+isa4928O /wA06prKBB0IUcwdLmbiN3YWAbvkWncgVbyf1T7S1vbuz/wXailRpcCe4QbKZ7Qrv60B7zU7+sNp /wCiXIRPtO9o+TjP/UpKaLqyw66pGw8zHzU7PTnUH5n+8KB9D/dCSUb4eNZKqvbrDNQtJoxS39K5 zWx+a3cf+qai0npQMUN3u/evcWt/za2ud+KVItyqcbJueG1tiT2Ekq+/BrxhuzbAxwH8y33W/No0 b/aIRsw9c9NwwRV6Me44pMR/KDR6n+cVj4e/7Q39oz6E+7bG35wkSB4q1PgkyupbWmnEAqYdCAfc 7+s/+AWW9l1p1E+AAMD8F1VP7K932X0t3aIn5KT52CNyYZSPQ0kAPKDByncVu/zSPywpDp13Dy1s +Jk/cJW1kx7pJjvoqjfSnvPmm2eydGnV0ika2PdYfAe0fxVmvGZVpUwN8x/erLNvaB+P9yn7PM/1 tBPylKid1WOiJmJbb7WiT4DVEPTasdhsyXBx/NYOJRT9u2/ooDP+D1P8FERv/T7t38pOAiPFBJQ0 0FxkrRx8eClV6WkK5VtTlhU2sIwbAhO3bKJ7UUKa0IoGiiyIRNIRQpoU4SbwpCElLQnT6Jd0lKhO EkgkpZOknSUpJMkkpdJMnSU//9kNCmVuZHN0cmVhbQ1lbmRvYmoNODU0IDAgb2JqPDwvTGVuZ3Ro IDcwMC9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzPj5zdHJlYW0NCkiJjFRLaBNBGP4SWypY6kGtDyrM QYpIW5bGk4iQbB/2YRrSVGsRynZ38mg3u8vsNlbpSQSPonjwJPjAi94tnkQKHgR7KFUREepNVBAK paA1/vtoM7RanDDMN/988/3f/ycZoP6s5jhmnAGubolsb4qNXhxjDYtoQAzB0HTXSWYygwEmLraN 1bchd7H97+c7jj2CEgKx3YT3F0Lc4uOJECs+vuw5HuEuH+tFzSA8SrhN5LIq4euEmwoSnpCwwV0d qHtP2NIdQTp1dwgnDVcvE4dw/Ldfc2jHGwDOHAV2va7Fxlzg6WPgYGstdvwQcOACMJeoxVayQR9i zQtuPtEZhGKNKaD+U7W60go03AbWb1WrPx9Uq+sPKcdH4IWpT4tK1ItYPAGUzWk92u+l2citkWFa j5HPe9zt9nEbUQcNrYu84iThDwbv6o7id/Olnj7fIM35vOgZofU03X1Z8vpyIScuLDM9GGk2WXZ6 iDDVEJtxvFQ2vBvvdyvDvuYJmt8mtf4MrS1+cVP2gM+h+uOdV4s56gGOUJywmibcTHgeA9BQBoeg 1SLtLHqRQjscitjIo0Qfk+b2uEnsPFZpz2QV5YmyrHzZVGLKO+W7sqTcVx4pX/nM0LnK2uR47fSa GC/pCzd/IBPc3tCNTimbFjhjULFMGcLdhpcpybvsa+M8s8Xrr61e4VbWCqdq+Xwn/EZ6dVNhgngu 5RGkUSFs0o4T34s0Za3tHeIBR61x3njPc89ma/mW6uYuLTa+mv1H9UaQS8XnzRxyRbbE7KGdR1OX /Eh5JaaswLd0KIvzUl6THQ76Gn4HPOD41RWjXPD4jOf/+FXbuSJKhaLHOhUlwZL0tHCm2mVn2uOC 9Vl6RxvTTJMFHJcJ7nJR4UaHfzf8zwdjn6qVudCY/7RlhJ0vmVx6fXY+/e/xR4ABAKVzBRINCmVu ZHN0cmVhbQ1lbmRvYmoNODU1IDAgb2JqPDwvSW50ZW50L1JlbGF0aXZlQ29sb3JpbWV0cmljL1N1 YnR5cGUvSW1hZ2UvTGVuZ3RoIDExNTI5L0ZpbHRlci9EQ1REZWNvZGUvTmFtZS9YL0JpdHNQZXJD b21wb25lbnQgOC9Db2xvclNwYWNlIDgzNSAwIFIvV2lkdGggMzkzL0hlaWdodCAyODUvVHlwZS9Y T2JqZWN0Pj5zdHJlYW0NCv/Y/+AAEEpGSUYAAQIAAYkBHQAA/+4ADkFkb2JlAGSAAAAAAf/bAIQA DAgICAgIDAgIDBALCwsQFA4NDQ4UGBITExMSGBQSFBQUFBIUFBseHh4bFCQnJycnJDI1NTUyOzs7 Ozs7Ozs7OwENCgoMCgwODAwOEQ4ODhEUDw8PDxQUEBESERAUFBMUFRUUExQVFRUVFRUVGhoaGhoa Hh4eHh4jIyMjJycnLCws/8AAEQgBHQGJAwEiAAIRAQMRAf/EAUIAAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYCOwEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x9fn9//aAAwDAQACEQMRAD8A4LD6iWEMt1HYrVa9r27mmQVzcK1iZr8dwa7V qSnahKE1VjLmhzTMqe1JTFMpEJiElKCluURokkpnKNj023u2VtLvPsFPA6bbmHefZU3l5/gtljK6 Geljja0cnuUqUShxcRmIQ8ndb4j834HsjE9j8YHCYkJiittcuUXHRIlQcUVKlODCgdEgUlJQ5SDi ECYTh8JKbQt3CH6hDna7TshiwKTnSUkNfN6eL2nIxxFo1cwcO8x5rMaZ+IXQUOkLO6riip4yqx7X mHjwPj80CExPRozCiSnJ8FEnVBcoalWWDsq7B7grbBokpcBPCk0KQaihZrURoKdrEeumdSkpg1pK m2oDlGDAOE+1FFowE8J3FjBLiB8UCzPw653WgIKSwlHZVD1jp8x6rfvRGZ+Hb9C1p+aSk0JJw5rh LSD8EklLJJ0kkrJlKEySlJiJEHg+KdIpKRPq7t+5Dk8qyhvrnUcpKYi1wGuoTWU4+QIeIPio8JIJ ar8C+h3qYjyCNRCXqdZ/0z/vP96th7m8HRP6pS1U+f6nhLQKROkBRI0SSmxsuzHeHA+3uFu42TXk MBadfBc0ZRca+zHfvafiElPTFqiWoOLmV5LJB93cI5SUwLVf6Z0v7T+sZHtob/0j4BS6X005thss 9uPVrY/+AWtbYHQysbK2aMaPBIBBLF7gQGsAZW3RrQoE+CTioEpy1clRJTTKSSl50UXFOouSUxJT tKgTomDikpISFEuTSol0JKZbiptcCgblIORQ26HalHsrbfU6p3DhCqY7uVaa5JDzj2urc6t3LCQf kohXOr1hmXvHFrZ+YVIcphZBqEtIlyttCr0DurVbdUVFIxqM2uU9bJVplcBFbbCuqOUUNUg1Dysm rFqNlhADRKSFWWMqaXWEABYXUfrNXVNeN7j4rJ6t1u7NeWVktr/KsuPFC1wDbyerZ2UTLy0HwVQl zjL3EnzKZxDVEFzvohJLKGpw9zdWuj7wmFdpT+k4d/wSU2KOp5+MZreSB2mVsYP1raSK81u3tuC5 7a8JGHaOCSqfQaMijJYLKXhwPgiQuAxMzLwLBZjPMd2Huuq6X1ynqTAydlw+kw/wSQRTqkJlCXeK fc5JC6SQcD5JyCEkrJJJQkpG9gcJHKCZB1VlCsb+dHxSUjlKSmSSU8W6idW6obgRop7y3jgpBwJ1 QXISIUdVZLGv40QtscJKZUWux3b2nXwXRdHD+r2sooHvJ93kPFczBc4NaJJMADuSvROidMH1f6Q0 u/puYNzj3a0pUgmm1d6VFbcHG/mqvpOH57u5VclPwFB0py1Zx1UCU5SDSTCSlgVIBNY+qj6Zl37o 5Vd+Tk2fzTQxvj/tKCqtskHwQ3qm5uRYfpyfMlHowLHxuf8AclYTRWcmlW/2ZbHss+8IFuNfTrY3 2/vDUIophKiSnJUCUUKPKeYUCUxKSmzTZBVplgWW2yCrDLuDKSCrrI3VV2fuuj71mNWhn2B+KR4E FZ7TCbLdfHZs08QrtLeFSpPC0sdvikFFs01qwGobCFLeBynLVW2MpYbHmANSSuJ651Z+fca6yRU0 6DxWj9ZerTOHSdPzyPyLmwO55KaVwDGFEu7N5TvdJgKVdfcpJWZVu1cjhoHCYacKYCSlAeKiSFNw Q3cpKWOqjtCknAlJSMsjUJhvreLanbLGmQ4IhUS2eElPT9D623OH2bJ9mQ0fJ3mtr0nETGi89Bc1 zXsO2xhlrh2K63ovWnZ2P6bztvq0cPHzSQXULCEvcB4hJuVYPpajzViuzFt0sBYT+c3Ufckprpij vogbmkOb2IQywhJTCExCcpJKa9jNp04PCijvbubH3IfpFJTwkyEw8FIs7tUD+KC5nJAhO2O+qYea YTIDdSdAElPQfU7o7OodT+03D9XxR6jz2karqMvIOTe606DhrfBo4Cj0/C/YvQKsVwjIyzvt8Q0d vvQidE4LSo8KPwSJU66y74dykhgGk+QHJUX2Od+jo+bu5RXA2nYzRn5UVmOGDQJpPQLox6lpeg2s bn+534IXusdJ4HAVzIb2Q6qi72tGpQASSjqxyXA+K1KKYHCdmPXjs9XJc2sR+cYVa76xdLxzsZYH EdxqnUh0WVwOERtQdLSNO6xq/rLjWmGWfc0H+K0cTq2Pcdpe1xPxa77nf3pIc/qvTfs4ORQPby5v h5hZBtbErtMoVvxjZILY/BeXZz7ftd1YedjXkATwJRtFW69mZTX9N4HzVV/VqB9EF3wWTA+KfQIW mg6H7VbP0Cis6rUYmWlZTS0lH9NsTolZVQdQ5rLq9rXAyolwCydhGo0RG33s0J3DzSOqQKdai4bg tOrIaABK5uvMAPvBCtVZrOzkggh6Rl090HqOcMTEfbPuOjPistnUI7/NZvWepfaXCtp9rB+KNoAa FtjrrHPeZJMlCe+NEtwAQpmSUFyfHqFtg3GG9yt6vC6HmVioCzAtiG2hxtYT/LY7X7lzdeQ6t2nB 7LTw8htpHug+CQUzz+k53TIfkMD6HfQyKjvqd/a7fAqs06Ldxc/IxgRU72u0fW4bmOHg5p0KBkUd FySbRVbiWH6Tcdw9M/BrwdqVKcp1jWCXGE1VOTlH9Wotun9xhI+9adTMSh/6tQ0vHD7f0jvx0/BF uz8k+2y13k0GAPuSU556N1sDccC8D+qq1lWTjH9Zotq/rtIWj+0ba5DZkd5RGddzq2x6jtp7O1af kZCWinHDmv1aZSWq+7peb/TMZrHH/DY36N4+LfolAyOkXMrORg2DNx26u2iLWD+Wz+ISU0HCdRyp Y+Rbi3NyqPps5H7w7gpaHVpkHuoEQd33pKezw8qvNx2ZFRkPE/A9wjiey5joeacTLGO8/ocg6eDX /wC1dQEkFNTa9pkaHurlPo3mD7PH+9Z7TtMorHQQ5vKSmxm4noOBbq08FVYWgy0ZFJqdzyB4FUXt 2khJTDyShPCSSnz/AFHCiQHa90aAUJzSNUFzAyNCtj6q9NPVOt49H5jHCx58ACsoEEQ5dn9RsX7H g53Vzzt9Ko+bvb/ekEF1uqZDcjNsNZmph9Ov+q3QfeqZKZJok6Jy1nWze6ArDmaem3gfS8yiY1Ja zf3do3+9XcLCNr9xHtb+JSOn1SBbXpxS1u5w1Kc1wFo5FewaLP1LoiZ7ICKbaj6XWP2tEknRVs3q VHSmmrHAuyu55az+8pdY6q3CBxMdw9dw/SPH5o/dC5q97vTcZncYn4o7Ka3Ueo52ZYX32OcD56Kg S6ddVoWNaRwgGkFBTXa5w1HZWqeqXVGHODwPHn71Qts3yBo0HQKASU9dg/WC27GfjhxgjVp1+5YG e/8AWbHD84ym6SSMjTwKn1Ov07vI6j5pKam4piUkxKSmVfKO8w1Br5RLT2SUpjyCrLdjhroqrJPC K20N0cCElJjS08EFQdjkdoTh7Tq0yn9Rw7pKRGtzeCUN1W7UgFHNruFB1nkkpruob4KJpaOyM6we CgXykpEamjsFCCwyNEUklQedElNqnqVlYAf72+PdXsQjOtFVbg2eS7SFlU1B9evin220uD2Egjgh JT2DcOjHqIbqY1ceSsbMALy5ogT2TYvV7MisU3O9w/FPaQSTrrqmbGyv3FBrtb6xDTzIB+CrdWkZ TmT7WQ1o8APBaeF0vO6hcwYVRsMySNAB/KKudU+pHXrbHZFbGPnXaHQfxEIghaR4PKsvtYdDI8Ct bpmW172+nccfIB9k6A+W5Qr+qvWHPLLKvSI5Dzr+Eq9R9TMon9NYAPBo/vRtC+XgtznOcGDGzuS3 iu7+5yx3Mc1zmPaWuaYc1wggjsV2mJ0k49Ix73G5rfol+rm/Aqv1voByaPtWNrfWI83tH5rvPwKS Xkg3cCzg8tPgut6PmfbsJljv51n6O0fyh3+Y1XKRBnuOy0+h5P2XqArcYqyxsM8B4+gf4IoL0sJC Rwjel5pjV5pIWbc6shzUn3l7pIhL0j4qJrcOElMuRKUeSgA9vbRS3n91JTwafQiCoxClEhBcwdWB qvQ6qW9P+rPTsNoh94ORZ5zo1cJiVG/Jqoid7w0fevQOvODMxmMPo41VdQ+TdfyohBc4o+NWXvA8 VX0JWr0qkvfuAkjQfE6BELW9VjkgNaJ/MaPPut2rBFFTah2HuPn3S6bgt+0NJ1bSP+l/vWz9nYkK Jsp2DzmVikyY0WH13JZ0bDNv/ai2W1Dw8XLtMququS4wBqT5LyT60dUd1TqllgP6Nh2VjtAT5EAa dUDUuLfc6x5e4kuOpJ8VW+0vLhB9o1Hx8U9zt7iwcD6R8T4IUHso1zY+0Bw9wULbAKXuHcQPmgwe yFbZuhg+iOfMpKRdk0KRTJKS49zqLQ9vIWh1DJoy8aq2sxY32vb4eay4jROxx+ieCgplKbum14PZ IIqTVHWFK0qFfKd51SUyq5RQUKvglEaUlM3MqLQ4DXg+KGWkfRcR+KckJiUksSbB3BUC53cKRKgU kLSSYhMQe6k0ao1ODmZTv0FL7J7hpj70ktdCet/G+qPVr9bA2kH94yfuC1sX6hUGHZNllp7hsMH8 ShYVReTx/bWFdoxMnI0pqfZPgDH3rucX6s9OxY2UsBHd3vP4ytFmDU0QGkx8ghaqeBp+qnULnbjt xzyCTJ+5srbxfqsAGnIebSOYG0FdS3HA4aB8kQUTzqlunZr9LaOnMFVVbGV92sELeospyG6c+BWY 2geCLW11btzdCkpn1LpTLm+pWNr28FZtFIsaQ4Q5phw81v03i1ux+jlQsx/Syy5v0bBr8QkhoWYm mgQGNaCWkfyXNW06oELHzZpvDyIa72u/gUlPHfWvo32PI+3UD9Fcf0nk48O+fdYTQXNLWmHN9zT4 Ea/lXpWRj1dRw34to3BwIXneTi2YGY/Gt5rdtk92ng/cip7DpuUM7Cqyu72+4eDxo4feFZIWF9Vr 9rsjCd2IuZ8D7XfjC34RQw2pi1EhMQkhFtS2hTIShJT57oeU2rU5Cb4oLnW+quP9p+sGFWRI9QOP wbqum6nZ6+fkW+Njo+RhY31EZP1grs/0bHu+4FaVjtz3OPdxP3ohaURkGQrGJ9Za+iPZbk0+tWDJ aDDvl8FWcYWP1N4svg6ta0AD46ooD6T0v/GF9UbKg5+Z9mseZcy9jmkfMAhbdP1s+rN4mrqmKfja 1v8A1RC8JfjsPCC6nby1BdVvsP1v+tHS6Om3fZc2i2ywbGiuxrj7uT7SV5bkWFrC4aueYb8Ssx7G ASQAFI5Lnlri4HaIA4Ru1VScs2jaNY7qEJm5Bn3BSLwGGw9vyoKQ3P2/o28nlBKUkkuPJSSUpMnT FJS5HB8kynHtaU0JKWd9L4hIJO7J2oKSVpnHVO3QKJ5RUkZo1TCgNAApDhJS4THUgLp+gfUfN6rQ MvJccah/0BHvcPGDwF0mJ9UMfpPvrrbc8c2P1f8ALsECaTVvDYX1c6rnwW1elWfz7fb+HK38L6iY 4AOZY+13drfY3+JXX4tdThEQ4ct7q2Kfl8E2ymg8/jfVjpmLBrx2A+Lhud/0pV9mHWwQ1un3LTFI S9IJKaTaAOAAiCnx1VkVqWxGlW1hSPBTFSPsThqSLQCtS9MI21LakpEGJbUTanhFSMNPZSMujdrC JXUXyRwBJKieUlMmslZ/Venm6pzxyAdFpsUnxtM+CSnlOm3EuNbuf7tFjfXbpc1s6pU36J2Wx4Hg /ep9Z6nj9Nz2y70n2WbmsOhDXCTuC3KBR1jpj6HvFld7S2fCRH4JKeB6TecfqWNcfouPpP8Ag/2/ lhdpHiuDvouxbLcazS2h5afJzT/eF2+NeMnHqyBxaxr/ALxqigpI8ExCkmKSGJATQE5TJKfPJB1C RE6qs15COyzsUFz0v1FBHVLnfu49h/BXncKl9STHUrgPzsez8iuv40RC0oLCsPMduvsJ8Y+4Las0 lYWSZuf/AFiiVBEVElSKjyglG6prxBVd2E4ElpIA8VdhJjiw+IPISS0hXAifvTPcfTbX8ytK3prr a/Xx/cO7RyPks+yh40IghBCJJIJIqUmKdO1u5wA7lJTMiGtHkooj/pH7lCElLPH0UwV/F6d9oaLX ugcADyVz9lYvcE/NBTkA6KPdatvSqA0ljnNP3qGF0HPzsluPjAO3H3P7NHiUktbHpvy7GY9DDZY7 RrWjVd39XPqdVhuZl9RAuuGrWRLGH58lavQPqzidIpArG+1w99rhqT/ALdrpDeyBPZIHdsY+3YAB EaI5qa4cKs0Eaqwy2NHIKaGXhbHetUIcPxRKoewOV97W2Nkaqo2v03EDhFC21NtRCE0JKR7UtqJC aEVMNqfapwEgY1CSlhW49kzm7ZB7eCk+x7zLyShkpKWhIJSmlJTKYEeKikXKMpKSNKJuQWypwkp8 u+vfT8vP+tNxxWbmtrqBcTABhXfq1kZHTLmYeSZbYdp8A7sQtfqLGXdUy4+mx7Q7/NaQsvMawWem 0xc1vqt/slOAH2rSUH12wvs/V25bBDc6ltp/rsOx/wD1Mqz9W7vV6Wxh5pe6v5A7h+Dle+ttYzfq 7h9QYJNNoBP8jIZ/5JixvqnZpl4/7rmWD5gtP/UoJd9MVJMQkhgUymWlRhJT5gnaYU7aLKHQ8aeK GEFz1H1FtDus+mfz6bB+C1tkkt7hcz9Usg431gxHTAc7Yf7QhdZe015NjPBzh+KIWloXMMwsDKBb e9rtIcfxXT2MD9QrGFg9Pz3voz6hYRtIcCWujjlpCRUHiinDe67XqH1Q6NBbim3HfyCX+oPhDh/F YTvqv1CqtzzdjOIHtYx7i52vmwD8ULBXVTkRoouCsXY9uOYyGFmsA9j/AAQSySHNIPwSU2mSxkgk HyVLLe5ztTKsWZNVTILpPgNSsy/INpMCAUlIu5KSSSKF1OrSbPDQfEocToEQmAGjgc/FJSkmiXAB NKudMx/WvDjq1nuKSnWxqvTpYzwGvxRdqmBAUqabci1tFIl7zA7D4k+CapbD6dldWzGYWI2XHVzu zR4ld7hdF6f0HHYx7wHEjdY7SXLCr+sf1e+qWIcbEeM7OdraadRu83nSB5LkOsfWfO6zc63IJa3h rWuPtHw/ilunZ9fYwQC3UHghEDF5P9X/AK8dU6GW03fruH+44+9o/kP/AIFem9G6307r2L9r6e/c AYew6OY7na4JUm26Gp4UoShJSwJHCY66pymSQsU0JzAUS5FSioykSoykplKYlNKaCkpclQJUoTQk pjqniU8JwkpiWpoRHDVQSUzaFJQaVKUlPGdVccP62uadGZ1LSP6zJH8E2ZhOffVk18skOB7tPKN9 e6/RdgdSb9Km7YT5HX+CPIewEd+Eei2QB3Riv7T9T87GJl1DHFo86Hiwf9Fct9WbAzq1tXa2h3/R cD/FdbgAfY+o45/Oa8R/XqLf4Liegv2dcxT++17PvYT/AASKej2aY6JSmJSQsSmlIlMkp4i1otbt eJ81m3YzqzLeFpByZzQ4IJc/CvONl03jQ12Nd9xXoOeQ7K9UcWgPH9oArgrsWfcxdjiX/a+kYeQf p1t9J/xYiFFJwZTC842Sy4cOGx35QnKFfWbKi0c8j4hJDpZXUG2Q4HkCfis+3MEE+Cy35T428Hgj zCrW3WDQk6ptUuu0+WftlNjB9Jvvb8uVhAxpxC1Be6twe0y5vYeCr5+KCPtmMJqfyB+Y7wKKmmCD PmqnBPxRw7WUG0Q8nsdUlMUkgCeERtRiUULD2ie6aU7gmSUu0FxAHddD0/G+z0hpHudq7+5UuldP MjJtH9QH8q2AIQUtErG6hmWPtdS1xbWNC0aT8fFdj0XpwdTk9XyR+r4Vb7Gg8Oe1pI+5cFZY+20u PJ0+7RJVLEaaceCbw/A9wr1PTway/IsZS0DdqZcfABoQrsemt0CwWACdJj8UlNdroM/evVP8XfQM vpWDbm5gLH5u1zajy1jQdu7zMrA+oP1UHU7x1rOr/VKXfq9bhpY8fnn+S1engACAkljCYqRUSkpj CYmE7jGiESkpclQJTwSn2pKYQnhSISiUlMYShTNbmmHCEtAkpjCiUb1YYWBo17xrqhESkpikDBlO mSUksIf7gIlCKkDoouSUtu1Sc8woSmedElPO/Xr39De79x7HD71knIfdXQxlpZNbX7eAdDMn5LV+ urh+wrge7mD/AKQWDiNfaMesCXCtu0EEgAg+6dAI/FEIehwG7De0/wCErY6CZ7EcrhenH0+sYRHa 4NPzBau6x3D1nN7ito/ErgcZ0dVxD/3ZZ/1SXVXR7qUxOiYu5TSkhYlNKR802iSnhg8KW/RVWvRA 6SB5hJLZsx8ilrbXthrlr9DyGmu3DnR/6Rg/lDlaHUsRtnSKnx+aNVzePa/EyG2t5YZ+I7oJIekB kfBMU1b2WDezVrgHN+akUVrl9TxXNnJq/tgdv5SxrLn/AETqV1Z10OoPZZOd0ckm3E78s/uSSHE9 Yg6GFZw859DjEOa76TTqCFWuxbKjtIIPfcIQ2u2uQTTpZGJgZY9TGf8AZrO7HasPwPZZuRjWVe18 Hwc0yPwTueXGTonrZbadtbS4+QlJTVEtVrHNRPvIE8ytCjobrPdknYD2HKOOhYTTJLyPCR/cki3N uqof/MHc790cqzg9Igi3JHmGf3rTpxMfHEVMDfPv96IkolYAAQFYwcOzOyGY9fc+4+AQACSGtEkm AB4ldj0DpH2OsXO/nHxu8PkkdFAWg+tV9XSvq3b03H9u+sM08yJXltWr/mu8/wAYFOZtbbtcaBIc 4cCeJXC06OKQSU7/AKK0Pq50K36w9UrwWyKWxZlWD81g7T4u7Kph4eX1PIZidOqdfa4xDRo3zceA F659VPq5T9XenCiQ/ItO/It/ed4DyHZJTrY2NTh49eNjsFdVTQxjW6AAIhT86BSIDBJ1KSkTtFB7 oTk90JzklLOKYNUmtlEDQAkpgGpKRBKYwElMCluPbROVApKXJJ1KSaUklLFJJMkpRTJnOAEnhD9Z pkDWElJeyi4obrHkDbpPMqBIc7dMx9ySl3PaJJ7KHqh+gHzTwIg6zrqh2vDGEnQN1SU8v9eskDCq xQdbLASO8N14Wf04PrDHWDa2sS5x54+jM6jVUvrD1OjK6oTbaG14+gB5J7wszK+sILPQxg4s7l3J +9IKL2XScoZBysgTtaQ0T4NBPHZcXiHd1PC872H8ZW/0HJs/YGTlWmHPbc4fBrSB+KwOmjd1jBZ4 Wg/5oJS6q6PdbtSolyEX8pi5Fazc9NvKGSmlJTwQcisMub8Qq4KLUZe34hJL6cxjH9EAcJGxcPl1 Q4ub4rusaD0UT+4uNfWXWlnYkoR2K47hfpWbtH2ew8atP8Fr8iVzmTRZi2bvmCtXBy3Oray4bS4e 0ngpA2tlExOujdKSSUIoYPYywRY0OHmJQHdMwHmXUM/IrUJigpqfszp7TIoZPnqiBldY21tDR4AQ iOKGUlLFRKcpklMSmc5rAXOMAclQyMirGYX2ugeHcqr0zHv+snUW4wlmLX77Y/dnj4lJNW9J9V8A 5r/2jY39EDFAPfxf/cu2rYGgMHbU/FVsLGZi1NZW0NDQGsaOBCvUsn4DVxTd12ynYtWQwtuYHMOh DhIhZrvqf9Vnv3nBp3HwbA+7hapPqGBo0cBEa2OEVIsLp+FgVivDprpYO1bQ0fgrJTNG0z+CQIJ1 RQyaI9xULHyfJSsdAgIDikpi9yi0SUzjJU2BBTNuilPiopi7WEVLlygUiVElJSxKiU5KgXIKXJAE nRQNzNY1gSo3GWfNBY18zEA8oqTC1xJ9sAeKi9xcwguEjU+P4KJYSZe75JgGVggd+ZSUxYWn2Q50 nUu04/3KQkEwAB2UHXAIL8lo7oKTFreXOJUNzWDa3RZ+X1fFxW7r7WVjxcQFh5f126dSD9n3ZDv5 Og+8pKerNoA1K5761fWenpOK6mlwfmWiK2c7Qfz3Llc/689SyAWYrW0A/nfSd8uy5u222+x1tzy+ x5lznGSSjSrWc51r3WWEuc4ySeSSp4zBbfXW76LnAE+SGBKtYNHqXsb2J1+CKHprXtxuiXV1w1pD KmAce9293/Rasronv61Sf3G2P/6MfxVnq13p42Pi8F27Id8/0bPwBQfq03f1G63tXWGj4uP+xAJL 1QKYuUZSJSWrkppUZSlJTwsJ2GHj4hPCcDUIpfTMdx/YQP8AI/guUDnbyRyDK6nF16A3+p/BcsDD j80I7Fd1DYrw7esZDKBo0avd4BA+s4d01tdNRgt8fJbP1Wl+XcP5Ernfrfu/aNrXGYSoDQKlIyNn Vl0v6wVWgU5J2v4BK22Oa9u5pBB4IXngkOkcha3Tup3MhoeWkfiktp66FBxVAdTtbT6sC0d40Krn 6xUfnVPB+SSqdQqBWW76xVHRlTj8Sq9vWcqzSsNYPvKSnZseysbnuDQO5Wbl9ZYwFuMN7v3jwsy2 y647rXlx81BjQdCkql3vvy7AXE2PcYAGup7AL036odBHScAesP1i79JefDwYPgFjfUv6uhoHU8lk vf8AzLSPot/e+JXdVsA9o4HPmUCVwCSthJBjyAR3e0ek3+0Um/o27j9I8BOxvc8lBTJrYEIjRKZo Uz7RHcooYW2V1tLrHBjRy5xgfiossrsbvrcHjsWmVmfWHGuyKatmtbXzYPl7SVLpNAx6NrT3J8tU lOgXSJQXuUydCq9j4SUu0yUZpVZjkUPSUlJUZ791Heol6SmZKiXKBsCG60JKSFwQy9V7MgDuq12f VU0useGgckmAkpvmwIbrgO65jO+unScWWssNzx+bUN348LAzfr3mWy3EpFY7OeZP3BJT39mXWzUk LPyOt41eheCfAarzXK611TLM35D4/dado+4K503qzdKMnUHj+8JKeuf1t1tgrrAaD+e8w0Knk9Rt vfsqeQwcu4lAZVXfXNbg8HsUM411f82JA7FEKaWd01uXNjHbn+ZmVg34T2OLHNLCulysipm2mkRZ /hHkRHkEPKLWubU8i50bnSPozwJCSHmfsVp0GqZ+Haww4arq8Oiu0bAz2jVxmTHlohZOPUHFzNoE 6T7nQlanm20Ob7SDJWn0zFh24+2dJPYfnFEGPueXEz5lDz8gUV/Y6jD7R74/NZ4fNI9kju1c7L+1 ZFl40YdGDwY0bW/gFq/VWnbi2ZB5teY+DVz2Q727W8u0AXY9Mx/suFVT3a0T8TqUkFtylKaU0pIV KUlNKaUlPFcKQKWhSjuil9AoyNvRGN8WBYLWFxcewWix5HSKgP3AoU0huI6wjUoE8I8yyY4ccjfQ W6P1RYPVvs8GwuZ+tvu6pf5aLpvqi4N+0T3/AILnPrKBZ1C9w7lHqsOzyh+kVJri0hzdCEzxDyEg gh2en5vZ3B0cEuo4gYfXq1Y7XRZlbyw7gtnByWXV+hZqHcT2KSXJKkx+uqNmYzsewgjQ8KtwZCSm zMha/wBWeiO6tnB9g/VqSDZ/KPZn96y8DGuz8ivEoE2WGB5eJPwXq3Quk0dMw2UVjRgknu5x5J+K B0UA38agU1hrRBIgeQVymscn6LVCthJ8yjO1itvA5PiglQmx248dkVoUWiAiNaihmyANx7KPJlLy SmAipZ8RBQSA3RoA+Cm4oT3QElMXuhvxJVK60buUXKtDBqeAuO6x9ZdljqcOHOGhefoj+9JT05y2 N5KTc+v94Lzm3qGbe7dZc8+QMD8FFuRkji1/+cUKVb6Uc6vxQrOpUsEueB8SvPftOQdDa8/2ioku d9Il3xMpUq3trvrDhV6eq0nwGv5FQyPrLMilhd5nRcw32mQrTDubKNIt0bOo5ubU5tVno2do1/Ku S6i3Mda5uZY+xw/fJI+S3WlzHSNCiZWLV1OqDDbgND4pKePI7KBEK7mYduNaa7RBHB8VVIIRUwlJ It8E2o8klOhh9TuxoLiSB+cOR8R3W9i9aZcyXQ4eLf4rkg7xUmkg7mOLXeLTCCXoM7ddYbagSD4a /kVNvrMMjcCfiqdfUcuvnbYPP2n7wrLetvH0q3j+q6fypKdjp/qOadzT/W1AhTvtr2+k2HHvt1WG /rUj+ae7+u9VrupZdw2sIpaeRXz/AJxS1Vo6Gbn14v6NkPu/NYOG+bllS8k2Pdue8y5x5JUA0N17 lQufA2Dk8pUoltdJxjm9RaSJrq9x+XH4rsBoAAszoOB9kxQ54/SWe53l4BaZSQqe6SZKUlKSlMkk p4sGFIFRKSKnsKDu6XV/VCNc70sINHMKrhO3dMqHkEXNdFIamkWYjxZcZqMz4U6/1ToLsS63xcW/ guY6239ctB8Suu+qLiOm2D/hD+QLlOuNP22w+Lj+VPG7F0eUyG7bSoBHzBFqAgpkCjY9xqePBBap 6JKd6WdQxtrv5xo5WO+sscWu5CNg5LqnjXhdR0PodXU81mc9s01GY7OeOPuQ2Tu6f1J+rxw6PtuQ 39YvHB/MZ2b8T3XZ1tGkcDjzKFRUGNDByRr5BXKmNaN54bwm7p2Zfzbf5TvwCdjYCZoLjvd3RWhF S7WyVMmNAl9EeZTIoUFFxTuPZCcUlLOKBY7WPFTe6AsfrXVqel4VuZcdGCGju5x0ACCnG+t31gbi gYVLouvmSPzW+K44KjmZl2blPy7zussMny8APgrWPYLWA9xoUUJgJUwmaFMJKUFMBMApgJIWhTqc WmDwU0JklNmFNktghQpdvCM1qSWd2Pj9Qq9K8Q/81y57qPSL8JxDmy3sQuhARm2hzPSvaLKzpB5H wStTwxrKgWyupzugsuBswnCedhWDfiX4zi25hBCKmka/BMQe6NHgokRykpFqlDkT2+KTiPFBLDaI T8cJFw8ZUS5x0Gn5UlKe8N0Grlo9D6W7ItGXeJrYZaD+c7+4J+mdEsySLsgFlXIB5d/sXS1VspYG MAaGiAB2SQyAAEBMSnTFJS0pJJklK1S3JJpPikp45OnLUoRU9P0zXp1f+vdTzXaAIPSH7sJrfBLN cZCH6QXjSEvGnqPqfLun2j/hD+Rc11+vbnWeG4re+qOY2rEspd3fuH3LG+sRByy7xJKcPmKw7PJd SbFkqmtHqTQQCFngFA7qCgphMGlTaxxIAEk6ADxSU2+lYF/U82vEx/pOMud2a0cuK9c6T06rAxWU 1NhrAAB4lYf1O+r37NxRbe39ZuAdYf3R2b8l1tbZiBpw0JpNrholprJMdzqSiEh7trfotSI9Nvpj 6TuVJjYEJKZtCKxsCSosbJUnH80cBFCxMlImAlwoOKSlnFCc5O5yBbZAQUiybgxpJK8r+tnXHdWz nU0vnFxyQwDhzuHO/uXRfXf6w/Zaf2djO/T3j3kcsYf4lcACiELhwHKPhXFl20/Rcq0ao1fkkp2Q FIBBxbPUrE8jQq0AihYKQShPCSlKJUiooJZ1P2ulX2wRIWarmLZuG08hJSdJOmQUyaSFNwqvbsvY LB58oYUwipoZP1ewb5dS40uPY6hZt31ZzmyanNsHkV0XqEBDc89tEUPKv6L1Fpg0k/BRHRs53+Cc PjC6r1HDuVEud4oJcCn6t3Og3PawfGT9wWji9HxMYh231Hj8539yuxPOqkkpQACRKSbskpRTJSkk pYnwTJFNKSlyopHhRlJTzDgWkg9lGFd6rSKcl23glUpRU7vRf6OfipZbpch9EePQcPNNku/SJDdd fpdnoBgafvKr9YmuF7Sj9BdqP6yb6yFrrGR5oj5lp2eWzBuZqs8DstbJrmsrLaIcUpbqDINK6L6o dDf1DNbmWt/V8YgifznjgD4clZ3Rel29WzW4zJDB7rXj81v95XqvTMCnBx2U0MDGtEMaPyphNJAt tU1BoDB/a/uV6oCtvqu/shDoqkweBq4ohPqO/kt0AQSpgJO93JRmhRaEZgDRvPyCKlz7GwOTyoBI kkyUxMBFCnHshOKdxQ3uQUxsfAWH1/rFPSsKzJsMkCGN7uceGhaOXkNqYXOMACST5Lyr6y9bf1nP Ppk/Z6SW1Dx8X/NFTl5mTdm5FmVkO3WWHc4/wHwQQpFR1lJDKCUWrwQ28KTPpJKbmJb6du08O0Wo 3hYwPccrVxbPVqBPI0KSinSShJJCiolOVElJKlKt5Y8OCikkp02nc2Qkq2Lb+YT8FaSUu0aqTkm6 JnFJTElRKcqJSQsU0J08JJUmT9kySlJJJklKTJ0ySljCYp+ExSUxPBUVI8JQkpx+pPF8PWaRCtvm O8earujuip0OlW7GEeae5+6xV8CdYUnTvSG6ej0/1QrZkXW1ujRsiVU+sLDVnOZMgahF+p/q/bH7 P3dUL6ybvt7907o1SHzIOzjv9wIWe3HdZkCqtpc95hrRySVf1laf1V/Z/wC1T9oJ+0R+hBA2/wAr WfpIy2RF6j6s9Cr6Zihpj1He+1/ifD5LpKmEkEDU6NCBTs2Nj6Pf4q9R32/Tj2qNkXf7QKWc/nFS Y2NEOuJM890ZsIoSNaneZgDgJMn83lR+KSF0NzlN3CE5FTFzlXusDQiPlZfVTmDHs+yBpt2nZvJD Z84BQU8j9d/rAYPScV3ucJvcOzT+Z8+64mYKNl/aPtFv2qfX3n1d3O6dZQUVMj4po1SHGqfskpdu hTgTPkmHCkzkpIZB8DRW+n3PbdDvouVIRPkrdXAhJTsJFRr3bBu5hSMJKYlRIUikkphqlKk7aoGE lMmuLXAhaVTw9gIWWruFvg+CSm3MBRMlScmSQxKiVIpklLcp+OUh5JyklilCdNokpZJL4JFJSyZO l8ElMSmUjwolJS0ageYRfTQ2/TZPG4flV39Gkp//2Q0KZW5kc3RyZWFtDWVuZG9iag04NTYgMCBv Ymo8PC9JbnRlbnQvUmVsYXRpdmVDb2xvcmltZXRyaWMvU3VidHlwZS9JbWFnZS9MZW5ndGggMTk0 MDQvRmlsdGVyL0RDVERlY29kZS9OYW1lL1gvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2Uv RGV2aWNlQ01ZSy9XaWR0aCAzOTgvSGVpZ2h0IDI4NS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K/9j/ 7gAOQWRvYmUAZIAAAAAC/9sAhAAMCAgICAgMCAgMEAsLCxAUDg0NDhQYEhMTExIYFBIUFBQUEhQU Gx4eHhsUJCcnJyckMjU1NTI7Ozs7Ozs7Ozs7AQ0KCgwKDA4MDA4RDg4OERQPDw8PFBQQERIREBQU ExQVFRQTFBUVFRUVFRUaGhoaGhoeHh4eHiMjIyMnJycsLCz/wAAUCAEdAY4EASIAAhEBAxEBBCIA /8QBQgAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUG BwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLR QwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZm doaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgI7AQACEQMhMRIEQVFhcSITBTKB kRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aU pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH1+f3/9oADgQBAAIRAxEEAAA/AO7S lKE65FqPlSSSSZIJwlwipSSSSZOkkkpSSSSSSSSKVJJJJJJJ0lKSSSTJ0kkVKSSSTJ4SSQSpJJJK EkkklKSSSSSSSRClJJJJJJ0kVKSSSSSTJ0lKSSSSSSSSUpJJJJJJJJSkkkkkkkklKSSSSSSSSUpJ JJJJJJBSkkkkySdJJSkkkkkkydK1KSSSSTJ0kipSSSSSSSSSlJJJJJk6ZJSkkkkkkkklKSSSSSSS SUpJJJJJJJBSkkkkySSSCFJJJJkkk6SFJJJJcJk6SSVJJJJJJJIqUkkkkkknSpSkkkkydJJFSkkk kkkxc1olxUHXBomD8+fuSAtWikkkkRJU7M2lrtr3kEiduuk+MJes17NzHhw40M6pwxkqtSSUGJSi OVbLmjkgJb2eIWaXuDocRPeOPyItb93GqlHLWLsppSSSSu7m+KeR4oDATzoihiR5euqqUkkkppJg Cn+KBwlSkkkkkkxMKPqNTDCQ6KUkkkppJtzfFIOadJCFEbhSkkkk6SUpIKUkkkkkkkkpSSSSSSSS VKUkkkkkkkkpSSSSSSSSClJJJJJJJJKUkkkkkkkklSSSSSZOkkhSSSSSSSSKlJJJJJJJJKUkkkkm TpIKUkkkmSSSSUpJJJJJJJBSkkkkySSSCFJJJJJJJIqUkkkkE6ZOkpSSSSSSSg60NO3k/kRGqlJJ JKRIbyhvtgSTtHbuSq92Ua2udG4kw09z5AJV2WRu9MB2u8jU/enxhat1JJASYSUx6rjLfaPx+JKj YxwENduPdCOXjA7fU3H91nvP4Spts3aCsjvNh/761S+0aqq8VUpJSFbyJggeJ0UYhMGNAHqCfKP7 0xgjZs2g+OitVY99jZOjfH6I/vQn1FgJbBBkEjkqWOCMTHikbPT/AH0iO2qkkklUY0zAI55DiPyq 3UwHWde06obGGNR8pRWtLeQT8Fc9uPRfSkkklaYyB4fAz+VTDByY+Yj8QgscI1BB+CKHmQA5NOIJ pSSSSfb/AKgz+VMdBzHkdP8AYph37wlO4g6guHhOoTThtHCpJJJBcJGmvw/2Ku7n4lWXBusiT4jR V3l+4CCGjU6zz5JpwkdEGKkkkk4EDy+aBa8i6qD+eP4qwCDEEfkVXJc1r97pIY19hMgj2tKd7Hcf gohSQSU6GGy5lY1L3NbHxK5rF63l4pLK7CWBztrXagCTpqtbG+tLHQMiv+0w/wACuQa/QKYsIUc+ XjLotp6LP6CLX72t2O2t3RpJAEmFlX9GyqpLfcvRr8UWWOcRMklVLenNd2XoFHVsDIjZaGk9naFW wQRIMjxC84be4cFXMfquVjn9FY5vwOihlytbFVvm9lF1Rh7CIUF31/SGOkFsrKyfq9U7UNg+S7xJ cxjfWm9ul7W2Dx4P4LUx/rBgXQHk1H+VqPvCiOKcel+SreWSWtf0C5mtZ+RVC3ByavpMMeIWknQ6 7qbhuqe14/kmVNR+akCSRBGhEJJJJJIKUkkkkkkkkpSSSSSSSSSVJJJJJJJJIUkkklCSSSSlJJJJ JJQkkpSSSSSSSSSlJJJJJk6SClJJJJkkkklKSSSTQkkkghSSSSSSSSSlJJJJ0kkO18ewHaTyfAI1 alJJJKF9z2gspG5/c9ghVUvImwyTz4KbntY0QCGdz/tQi+7IgD9HWpceLqdlVe6kkk+iFaz3F+7X jeeGj+R/eiU30hraqzo0QA3VG9HHe0NcN4HjqiNrqYIrYAP5IUhl0iAAnyVuMQmM8lJJArrFZc72 NkcNbtMeaTMqnaSCRt1MjwUMm8NDmM0AEvcOYHYIeNvcWuthtQElo7eAPmiLGspfS1KJJ5JKUJAJ zHCt1dVqvY5jLNTrBG0gIVjg6Cwu2tGmkAkpm0Y3qG2hm1x0JCG9r2lok1kDx7dtVNjMcuQEEnh7 pBs+SnMc3lMnLiQAToEynuEQ1oPkSpVngGtzP6rpVcFz9Gw4g8q1RXYCJrJH8kq8IgBepJL4pKyw EDQk/HVSAnkAphXXpG5n4/lUgx/5r2v+Oh/FDTolSSSSUQJ1HwUtx26yoOLmavaQPEcJxdp7Xj4H RIBIUkkkou1kiDHZVnPBt42xqI11Vq1x2AOYHazubz+CpVuD7TscC1ukdwU4RshRCkkkohWA4lsy Y8YWR1i0V4ebYIEVbGngy4x/FaziQDIJjuFzX1jv29NcCdbrgPMhsnVSGC06KWj9XqRkdbwqjqPV DiP6nu/gs5dH9RMf1+ub4kU0vdPgTDf+/LmZThyhKUhE4onotp76T31SOw6HRT9MyUxYTyiBykHI QTzCily97FFIXUtKC/FB7KyWuCXujXVGFhU23OHdVwU4KilgI3CKc63Baeyp29MY4HSVuy3uITGt rhor9WdbUQ5ji0juCtPG+smZVAe4WDwdr+K54OUg9QzwA7hVPI5PQqXzLR9yysj6ulsmskLvnYwP ZV7MJp7LtKPrNjPEXMLD4t1H4wr9HU8HI/m7myeztD+K8/FpCm3IcO6glyg6WEavnNvS8uo/R3fB Vn021mHtIXolvTWu7KpkdIrdy38F6Oksr6uZ5zMAMsM2UnaT3LfzVqqpKJjIxPRLwaSvdawvsOe+ pohrgHt+aopJJJ5SSpJJJJMnTJKUkkknSSSlJSkkkkySSSCFJJJJJJJJKUkkkkkkkgpSSSSSZOki pSSSSiUkkkxCkkkkkkkkQpSSSSjbZ6bdNXHgKhVebLbiZ2MOwfyn/nfdwrGS5wB2n3v0Z5efyVWm ohk/QqZ9GeXHxUsIWRf2K6qTlsAeJ1TDzSJnVRyrHVfpfztAxvIHkOys4r2lsXNLXGJDvvCE+sti 14+gCQD4nhNS/c57ruIAI+8qxUhAyJAjfDX0TsGQ90N4CiRBSS7KxkZteMIcA09gSJ+4KtZk32t1 ljT4jb/vRBVS8iG8cSZUwCwna0QBMqE5B5otcNLuBKaI5SkpIGNgOyX67mMGri7kj4I12G+2z0qp a1vDCNAPGfFWse+WFzACSp13Xid5brxHZS454+E8QJJSKpclNKSSpWD7PXZbJc9gIA7Twg5Dgwgl jnGJdppPkU+fkNeTiVndZAc8j80eaO6nKvh1FjCB+aOfvT+VxmE76EXSYjVQSiVIMcGiwj2kwCe5 Cjp3VSsUPIJHp/Hx/BaeKSBoQR5qsyrJbZF9ItnuIP4BWq6KXGRW6k9wFf4JS2/Kl4BVqkkkrW50 aj/X5pEVHUtj8Em1QPZafg8IgFrRq0PHiNU4Y5dR+1dwlSSSSrva0j2n5EoVjARDgPjwrfoG1pIZ x20QLqX1iTuA7k8BP9sgJ4VJJJKleWVMeWOIIHB1CrYXqne5zWuLjMtjVWMw7aTBD3O7Hw+IQsJr BSHAFgJJEIwj6h4IpQTujtPzTDnVO6Z11T3WtrYSd9ZA5HC5P6zZEtxaJGjXWOA8Xnv9y6nNNnou 2WNeDA2mC7XT4rifrDaX9UsaRHogVQP5I1/FSkahbJbnReg/4run+qM/LI0llLT8Jcf4Lz4cr2D/ ABcYn2b6tVPI92RY+0/Ana38AqIenDkKUpKPCh2LMGDIVezGcDMaLZLRBCY1NI1COClKEHpw9Cio uA6lwQyxbr8Vjuyr2YE8Isp0MOCfchSHHczmFHb3K0LMJ4nRBdjkchElKVCU8pphE9FU1ZcNEtwP 0gjGvyQzXqp7k4chynlRnCOiKYFrCouoa7UIhrgJiCNAVufV/OOJaHfmkw4eRXbNIcA5uoIkFecY j9oXZfV/PGRR9mefdXq3zb/sWTzmKpEjoUbGnifrlhzlB7Rq1gXKr0D6w0C60z4QuHzsc49xEaFa ySSSq0lrpJJJJJJJKUkkkkkkkkhSSSSSSSSSlJJJJJJJJKUkkkkkkkkpSSSSSZOmQUpJJJRTpJJu yFJJJJIWRkMpZ7tUVUHW7t9h4Ljp5D/cnR3RakkkkSubD6z+ToB4BT5O49vog/lVGrKdc6xlH02h pdPHmpuedpDXiT9N4lx+DQrIBiB08U7KSUnVua1rncOmPkmA1/v0UrrPVtDG6hp+Up34z3H2u08f 4psMUaNbO/wcCD+KuCp44CZlJlUeg7KOqySdwM6x8uEyqtx7xpuEeKLtNbCXOB7k+ARtgH0j8gqe daz0vTYQQ76WvYcpgge2yKUkkkOVVwrLKrRs1puPE6ieCtBzbPULn/zXADdSZ7keSqYrDUz1nNgc 1tPPhJRmX2OdBMa8AaKWGb2rjGIIPcajy/gkSrRm4CIP0goJ3GT4+KZCbSKLnWColthlod7ST+8f FSZ9meY9N1Vg0BEif4J8kP3y68yeAdfkj4bbAybAHazI8FpctAGINaHXa2SAXLi4AEk7dB5BNql8 kkarHbU2a7XOcfHsr1bcgtBf7gO6rsdW76VfzGit1AADY4/AlXRQGjKFJJJKQDe7Y+CWxpPtMIw3 xqAUx2H6TYRpdSkkkkm1ujV33qP6QHUyPHsiCCPaUnOIaTEp1KUkkksrqmJj2tLg5oc86OBiCPgn ro2VhjgHEDUn+9Sy/TtsZXZWYHceJRQyqID9pHilGIslRCgSDISSSWV1CvDa0WWsdWa/eXAyIA81 53kNdkWvv7vcXa+Zld39bLraOmOrfYHOtcK2RB9p1K4zbDYQOsj4MM912Nc94YwS5xDQPEleudH6 tR0nGq6a4z6LQyRx7RC81+rdTLOr0vs+hTNrp1+gNPxhdI642XbnH3E6lUDU4dlAgrQ2g6KLqWuS ta+hU9ZxbSGteJPIV1mQx4lrgvNBfawbmu+kZVrG6zl47pa4kjx4VGEytOxvBCdS4dkbS+ibwU4h chjfWh+6LY7fitbH6/jWwN0E+KHJCcOKRaQmhLRTsFrSNUN+Oxx4UKsymwexwKMLG8qQepB6Enko GPZTVfgiNFWswHjhaoIKRAKMHJ5QNxUg4ygQVOC/GcDwhuqcFvupY4ahBuxay0mFdpMNC0+m5jsW 9lrTq0/h4LKrMNCPW+CszPC5S8SVheM6pVvtdK5XrGBvYSBqNQu1za91jjCxs3G3Ahei02svqbdW Za8SFNc/9W+oTOHYeda/j3C6BZs48EiFDV8/ILSQeQktDq2GaLjY0aE6rPSSSSTVKSSSSSSSQSpJ JJJJJJG1KSSSSSSSSQpJJJJJJJJSkkkkkkkkKUpJJJQSSSlMQpJJJNY7bW53gCqvptrrO/8Ac1n4 En8qLkEksqGu4yR5DVV81+ysh+m72nynxUuMWb7ICkkk4BJ0VLDx7g+/Ijab/ogfu8yjsr9SgtIh swEfFeCw2D6Lz7f6o0H5EQwGR2T5yMjulNfa11ddLdfTmT4koE6yneNrtp5HPxTLF2XYeRupcdrJ c4eEcrX+0XZFDbMdzWucJG/UIBDXWue8e0Avd/a0/IFPHIpogAckMCPCRAT6XSulpw5trNrgN5gN PCDAa6HzpoYTJEkmTqVE1Z1jS2x25x7NMN/vRK+nskOt92n0e0qtZdlB290lk/motd7n6scR/W7J sspOlUgnwXJbOnHmmk9ktCktDI9Ka6dpII+kOAhPqGNvdodo5QHXuLhRZDLeannUHxCL1Cmy6uGm GtIJgzPjzCl4feAIABBA03+xd8ykkgNJTgwVUZ6DmNN8749zogbvjC0sSuawabZ7RyqLbwP5+lpB MbmnYfuKu44xCwEOcwfyx/ELUwegCNbDyZI6KPOnCZKAkr1bbWfSaHDjwR2ms/SBb8dQqzNBNVpI 8D7h+KOy20CS0O+Gh+5WAT1/iygqSSSRmtb+Y77k53j+UEL1aj9NsHzUhB+g8/A6p4I6JUkkkpS0 /SEJjs/MI+9ImwDVod8FWsspIO9pYfFOtSkkkk4F5tJ9rglaa4/SMI8wo4zJ1pt3DjXtClkG9jPc A4J0dlFSSSS4z622sN1GLWSQN1hnnUwFhli0ut2et1e88CvbWP7I1/KqZA+5M7nuWCWpLufVyv06 srLJiA2lp83e4/8AUq42+CqeL+h6ZSyNbHOtPzO0f9SmY4/eVX2Ji1WNmiYslJDo/aDpqituEBZh thxPmpNuIPKrwokBHLFEsSU6geJkIjbXgy08LNZdwEVt3mgOraUN2MDwrJbrKjBCSnVo6jk0atcf vWpjfWjIrgWajhc4y6RCmHNKpOx3jhDLHDkLR+KiWtKSnucb6zYdhAs9hK1Ks/HuB9N4PzXmuoMg x2RKsm+sktcR20Kz4Tt5V11TT2QH1BgHmkTop9MbexxgEGFDJcBVA5OkLz+nqmWzaRY4GfFdF0vq tvUbbWuMtYC4fkCm0witcgAqbXKrlxiQtBDC6vdJjklZuRToTC231qnfTIK0MTIdTY2xpgtIIK7r CyRmYteQPzxqPMaFedsdC6HpObkVYcVPLdrjpyNfIrPzcucm2hCA8h1bBFrHCJlchbW6mx1buWr0 fKx90rieuUCrqBbHLQV1SSx6us3N/nmtePEe0/xVqvq+M/Rwc0/CfyKrLl8kd435apcxJTLPDRRL CFeSQasvGudtrsBd+7wfxRlGYkaHRSySRaQJI0SSSSSSQpJJJJJJJJSkkkkkkkklKSSSSSSSSUpJ JJQSASSTFqkkklUyHlmQ1+4AABsfFUr8Z+Q8HJMM3HcDoIHEeJKuZjNz2uPBeB9wch30uuaHOII2 8HxUkJUK8VBSmyw1/Q0Piojv8EwMGUagMsB2cD6McQo5D/TZtA3OdpHxWdi7+m2mpziWPd7J8+3y KsWUmxwf6kQJk8gFSEAWbo+KVHzSCsXvGTtsa3a5rIsjy7qvMKQrJpua9w3WaAj8FcqwS6loB+iI jzVRjqKB6pJJby6PBW8LPqub+heCHaiQR+VKMtOGdmG+ndQI6qBggpJAFxAHJ4Un1vrcWPEOboQo HHtrO1pDfGe6f03tbwHDuFasl/0iD4KGwDuUyUdTV0qmKSSSpZbYpLyJDfcW8aDwPigXvYSx9gIc 9oJAOoVrNuZXURyTpA1Oqo322EsDWjaxu1wInUKblYkZLrQBURqoamE8cwmAkwpNA789kRlrQ0kW cfmWCT96uYt9jmn9HuHiwyPuWWHVAGWkHxaNP81Kid81u2O5JBLStTHKj/L9rIDS0eSZSgnSR807 5jX4eK6PH2Fs/RPbt+CLZu2e0ifPRUcXKsawMeWuA/eHPzCO7Jocza8Pb4uZDgp+IHrTJYLBJJJS bfa0yQSD8HBWA9nPHmNFQqdvd+heJGvu9pVg2XOZDwAe5aZlGBtMTakkkkZ1o4rsk/ulV8nJ2NAI 3RqWxqoW0tawO3EEayANFT6pblMFTW3NdJgg/SI8U66TdKSSTt267p40hadD8c1guHplwniOVHIc Gt3MuEDUgnsBP8FS+221Vj1atzY5aZWV1bqeM7BvDN7bNuwTwS8x+RS3ogzWSAkwElb6XjuvzqRE gO3H4N1XPvvdkX2ZFhl1ry9x8yU0oLXQFIO1+CYwuvdX6dddQ1FTAwfIIJZ+RaF1W55+/VAdWYPm jSEkMOT7kVNPaeU5nlWDVAPwUPT7QpEKMJbk8pKRteQiBx/vTemltI07KBaolqmkYQUmbbCK20ga FVj20UhuiUItTbUUgJ2tB1KSm227TVSN2mqqAkQOFG2x7YAKA5uirZJhwb81fc33ALNyTN7vLRAq dCq73Se2v3LqvqnSH4+RkEcltbT95P5Vw9dp9N7z5D716N9VaPT6FjuPNxdb95gfkUAdUQFCTg6p pFqbj69FVtq0K0nMlAsrkFWGuW90cF+KQB3K50OW3h23Y2JVZW3e3QvaDEtJk69lD7YslMRq4mRR oTC8++tbPS6uRI1rYYHaR3XqFtMzovN+sV4+d9YMyrIs9MtJZWTxLA1rR+C03MhRDiCj4+bidQaf s9NlQa33te7cA7wDoB4QnsDXHy4TZYAdjaTF58OUoBCP1Lp1vTbGsse12/VhaZkDSfLXRVg7RCyC 5rw9pjuI8VtY3VqThNttM2gQ5vBJH96yMgA+n/r3UGHZYazq17ePMKtn5UGNn9ErTGgmxw1zS0ju hWVFthaOO3zUqiQHQpn30iwaOa7n4q6frDkiz+aZsHLdZj4rWws2rNr316EfSaeQuctDWtMCFLp2 U7EtFg+iRtd4aqvLlhKJ4RRCKUMQFs7tToPiq72OY7a5WKi57xJlSyW7yR+cOAupSXPZmQ/IJL3E js3t9yHidTycOxocS+o6OYTMDxEqH7tOtCCeyGokiVyCjmiuxpLTtcNR5rpUkN+TRXWLXvG1wlvm CgM6phvfs3lhPG4QCouGW9H7FNRJKDMd0+x0TGitpJJk1SySSSgnTJSo7WqSSSVTOO1jX+FjfxkJ iCaiP5P8E3U2vfQ5jOYn5giFN1bvTc09gApoi6+ilBJSrIDwTx3UVQytr2tefzXNd8N3P8UcB76W trElxJcT5aKteHAPsI9vpgj5Ok/gVexmusqa5n0YkeKkyjQdx6T/AC8klnXIJA/OBCgiVgPLWTBJ P+xDIIMHkIZqfV9MaHnwVZ1P2Z2+skVHVsfmE8x5Fae78x6g6hpa5vII4UYP2IpSm55sjdq4aT4g eKgklj5Btq/SQXN0cRpr4hV3X7cgPZkW7Rp6YDS0/MoGO5/qWVnRu2f80pq2eo50GROmilhx4zxx r09xe6dRqo8qYc0VlhYC4mQ+TI/GExA2gzrKY6Qrlt9dwNlbdjm6A6LPsqcTo4h0zzBRrgKnsqMu BaXOEcqL66nCWuEeBVjDMyuUtST5JBJ1Kym10ciVECQT4QkCQUFpyGktcGv8CdHBWseve4BzQZ5k IDK27gQZ+B5V/HD2wS0OHc8GVbjKiLXhI70S0bdzXdxyEI+SkSYUVYrxwxsNBZHzTua8HgOH3FSb c3xLfJS3bhOjvgngxPymvxXaFSSSSapmPa8NfuY7u1wkf5w1VuuiG7MeyBPI90eWqrVW1Ndtubof FWG249YnHudX/JI3BTYyANx+RXxUkkkh3evWIJqs176OKx7c2vIzS2C0N/OHGn+9a+ddkOr3sLXh gM7WkTI05lc7j6Gx97d248jTzRMvWB+apGlKRrIYHyNe3dRRLS07QyYiYJlaBuya276LGvBkaiCf kud69mufVVW+trH2PNji0RLWjaP4rTyPRIJosLHDUB+n4rl+tZFr801WO3+g0VAzI01P4lS2Toxk 2jXSfVHppybcjIBJbUwMHxfqfyLnmfSEt3DvC9T+oXSGM6CzJLYdl2OtI/kg7W/gFAXBTFgKobyp C0gparXLt6Re0FwbKp24TmENII+S9DfgtiBCqXdKrc2XNEq+HqQdoqTb4RG3g8pKeCOP4+CC6mDp rK6+/oDXCQIJWbd0O5klgmOFalPuQW2tPBUtwSU8+axqo+nrrqtG7AuZO9hBlANLh2iESdEpUJSB SU09knXun2QdArOyDEfFMWGFMFTaEIFSD0lNctOndCeYMAd1bLO4H3ITqNZTl0FzjwAsl7tzi7xJ K0L37aHHuVnEQgUsG1+oK626Oe4wPwC9bwsYYuHRi9qa2s+4LzroWF9r61i0R7WvaXfBvuK9NDp1 STpkkFMS1CexHKg4BSDl1XQcd+RjepVqxrWAz58rlACdBqToAvSPqZgBnQ2m36T3u08A3SPvQpdA WWq6mdF5D9ba3UddzK7NHjItMjTTd7fwXsm5rXBziGtGrnHQADUleNfXLOr6j9YsvKq/m3OAaf3g Ggbh5OiVUtqfiVuDWBsdmx58/cs63J+9dZ1Xp+7EeWHjXVcXnA18iIH+vKRFLpCnIl1rpe4uPiZJ Ra8ckoDTDgfBanTmi14bPzRbb4djyeWk/wDSP9yk527KZt7yqV292Zi0cO9KoR5v9/8A35Ge40Zx Y8ztcdU0gG77rWvXjE03OA+i4D8JQ2AjGfPkt9uOxnR8m+JBteQR4N9n/fVmej6uAXsbEtGkd1ey 2ltEOEOI54QAJolp0A1+aJkdQqyKCwakDRU6rg2ks5kzKb7cbNdRSiBbRxT+nadYlTLv1iXDUmfx SrxMiq1he0tBI1VjIx3uv38BoiPgFo47H20tdyYQDXNhY5X+kFrqIKrZBazJMeKjPLAEEd0cFU0r oba4DiUQWFrNzULIEXOHmnYCaz4JqL3lpocZ2aD4KGQ32z3HChj+7MI7GQrmZR6dW6VDk5eQJIGg K0xLK+sSLWjR+vzT47odHIPMqdpjEaPMFApd7wPFWei5/tONe76Imtzj28FsLlg0NDHeJgj4qw3q F/2V+E6TwGvnUN8FWy8oY5YEbSIJH1QY0WWRWA7c0QCdR5oKNvJLm/d8kiwAttHBmR5hbkpJkpWX bGhSSSQbwN0u42yAhG9zT6W0uL6y5nmRoR8QUTLBLA4GIME/HRAsBfTvGj6juEdtP7lLjlt4KBUn 2+3d5wUycfgUF1RNkuEsNZY8GZgjhXKLGMcGjQERBEQol3rtD26F7Plu7qrf6prAJLSw8SpNSa+q V2uLdQYcDII8QonXUpJ286rTsra/Xv4qIYQ2Tqq2Jnb2gP4415B8CjZLmur+kWDuhVHVOiySdzS0 plSw2tGRVdYT+ja4Ob4hy0KaqiHOnedNrgI0WW7NrY4MraSSY3O7q2LrsYEPgNcJBHHxUsZ5Ix4f 0ZfsUD9jPfDHMA0cQZ+H+9QUhWS0ukadlFV88EZe9p1DNg8tZKrvL+S2fHsVKx3qEvsJc49+UN/0 YB5Ks44cEQEgMg72FnYmT8kgB4x+RIeSdvKasgv2lwDp4On4rVxLX0tkiW+eoWdXWHOgnTxV2nT6 B+XCsAdRouC7mnbIGniNUNSJUVcNlL2w5sE91GyquBse3yI0Qwddf9fmn2tdH8SkL60fwKQpJJJK q3JoMOIsr19jx/FEfkYL9H1voJ03M9wn4aITv0WoLgfvCa217vdsY4cHZ7fyKSMzVH/nC/xXcRUk kkq2Ve2t7mY2QSe8Esd9yHi2vxqwbWC1h1LXef8AKEoOU2pwLhO4nZBbqJ51CmBbW0OpduA/dMj/ ADSn4r4r107a/gglkGO2h5B2ngxok+C87dB5KVTnA86AbonwUNCfcquZZjWEaelqXGDIgarjrbDZ Y55/OJP3ro+r5LRjXFzR6hAYHcau50+AXNEqeGpJ/ZSE+NXe50VN3F0MaPEvO0flXvHTsJuDgY+I xu0U1NYQPEDVeSfUnprs36wYLA6a2PORY3kbatR95Xs4CUpSmSUlKRlshI1yIKLtS2p5Ug5QSQpC A0NPIVd+CwnQcK9tS2orbIRW3FVU4cQkQpxb+mNcfozP8Vl5fRGuGjQD4rrCwIdmMx+rhKvNtBUw 8KgLCERtyGqngMnpFlcwO8qi/DsDiIK9Dt6bXZMiFn39C9xIHwVvekH8qqbdE7bdChanixjuBE6x 2StxiA0Rq7VdZX0UbzvHKFmdEBczaD4R8AiZLpaG+JQCFJztzvgmUc5epTT+qONGbdkn/B1wPi7R dYyzsVm9KxRi4hjmx0k+Q0CuSoQkApwlCIlaWz6gM/JQfaB35VcvICEbZETwj4DQMplhEtqmx39k af8ASherdCxfsnSMSg8isOd8Xe4/lXnnQcJuTsq/PysllPH+CZ+ks/gvUmgNAa3QDQBOgLJPZkgK DT+sWSWdJyQHbXXNFNcHUmxwBH+bK8fzbvtGXdcNA95IHgJ0XefXPPcyxlW6GUUvvIBj9JYTTX+G 5eeoGcAcV4PguA65W5t+xsHcYAXfZ5AxnSuK2DM6/TSNW+o2R4Bp1/IlNMtgpanR3MaXvdI2NJlZ avVH0en2PiC87QR3kINWOL/rdXREtqsrYR/xTGNI/wCiq/WmOb1LOeCdrLXjTzOi0/q4PtH1otyO fddZP9Yu/vTWY32yxx0/Ws5rT8PUP/kU07fVFX9rsZOR6X1YY3Xdbz5F7nOn7ih9KfWW4uMQ0mwB 2v8AJLiePIKp1K2OmU0jj2/9EIGPa6rILpg04zgPiWH/AMksfMxLsK+ml7S11lW/4gypU0v/AGbZ mn6Lbm1fMiV0P1nxm3dbxmtEBmK9xA8iQFTdQWfVPGYRrkZhePh7/wC5KqJHZRi6uNdXl4OVkvI/ RXN2NjgHTlDymA9QZjsP+C3n5rPxr/R6NlMHNl1IB+Ae4/kR7Mj/ACnkWj/BUbZ+AaPyrMxepWUN axgk9wnvyvWe14P0oj5q503of2r9pOdp9jr21kae8t3Efgs/pmMcnKwKSJF1jRr4Az/BLoFtFlld HNltlu4MaDAPidP70GnBfV6jLW617g4fBWMvPc3D6eAZNznXXBxkGH7G6dtBqrXULWtv6psgGsad tXQP4o+HcPtQJPcrYzra34ukHRc5ml2PnZGwmGWWNB+DoU/WyKXim6YezcJ80u6rrRyszHczGBjQ AH71Qrne2PFdRiY9WZh0UPEve2vTyA3H8AqbsHFvodl48A127HAHtKuuvG1tc6h2iI4xazwIOvwl UW+oaBkfmut9OfHRWX2guYJ1aD+KaYgkX0A/NTlMpcSXgS2JKi0TW/XUEaLSsoY251A1cyj1Pgef yLPbW4B5gwSF1EpSokppXLW1mskkknsbvY5p/OEIbB9F4/OEOH8r/epyo6SWHl2rfipMRs13SFJJ JKs0mlzqm+4NMt/qn/YQiwy9oI54B8fIqLXe6XDuWfAjVv5Ub0WvPqsO0nR47EqUghK519yZJJUr sZ1ZNlQ1idvjCK93rY7HkxEgjzVi3expnluoPiAqYBsbdTWACNW69x5fAqSIEx6u4TS4M6HhNwUk 8RBP3eSE2kA7jrCmfUc70mmW1EEgn94I+DRkNY6y1mp0DSgZe9ua4NMB7Q6z+yIaPvRAPGQP95VK lKIEnvwk6J9vCmNppO7kEBvz1KieYc2Pw/FDsYDMsJHiNCitO3Tt4dvuKT3PYJZqPD/YVZhe56Lm Cdpg8/eopwJ50Q8eqCDuLiP3hz8wr9dbCNZafJCxXNe7WGnwdotX06tg31lgj6TfcPwViI446H7d fxXgWu9wcdGhoPYKKREJKkanjVkO/L+KjZYGtj09Y4Pf71adTW4TW4Hy7oLnOrlgMk6wdQkeKI7j wqSqpSSSSg1weGwPMgHw+KjaC9pja5rgQYO1wTudUSfVr+bdPwVS30wyx1ZcPzWtdoTOh1CAIGn5 GvwKlJAwQfBJO3kHw18VUHusbJcQ0T7jDtdFK4AN3N/6QI/EJ2D6T5kH2yfcNPxQb3P2xU4Akx7T 4/ySpIEAa1r30/ELSkOjXaAFxjQaaaqLOYP4apO7A/Hw5RKQ0OmwS0amR4eYWD129zhVUe82Ec86 D8iyVa6nd6+ZY6ZDTsHwboqquYxUR/vqfQ/8VnTWepm9Tj6AbjVmI1+nZ/BeiQsH6kdO/Z31cxGO G197ftFgP71nu/JC3kySdMnJUknSShJJJG1LJRonhJJJJOkpjCaFNNATJJJJKY7UxYiJQnlSBUFJ upTZbIQGlpMwDCDbSTI2yTMHwVyAh2kNYT9yKEkklVuygOeKxWBW3gJ9sp/EqTeEpSlMna3e9rP3 iB96fFcCicw9kF9MgjxV9rQULKc3Gxrclw0pY6w/2QSu1+qOIDn4jHD+iYrsg/18gyP+gQu4XI/V CxlIy7yP5x7WNgdmDiB8V0lebWdHOE91LiI4fNmiLD5T9bss235b2u9tuQKANPo4w2/9VK5haXW7 S99LXGXbDY7v7rCXEz5rNVTr2WMelrJALtdfALl+iPDs3K6g7/tPTY8E+O0gKz9bOoNdluqYZ9No aPCeVl4lhx+h5lpMG91dLfPc7e78GISNy/l0Revku0bjAV/KY5lGPi6y47iPio9LxTfc0kDbMGVo XU/aOsNrYNwoYXHTiB/eVqfUwCu3OzHcVVD+Lj/1Ku9Kxy49M3jVz33n+ywu/wCqeqHQ3el9Weo5 DTtdc/0mn4gNj/prb6Vtdn1VjUY+LPzsfH5GJDXhH8t0x2afVB7aKh9LU/eqz3S/IdxADBr5gfkC u9UZt6nVVyK2tcfl7j+AWaQTUbD+e+PuE/xVXrEO6nmWn/AYbGg/1i938EK7GJweh4J0JabCO87B /wCTUepWb2dVuGrrb247fg0Mr/KSr2TB6/RWfoYeMHfNxM/hWluZH+W6eyYf0SmqdLLnEj4BrQfx KnbaXvzbf3yGD4F3/mKixv6TFYeGt9R33ud+QIZ0wy7vbb+DR/5kl0tra+ndVyY/nLsg/Jjdg/Is ToeGB1PpLe7KXWu/zf8AatppNX1Re/8AOtpe7XubnH/ySFhVtq61e5o3fZcOOY1J/wDMUT+iikl5 32Ytc/RrY34biXf9+VrMyN/7TsExbe1o+EuP/fVU2g57Wjhrmj5NA/uUST9jjvZdP3D/AMyXP24P 2ul1wAJycwVgf17X/wAGq99asBn7bwqaRtacZ0geFcq302gGjo9YGtl5vd/1utz/AMr0XrIFnXLL HcYvTrHT5vJA/IgNifJRj+Lp4uS+jN3B5aMfELuO/ox/35N028VdA6gTq71qds+J3T+AVR9m27Of z7PTHzcwfkCfGIHTRXOt2XWNviGNP/kli3Usp+qmC8j33ZRfPx3D8gWQLz9odrpvA/guh68fR6D0 XHIAJDXkeQr/APMlx4sO8u8XbvxlNO9eAWH5gG8S63rOX2bVjubERo1jQrFnTQ3ApcB7nVOsPyl3 5FVwGCzN6pZM+x7W+ZfY1oXdv6dU+itu0/o6DVEdy0tXopTFKeyiuVLVfKEkkk8qFgkAj80ynJTE hGJo2pSSSSg1wLbCT7hBcPgdCFFmW6q3baABYYDh9E/7UzxB3DkfiO6XpNLNrhvrf2PYqzGQkLK7 dSfbIkaxyEyQJBkcq697LKyBqSDos9r62Wzua20iDJEqTA+oiuxxc06MsP8A1LvNV8rEbY4OHtcR E/wUkOx2KVJ4cWzBgJOh2o0PcKVdrmDby2ZgrXbltcwC0hpHJ8fNZeQ8PtcZiTofLwRmVv2e92gb z4lV4MwIjuCnwriJu0sE4TGJ0SSEkAGLATwk4S4em4tPdv8A5i5OWiuDtIB7j+5Iy+IIcB2P+1Td Er/gnHBkSm5S4R6mtIh/b5flVlgLNaLC0+HH+xBpkCPw/wBhRBHAMeX+9OBrXbx2/FQWSSSR3XXf 4ZjX/wAqNp+8aITrKiCdWO89R94TtJbqSI8Dp/sTWPqcACwAnv8A7QpQbFk/42v4hfem6kkklEuc WHZBEakHhVb9rWNbt2u117uJ45Vh1QIJB+CqXevZaGOJLRrtADhp38UCb6f90P4oUnCZSBAadNTw fBQLW1thwg/5pWdnOZUyy8Eg1tLhu8ToNQtJ5cJ2EGfzQQf+i5YXXbizGbUYDrnSY09rfJOibIAP 2H9hQtJJn/atHo+I/qGdjdPbqMq1tZj92Zd+Czguz/xa4AyetvzSJZhVGCdffZ7Rr8JWA4SSe55U YREyuCdKfVK9tdbamiGsAa0eAGgRA8FVwnLtUOEkSE20JwyKbG5PIKrhycPhQTKexLYjxjulPKdB 9WE4tCgkpFpTQU6weqkqSgHtUg8eKZJJJJS8JapbglKSJWNSUNGYIamZpVHz0QVKtlugBqsyqOS/ dYR4aJ0kklWBQi7KbTqoSpByZGxKzZkMaOxlCV7pTWte6+zRrOfuRlKokppK0rI+tua3D6DkOPNo FQgx9Ln8i1QVx3+MTItubidLo1su94GgEl20T9xWxh5gx6g0GJdPHcndyFeZ1hzdeQDPY6jzXPMv xcnd6O9j28buCEzLXuIZx8NeyMctaEEV3XiVPB52LbbkOfE7WAdxo0bZg+apnDfMcHznuuxz+g9Z 6EzHd1IUX0ZBAIpPuY6JHhr5hBysCmmt1/0hIMO9p1J8BHxRMvIfkZFj3EkucTr5qGRlfqlWKDw9 1rvu2D+KmagyouPJ0HxKzbXEvI8NAhDJxElFoOnYdeNi1Pe3WJJBhwPwV/o/SnWZeTlOB2v2UtJ7 n+cd/BZ1eW7IymVDRjfc7yDQu96VitrwqnPbtLmm12mskaH7gF0VGaKuhY+GNDbf6z/g0SPxhb3Q OoUs/aHULTAbsqb8K2Fy4p1rjUweYa0D8UjmW14zqGuID3EkeM6KSMvV5LhOnzjqlT39a6g5mopa amfP2afisnJofVVi0x7rGmwDvL3bR+DQuzo6bU7OzLHSRWyy+xzhHOjfyouN0KnN6vXfY3dXjU1k AD9wBwXR4WR6/wCz6XGXZGV69k+AcbCrefmj7b1fJBnZWaGfFrQzT5vXNYOY6vOotB0xxuj4KQzX Pca7CYuua6yPN28og/n+S7jeQspDMnNcB7MWr0vn7agg10ue7Dxv3z6h/tH+5q6LqHSzR0nKtc39 JnZLWtPwO7+Kr/sxzHnMY2G041prnj2j026/GV23VduN0rAwJj1LKK48RWN7v+pWcLycbruaNJDM dh842/8AflS6116vN6nQKj+ixhY4fE+0IFGWz9hBj59TKy95PixvuP5AnSOvkE8QcCr3233RIax7 v872j/qkaur+g193F1pHOm7+5iPi9PvHR8nILCDdZVTXpzy935AjZuN9n6jZUznCxmsP9ct2/leu j6c1v7SwqG8Y2JY/4F7mMH4NVTqlzLL+tWt7V04YPi530v8AqkT6v5DH52fmWO9mPVTSD8A5zvxW RjZJzWVbtf2h1H1XN8WsMj8iV+n6/lom3NknFutPNtrRPwDnH8qLU0sZh7dXFz7oP8kgD/qFHJr9 Hp+IO9xstPwkMb/1KvX0fZsm5gGuHhNBn994aD+NpUvrnY2vLxcRugxcUkjzOgH4LkPJdD9asn7T 1fOeOK9tDe/0Yn8Vz8apgleQ+YH2MRPr+rY+rdHrVPt5fkZVVJ07TvcvRRGxz++mmnErifqzV6bO mVmf0lluQ4fIsH5F2ReBW0AyDJLp0A5XoxUSU5KiSuWaz44kkkmJUZ8E5USgShSSSSRKlUAzzY7R w8EMlJlmx2vB0KkxT4TR2XA0pJJJHfUeAN7DyPEeXmFAsY47XxIEz+83x+I7qJyjS8NfBqfwfBFe xlrQ+t3GunIPiFajfRcFJJATwkDCHeWub6bYaWxIJiQq4E8pWSLSBr4wk1zXaaO8uCpeFKkkuySj qOHEeIPCKxu780HxhQ8gT8HBTaNdBM+CcJ0q1JJJI7WVwA4Fvn2Uy1zRLXbgVBr4HJHk7X8VOQdY +YT4yB8/5fy2SpJJJKdrPc0iTwOEP9HuBbx/r4KRc5p9roHj3/BDc6WncGmOT3+8JE66dP5bhKkk klO33Oc8ANbyNuoVNoMbwS4jmDI/DVFcQGAscZPaZ0+SEbCDDwBHDv8AaNU/ivX+X4KJUnPhCZPz wgXOFjSJOsN7OE/lC5vrlwszjW0y2kBgny5XS2XFm6972uZS0vOod+MArjLLDbY6x3LyXH5qXB6p E70PNAZ16Onw18OF6t/i56ccT6v/AGt4izNsdb/ZHtb+QryzHx7Mi6vFraTZe9tbPi4wvdsHErwc KjCqENx621j+yIUUkklYSnCSdJJJJJFKwSJT8app7pJJJIIUlOqQOqSSSSSNqXBS3eCaUkxAUS3w U0kYzIUzDyERtmirqQOigG6oiYJ03LMmh2QUxsgFyoudJJRrXQyJ0VdJJJJRoV4J0w8k8pLT6ZWx +ETa1xY633BujnMHIaqGPT69ra+x5+C6Ftba621tG0NEABMyZBEcPWwVwLIFcH9ecl2P9aqhTY3f j4rNu7VrLDMF33rrOudV/Y/Tbc1sGxsNqDuC88fdyvIbsm7KyLMq95ssucXPe4ySSqWdjdMaWnpZ yCT9MXho2jwG1Pi0a7yPKEfaZPdFaA0Bvio55jPoB5JJt6rE611B8s6r6BoYCR6Xuc+wj6Uk+Giz OrdQ3N9BjpEl0jRZxeIaBppx8EB7nOLneCr5WjY49NpefjwPxWMxm54HeVs5ZBx7X/vODR8Gqjg0 iyzcRoNfuSxZOEHxU3+ktNmQ1p1+0WMoH9UkF/8A0QvTczMbj4dr5AYG7G6fLxXmnRgW9SxK2jVg Nh/rO0H4LpPrX1B2Pjsxa3ndEEeMjklTbSXZFVfIY0uPxiVQdLnx4FbuCwPstuPGoCyrafTvsnhs o4825PXZQaZ6g2rpGfkEkPyrG1Mk/mh20/lJXZYtbKMA5IhpsrGoEEyO51Xl/VrXV0Y2GD9EB7vj z/FdphdWOV0jDx2GHOLWu+KjjS60gd9D8FIuc1gv4JeY+SJj1ObQ+1wiRtHzRM7H9PCo7ck/NPGX 1gKTfWBtdXTqjH0QHMcBMvJG1vzQGY1V2UelMG4Mxa2vj+W7UfgqfXOo1ZPU6Mal0tqIss+NfaPk hfVfqX2j6xZZed28NDJ/kaKky0+53ciFZN7241bZ0bo35qqGkBvmVcbTvuoqAiTud/r8lJLKBZtN u/ldJrP2XEaNrGP9V/8At+5YLOmVZXWsskbQ7dZZPgwafiV1F2RXdfkOb9GpkCPFcu3PGPgdUynP 3H0zRUfLiBHaXKbeq5GNiX4zDHr2bnnuYEI3Ts70sjDEw3HDnmPE8rJuk3FvmUbGa59oA0nRScdA HsLVdKr+rVfUuo4Tv+09GPX7APA7tT25VHrHTbPQ6pmwd2Vksqr/AKoM/wBy7rpTam9Jbk8FzGsa eDDRAWN199WP0+CA6CbRpA0Mc8ckK3cXXtfdZ9K602P+cu/iqUa/NaMbmA+MkfAlV/Rk7uwKpwzV xSPmttwqbm42ZsrO4Y+O2msjx9rCf+iV0JtbsAmRsjzGi47f6d8NOrQ0O/rNAJ/ErU/aLmMNIJLr GyfKNV25UTKkVErCYHiEkklEqMqRUSJSpSkkkk2ii5OeVEpKUkkkmDgD7hLTyCjbWCs1tdtYfPgq uVB0xEqXDn4NJbLoypSSSQUGnt/H8hRBro4gnwdofvQhoVIa8fd/sVzjEhpquXKSeZCZGaexkfHV FAJ8D+BQGGOPw4RmGR/FMKlkkkkVvxI+KmPDk+Sg3XX8iW4NG5xjzToy7pCkkklGx0cOHwchueQ2 Sz5gyI+B/vTvsl0mHRrKCXBg3CW+fZPEh3Vakkk4EpnOLyJJc0cA8hMXOdo0B8/mu1P8CoE/nkxu PIUbWue2DWLQdNzHRqdBoncd+KLVx5FOPNLyH3KdcB07thGuo5hZ3W7vRwCws9N+Q+OfzW8rnFp9 fyBbmChkhlDQ2D+8fpLMV7lxwwHc6rg9N/i+6aM76xV3H31YLDcZH559rPxK9ZXH/wCLXpn2Xo1n UbAPUz7CQf8Ag2e0fjK68JJJJKVLIapu6cFLlJJJJJWqilpwklCSSSSSlfJKE8JfxSSSSSUsAZTF SGiUSkkkkkpaAlGqeNExgAlOE6QSUROqENzpdHghSk90uUNySSScAkgDk6IWpJKUoZcmfaypjrbD DWNLnHyGq0OkVe51p+A+S1Cfaq2MwU0Bo5UzbIVSU+KRPdTxn+MTqG51HTmH6A3vHaX8fcPyriQ0 7gOdVpdXy39S6ldlWfnuJA8PBVRRtJjWO6QBBngeCkbIrLvkFBzuA1MDutYzs33uTTLoFWu4tLdu pI0ngKDad1za58z8AisYACXnj8qlBrxrL/zrD6TPnyfuQuon06GU9+/x5KjSPQxi7gkfih5TzflB vYIlvufXSO51CJlQNeQS6H1XqGT1N+Sfot4/IPwTdSuPUurED3NDoH9Uf7ArvSKxgdGtyIhzxp4y 7QfhKz8UbKcjNdGgIafM9lfw2+liieTqVmZAFuQWD850H4DladtgZUGjsIWbSDZcX+BSvaIUHJ6j Z6+c8jgGB8l0XTLXYfT/ALSdTSwuaP5Tva1c5RUbb9x1JMroc5zMXArx41eNx7doCsWtBdXjs4nV WOpVg44Z4RCFjfpMo2chmil1C0bCPFES3Pj+SnOx7HbMjOtgOIhvz1VXoeQ+nqDbhqSTPnKLm/q/ T66eHWncR5KPRccvyWnw1WbTT6lwBEtZytDArFmS+6NGAx+RVqf0dLnn6R/BX8BvpY8nl/PyR4ia B81EvTZ3UnY3TX7XRdkk6z2XPdVuNOBViTBfDn+f5yu55+0ZtdDP5psAecLH6vb6+aQPos0Cx8in blWk8DVTxKy1jrSDu/NI7yjZQ9S0tby4wjbA2GN1DfcQnHKeEi/BVvbdL6tv6HhYzPpudtIHgCq3 1jz2ZGRTg1PDqmfzjSONmpdM+AWX0iw41Dbnk7amlw+PZUjfZZvvsMOeS1p55Ov4JNbADeO33J9g gN8VIDa0H8igXe8KK6ihjY/e91o1kl8+RP8AtTes8uNk8GJUC4veRBjvP4KYZ+jPh4911hUSFMqJ WUwuIkkkoFRJUio8IA6qUkkkoElRJ7qZQ3eCRSpJJJQc9Ce9TcYCC6UCVaKSASThIuTtfrqoJwlD LKHyn6JulJ0kkdrgf9dUZjv9f939yqByI20iJ1Csw5qJ+bT8kiXdZMnSV1pBHj/r5JnugaHj5oDc lh5MFNbcOxlTicZDQgptZJKE4Ci50aj8FB7w4Bkz46zIQ32e4E/6/wAVFh3uLna+ep18+CjdIUna I1Umt0TuG0R+CKX7Qdx2+cSEGx9bA7Ic1pbS0vL6nR5ahTL4+iTP8k6/isrrN4biisQXXuknbtdt b4x4p2KJnMDuoMAJOmqs4uNdlXVYdJPqZFjamtcO7jzKABJ148wuv/xfdM+09Zdm2A+ngM9usj1b NBz4CVi2WOtsdY8y55LiT4lRSSWoCAKXvpGDi1YOJThUgBlDG1tA8GiFYlCDlIFMknSTrUkTyoAp 0ySSSKmUpwohOCkkkkkpeNUoSmUhokkkkilUJ4SJSSThMpAaJmSVRUVQg5D9jPiiz2VHLuDrNvZq SdKE8KAyQwc6FHd5obnydFHcUyPhV77Q48NQFapd6dekieXdpUeWdRoblSYOkrF+t3UDi9O+zMMW ZGh/qj+8rXbAEkwAJJXKdWrs6jnutMO2j2VAjdtHHtmVfc+dAke6rttnWVMPVXiQ8vXVtEu+B8R5 p2cDnhaFmG5kt2x4ygvo101PhCIx8AucdO3wCYP9Ol1rvpWa/Lsq7rPVsDJ9o+l8FHLu3kMb8AjE 2VNe2nc9tVTZJgGNdSp/Z/tWbXhV6sp9pI/e/PK0asN2HiHKLf0jvbUD4nv8lZ+r+AKd2VeJaPcS e8GfxT4sutNh1VjFBsvdceG6BAbtqoP3AK1jxXSB35KJOo+1K3XA3HxKsFhggBzh4l3APwasnqbh jYNWE0+5/vf81o3G3P6lLvEve4cADU/gsbqDzkZj3/mzDfgEs63YzzQaYppL+8T80PJebbgwagal Tf73Mqb31KHFuVM+iYpyMloA0mfuVvOcc3PFQHtkNH9UK10ipmFgW5T/AGuf7WfAqtQDRXdmPghg LWfEq3hj06d55dqq+VYLLA3kKyYayOwCpsMvLz34RvYKcvqzhdmemz6NftCvdLpdTS63RjjoCVmg Gy3d+c48rYtGzHbSwfR5OvMKdgnZU384jRaNjhVSGj80Qs/GHqZJf2r0HxRM20hm0fnaBHi3KkOM SPWynz+jBg9pPgsStrr8jcdS90/etvqJ+z9Nrp4ff73DyKrdIxg+7e7QMG4/JCq/SWF57cIzTILu ATA07BBq9rQ0cn+KtS1oDfDhLoptZRGPjsobqTq4HwAVGwbXNYdXNG52se46q3lH1HueY2ggQRwB rys+H2Fz/EyUN7j/AACA+5zciuhsFzwS/wAgBI/IiPsbvl2jWgud8As31rPX+1fnTMeXG37tE6FH ikegIHnSktLAT+JWvi9JZb0DN6zeS1tFldeMP3iXtbYf+mB8lQxcW60NqpE2XvFdfxP+sld6cXp/ 7Mb0CR9n9I1T33fS9X47/cvQlEqRTRKyWEPkCSSSGQExCIVAhJSkkkkNwQnIrphCIKBVSkkkkJ2v CE7QorhCG4JpTSk6ZOENJOQmhNSukkknlIuTJilSFkoTpJnOQ3OUnITk6KCoBTaFEIjU28gydVJt 47nVCcUJxKsQySGl2gSLNo7d0nVnkcJ2hWKwrjnyyJGumuvz1B4WBn5H2nIc9v0G+ysfyQrtj3lp ZJhwg/BUbKAPon71c5fNGJs6FkjINeqs75gmOw5JPAEeJXqf1Y6b+x+lVY7x+ns/S5B/4R/b5DRc DhhrLWWtaC6s7mzqAfGF1vT/AKw36NyGB/aWmCq6SkWEKJV+ExL5SCv3era5Ea9ZuN1TFujUsPg4 f3LQrLbBLHB3wKZJJJSAqShykCoAEJ9Ukkkk61MwU8qASlMknSRtSQFKVAFPKZJOkkCplPZSB01Q 5TykBJU4TMHdTUGadmuylXWCutzz24WO55JJPJVjqWRLhSDEalZ7j5wO5TJAFxgCSptYTzoEVrQO Aqs84jpHU/gtlMDbVLuTW5FGKz1ch4Y0dz3+AWdldUZTLcf3v/eP0R/esPJyLL3l9zy93n/BRroA O5+sdkX02wQ0uaD2B0+4pBOAq0sk5GzIsZke7odT+sdl9LsfDYamuP8AOuPugeA7LKHUsne117Kr y3UOe0Bw+D2bShuIiOyGXDuhml7foEEeHCk1lrtHO2j7yp6pGQhxy8FccnUb1fDySTmMfW88uHvH 8CgW53TqIfRU6+wD872snx8VR9h0SAaRBQLGGgggyD+VKn3P3ET4TwiuAe2HcKAYGiJJHgnxyCtd 10cmmu7vYGVV1xjq7KxVbSBoDILT3E8JdTLaMYY1btvO4t5+AWPi3WYdzb8c7Xt08iDyCrVvULbz v2Ma8/nCZHwkqNlodaI+i38qP9ohkoboc2D8vJAbIO1yI9eu1dF0ZcXg38XpltXTXWETddoY1LWD sfMrHHSXPyNpEAak+SNivtx723VucCDLhP0vEFb+SKbavtGPBDtQByD5q3WNo3kw46knwT49m+11 p76N+Cr2O3tgaToSoV2uYY8EeGx6TZHRNvNZR9V3oMaSxpDWtbpLj2T9Wxji41WA3VzButP8o9lq dPFWHe228OuDHFzGAAan84khXc7plOYz7VUSWu5BEEHwK0brg4bByUJzgyvd3AhBY8k7j46JrLw+ 0A6tb+JSiCbPZLxuHiOa71XjRqu00vyMkUz7S7cY1AA1JI+SvZOM1jfSbpoZVqjotuH0o3BpF2SN J5azx/tK9igVU688uQrHi63T6LPylDfkHZDTqU9Y2sjue/mUL6KeY6pY7LzXOb9AexnwCtY1JwsK XiLLzx/Ib/erOP0qcgG1vsbq7yAUMuz1chzwDsZADBpDQj1c7j24T2v8DqFD1GtESnrrda7c8Q37 iUJ5BEalaZAaloZU7TW3vqY7DwUMev8AeHtJ47EfJHND7Xk7dOQEHKyq8VhqocHWnRxGoCNRhNvr i4kNcZIGhdHElX24WGMd1IqbtMT48+PKFX9ysgnYVSlnnKYJOgOg6LDI3bC/rVuDlbsMML62FjHk SGbvpbR4rOPV+puym5ZyXm5v0XToJ/k8IL/vQu62UoTxom0TVLJJJKJBPkokInwUSCkpSSSSC5qg Wo5aoFqQCgpJJJVnNKGW/crTmIZYgYpUkkkq23ulsRyxNsTaUulKZJV4TEFWPTTGtLhKl5TqKSqu ahOarbq0N1ZS2QzBU2lCBThypuahParjq0F7E+MlrYa5HreqYeiMshU7AYVV4V+xhVaxhU8JKDqY 7gHStbFsGi5+m0LSxsgCNVTeEIhWXsQnMViE6XgvT4lg0WrTbB00PaFzGNlgQVp0ZsAQQhEBRhEL ExarePmK6/aut6WnJtEDcY89VbryA4e5vzC52rPA7q7Vmt8VBJPCUKxHLGXZNu0Cx3i34p/TnUa/ BZ9WYyeVaryaz3TJJEJgCpKiRoQm0uwhRIhGZfWdCQne6kiSYTpwJKQBRGMUGTPHGN7PggmkEwh3 XimsvPPb4od2bjMJDncLF6h1T1Pona0aASkB2Cm1ikytGZUVQyZjLc0slJnk5TGOc953OPb+9ZOZ mvt5dDezRwq2Vmgd9VmX5o11UA1TDCjMplHZQq8sgCxs2XjUyqtmQB3VK7N51VKzLJ7qqKypCsq6 3HCkMdRnKEOi7JHihnKCy3ZTuygcgqj6RS9IrRGMSn+y+SHvKp1vtQHCQywsc5BTfaHLLNRTGsrV +yeSicPyS98K1dxuYPFFZmN8Vz32h3ipDKd4rINZUCwrYOH5KBwfJPHMBOr1FeYzsVZry2DvouQG a8d0UdSsHBWO5jkMtMraOAfBDd08+CkhzMQd0iVPa05dJIkrWxs6gMLCfY7mPyrzdvVrBwSj19dt aOSsoufEDRCMhbH7PPgoHphPZS4+dhA7Ciu43v66ME3+q5we2Z28SR4rbxraL63VvIcHcT2XlQ+s Fo/OR6vrVfX9F0KhUQSN0+StM3EAdu6sM6cW9laqwtOFFl5mJvh0tRne2j2PV6TU19dIaBPuJIGn guXyXVVlxBl3AjQAKhk/WG3IJL3TKzbs97zyq9VZPZW66T4KxVhkdlarxiNSFUlMy2WtnJyORJj4 qg+2UN9zncoZMqtXQVZFP6M+KO2oaImwbSEOFTJz5UZSSVlMnKXZOUpJJJNCYpymPmkpSSSSYhRj RSKSSVJJJIZao7EXSE2iSrUkkkheml6fgjaJe1JSkkkkD00xrVj2pjs7oKUkkkqpqUHUhXDtUHbU NEKSSSVF1KE+k+Cvu2Tqhu2IV4qVKkHKKSzbKCq76FqP9NV3+knxMhspMy2CrNeUQqGqmN3ZZb6C hOoK1HekhH0lJGcx+ifsQ7FOcRGquV9SjuueHqIo9ZZhoPgoGg+C0j6SgfRUgyT/AHZfYU6vTV9V /lKyzrEfnLlR9oRG/adYWccc+CiaCtI+imPownjJk6Rl9hTZ8Xrq+tgH6RVlnXuPcuMH2vspN+1z x+JWZ6BTjHK0f0Kf9An+7nr5Z15FVy7F7hv1i2fnKNv1lcWwHLiv1yePxKgftngqLcc+CKyjyVse iit9BQyyT/dl9hQSXp7+tTqXAys6/qhd+csZ32rugv8AtPdVWUKwyiEdvpSjM9OFFKUz0KHQvzye 6o2ZW5Vn+p3Q3bu6FXQPBHZRHZEZs0RxCjPipI+8lCc8lRMpkIUcIjadNAis2wijahSl5TSkkgCm eym3HA5HyRhHzUtY0S06qUkkkg+gPBMcccI+sap0tFKSSSVf7OOITDHafkVZS+KGilJJJKt9m8vw S+yg9lZSSoJUkkkqv2RvgnGI2eFZTHlKgpSUpJKv9lb4KTcdrTwEbVOPJGgpSSSSgKx4KQY1Pql2 RUpJJJLaAnjSEvh8k6StFJJJL//ZDQplbmRzdHJlYW0NZW5kb2JqDTg1NyAwIG9iajw8L0ludGVu dC9SZWxhdGl2ZUNvbG9yaW1ldHJpYy9TdWJ0eXBlL0ltYWdlL0xlbmd0aCA4NTk4My9GaWx0ZXIv RENURGVjb2RlL05hbWUvWC9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA4MzQgMCBSL1dp ZHRoIDEyODEvSGVpZ2h0IDQwNC9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K/9j/4AAQSkZJRgABAgAF AQGUAAD/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgNCA0RDg4RFxUWFRcbGRkZGRsiFxcXFxciIBsd HR0dGyAiJycnJyciLC8vLy8sNzs7Ozc7Ozs7Ozs7Ozs7AQ0LCxAOECIYGCIyKCEoMjsyMjIyOzs7 Ozs7Ozs7Ozs7Ozs7OztAQEBAQDtAQEBAQEBAQEBAQEBAQEBAQEBAQED/wAARCAGUBQEDASIAAhEB AxEB/8QBQgAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAID BAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0 coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl 9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgI7AQACEQMhMRIEQVFhcSIT BTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj 80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH1+f3/9oADAMBAAIRAxEAPwDg Uk6SmWKSSSRUvCUJJ0kLQnhJOkpjCeE6SSlkk6SSloShPCSSmMJ4TwlCSmMJQpQmhJS0JQnhKElM YShShKElMYShSSSUxhKFJNCSloSTwkkpZJEcGQ3bMxrPj5KEJKUklCeElLJJ0kVLJJ0klLJy0tME JJcpKWTpJ0lLJJ4ShJSySeEklLQknhJKlKSTwlCSFkk8JQipSSSdJSydJJJSk6SUJKUkkkkpSdJJ JSkkkklLpJJJKUkkjMx99T7N7RtIG0n3O3fujy7pKRJJJJKWTpJJKUmTpJKWSTpoSUpMnShJSxSS hKElKSTpJKWSTpJKYpJ0kVKTJ0kFLJJ0kVLJJ0oQUsknSSUsnSSRUtCeEk6SlkoTpJKWhKE6UJKW hKE6SSloShSSSUxhKFJMkpUJQknSUskknSUslCdJJSySeEoSUtCRk8p4ShJS0JQiMr3hxkDaJgnU /BQSUtCUJ0klLQknSSUsknSSUsknSSUslCdJJS0KTK3PnaCYEmOw8UycOLZgkToYSUxhKE6SSlkk 6SSlkoTpJKWhJOkkpZKE8JQkpaEoTwlCSloShPCUJKYwnTwmSUtCUJ4SSUtCUJ0oSUtCUJ0kFLJJ 4SSUsknSSUsnTJ4SUpJJJJSoSSSRU1pSTJ0xcukmlJJTIJ1FJJDJJMkkpdOmSSUukmSSUukmSSUu klKSKlJJJ0FLJJ4SRUslCkmhJS0JQpJJIYwlCdJJTGE8J4SSStCUKUJoSQtCUKUJQipjCUKUJQkp jCUKUJQkpjCUKUJQkpaEoUoShJTFKFKE0JKWhOnhJJS0JJ0klLQlCeEoSUsnhOlCSlkk8JQkpaEo TpJKWShOnSUxTp0klLJJ4SSUsnhJJFSkkk6Slk6SSSlJJJ0lLJJ4ShJSySeEoSUsknhKElLJJ4Sh JS0JJ4ShJTFJPCUJKWSTwlCSlkk8JJKWShPCUJIWhMpJJUpaEk6UJKWhKE6UJUpaEoTwnhGlLQlC eE8JUpjCUKUJQkpjCeE8JQkpjCUKUJQlSmMJQpQlCVKWhKE8JQkpikpQkAO6SmKSeEoSUsnSSSUp JJJJSkk6ZJSkkoTpKWSTpJKWSShPCSloShPCUJKWShOkkpaEoTpJKWhJPCUJKWhKE6UJKWhKFJKE lMYShShKElMYTwnhJJS0JQnSSpS0JQnShJS0JlJKElMUoTpQgpaEoTwlCSmMJQpJQkpjCUKUJQkp jCSlCUJKYpoUoShJTFJThKElMIShThKElMYSUoSSU0klKE8Ji5gkpwlCSmKSlCUJKWSTwlCSlk6U JQipUpJQkkpdJNCSSl0kkklKlKUkklLynlMkipeUpTJJKXTpkklLpJk8JIUkknSUsnSTpKWSTwnh JS0JQnSSUtCUKSUJKYwlClCeElMYU6MezJeK6mlzjwByU0J2ktMgkJKYQlClCUIqYwlClCUJKYwl ClCUJKYwlClCUJKYwlClCUJKYpQpQlCSGKSlCUJKYp4TwlCSloShSSSUxhKFJKEVLQlCeEoSUtCU J4TpKYwlClCUJKYwnhOlCSloSTpJKWhJOlCSloSTpJKWShSSSUxSTwkkpaEoUoSSUxhKFJJJTGE0 KUJJKWhKE6SSloShSSSUxhKFJKElMYShShKElMYTwnhKElLJQnhKEVLJJ4SQUsknShJSySeEoRUp MnhKElLJQnShJS0JQpQlCSmMJQpQlCSmMJQpQlCSmMJQpQlCSmMJQpQlCSmMJQpQlCSmMJQpQlCS mMJQpQlCSmMJQpQlCSmMJKUJQkpikpQlCSmKUKUJQkpjCdPCUJKWhJPCeElMYShShKElMYSUoShJ TFKFKEoSUxhJShKEFMUoUoShJTGEoUoShJTFNCnCUJKYQlCnCSSmMJQpJJKYwlCkmSUtCUJ0klLQ lCdJJS0JJ4ShJTFJSSSU04ShOnTFy0JQnSSUqEoTp0kMYS2qSSSWMJbVKEoRQx2pbVKEoSUw2pQp QlCSmMJQpQmhJSySeE8JJYwnTpQkhZPCSSSlQlCSdJS0J4SSSUpJJJJS6SSdFSkkk6SlJJJ0lKhK E6SSFoTwnShJS0J4ShPCVKWhKE6SNKVCUJ08JKYwmhThLakphCSntS2pKYQlCntS2pKYQlCntS2p KYQlCntS2pKYQlCltS2pKYwlClCUIqYwlClCUJKYwnhPCeElMYShShKElMYShShKElLQmhShPCVK YwlClCUJUpjCUKUJQlSmMJQpQlCSmKUKUJQlSmKZT2pbUqUxSTwlCVKWShPCUJKWhKFKEkaUxhKF JJKkMYShSSSpLGEoUkkqQtCUJ06VKYwlClCUJUpjCSlCUJUpilClCUJUpjCUKcJbUqUw2pbVPan2 o8KmG1LapwnhLhUw2pbVOEoSpTDaltU4SRpTDan2qcJQlSmG1LapwlCVKYbUtqnCUJcKmG1NtRIS hKlI9qW1ThKEqUw2pbVOEoQ4VMIShThNCXCpjtS2qUJQlSmMJQpQlCVKYwlCkklSmMJQpJJUpjCU J06VKYwlClCUJUpjCUKUJoSpS0JQnSSpS0JQnSSpS0J4SSSpSkkkkqUsknSSpSySdJClMYShShJK lMYShOnSpTGEoUkyVKWhKFKE0JUpaEoUoShKlMUlLaltSpLGElLaklSmlCUJ08KNLGEoUoShJTGE 6eEoSUsknhJJSydJOkpZJOlCSlkk8JQkpZKE8J4RUxhKFKEoSUxhKFOEoSUwhKFOEoSQwhKFKEoS pTGElLaltSUxShShKEksYShShKElLJKUJbUkLJKUJQipZJPCeElLJ08JQkpZOnhKElKTpQlCKl4T wownhKlLwnhMnRpSoShOnSpS0JQnTo0hjCUKUJ4SpSOEtqJCUJUpHtS2okJoRpSPaltRIShClI4S hEhNCNKYQlCnCUJUphCUKUJQlSmMJQpQlCVKWhNCklCVKWhKFKEoRpSznbzJj5aJoUoTwlSmEJQp QnhKlMIShThKEuFVsIShThKEuFVsIShThKEuFTCE0IkJQlwqtHCUIm1LalwqtHCUKe1PsS4VWihP CJsS2I8KLRwlCLsS2JcKrRQnhF2JbEuFVooKeETYltR4VWjhPCntT7UuFVo4Twp7UtqXCq2EJQpQ nhKlMYShSTJUpUJQkkjSlQlCdMlSlQnhJKUqUqEoSlPKVKWhKE8pSlSloShKUkqUqEoSSSpS0JQE 6SVKWgJQkklSlQlCSUoUpaEoTymlKlLJJ0yVKUlCSSVKWShOmhClKhKE8JQlSloShPCUJUpaEoTw lCVKYwkpQmhKlLJJ4ShKkrJJ4ShKkLJJ4ShKlLJQnhOlSmMJQpJQlSWMJQpQlCVIYwlCkklSloSh OklSloTwnSSpK0JQpJJUpaEoTwlCVKWhJShJKlOdCUJ5Tyq65aElLRIIqYwnhSTpIYQlCmkkphCU KcBPCSkcJQibU21JTBKVPalsSpTCU8qWxL00VLSkn9NLYUlLJ9E+wpbClSloShPtKW0pUpaEoT7S nhJTGEoUoShKlMYShShJGlMYShShKEqUxhJS2pbUqUxSU9qW1KlMITwp7UtiNKYQnhS2p9qVKYwn hPCdGkMYTwnTwjSloShPCeEqUtCeE8JI0pUJAJ5TyjSloTwlKSVIVCUJJ4RpS0JJ4ShKlLJlKEoS pTFJS2pQlSmKSeEoSpS0JoUoShGlMYShThNCVKtjCUKcJQlSmMJQpwltSpTCEoU9qfajSkcJQibU tqVIthCUKcJbUqUwhKFPalCVKYQlCnCUJUphCeFKE8I0phCUKcJbUqUwhPtU9ifYlSke1PCJsT7E qUihKEXYn2I0pFCUIuxLYlSkMJIuxLYlSrRJIuxLYlSkcJQp7UtqVKYQmhE2pQlSkcJQpwlCVKYQ ltU9qUJUpHtS2okJQlSke1KESE0JUpHCeFPamhKlMIShShKEKUxhJPCUJUpilKlCW1KlMJSlT2pb EqUwlJT2pbUqUwSU9qW1KlMIShE2pbEqUjhKEXYlsS4VIoShG2JbEuFVodpS2lH2JbUuFVoNqeEb YlsS4VIdqUI2xNtS4VWihKEXam2pcKkaSJtS2pUpGmRdqbYlwqRpQibUtiVKtFCSLsS2IcKrRQkj bEtiXCq0MJ4RdiWxHhVaKE+1F2pbUuFSLaltRYShKlWi2p9qmklSmG1KFNMhSmMJoU4ShKlME6lt S2JUpikpbEtqVJYpKe1JKkOYkmlKVVZF0kkpSQukmTykpeU4KaUpRUylKVGU6SmcpwUOUpSUkT6I cpSkpJAShQlOCipnCeFEFOCiFMoShMCn3I0hUJ9oS3JbkaUram2qW5PISpTDaltU5CeUqUj2ptqK mgI0pHCaEXam2JcKrRwngKfppemlwqYQnhP6aXppUVLQlCfYlsKNIWTpbSltKVKUkngpQUqUpJPC SNKWTwnSRpS0JbU6dKlLbU0KSSVKYp06SNIWlOkklSlSlKSklSmMp06SNKWTwnTgJUpjtS2qUJQj SmO1PtUoShKlMdqfYpAJ4SpTDaltU4TwjSmG1LapwlCVKYbUtqntS2pUphtS2om1LakpHtS2om1L akpHtT7UTaltSpSPaltRNqW1JSPaltRNqfakpHtT7VPan2pKYAJwFPan2oqYbU+1TATwkhGGp9qJ omQUx2pbVJKUlMdoS2hSSRUx2ptimkgph6aXpooTwkpD6ab00eEoSUg9NNsR4CW0JKQbE2xHgJQE lINqWxHgJQElNfYl6aswEgB4JKa/pJvSVqAn2hJVtT0kvSVzaEtoSVbT9FL0FcgJbUlW1PQKXoFW 4ShJVtT0EvQVqEoSVbV9JL04VnalsSU1vTS9NWdiWxJVtf0kvTR9iYsSUh2JtiNtTFqKkW1LaibU tqSUe1LaibClsSUj2pbUTalsSQi2pbUXYn2JJQ7U21H2JbElINqbYrG1NtQUg2J9iNtS2oqQ7Etq LtS2oKRbU21FhKElIoTQiwmhJSOE0IkJoSUxhKFKCltKSmMJQpbCm2FJS0JoUtiWxJTGEoUtiW1J TGEoU4CUBJTCE+0qcJJKYbSm2lESSpSPYUkVJGlORsS2IsJwAqdL0XppemjQE+1GlWg9NL01Y2Jb EuFFtf00vTVjYn2FLhVbW2JtitbD4JbPJLhVbV2FLaVa2eSXphLhVbVgpKz6ab0/JLhVaCUpR/T8 kvT8kuEqtDKeSi+ml6SPCVWjThE9NL00eEqtgE4U/TS9NHhKrYynlS9JL00aKFtEoT+mU+wo0paE oUtqUJUpZPKUJfJGlK3J5SSSUpOmlOihSSfRPojSmKSnAThoSpSNKEYMT7UaUh2p9iLtTgJUpD6a f0kWE+1GlIPSS9Eo+1S2pUhrekUvSKs7Sn2FKktb0kvTVr0z4J/T8kqQ1PTS9NW/SHgnFQSpTT9N L01d9FqXohKlW0vTKWwq76AS+zpKtpbCn2HwVz7MUvsxSVbT2p9qtfZikccpKtq7E4YrHoJegklB sThiN6BS9EpKQ7UoRvRKXpFJSLakGovpHwT+mfBJSKE+1FFZ8E4rPgkpDtS2qwK/JP6XklaGttS2 qz6Sb0krVbX2pQrHpJeklamvCdGNSb00kokkX00vTSUjlNKN6YT+mErUgkp5KN6YTbAlakUpIhYE 2xJTBOn2pahJSySeU0pKXSTSlykpdNomS0SUvIS3JoShJStyW5KPJPB8ElLbilKeD4JbT4JKWlLV PtKW0pKWkpSVINKkGpKYapxKKGqQYlakIBT7SjBil6aFotAGlS2lFFRT+iUrUiAS2o4oUhSELQ14 S2qz6IS9EJWprbUtoVj047KO3yStSHYEtqKQmIRtSPYEtoCkYUS7ySSqAlCYvjsm3pKpeEoPgo+o mNpSVTIg+CYhR9QpbyUlUyTSE2pS2oppUhKQlCW1JStEyltS2lJDFJS9MpeiUrSwKaUT0U/ohK1I dyW4IppCiaglake4JbgpmpL0krUj3BKUT0k/pHwSUhlNKP6Pkl6XkkpBKSP6Pkl6XkkpAlKP6Sb0 0lIEkb0yo7ElI9U8KW1KCkpjtKW1S2lKCkpjsT7U8FPtKSmOxLYpbU8eaSmGxPsUoHilp4pKY7Ul KB4pIqcfeE+8JCkpegVUorlbwn9RL0Sn9EpaqXFqcWKPpFLYUdVJA9PuQthT7CjqpLuTyhem5P6b kdUJZToW1yUORUmACeAg6p5KKksBNAUJT7kUM9oSDAob0+8JKZ7An9MIfqJ/VRUz9MJ/SCgLfNP6 vmipl6SXpFN63mn9ZKlK9Ip/SKb10/rhGghb0yl6ZUxcCnFoSpSP00vTCJ6gT7mo0pDsHgltCNIT wEqU19qbYrMBLaEqU1tibarewFIVApUlqQUoVz0Al9nQpVtQSnkqz9mS+y+RRU19ycOR/shS+yFJ SIFSCn9kKX2ZwSUsFNoCj6Lh2UhW4dkkMwApgBCDXDspCR2SVSWAltUA5OHhBFMtib00vUCfeElL emUvST7gluSSsKypCsppKfVJDIVnxUvRPioapAlBVM/ST+mFAOIT70lUy2BLY1N6hTeoUlUy2NTb Gpt5S3lJVL7Am2hLcSlqkpW0J/amgpbCkpeW+SUhRNRKiaCUlM5CaVA47kvQeO6SWaiVA1vHdN6b 0VUzMeKjI8U3pOKXoFJSp80p80vQPgn9E+CSVpTbipeifBP6J8ElMJKeVMUlSFJStCNLbKMKHJ/s 7ihakGwpemUf7K5L7K5K1IPTKYsKs/Zj3T+hHilammWnwUSD4K56KXpeSNqtp7T4Jtquel5JvS8k rTbUDU+0K16KXoJWq2sGhSDUf0PJP6HkhaLQQnARxT5J/R8krVaABSARvS8k4pKVqRBgT+mCrApK kKfJC0Nb0UvQVsVeScVhLiS1Ps6cUK56bUvTahxKpqekn2QrWwJbB4JcSqa0EJSVa2DwS9NqVqpq ynlWfTHgn2DwStVNWUtpPdWvTHgm9Nvglaqau0pbCrW1oShoStVNX0yeyY1HwVr2+KaWpWqmn6JU TjlX9zQm3tS4lOf9nKiccrQ9QeCYvHgjxFTn/Zim+zeavlw8FGR4I8SraX2dL7Orungm08ErVbT9 Ep/SVo/BMZStVtb00vSViClB8ErVaD0yn9Mo22eyls8krU1/TKb0j4q16c9kvS8krU1vTKkK0f0f JL0SlaEGwJbAj+iUvRKVqQ7QlAR/RKXoIWpBIHZKfJH9BP6ASsJa8+SU+SseiEvTAStCD5JbUba0 eCRAStSD00xrViU2vglamvs8lEs8la2kpekUbU1DWfBR9M+CvegUvSStLR9F3gmND1oCpP6aXEpz Ps70vs71pen5JiwJcSrc37O5L7M5aBrUfT80rVbQ+zOS+yuV7Z5pbEbVbR+yuSV7YklarcD0il6Z UpS3eSipctsI7JbHJ98J95RpS20p9qW8p/UKVIVtCfa1RNpS3lFTLa3xT7R4oe9PKKme1LYoalKE lM9gSLAowngI0pYsHimLfgiBoUgxvmlSrQbEtnmrHpM81IVM80uFVtX0/NL0j4q36TU/pBHhRbT9 E+KXoFXRSE4pHilQVbT9Ap/QKuekB3T7YSoKtqChycUHwVvhPu8kaU1PRd4J/Rd4K1vHglub5pKa npFP6RCsusYwEnSBOqxc76wtjbjjWfpEaR5BR5MscY1XRiZOj6bk+1yxGfWK8NILWk9jCK36zOEb qm+cEqMc3jXe1J1tQn3FVsXr+Lfo/wBh8+PvQrvrJRW/axhcB34+5PPMY6u0e3Ls39x8E4efBQwu p42do1wDv3XaFXfRBT4zEhYWkEbtcWHwUhaQjHHUXURqdEbQxGQR2UhleSQolL7OfBLRWjMZYTjK b4Ku41Mdsc9oPgSJU/QHghoVUm+0s8E4vYeyB6Hkm9IeaNKoNn1mJvWYq3pgJbB5pUqmybWlNuBQ AzyKkGfFKlUzMFN6YKYAeakICSlvQlN9mPZFDgnDkLUg+zPCcUWI/qR2Ti3ySsqtAKbAn9K1WBd5 JxdHZKyprhlqW2zwVj7Wzxb94Um5TDwQfmhxKawD/BSDXnsrYvHgnF7fBK1NUUuKcYxKti4FL1Ah xFTV+yFSGGVZDwnD2eKVlTW+yOT/AGVysb2BP6jUrKqa4xXJ/s5Vj1QnFqFlVNb7OU/2cqx6hTOs I5Ssqpr/AGdP6ELMzfrZiYpLWk2OGnt4+8oGN9csa10WsdWOx+l+RRnPC6tf7cuzt+kn9NNi5dOa 3fU8OHkfyhPk5NOIzfa8MHiSn8Qq1tLbB5JemFj531qxK6nGhxe/hoggT46rlG9Vy2WeqLn7vGf4 KGfMxidNV8cJL6GK2pClq4Nv1iz2kH13aGdY1+K3+jfWtuS415W1jvzXDRp8j4JQ5mMjSpYSHe9E BL0lM3BokxHil64HZT2WNh6Y8E+0eCf7SP3Sl9p/kpaqWjyS18EjkeSb7R5JUplqlJQ/tB8FH1z4 JUpNuSkFANpTeoSlSmz7UtrfFVtzin9xSpTY9qeWeCrbXFPsJSpTY9Rg7JjawdkEVpxWlQUkNtfg Exsr8FH0x/qE4rHilopRtZ4Jeq3wUhUE/pBLRTD1gm9UInoNKb7O1LRTD1QlvCn9maUhht8UtFMd 48U28eKIMNvin+xtSsJR7wO6f1PNTOKxokrB6j9Z8TCcWUt9Vw5IMMB+KbPJGI1TGJls7fqeaXq+ a5ur66VwPUxzPfa4fxRcT65Y9jiLqiwTo4e7TzTBzGPuu9qTv+ol6iJTZXe0Orc1wPBGqDf1HFxd 3qWsaW6kSJ+5SGQWUV/UPgn9R3gsl/1xwGugbyPEN0VvD6/g5x2stAPg72/lTBlgeq4wkG2XOKY7 ijhoKfYE+1rWLSVE1HxVv0wl6YRtVNM0lL0CrnphP6YS4lU0vR80/oq36aXpJcSqawqT+mrPopvR KFqpr+n5JGvyCP6JTemQjakBamgeCWXlU4Ld172sHmfyBZN/1swKvolz/g2PypsskY7lIgS60t8E pb4LAyvrnjs/manP83e0fxWZn/WzIygG0j0o5IMkqOXM4wuGKRexkeCUjwXC4/1lzqHhxs3ju1w0 KXU/rFkdQLdpNTW9mk8+Mpv3uFJ9k291ITgrjujfWizDIryJezx5e3+9a+V9bcOiPTDrJE6e0D70 +PMQItacUgXblPJWAPrlibJ2P3fuwPyrOs+umQXksrYG9gZJ+9I8xjHVIxSexBSlcXh/W/Kqsm+H sPIADSPgtsfWzp5E73DTjaUo54S6qOKQdlMZXNWfXWsPhtJLPEmHfcnzvrjU1g+zNLnHneIA/vS9 /H3R7UnozuTFrlxg+uOaO1Z/s/7U7vrlmECG1jTwPPjym/eoJ9mT2PpvPdN6Lj3XJV/XTKaRvrrI 7xI/itjpv1qx+oWioscxxGhJET4J0eYhIoOKQdX7O490vsrj3RRaEvWhS2ViMYh8VIYil66b7Slq rRf7Kn9CFE5RTfaktVM/TATEAKP2ifFM7IDQXHQDknhJS5PkoF57BVMrruHjM3utaZ4DTuJ+5cjn fWXMynkssNbZ0a3SB8VHPPGC+OMye3NjvBRL3rkKPrdlVMDXNa8j84zJ+5WG/XN351A+TigOaxp9 mT0pc/xTEu8VmY/1nwrmbnksI5aRP3QtHDzKM9m+lwcBz4j4hSRyQlsVhiQok+aWp8VI5FTSGl7A ToBuEoOb1TH6eP0tgB8Bq77k4zAQASk2OPYp/TPggdP63R1KRU73D806OV31HJRmJCwoghD6bvBJ H9RySdankcjqtVAIHuPgFnP6ve+YIE+AVNMsyeecurajjiGTrXPMuJPzUm5FjQAHu080NOorXtwd XyAIkfGFZxutagXN08R/cspJSDNMdVphEvVVWVXN3NMjyU4rXLV5FlMhjiJ8FL7XcRBe6D5qwOcF ahjOHxen2MKf02eK5QWv43H71cxeq2UaP97fPkJ0eciTqEHCXf8ATb2Kf0/5SBS9uQwPYZBUwwq0 CCGIpfT80vTPiqHUOoDDbDCC89vBY7uo5DzPqO+RhQ5eahA0vjiMg9QGFSDXLlh1LJGnquVirruR WIdDviNfwTRzsOoScEnogHeCkJ8FiV/WMge+vXyKVv1kO32VwfM6J/3rFW632pu7u+Kf1I8VzDfr Bkh0ktI8IUrPrDkO+iGt+Upv3zGn2JPS+qhXZjKBNjg34rl7Oq5Vog2GPLT8iqucXakz8VHLnh0C 4YO7t5P1l2uipkjxdog/85rv9G38VjpKA8zkJ3ZBjj2dC7ruVadHbR4NCZvXMtv58/EBUEkz3Z9y ngj2dRv1hyQNQ0/JDyutX5QgHYO4b/eqCSJzTIq1cEezI2OcZLiT8UyZKVGuXTFKUuUlLJ0kgkpU qxj9RyMUEV2OA8FXhJEEjZR1bjusZjgQbna+arvybbBtc9xHMEnlDSCRkTuUAAJqMy7GM1vc34FT f1LKsMm58/FVkkrKqC5cXGSZPiVJt9jDIc4fMqCSCWwOo5Idu9Z8/wBYo9XXcyoz6pPk7UKgkiJy HVHCHoK/rY6PfSCfEGEK760ZD/oMY3/pLETgqT38h6rfbj2dK7r+ZdHv2x+6IRafrLlViHBr/iNf wWSE6b7s73TwR7Oy361ZAOtbCPmFYo+tTdp9WrX+SdPxXPJJw5jIOqDjj2egu+tZkelSI77jr+CV f1sdu99I2+R1/Fc+kl94yd1e1Hs9hjfWHEvYXPPpkdnd/hCxM36w5N1jjS8sZ2Gk/NZSdGfMTkKt UcUQWyeq5bubn/egvyLbJ3PcZ8SUNJREkr6Ck4JbqEydBTt9O+s1tJDcgb2+I+kP71u1dawbQCLm jyOhXDJFTQ5mcfFjliiX0P7TSKjdvbsAncDpC5LrPXrOoONdZ21A6Du7zKypIESoylk5iUxSoYhE un07r+R08xPqM/dcTp8Cuip+s2DYCS4tPgR/cuKCdCGecEyxxk9VnfW6pgjGYXO8XCGhc7l9Tyc4 zZYT4AaAfIKuUybPLKe6YwEW3V1jMpjbe/TsTI/FXrvrXm2tDWlrCOS0an71jJIDJIdU8I7Ohf1/ OyPpXOH9X2/kVSzJutHvsc74uJQ0kDIndIADFKE8JIKT4WfdgP30u2kiD5hNlZl2a7fc8uPn2QUk rNUqlk6UJJKUAmTykNUlOjf1q7Iw2YjuGmd3ctHA+SP0n6yZGA5rbCX1DQtPIHkVjpJwnIG7Rwin 1Gq2q2sWtI2ETPaE1ORj5E+k9jo52kFeZC54aW7jB7SY+5MHEcGFP97PZj9gd31P0geygK2OMCD8 CvNx1LKawsF1m3w3GEKnJsx3h9bi1wMyCj978Eex4vp3oNS9BvgvNn9SyX3C82u3zIM8f7F0eH9d mmBkVEeLmGf+inx5qJ30WywkbPT+g3wT+gzwXK9T+uT22AYcFo5c4fS8kqfrzZP6SgR/Jd/ej94h e6vak9V6DPBL0AsYfXDDNRs3OkfmR7j/AAXP5n1tzskn03Cps6Bo1+8pS5iMeqhikXufRPimNe3U uAHnouB/5zdR/wBOfuH9yrZfV8vNbtuuc5szB4n4Jh5sdk+yX0gV7uCD8E3pEd15lj5d2K7dVY5h 8iQtnD+uOZRpaBaPP2n7wlHmgd1HCej2Zrcon2AkmABJKyaPrbg2s3Pc5hHLSJ+6Fl9d+tTMul2P jNdDtHPOkjyCklngBdrRjkSrqX1wsFhZiBu0ab3CS74BUB9bOoA/zjT/AGQsdJUzlmTuziER0ejp +ut7QBZUx3iQS2Uc/XdvbHP+f/sXKpQiM+Tur249npnfXezXbQ0eEuJ/goj673x/MMnxkrm0kvfy d1e3Hs7GT9as/IOlnpjwYI/EqNX1o6hU3b6s+bgCfvWSnhN9yXdPCOzbyOr5mW0stue5pMkToqad MmkkpqlJJBIpKZ05FmOZre5p/kkhQJJMlKEoSUsnShJBTbxerZeEAKrntA7Tp9y2en/XXIqdGS0W NPcDa4fwK5tJPjklHYoMQX0zA6zi9SE02ie7T7XfcVd2uK8mBI1C6jp313toaGZLN8CNzTDvmFYx 8yD8zFLD2ex2OTFrlzrvr3jj6NVh+4LNz/rtkXt20MFX8onc5SHmIDqtGKRej6v1qno7JsMvP0WD k/3BUOk/W2rqFvpWs9In6JmWny+K4q65+Q8vscXOJkk8lQUB5mRkyDEKfVHXNr+k4D4kBZ2b9ZsH BcWusLnDswbvx4XnrnF2pJPxTIy5qXQIGEPXZP16YP5mgnzeY/IsfJ+tfUL3EizYCI2tGn4rIhJR SzTPVeIRDK66y926xznHxcZUE6SYuW5SSSSUoiEydNCSlJk6eElMUk8JQkpZOUkikpZOmSSUpJJJ JSkgUoSCSmyzqeVUwVtueGjgAojOuZ1fF7/mZ/KqUJQncRHVFB1v+dGeSD6g0/kjX4rQq+uhgepR 8S1394XMpJwzTHVBxxPR6k/XRkj9A6O/uE/kVx/1swWOABeRpqG6BcUknDmcndb7UXsc363YtTD6 Ac90aSNrR8Vy+Z1TJ6gf01hI8OG/cqqSbPLKe66MBFUJJJJi5SSUJJKUpstfXIa4gHQwYlQSSUqe 6ckuMnUpkklM6rX0PD2OLXDUEdlqYP1my8Rzi9xtBHDj38VkJIxkY7IIBei/56X/AOhZ95SXOpJ/ v5O63249mSdMUgol6oSTpJKWTwmJhLckpcpJtybcUqUknRMoSUtxSpTZx8u3FM1uI8uysP6zkvEb gPgFn7kt6cJzAoFBiCzJLjJTJt4TF6alkmlQ3p9wSUvMpJJJJUkkkkhSSSSSVQkkkkhSSSSSlJJ0 ySVJJJJIUnSSSUpJJJJSkkkklKSSSSUpJOmSUpJJOkpZJOkgpZKE6SKlAwn3JkklKlPKZJJS8pwV FJJTJOoynlJS6SSSSlk6SSSlJk6SSlk0KUJJKWhJOmKSlQmThJJSySlCYhJSydMNVIpKWKZOQkEF LJJykAkpUJJ0xRUskNCnhMgpc6poTp0VLAJJ4SSUslCUppSUop0ySSmSZNKeUEqTpkkkLpJSlKSl kkkkkrhMU/CSSloShOkkhYBOnlMklaEoTpJKWSTpklKSShJJSkk6SSlkgnTJKXhNCdKElMYTwnhM kpZPCUJJKUUwUiNEwSUslCScpKWlJJPCSlkyeEkkLJJyEoSUxhOknSUtCUJ0klMUkiEikpSRKSUI qUkmTpKWhJJJJSkkoShJSySkmSUsnKXCZJSkoSSSUpJJJJSydJJJSkkkklKSSSSUpJJJJSySSSSl JJQkipdJMkkpW5LcoJ5SSz3FMSVGUpSQySlRlJJLKU0pkkkLylKZJJS8pJkkFKSSTSildOmlJBC8 pSmSSUvJT7lGUklMw5PIKGklSkiSHKUpUlIkoB5Th6SmaUpQYlJBSydJPCSlkk41TwULVTFKE8Qk jaqUmUxW4t3QY8eyjCVqpZJSDSTCW0pWpZJTfS+sNc5pAcJafEDTRQStSkkoISStSkkazFdXU20l sOJAAcC7TxbyEECUAQVEUpKUWnEtyA4saSGglx7ABMMW0s3hjtuvugxpzr5JcQTRRpJtUyKGUpKO qWqSl5SBSIhKErUulKUFMlamW5S5UAlCSmaQUQU8pWpdPCaUiUlKlMkna7aQYBjseElLJJ9CmlK1 Lpk6aUlKT8ppSDo1CVqZFpboUyRfuMnkpTCFqVCYJ5THQwUbVSoT8KMpbkrUySUZTylalFJJNKVq XCUpkyVqZSmSSSUpJMnSUpJLlJJSkkk5YWgE9/NJSySSSSl0kydBSkkkkrUukmTpWpSaU6aErVSk pTwnAStNLSmUoS2lC1UsE8p4hJ2pnhK1UxTJ0ijaqUEXHoOS/YC0GCfcQ0e0TyUFOUrUpMkklaFQ kkklal0jomSStKkkkpStC8pkkxStS6RTBIpWpSUpJJWpSSZSStSimTwlCVqpinS2pHRK1KKSYpSi pRTJ5SSUskU6ZK1KSSSStSk6QSII5CVqWSSSStSySSSSlk6ZKUlKSTkpklKSSiUpSUpJMnSUpJJM ipdJMkkpeU0pJklLpJkkkLpJJSkpSSZJJLdd0XMZa6n0nb2t3OaBJa3mTCVHR7r37RtA3Bpsma2l wkS5srUxcVuM9t7i949xeW7mvYB7Y5EySOCp9Nzmu3Y7mmomdrwdrt7uA5zuBrqfkoDllWjN7YcT 9m3utFLay551DQJJETp8kSnpGRkUG9jQWh4rIn3biC7j4BbT/T+02XX3MqtrloY2s+n7RENI8exI VWw1Pptra+xzQ5ha5rQ2skiDvbzI7FIZSVe2GkzoWS5xaQ1rtoLWucA5+7gNHc+ShT0i+9xraG7w 7bsLg10j4rSblOqzGOstc30WlrbNkudtHt3NPIPGvZGuoxLqw6v+lSdwkPpeRMxppP5okpe7Ibq9 sHZ530XTEKxR0y7JLQwCXGACQDr5HWNVcFjqMf7O7GG55379d8CY07QruZm249FLG2WMdW6WgxuA A53ASCDIjwRlkPRAgHK/YmQXWNAaTXM+4e7bzsPDo8kDJ6ffiWOqsrIcwS4c7fjC0868vuraWvFL SC1geXBrTBdtcR35Wn1LFqtLW4heXNJFznNd7mWQW77J1HDe2qHukbq9u3kYShdHVQ3HNuPdjE12 WN97QdzNk6MLh9HXVByKas/JpxmBrWNIr3xsBEn3udHHxThmsoOPRwoTQujf0Kt1jaPStDwC07P0 jbHmSxwOg1A/uQLOkgvbS1ps2amyobmuadRoATu4HkiM0Sr2i4cKTa3OBIBIHJjhalPS2+gby5pI I9hlrjrENEe75Ij73GljWbwXja/Zo0tadA5oAnRH3QjgLjtrc7gSpHHsa0OLHBp4MGD810mY6q+w 00MsrcGire47WlnADmuA2g+JOilm13nDjL32Rb6bbd5NLWtb+Zt0Pnpwme8n2nlywjkJCt0EwYHJ hdF1HBaWVGuwGulo3CNjxuOrmtfq4O5/uVnZW/O95DvUc00vd+jrslwG97tNBHh4pe/Y2T7Wryew 8wmIXWX9UZhPOLzFk2PBFjRDuK2kbTEfS7ql1Omh1HqV4lleuljtA5p/eHd09xp5IjKb1C04/FwI UxRYQHbHQeDBhHa0NeH7BtBnaZIPkVo1YmfbXWxtkNLXvrbvH0Nd8DtxwU6U6QIW5uN06/LsFVVb nPPDQNeJ4Vyj6sdSyQ91eLaQwEu9p028q2Ol5lGY2mh7nvYG27mD6OktMu4HxUsx/VMZjrjk2va4 y99ds17niYJB+l4hN9yzungI6OPezJa1lVm4BpIa12m0nU6FKrAutsbW2Jc4N5ka/BK+p4cfUD50 +lzqNOfJNLA5u3cAANZkz3hPvRFOyzodPTQbM22p4IOxtdk7o/O3MBgfFVul4uFm2Cu+00zALiJ1 Ph/tIUK+q3U17K3gNkADa3dERzHHinysgU7BVeLQWNB9m0t2mduo/FRVJeOF6DA+ptNuK+62wlxj 0hW5ha+T310W31H/ABf9O6dgnIfZaXtDXFgLZO6NBE8SuOGR61ddVZm4uL/bAr2vA00iC37gtHpm Zl35j2NdT61dbwHOIc15AiQ7gu8CNNFARMXZZQYmqDn34PTaXbXWWyS4GBoyONHAH8iJl9D6fW9z aczeA0HcW+mOJP0v4K1n2V+s39oSP0YafTB3Axq90t9xJgnXus+jL+z+mx7rIY1z2Bs/zjxp9Lx7 lOiSRuUGhuA7WN0Bv7Je23OFcn1fs+2dzxozUdz2WDjdPssc5tj/AE2tElxZugx7RoJ93CsZHUsr bsyLg7a3QEAvDtYh0ctnn+5AOPTY4Ox7w5wY5zzbDB4QwSZOqdGxuVhIPRgzpF7zW5xaN1gZB1cH HxaNUsnpeXkPtucN3vfJjbJbq4hunHdaGT0G2xjLGXseA0kmqp20BvJ3QJidSoek95p9W0Xhoftb tefpSPdt7yP70YzvqqUa0poW9KuNNT9+4lpOzWa2zpz+9yIVIVPkAAzHELYbgWN0qvcJY8b3y0ON ZkNbu+jpBWj07o2PiOZbbnOrLq9zHit/sYSWnSDz8kfdrqt4XnfVvfS2kn2NJf8AREjdAJJ5ULKN znCsl7WmN0Rp2JHaV3GL0/pORb+pb7Xlm17nbgATIL4a3aRHj3U+lVXUNYLMet+2wfomhnqPY3gP DRunxUR5mujIMN9XkbOj5eRX9qbT+jLeWgbRshpJjj5qjXjF+kTJgaga+a9EquzLMq70ek2+haSH 06ta8D27TwBB1/BULPqoxkm2qqse0t33+m6HfSOs/RKIzkBBxC3j6MbJdNLC6HugtB0Jb4ha2Z0f qfSb2dOyLjW17f3iaw2zU8eJGoWv1qzp2Jj01syfUtkMc6kBobSPzZ9u7Xx5VOuwdT3PF7jYz2ta fpvDwdxB3QBESSkckqUIhzeo/V+7FIAbWeNa3F7XboET8eVBvQ3ghroloLnQ2eQDt1OsT8l0fSuk 0ZbqrqbifTYwb2h4bU4Ena4/Dus5zKS11e0l4DrXtLmwNurvd2kDhM96Z0XmER0cxn1btJh72MJI ADzsLyRMNH8eFaxfqzjvpc+7LqbB+k1xc3Xto3t3Vu3reHcHPOMBcKRte1/taY90CAA74J3ZWJ1H Ga8YbgKyA7Y6Whob7WkAfnRqUZTy0gCAOzmfsHYdsteHgkFrgNsebo081qdN6Dg02tsyarrKSDIa 5u5ro8QdYVqimvqVZsx6hjMDm1lttjiHOIMbJb/nLMFF7S1zSyx4LnMDWHaa6plzXaS2Z80uOZ3K fR2bXWOndGxi708fMbLS1pO3aLB8tfkucuxqq3yJLTrAcC4N7ytQuyhU1tYtFh9+0NOjDp8h4IYy LS2t9w3NY73AtiS7gT3jmE+MiOqyQBaIpx9uhg8EnX6Xh4QiHYwsGlwYwhoI9oEkmePir1bGdOY5 5xxdva4B2/Rus+4NnWI8FHKsdlkvrbW0ue0ueIADnNmPLjsjx2VvC1MrHY0myxjQ5/uDGEBrAe0C fuQvs2M7/COHjpPcafEarUrabR6Nzj9oL3Gdu4ku02u+PbwV7pnRcK+m5l9gDxDqw4bS4N+lB3dz 2KactBcIW4L8Khp9jnmRI9syPwTW4NTYIe74en4CT3W7VgZL632YVRIe32wHlzWtIa4AH978ip9Q D6HWh4ZXY4jdXDt7Z02S7yQjkJKTEDo5I6fkXncGH3Ojs33EbuNOyi/p19bdzmwJI5EyPKVrWUu9 Cu2wsc+xxEl+5zWt09zewRMvGZRf9nbay5o1DmtI97gJEHXThP8AdKzhDz4x3lu/adoIExpJ4SFD 4LtpgcmNBK6zo/Qz1EuxfTrdY9pLLDYWhr9BtI1Gnhyq2X9XcvplUl7NXfmWBznOZr9DvtR98K9p wMm23KfvsMkNDeI9rRA/BBNZHZdl0XouX1fGttOWysgEBr4l24nTjzQ8ejPuvbvpfddUYexzIDWu AYzVsFAZxaTiLyjKHvna0mBJgTASNbg3VsQeY/Bd9i9G6xVXvpqFYJ9Msgl5/rR/VhaF/wBXcwtD bMJ7y0l/0g4ExAcREF3l4Jh5k9l3s+L5gKiU4qJMQvU2/UOltu+yn0jo4EPO3dyA0RP9ypP+pdGX VZlPmsgAlgPqFxkgmR4pfeq3BSOXvYvnBYQUxDnEk6k916M/6i4lFVVl3qNY46vJa0BrvouM8LOy Og9IrqufXc5xr2tE+0WF59rm+4Et05R+8+BW+we7xOxLYu86P9SqutUttZZUwOLTtLiXtkkFsTKj Z9SGubbZSx72B5awgHaYPc/u/wApE8yB0KvZJeE2JbV3XRehdM6xc3FFD2uJM2F5DZGpjTUeCy+q fVluHaPTe81ucQHmt0NAMdpnXREcwCg4SHmtp8E5rIaHRoSRPmFt5XQ31P2TY46Bw2O0cAJ+WqN1 X6p3dKj1Dy0OIggjyPmj78UezJ58NbtJJM6QI58VGFtY31bzMot9Ol5DhIO0xHjwon6v5bSZofoC 6dpja3Qn4I+9G91e1Ls4+wRM6+CRa2CZ1kQIW3R9WM7JG5uO+IJB2mCAPFTr+p3U7WlwxbNI5EHX 4pe/Duj2pdnBIaGiJ3SZ8I7Qm5Oq3nfVHObYK3Vhri7YA5zWku8NSq9vQMih1jbQGFjdx3Hn3bfb 46ojNHuo4pDo5MJlp/sos3Gw7QNJALhMT2Ts6bXbOywENEudBgD4Ql70Ve0XLSAJ1haVHSLMoF1b SQ2J7nUxoOSmrwrHONDCQXkAtPt3QdJmEfdijgLnQkAVdowLMp/p1NLnQTA8tSpfs98tABdu4gFI 5AjgLScwsMEQQltWy36t5vqNqdQ9r3ODWgtglx1hSf8AV3Jxy/1mGsMMOkHQ/BNOaIXDGS4u1Lau jq+q5sEm6tp9I2Q4lrnNn2xpy4ahTr+rVRxn5DsmsFrA7ZPvO4xtA7lN9+KRhk81tKW1b9PRK7MM 37veLNob24LjPn4KVX1fuza7bacc7a43Q4u2z2+5D7xFPsyee2lOGreZ0S22o2Mx3OaSWtcJJaW6 n8Ec/VnJxq3XWYzwwQQXaDXx8il94in2ZPNhqcNW1h9HdlvFdbdzyQAwTJWpifUrNymuLcc6H/UI HPEKGIl5vB6fbnlzatpcAIaTDn/1R3UsrpdmMyt5dWd/ZrgXN50cO3C18jplmCXUlgY9sbj+drp3 /grZ+q2RltrfW0lhAaXCBO0awANSmnmBa72TTyJrInUaJei6CfD+K6k4Zuqe+uujZWYIP844eMTr 5wh34LMSttmRj1j1W76/pAQSeIPZEcx4IODxeYFRPCmxltbobyDEROpXQNrxXNc77K2AWuj1Tq2Q CB8UbPxaMJ7WPwnVP0cALC72ESDI7o/ePBHs+LzTcdsWb37XNiG7T7jOo8oUHVtDQQ6TrIjjw1XR t6Q3qRa3Gr/SPefabA5xny0OkFR6j9XLMBwYQ12hIc07g4T2+CP3iKvYLzra90yQIE69/JTyMZ2P Y6slpI7tO5p07Fdk36iXOewH2752hw26MG4nVUsv6v1sYx1JaQKy95L266x7QDPyQHMxKjgIebxs U5VjawWtLjEvO1vzJWnR9VMq9rn76g1pgu9RpHx0lbbfqrkesy7Bra5uwXtBc2za0Dh/bnsr2N0e zqjbbsqltddpD2uJbWwPr+kPnromT5iXRfDCOrzp+pmQ3V99DRxJeI3dmg8H5KDvqqa3lj8qgaAt 9494P5Fq9Rv6VUPs9Qs9hLZ3bmfTDjtd4eBQ3uwMh7rAWtaXCA9zi4GxpaSIHDfBNGXL1/JPtwc2 36sVsaxzc6g7iQOREczoVk24VlReNCG9wdCDwWzyCugrzKaw7SuWs2teN/5vH3/xQ8S9jzNljZMi S0y0P78EQ2OFJHLMb6rTjiXnSwhNtIXV5uIMhwfurAsEgOHp/wA1xJcPzh/cqVdbclm0NqYWgMJJ Dd28+fh4jhPGewsOJwdqW0rpT0ey0MdSKnTBHpjc7e0ERAGg0R/2IMV9uPZVYXhsOO0iGn3bzI/N 480DzMQkYCXktqcMK6odHpbte+lzA5stDht3O+iWgmNIIcFpf8xaLafUZksDA0vJdDbGuj6Dtx48 CkOaiUnl5U8K2hzuAtCj7GzDtZbW837h6bgfaAPpBwXT09A6Je0OZe/btgmBuY7uXCR4w0hH6j9T +nYQqtbkbmve1obtI1A7yRo7/cmnmYpGAh5rp3UsDD9t/Tm2iCJL3NfJ4Omn4KXUc/pnUT+jxPs2 2sxsJs32dt0kQFtWfVvp73VNrNlbXCLbLmkNqgzMg89oKyc3pmNhW7NzXjc/3NJ2ub+bBn/akMkC jgkHNrbf0jIrvdUJbtsDXAOYQ73NkeBCDl5jsqx7zXW3e4uhrYAkzp4LpMf6uYr8MZFmXQHEEGtz 4e3ae0TytTA6B0LMsuYbNjANzbHO0ZOkTMHXhOOYXsgYzT5+ST2H3KPyXpH/ADP6FU1zm9QqeY0D h7fwIWMehYWRfktstaxtTN4NLN7HhuhiXSE45gN1vtEvJZD22vLmMDAfzQSQPv1Q9pW4enYZLy21 5bIDTtEkxrI3KxjdG6feJ+02yZ9opJdxp3hH34gK9ol5vaUthK6zp31Wxc/a4ZJDS4tMshzIE7nD wnRA6p9XsbAsBbe59RP0vTO4eZE9+yH3mBNJ9iVPPNpDiADqTAnQfGU9+K/GsdW+JaYMEOHyI5W5 b0fCbSLW5XL9u11ZD4id0Tx81Cjo1FwB+1VtJEw4EQZ4S+8RUMRceqh9zmta2SdABySrGT0jMoJ9 amxsQDuadF0R+qTsR1b68ukukOADoe34jxW31HE66ypjsjOsNROjhq3bH0jtUcuaHRfHly+bOqI7 K5g4WPey422WNLWyzbXvDndg4yNoW43oAy67bBlgirV4cNrtvi0E+5Ro6VYzEORTlgNfYKXiY0ID hMHjTw7J45gELfZIeZsocwwWkEcgjuoBnjot0h2abLb8steOd87n9tE2V0MUCpzr2OD2tcdsuLA7 xjuPBP8AfC32idnGra33SRxpIOv3KBEnQQtgdHqdt2ZDDueGgwQNY5kaconUOgNwIH2mp53OaQ0k 7S35cHsURmir2pOFtT7FvdC6A3qt4rstbSzWbHEbWkCdZI5QmdHN2QaKntcAT759sD84nwSOaIQM RcbYltXWZ/1PdjNpLMmi31Gy0NeO2sGVm4/Qbsm70mlk6alwA17SeeUBzEV3sycgNbA0M9/BWOpW 0ZNgdj0+i3a0bdxd7gNXSfFaN/QTi2Gt9rJD9siXCOzhtnQraP1R6dThm23qNYt2zsHuG4xDZCBz xUMUnidiXprrsP6j2ZlVNoyKg20uAkn2lv73hKsN+ocFjRmY7nusDNgeJ1Eyl94ij2S8Saym2Ltf rP8AU1nS7Q3Gsa9ogO3OaC18T48LOx/qhfkh5F2OA0AmbWiZ8NURnio4iHnrtrzLG7RAETOsanXx Q9pWzndFOLkPoFtby0SHNd7H6T7T3VSvBdZugtG3mSB9ycMopaYG2k0bSDEo2Te297nNpYwEztbM DyElWLOnPqOu3idHA6f3+SuUfVy/Irre19MWAloNjQ7QxBHYpHLGrSMcrpw9qm2vfDWtJJOi26+g 5OYIY6t3pgj2ubpr3jxJ0lEv+qefinVkxElpnaXdjHdNPMQHVIwy7OL+zsj/AEL/APNKS1/2BneD vvKSb95j3CfYl2Lcs6lRSy1rDc4F5Dw5rRt/d287TpqRHzVzG67i5d7Tlbth3Ot3lge8lusQ3WYE eap5OTjW3ucxgZS6rbIAgObOwkNPuOkSfjCN1rJpzcio3UCktazedLW7AJbt2ke3t3UXCD0ZDbPq HVOl51HpOdYx9Dj6RaGvre0fQnRpngEo+XmdPpfjZ7bTufQ5z2CHF18bONu1vw8Aqebh9PsfbU2v 0w5tb2vALvS7Oa4NJ3E+P8VRtxKasjbtIbDWuDm8SNXe0mEAInun1B0OmsHVg+miwtNzXOtDgHNr ayNgL3CY8wZ4W63onTbaHV1WOqFD91zAHbi5rZDt7hp37feuf6oHYxqxmNrDZaWCSSS3+VA9rp0B 47onVaczo7raGbB7q3k1yfoNkPAM+OpQ32Ttu2Oq13HJNtljHNFbwQGuDay8bXFrh9IT3nlQv6L1 HMqfN1L/AE7WbntPuDtoDRxrp4Kla5uTcW5FoaIJeZ3ta58SWNbyZ5Cstyslt/oX2hrMoVBxaARY 381z4IjTwI80QCAEHUtr9lZVVgqpyKBa5rwKoIr3OAa4MJ03lup+Kzas6zp7bKKiK6bA+Nx3F7gN sEtj87VshafTOjX9Juue8uaaQXVPaBYLXkAFjRO0yHap8P0up5LMZuJSDbFg2g7mPbMtJdz8OE0y I8UuGOoZnSr66bZsGO+dhduaNOARx8lWuty8hhsNji18iN0+xh3e7yBPddV0npDKTZjTSbXAhzLW EuFrH+xjSDB3d0+ZidMozcjGy2F5cYD6or2WNb9HZG2J0CkGTXZaYnZ5jprOo9Vymeja82jUPc/b t299xOkK1iuv6a6yuovsuL3N217tpYCC57S36W6P4rrcp+J9XqqCen0tt+jZWYssnb7XAEwBKz24 /Uup30ZLsqhr6iWucXBja2anbLDqyEDOyoRcrCpvzWNbufXSbCaXEtL2xy0e4R34GpV7o7sn6vWW UVVvvJnR1Rayt0S9/u7gDUdwhZ7KsF9mRjZtJ2F7a6mNJJ3GHtGhAaZMEkoFPUc7EyLW45DRfXtB h4ZMAS0O/O7bigQSm2/1f60U9Srv2Mc20N2NFbGlhbJlxdrpB4CD0Wm3KZRS7IY/YHbai8NZXU9s uMtMmeC3TlQb1bP6Qaseuuhzm1uYamNFv043OeWzuLvij/V1+NXbkv6tjE+oHPl9UNFo9zWiBpu8 EuAVSDIpupfVz7HX9oGWSGVkUGwsZWd271K2kl07fJct+28t2F9ilprAOhaC5rZmAT5rtek2U9Sp bkObQ1tLXNbQKnXFsSdxl20SsjpHQLL7LG147LzZUdoaWnZuggk9uY01SE4jpaqPdyOndZZhNFzK y/LbDWPfHpVVgQPbGp+OiDndazMm0evkC0tY4B20OjePc3UfLy7Lt8f6mZAqtN3TcVpcBtm5zdmz V3cnUc6rKq+q4ox3vysB0QHNey1sbQOdXDmR2UpmB0WAE9XE/aeRl02UOez0Hemz1HVhrWOrb7QI 47zzKp4nUfs1tFrWND6SNpaPpkO/OXQ5OD0GlzaXtyK3hrXFjnNc2SOCWnTnd+CsVfVjotgfcclz awQAIIsJkNiD2J1lNOSA0pIhLe3Ix7hgPNOZijdY8W2aE2OpdMsLWkbR38VPpeTgYjLHX4YsbscN xL9psf7mN49pABHmugzui9KblW11G9zqwG2PNoDnGQPbP0hHmtrqf1S6QQ1733MD49oduYS0QNAf zfFNMxronhOjxLerVVU4rPsM1tD7Xix0i50bGumJ2t/dQ/8AJmZnG/KqNVT2biwOAJJ+iW7Ww0Hw XSXfUrH6xVUen0WxEOdY4CCPAHsfJD6b9Sek7jTm3lttRLbGsmCTwdzhEBATjuFxiRo85l4vTC9+ Ni1WvDXuPqghzy3b7WwJEbu/dB+y4WZQDXRcLGsDIZDgbdZfZ+cBHgPFdTk9B6LTk2YmKMk2NqNg c14DJbqATE6eSy+m9JwLml4Nw+0H0qi182NeTM2tAEtOnH5U4ZB3WmJLj0XY9dbW/Zza1wawvIG8 ObqW1geJI9x1hSuYz0i23Bew7trHiW7XgQQTt1DTrC1bvq7dg0mui15eCXXlhlgYY+i0amOZRG4N uTkijHst20sa+kuta0ATL7Hn8zcHHTnVD3InUFPDIOT0rFudbVY94awu2brC70XDUulxmD5Qun6r mN6Fg4zqfSfdVbsc722u2chrG92xGp1XNZ1Vr7smq2/1vTBe1wuhg05bI93PzR+n9BZhVNysm6Hk TWyl7XWjvJHb5nRKVfNaBxbNrK6/jutDX1VgvcbLC+o7qrLeS1zHcARtHnqsLpv2Khxfa4OEluxz XExEh42kfDlXbOh2U0Oa8PbZZAZWHtf6p3H3EA8BbnTPqx02zGa611geWS0EtFdljhOxrvLzQM4R G6RCRLhux8TqNzaqsp7WtaAXOadWwNwa34zofvRbPq9fgdQ/Z9OR7nEbTO3v7d3hpqtHTqj8b0cF u9rWb2Daz1GtMN2c6uiS5dHmdcx+k+l6GFUy2XQ8Fr66/EOs8Z1JjyQ9zpa7g1aFv1Pu6TXdlZlu 9ln0g153S/2z9Al3PGiw39Ot+2+nXlh8VOFby0nR0jZZI0meSuo/bBz7RX1RzWvO5tBad9W+Odo7 zABWTXWcTHy2ObsDX7Xlts3P03FoeB9Dy8Sm8Q6bfRNVvu1L92M5rH5VktIrtDqzuawajbW07XN0 glWvqzY3pPVTktyqnVh7m2FrdrQx/BB4H3qU2fZTb6QrptkMqBaf0X0QHd2u3cO118kWnp+Dfgll pOOKdjbKS4Mfk2t1g+PPtPzSiaKjZa/1i6x6vVLRi2sNZZ2c4tt9ske385x7eKp4fQsd72BmfQyD /OHcHu3tEg/eQrFWE63Jvb9iebmsLa62uDq6m7dkzPI5+K3upfV7F6B0k35D7XXbdOJ3ObtDXfyQ iCZbI0FW8pk47cK19uMKLGU2N9QN37HNa6W6vmWnyMqWR0qoBl9HpXvcHOfXW72Dc5rW7nO11d2V zqPUamdK+zGhgfYS9/pENYxzNrK/ifH4pW4br22sbX+mc81lnDK2FrPoPdpoeZlLiVwFpZePlgZF rsJlNm4FoY7YWg7mmAHDx5UsHpl2Q859OM2ivHqLSXv3Tc0cu5kknQR5K10TpdHUstm0Daxrm2Nc Dsd6YgvJJ9x1n+TorPSs39nYudQ2lpbqw7XhrxtAc2wl2h+XdD3TsngDgZXS6nWU4baW1WPHuttc QzceTrG2CI7hXskU2j0W1205m9lTdj2hp9vsc5ojnWSmLLn4rLrbPcHgsDn/ANJawhoDSP5WuvKv 9P6dZ1vPbTkkVQQ8neHOs3H3CvboPopcZOi3hDk19DuecrHtL7shjy0NB3VgAS+wme2nP5VYZ0Wr pfqXXuttawN9EVksrsbadrmEtnYZPHdXhis6Pm2w3Y/EL3F4PputEbgHN1Edue/CyeodXxc2w2Mx vTbdaHPYCY9g+i2ONzvJOjKUuqjGIdunDtyckNx3PxbBW1rLJe5l9jBIYd2jQ2O/Kvv6hdlNaw/Z 6HNbFj3NL/UucPSOmhGw/nfwXMYnUcfF9C7IpaW+9ljA9+/QCPZOh/lcGUOrrNFUO9E2Mhw2vefc 7dvaXR4eA0QPEr0tfN6bmYdrMe9jqQXuMEF4DSAHWeJC2On9CzOkWtstrLiabQzgfow36TtzTprw NVft6m36wY78izHIDWCptsn1A/cNNDJb/GEsnrjW5NH23Dc1oZEB0u0dtJ2g99Gz3TTkJ0XDGBq1 ekjI6S6vJyqmX4r2tY4gAgM55jSF2wzsXqp29NbjvcGbvcySNsACPms/Jxn9RwS1z2NxODtn1GNa 7+bLf3geSubdg52FSzLxrBXW5rt3pNG5rmaDcf5WiEchGhUYA6u5lu6iCcY3kWVtNgbUAzaHaax4 eC5rqNLH3OpsYfVDXi25zTZ9IEjQD6ZP5y6HoX1jD7zRn07nsbDXOgO/RjcRp4fFaVmZg5jb8rEy 62OvbD2Wga+3ieZRjHqD9FSPSmh0n6pYt1b2W1Vm5jWvkN21ulogc9u/nqo9PyDbZSbMfGa9jrRU 4bW2BzR7WlumiwsfMy6LKcTEfuvIBb6ZDhMGQd0R/KChkdLx+nTfkfaK74DmCJh4Pus3N0gEaBHf VB7O3QM3NttsNmNU5sutBa5uxzXaS6OD9KfkidR+rXp41T22V2uZUXbi72OrmS1gngglZ1NeNll2 Xk3X1G1viA697RulzfAccaqhg5uU+ygvqkUmw03WjZvDR7WS6WgBC4cPiocYLbdfj4F9L25G2mX+ nbWCIJA9zWu7Top3npWBkvu9bIt3kB91ZIYZ2ky7jQ9lPC60cnIGM/CHp1u3lzi0OY3n27RtiZPm sXH6rZhsysJxcyokks2B40MtGpESUKB2/NknIkW9Q/63YteHZRjOt30kzYxwJf8AytxGoRundYys /EAptttt9QAOa5phsFx3eHHdZGI6vErc7LqY2q6kkVsLQXzrLmun6MadxKr4uTiYOVluoe0V7A4P a9zbHMdzWz2+49tdEIyMhoStoA9Hd6j1tua05bMq1vpgaVgbm3cFuwmYM/S4Vj6tddxsYOr9Q2Qz fZAE7yfvcuFfn0PLbceksIcBWHWasPxDhAnVbFJ6Lm4D7jvqvMyZlrXuI47kDlEiV31RoRXRt517 usZFmP6hcWsc5ldm0fT19h40EHVZJ+quWKzdYSyzdtqqfG97xqRodBGoPCXWS3LurbRY3JFQA3tJ bJ9ohxeQdFd/aj8CuvHrzQQ6W3B43txg8x7XAydPAoRjwmkyPEEOB1H0XV2wcYua0bnO3iws3biY E8x5ea1OnfWfNvqpoOR6Y9T03O9IFzRAjvqIPgs1n2XErO92OQwCttvp2EsJBce/lHz0VPHzK3+j cXBm+54c5gdupdYdIJdrA1CcARqFtg6N7Mv6izMfRh3B9bvfucGVB7D4a8dwoZDOo4d1eOLjWJ9R rtp9Ml3vMvcePLjRUaMSjqObe597G1UlxDbHFr3MGvt/LC6ar6y9LqruFLHNaam7Gl5LJIPtgz7p 8k0gg6LonRxW9YyacqnfmMsHvshgaGNa8Fzh7tJOog8K39ZfrNcWevRfWPVLC2uC6xm1up14mfDV Cbb9XWVvdaHOcI9m47edQNGmJ/2LNtownClmNkuuJc5pra2HER+87UcwE61F2/qx1w47W5D6LSHb 91pcBvcwbnNbwABJMK6/Of1zFycioGoQ6uloYdSSHOJcPILG6m3F6k9lXTshrDUwFzbHH3OrG6Zc 0AERtWMzrmdjtDftYbvcdzBpsIMbjAjXyR4CUcVF600/WHJrrqtloEsLdo9zWQ6TGsdpVR3Q+r2W Oe7ax+4OBY36WwiCfAQe3KcfXK3pV7mssrslpfuLi6d7Q6JPmq7eoMeKM+7ILq32vL2NP6RjgJ2x Ilp5UfqLJoFx9XepdQv9fKsO42h4cNGTMEvBLSB20U6/q31E5jWvbXYdzmhzmbmhhIdvgkbu8SgV FvXMZ9GM8s9EGwF7iH2Ealsz25j7lPpLurWV5bcdlj3bmVBxeXekSZ9plEcZW6B3m4z315WO+gOd rBra0NdbGw+09gNFi9S+r2V0/Ia3EqaG3MNG2A926NS/dwT2d4Kl1S3qXSHvxrsh7G1tL2ySC957 AiZ1mFZ6B9bbOlMeb2XW3e5wkjZtj6TjzpCEIyHVUpAub+x+qdIurZS5+9h3ks+jW5/t0PBMKX7H 6j1QuDrA9zZBc2HPe10HUyN0aadls/V/64NptIfVWWWOBI2+4WGJf3nwWn1jpRYy2/AzhukvDHQz a5x2kh3j2TjLJ3CKi8tg4OdVkv8As72VvpLIAaGB922PaD+P3ox6fm4d+OcvIbUyp5O4z7H2S8j2 +Mcq4eq5VDdjbmudYG2nhtgcBB9wMSPxCtU4mVlV2MszccsJ3bXMBc9p03QfFMGSYXcIIRV9efms FT8hrXhzr2WADQAfQa5+qu09V6l9Za2HDuaIG17GgNJkES4OHKzG15+C59ApY1xdtNnpiW16Fu10 8RMhateVd0TL9EWNNlzQdzWAsDdeNug1QllI6mutKGMeC/TMLI6E9tmTjttAlktbr7v+qhWdj6si 5tGK1zXQ0O0/RP53AO17rNe7IbdW63MJax7Yhx27id0O8fL7lDItPULH2WWh7XPAc36DWtaIfA/K AouPT+xkETaanpeRiZDLbcgzZvJIY0BhElr+NTM6Kxh9HzKDOE/022na8h3qCzvvMjQGVSxXZYc9 9Dny0kVMcd7Aw/nwRy4ffylgZubig1Pr2Ct5f6hO0ObG4ho0l3yQ9yXdBi7LsLLw6b6rb2sYSA0B skeTQBrP5EPHHUqanY7nVurbW02VOG5wY86n5BY/Uc+zPAf6n84QHMLgRLDz8B4o1+/Lshmcytra ydHgeq9sFu4f3+CfCZ6WiUNNabmTgU4ttjsZ5a97mGqKxr5A9oVjpuTk012end7SSSQyWtsET7te RrosJ+YMQOrszH2NLHNDi4b2Pd7hDm/7UHDwhaxzzfbWyuvbu9XVzfpEsaO57oY5a3t5KO1Nnq/S ndWyy82kv2794IaGRGpbzpHZa+PTnY2MKDmNbFgIL54cOQ8xwZlc19nb0+zdTfZYH1tDpMtcbB+8 7jxP3ItENpva7IjaQ9rXbbNxnT0wfo88I8RvdIAIbz63VuFG97WNc8uurLfTBd9IB3MfRVtldeXh W1vLiwBwburafY4wBWT9GNNFkZFxffUWW1gElwZ6eysu2gAWQY8UzmO6kSKsj02uYC5rW/4TbDg3 yKFkKNFm/ouFiuoxaXv9fbue4w0MqJ93fVzeyo4PS8puRa2jKDGUucG2E/T02yBrPtKt2Nt9OkF7 WmsOZZYWj6JEgAamQZ1Qun5GSMfIYWtJ2by4NaNn0WhzZ7+P4J4ySI0WmI6ttvTszoz7MzGdQ8uc 0Q2z3vDzDXRrE6/egfbrc62OovdsLWt2MgCvUS7cO8jhPjuxa8+u9loe0sduDmhjWOcA2YHedVY6 T02rLuDDtdWXu3lrNAG/RKUsoulRh1TdWxabchrPtl17hXDA1wa5rSOWgxOiavG6c/Coa57zstO1 stDmB43e7xPkoZLcIZrTl+pYGV+npo3QbGOA7aKNdeFj37bm+s0O3CwPO6Ihu0k8fFI5OqRAs7sF py8ltGQ/He4hm0EBjmkTo6B7eyjk/V20UjGZkOubtcXMY6WgjUn3cfJXa+r5WTeTWK3Othg3aEtZ +aQJ1lafWbbXY9dlgbUQ6XtnaXu+i7/ooaEE6pNggPCdN+qb+o3MqD9oIBO4iYInRbF/1Vf0Zjnt yH7ag1zyAJbu0iHfhC0sO+1+S51FlOy17QC4N3e1vG34d1odQ6yX3HGvZW5kBtgBEPnXQ9oTjMGP qJWiJEvSHGddj0YootdjTc6Ina6uwgAOO2dCOVk5oONcKbcVjfTDWuDHSbC7UOk6kd/Ja1X1a6YQ 6q2p4c4y1xJBLe3iFZZ9VMMOY9xftI2NLxujt7uCPJNM4yFJog6svrBkYX2PGeQx7qwGw4tcA1w4 +HiqGR0DL6hittb9kYwNJDmkNJYRw7lG6v0//m5V6TMSm2Zc2xwLva72xC5V2K+21rZLA6JaAQGn vAlPIAl6t0A+nR0sGi2uk2C5lRsdsY6txlu0ate0Cfh3V/AvNNV7L3+o61o2PJdvadJHtRfqxRVi WfrFbXBpIn84/ET2W71a+l/p5GKwC9jvbxtjjXsoTIGzYX0QQKLi3YnSbf0X2poa2swTu3F/8oHT 7ldzep4GN02mz0anuLSz9IDo7vIAmFzOT1O2s5bH49Zfa4HdH83B9234oZ65djvyHMcHNez05eN8 tAgNE+HipYUOm/1/NbLXq6fRL3dVteW0YTjVBaC4tkE8Nk6cTwrX1j6u62nHYaWbTDmgODyBMbXw FylFOO6it7sw1vBINYZJbrua4EdpXRdH+slYfjeu5rzW0tMtDW7T4xz4pTEYhbAmRtBnZGSxr8ii K6y5psZ6jXAh0tB+gI44KyKrntczI+zsd6sw1zWbXtb9LQREartrcvpmRiZLYY57nGC3z41K4/Bx 8bCyvUsqN7Ggyw93HjjhNxyjVFdKJ6NjLLPTyL6tlewABsN/TB8e1pB181Us+tLraqq7K6t9RHtN XEH3DkfOVp5H1ko6ja2vKw2+iSHQwgP3gbQ4O7earjqPQGPcfsl4cZ/SGyXHcdZ/11UsYRruslKV oqeoXfWB1GITTWwbn1k1itpIn2uc6RA8Fn5GfmOD8ekAtDi4uZW3dB0hxaPo6cIV9odQ9tIYKi+G sJmwAah/h5Sr3S+r5+BYXVlu97TW4uj6IEQZ0+aeQBrSBq5DBflX79peZGgZo7b5NW2ya+mG4v2u NwrLGsG5se5vxHZaX1b61ldNaaR6QbukOIlzdxg7I5Wv1LDb1K5gxq4bQSLQw686vaFFkyxOi+ED Fo9HtvxWZL7xXc2todYHANe3eOWEaFyrnMwMYWm7EJsZYyGOG0ua8aNcQCCfuWp0/DpGY8fpDjAb iXiD7+7vH3LH67i0/bGnFva0NO5osYTr5mDPzUUZRtfJrWdLz+tMBbgRtc4Na1grgT3d+dC6eroO JjU1PuwCPS0cXObDiRpPlKzeg2dVry6y/J3VOiSQ17SD/VW11LDt6Sx9YnIFjTtExsd+8pDIEX2/ kFgHqpXUOi4jMPd9jAJBdurO9w001cJhavTeo4bWMxHOY32NHpk6y7yIXnPUeo9VxGTL2NsZB/dc O+3yKzG5GVZY4va7VwFhAMifzDPw0UmORB4gsnGJHCXT+s+c/pmVbRRsLR7d4bzru17EhR+rdeV1 /Jimuhprr13CGiJ9xE6mSjdcHTenDZW2y0vZuG8bWBzh+7A7cELJxa7MZ42+rU1wmdhcS2Jn2xIQ iI8OyTI8W7ZzMfL6CW1ZOLU8ODtXNn1ATzI7Dsq3UPt2G2ux2OylsaENgObqANeeV0AfbnDEsc22 7ZLpIO11Y4DRGnnqpfWfq1nWq21BrK2M+gOR2BEwmjJG15ga0ePr61bSwMbXXIdu3FvuJ4WrjPz/ AKwMIqxqz6X6R20RoPn5aqlVgOsFpaWgsEkdyJ7Le6D1nJ+r7HsrpZ+kIIe8ceXwKkkcd7LIifd5 zJ6lkvvda5rJLw4t2+zcOParrGdSyQ/JroaG2+wlrPZMcN8+62ujzm2PNr6mse79INNwDz7oB8Pw WtnOq6ITXjZMVscywcEa6bgJ1I8FHLL/AFVwx67vMdD+q93V8g0ucKrKxPuJB0/IszqjMvp9j6HP Jhw1nu393wXbXfWH7Dsym2U3WWEl7dkOZGnI7d1Rz+tNz7G5dtWI+NzC06Hf2J7/ADRjkN2UHH0D y1XWXMx2UHHrdtOjjO6J3EaeJ7qJ6i5wewUt2vIMFzoa7ncJPK7anqRFVd/2PBaLAGh4aTtd3BHi ruZTlGstdj4Ja8lrXtrLgZHbaNCE/jhrp+a3hn3fOsrOda82Vfo97Yeze5wOvB3IDs15rDGsY0gk l7RDzPbd4L0/pP1cpfSH2VY9zW17XQCHu13d+Hdlm11Y1mZjtdg49dfqPaQASTH5UveiANFe2STq +fnIss2lwkgmCSZ+C3/q5hU9UvqrfiFwaDuaHuG/xPl8lbzMGmzN+yY+MIF5dI9znCNWdh20C3ui dRFWaLKcYMBlprZMjaI9wPBQyZRQpUcR1cDreJi9NsG7p5ra3VpLyHkz+cR4dkDp7+mdVtqoFDaH F+5z3PPpANHEeJ8V131j6vjdRxP01bfWa7RpEkMH0iVg44wMu2y1+GBSX1jdx6bddBt53DumicR1 XcBPgh6q/DxnW1NppuG1rg8Xbdm8xH0ZcfFQ6fb0444tONRuDXfozadz3tgD8zkzpqr/AFno/T8l tbsC6qtku0tZpLtPpAfd4LJu+rHUMr1clzaQAJGxvtfA4Y0BOBx1qslKXE1W9cxmkluEGHuGWls6 zrA+5aWF9c6aPc6i+QZ2+u4sdPYg8QBog4HTcmnM9cNxpYACCyaRIjUDuJV3ov1Kt6tvfuYCJk9j PEIE4ia3P1TU6stn/wAcXH/8r3f9ulJG/wDGzyf9Iz70k7T9z8Fun734vmO4juVIQe5VvY15Ic0i SSAICu/YKjgi9zhPqbWsgbyzkkkceGvyVvjYKaODaKrA7ePaDAeNzT8vHwWli9ds6bQ2qv0nbnPL nFu57muGyHz4DgKOXlVgBtdLmBzWiHQ86clpjRXsTCxc7acgDxcWe3tDWvdBDT8AockwN2SIPRwr su3Le5z/AHEkGYA+jp2Wn084XULy7OsdS2DHps9o00EeCm7oubivFRbs3QWOB9jpHazj/amubk5u Q+WtZZsLLNrWsBDBDp7T4wkZRKgC72FZ9XenDS117N0uY6vadAQId+Vc91KzBzs+MeaqHuABd+YD yT8EW3o+f0gsadkXEsDXObDtwB9wnjgys2jAfc1xBEtIBBOupjTxQEYjW0mUjo6pDsK94ostyqGO Bc9jntY7aPwhavW+qsy341lWHZilggua0h1j3CWiRHPiqOP0Lq+Jj221Piqo7iWPBYXeUclHso6v 1NjL33sdJYGs9QbpI9p29igZaJEbNpOms6O7FdfmXWMypdAbuLg4cOJ8fmsYYYybXvdfG7ca32e3 1C3mTOhW/ndDzcG6vJux6Lz6Rc6lpgbQI3ub469u6x8qo+jTW/E9O0B1nqOO31K4kAA6afeUAuID 0uJ9TbslrMvIuqeHM3HeS/2aefZc51jGxaA5lF+OWGwwQwi2ONf5KbL6meqWA41YpYxrAWGyATMT 7o5PKy+rZbM3IdZXS2kaDYwy0RoY+KOOMuqJyDufV7qP/N+yp7X4tnqtIIcJdVJ5c6NCr/1n69TZ XjsbmNyRXtc5jme1zideAJhcnl5tWRRTUyhrHVghzxO62Ty74JOzKjiCj0G7w/cbZO4tiNkcQn8J WWAkyOt3fabMjGd6BMgCoenDHdhCuXZWTfiHKdnB207G07iHNBEF20/cqNN9LMSyo0Bz3OaW2yZY ByAPNG6Xl42A2z7RjC7fWWtkxscfzkSdEVZ1bfT/AKxX1YV+HQHF17ffDdznOn82NQNvxQq+v04t baqmbGu2utawbS59f0dthcXNnuQqXTM1vTMpt7qy8NmWhxZMgj6TdVStIe4kNiToPBOFFbs6eT12 3JobT6r3Tq51hLjXr9Bhk+2OT3Q8rqOTWRtLwxxDg5zdpeIiNNNvkFAsGdVTTjYp9RoO9zdzzYSd NO0K30a+rFuczqQc6pgc303F2j400HEJWndDh20Qx9dbHXmzdBH6NjBPtIfoV1WH0XP6vS4iur0X 17arS/2sYCS6Gnue+mi5d/Tn/ZH3V45e0PkXAn2tj6Jb/FWOk9R+yttY2x4LmFrHNLyGE/SMN8fo pkvUuiAC9fj9J6R0T1XZmTXa5rWzSz3FhB/Mc90jVQp+vHTKJ+y4npA7g61xD3s3nV2zWdfNcXnW N6nabGVClsNbtBJJdEd+5KWDUKLnVfZzc9zTXteIFdzjAOh7eaFaK6vXs+umRm2jfeWVMmQGDfY0 yWvImB2ESs9/Va8620OyLXVEOfaQT6jWho9sfRIJ9vc91QbQzCwcnEvbUbRY3Vg9W1vHDm+0D58r I+x2W7WOa2na1xl8tJ/OEz38E3gEjqv46Ggeh6Y7prqa2ZORaWw+z2N91Q+iGNdyedeyBRk0Ydlr qm2CykFu76JpqYdusTuc4HtwVgDGrsLG02Oc4tE+2P0h/NGuvxWti/Vp9h9B+XXXc5xaanOge0Tu c7iPBEwiPqt4yVretNefWxcY7mtBe+xxcCGkctnUDjWU3TbMPKsuzOomyyPc6uoBgO48l3h8Ar9f 1CydjbbMmllJbuNpf7W+XmfJYN/TQ+01Ylpt2glziPTbp4binRApZxm271Hq/wC0PV9HFrZW3a5o DQ57Q3Qb3u1cFZwuo19KqsLMKq5zGtAtsAgA6/QJ93ksDGxLMi0UsfDiduphsdyXcQm+yS58WAtZ EuHHuTuCISJl0A4ZgsybGhlYtkhjRPu5A9wMeAW7l9Qpz+l0spqaKKngPc6PVDtdp9p9wgrl29PP 2cZD7Ia5+waE6jV33CE37PvcS2qbCC0H05e338aj7kDAHqoTI6PU9S6th/o8nArbWAPSsBEuc3T3 7Z/DsqTbg3db67mtseWkgNNXpfSDfSDidXduFgPxLK2h7iBLiyJ9wcOfbypDFta4h/sAdsLncNd4 FAYgE+4S979WKcXqby3OO6tnsrJmP7OsiVD6yY+F0bIDS2ythG81MO3c9p9jvLTXWVxuJlPxf0rL fc0+0a/erfVb7us5jW25XqkgD1CDExOyPEcKEYaK/wB0U3c/qeLknJtfVItAFb2uG9pEfSDtf63i o1ZeJ04UubU22y1oLnPfudX/AFezXHmTwsBuG59Rtnh22ACTKJhYTMq9lRuYwOBJe7RrY11UwxCq We49f9V+p9L6ZnWZdrzXtY0MbO4lz+SdvMd5Vn6y9RyfrfcKcGt9lYbuhpaeJ2nynzXEZdFNVjhV YS383cCCRP3I+J09+19rrfRa0SHGZcSCWgAfvRykAAK6I49Xp7uhZ2VcytuK5mO5oBDQ1xY6ALCw EmHOI5V6romTjuF1mK11WNUQ0W2VmY59QCee0cLiW02ta55c4FsEjdqATHj4rVyLum/ZMdlPqOvd /O87T4AJSGMdCujKR6uj0rKZiGy1jvT9XTZWQQ2dXnc4aaaCOFSLse3JurJG1zTDrA0sDvzjWG+0 Hb3JXQ/VOrpDsd32kwYOj9IHcyFyfXWUHIe2t3BIA4EeSqwJlJmloGdvU68yKrPZVUCW1udvYXNH sHAdt+fJU83qJy7fWk0uNbHBj3emPaQGbCBr7ZOvisqrp7bZLrWDa8NLZ1M8lp4jTlFu6O+42+k/ 1DWCYmT6TeCDwdPDhWOGFsIlJ1frV13G6vWLq3v9UbA4BoDHDnV3JLdOVzdueciHWElwJLi7XdKa vENrLHyAGCdTE6gaeJ1RbOjXVzO0foxZqYlrvAHkqSMYQFLJGUi3HOqb051jLW7vVDXN0D9pE/2h p8Ast2bIIjkk/wCoSfhPYGEQ7eCQGnc7vyBxwkcUubvaBECT4E+JToxiFspEtvB6saXsBBLGkktB 2k7hHIVjJz67WOfXZIBENc3UACAA4kn5Ki/pV9VFeQ5n6N5LQ7tI5B8OUrsGzGDdwYTYDDQdzgJ5 8p7JphAlInKnS6N9Zr+k2l7HEtI1afon5Lp8366YHVgNwdQGt97QA5t08t29j5rmcHo9+T0259eK yz3A+puPqMa3nazuPFZ1+HkYTjVY0tJAkEawdQo5Y8ciyCco6vUP+tXTcPKsGPjepW4gB75D2NAg bY/isbCwL8xjrah6gZq9oM7WzEu8As44bi/YDPOsHWBKjW6ymQxxG4QYMSPAp4xw6LDOR3en6fWO kdRZdlVkspsaLCw7mtnSNw8F22ZgU9WezJ6blt3tb7WWe5haOBBXk1VbgIc/a0xIn+CvBuR0d9dl d215AeNjjuaO0+CYYiqXRm9H1z6zdUxSacmhtdrSQLAzbO4ETuHgDpCyLuvjMoLcmyxz9vpSH6bD JLi3bB18+y6Lp/1zOXj+n1PFFtTiGl4EBzvPtu76Qo5/1J6dmXuqwsjZYWb21uIeHCN2jm/xTeCF rrLz1PVunYXTH01NsN9hc1ztxZ7NNsgGCPLxVh/Xulvx68UsLazte8NZMWNEaOJ3e7878Fg5nT7c R5rtYWuHYiCqjmEKT24y6rOOUej1XSut9HwWXuurdY61gG3aIZuOvpzPCo9V6/i5RZXjVuqrrbtb PudqdY10GnCwCmgpDl43aDmL0nRs3pBkZU1uAILwHP8AV3SDIn2rUzuodIxqPTxMqdzHVn2vOxsf mh3jx81w2qUoS5aMjdlcOYkA9Fb1SjKspNFz6rNuyx7wAHTqXHaDyT3Vp/Sce+5hry63udPqWAlw DyfpfRETOkrlAruB1HI6dv8AReW72ljgOHNPYozxdiiOTuHvG9I6UxtQsuqNglonc1vtJA9uo2gq tmYWB9p+zVZNDKXGXVDe7c8AtnjnwhVW/WTDyumXNvZ+tHaGOaA2A0R+Tlc9i9RFFgddULmtBDWO JgEjnSOFXhilbNKcXqf8nNHqN+yOBJaHue5r3aRqw6j4qtlt6UMS5z8suf6u4MDAX7z3DtPb4rAz OrX573Q1lbXADZW2G6RHnOiI/EJxJse8OrJGw1na3d/L847p4w0dSsOS9g72Vj9KzMaj1rxS50S0 VfpXF30XOPG2PBPjfV/pmM95dn1FkQXmp/tPbaeNe65l9r2V1g27g6JaJ3MDSQGmfvC28r60h2Fd hU0lrbSyXPf6jm7QBpACf7ZA3W+5bZx+m9B2tFnURuDdpLatOfMKDPq70q6RRm7pJcJYQW1tB9zj GnmucN42QH6xtMN+kAdAfhHKM4zabXQ1ruWUn6II7T2Q9sjqrjdOn6v0uY677TQdrdzQDo4MdDtw 51Gsd1XeMP021Vlm73FziCZ09oBmdT2hVcbKvFhZihxdZLYjc9wILY48CiXOdQ+m91L6i7c7eCZf GktkdiiYnurjDO2yqkj07GSwAu9sCwyAWiDq0c6omLnil/6PJLG+rq4A+o9upBdrx2iVl2u3RtGk mJA3a+PihtsNYI7OgHzA1hHgCuN335Jya7rMjIaHFpJaRJ3TECPoyFcvdg2VVbCw2W1bT7nw1xOt hMaRwR3XKeoTIkgEyUY51hp9EkbfgN3w3cwmezSfdd77G1vo4tbmut3uYLAHEbCJG0bfmHLpOk4R yG2U5t+O6wlsBzxvYWu7t7gwuIb1p9LWNrc8GozS4HaWExJ8+PFNd1rJycj7S+wmwkOc6BO4eGnk EvZB3R7h6PY5vSasbJdW2+hnplpaWuAJcePZrJARul13XZLKH5NRMNIDht9vMgNjw4XLbr+mMFuQ G2NyGOc2HzD9QHEt4InhBxupNttpa95b+a+06zxG6ezeE04Y3su4z3fRH9DY9p9bLrDfUE7Yb7hO 33doWZ1HpW3M3Pz6nkEDY90SPCONeVgO+tORS99d1NNoa4kAtENj90sI0WczquLYLTk47nFxJrLH lvp8mNQZGqcccCNlonIHUvVM6FTlmtn7RaS4kva06NFfB57eC2q/qfibWvutsJghvDNxdydOZ8V5 /d1Gh9wfhG2sCsNEhpIfMNbuH5uvPKJV1LO6G6yuyyxrmva0w6WsI1On0SYTRigNwvM5Hq+gs6ji dKfVj+hY60EtDgwmPD3nnwWF13K6rnOb6jWU7LIY1w7WgjeXfR0hc1Z1fMfYbq8xwa523e47TJEm Wt4Wr0vrbxi7JfksYRLSCNs/ytR+CBBjGkgAloO6RndZtdY5zHHYCC0ANO2PYAAIhVb+k341gYXt cY1267T4LuaetZnTHsbbiGuo2Q0tYHlocNI4P+xauLdTk2MdkY9bLbJ9I7Z3jxPgkATpYQRXR4Tp f1byc6XNZO0SVq3dLyLckb2MY0gOc0NhgEeXiuowMWiqwuqa5jS4sf7j7njXTxQ2HFflFl4DSyQB 4xrwmDEZVZXe5WweWtdg0uFv2drXM9xrc47bP5LdPylV+mivItua3GYRYCGF3DDzyO66zqPSulZI 9X12gdvcC1Yb6sTo4OXhva5lNgaXufIe+dWAR2RnikFQyAlyxg3DIZW8NqM8EF24+MAFdjgtdgCp wpofLT72HaHAn+V9yx+o/WLHDa77orvc7cHNJBaxp2lsfvfFZjuqv6fcx9j6barQ7Y17i07HHQmP vRiCNkSIO709ebTm2WgU1je7aDHuZpG7jhCy+gu6azY1zXMtG1wgTtBk6lU+ndSdi4jn3miouYXt Bk+uydAP9is025xFNtF1VrzXu9MGXNafBp5QMSRrv4fikSF6NfC6divutPoAtOlYd9JvHuPaFq2v b0fbVikVgwXuOm74Sua/51ZTL66t7WvDjDRWSZefomOVF31nv6hnV1vcH7XRt2OaZBkiIlNAMY2N 1xIMqOz0xyen9WebHVS9oa3V0au0GgXOYvQcY23MsuDS1pIERDp41GqsUdQxM7qD7m2taPc9oYC5 0t93G1bGL1Hp3WKyaNvqiXOscC3Y7mdw/BSgcZs/77GSI6Bq9M+rIxbH2My6/oyHBomOQ4Tx8Vi9 W61ZZYwPyN4BIIE6AmDrHcKqzP2WE1Wvf6bt/p7ZmDDiR2Cn1BuL9mtvIPqPdua1o2+lwX72c7RO hSJBFBQu7S4OV62PZVXQJDw5tm0uho0I0C2sbqPoWCmoMfugh+06Ef1gsbofUsPExXxluZY4H2bX TodfKCEfqmU3DqZczcBY3eHbSZZMazx8kyWLqF4y3oXVPWPt19VlhDNkAgCe+pbpwt7qvUW1Yz31 vY+BqDGrSuIwM7CyKXWG+X1gktra/dtmPxlbdXWMfGwmuOO+ykv2O0O8vHAI7J2OcomQP6XVbOMT R7Oazqxyyyq97TUHtPvgRr2PMeKB1nOw6MwW47mAVQWt1sa49/JPdVhZb35Iurqa0Cz0ntd7dY2l ZHUH4rm33C2sFmwhtAlrg/zPEd1EImX8WSRD0GJ9Y8ZzG2BlAc13GwyS7sAtLD+yW5XpWBpDvc17 fbo/WHCfuXn2Bdj3xusLIJ3Peya2tI01HcrosTI6JTeQ29/ptr1fDo9XtqO3cInHIdL80CYIbPXu iMpynMY07ZH4/wC9Dv8AqaK7mMbY0tfH0jtnXUR5d1nPzK+p5LWV5ToEsa9zDrYZ2hzuNex8FLJP Ufs9oseHvYT65j30Bp2/SmDPKAxUSo5draub0k1ZltNVchjoIBBgTpquk6d0WnFZtsra/wBRu+sj 81w0O/4d4XHdWdjY9u3FyX21FoLn7S33x9GPJa9F2Oyil7OoFnqNLnNe/VrgTpw6CdJTzhkVgyi3 f6r0SrIsFjHUsDw3dBhrXcEt8fFR6ac/pmW43VVuaIpB9rN0fQd/tVW+zD6hhGm3MoYfp12OLt0e Dfa2fNcZl3NqtLa8k2N093uEz8Uo4yNRok5LFF9Kyum9MtDMnKNYaP0ZYAB+lHO4tXHfWzGx8rNF mMawx7RAEAAtEEaf6lYd2TMtbfuaOJkax4Jsayre02v9s6xzCcY1sEXZ1dzB+pd+Vj/aRYwMABP5 23xBAVrF+q9Ppeq64WMJLSGbmODuwgj5p2dewqsWyui2wA6BhIG7jlDwOo5D8qo4jyNonbY79Htb 4nwUXFI6G2XhiBYb+d9Q24wr9K54cWlxECQxvJHHCF0XH6jiB3puhtwc02OG5rg3zQesdYzi97sl jmOA2ggnYdx12mY4+9Z1f1k6hQDQHuI27A13ZnhHiiRxHQoiQBq79nTc+3GFT69vpu1cfplruAex b4KfT/q5dXeBkP2bTuG4TqOWz5hZ+J9Z87JLqbXavAgn27Q3s3xlbHTOvWstdY4G4lusiVDLhjIW yDilHRq105AustND/TrBHscGuYOJmE7MxuZlCltj2tNZItD+CBqCQPDlRt6lkZYupYQxtnugAnXw MTBWRl314foXNI9zda2u1aJj9JHO4JYwJKkSHW6pjB1DMZ77XMDC6mG7m7uSZaT/AHLCe37LvoLX bgHBxczxOjtdZ7eSJkZuZi7amvOxw3Na10wD20107Arb6Vn9ObjuGS1zrNmhI1aTyPvT7oLatxrM Sb2MyHbwXtZshweyB9HUafcugwvq2MqjbbcxjmDRvBh35rjz5Lmbq6t+9wtEkFriNHDvB/ItnE6q yqm2uBYCPYXw1wHJ1nlNMgaXAEbMOmPyem5jq6CKySW7DqNfiNFfwulWOyGDNc8tIOh00cZ/KiU3 dNfSL697bA4bmnX4lXusdZxshjCySW/JMN8Osvp3TudB9ezDKwcWjLr21bmbtdCS4nkeapdTxKsv KLqMZxgGGxDdORthAzOtmtw9IOAmWyZbroYVajq9wu3G1zTMiAmmQ/FIiQrA6JZkvLmVe4GHjWfi oZuIfVbuYfVBJDQB7WgaOP3TELe6T140PcbDvc6ZKzuuZbL7TY3SdeIOvKbxxoEHVIErII0S4fQG 9TpMuLaQ7cWhg3tJ+lDueFh9RxMLEN1WG2xwcNdzAYYPpGeVq4HXzRW9jLYOgA09w7yVk51omwtL yXEho49p8Y/Ipo5NgsMNy134r8V9dlTmur2E7mAPfW0aS9vY8a/crnR+rZeHUCbHNG4EHbMhzvc7 ceFnVlmO5+p2u9onT29y4A9vBauXRd0ptLamQ29o1cQWe4/3eKkkSRotAFvXWHEya3vblOLiGu3R o3tJjhZeT0FuQGPZcMoNe8kAD88d9RqsTa/GpvcQQC8NhhljmiQdRzBCr5FtzAyK3hrw0ufuJDh2 8pCaJgk3FXDw7Ft5eLm47rchznNewtLNJ9PZ+afhPKrsyczFqD3OewvdG4GC/aZcHGdOVo/bcyn1 GDL9phrPUaNtlbtJG7iFQvyfWcx92QHucdQB9AACCe0lImhokDV3fq/l4+W237U8ixgLWBxl/pjz 5jVZ/VMfJAaxhAbYZFTRtBbrDnQfuXO4vVfs+XkvdqSPaC4kAgg66arWq6wer2+jW4eo46EuFYd4 DbwI1+SUsUhVBQkLNlo9Vt/YTxiuyHFzdNpkOqOsiNR35C1en/XDD6Z02KXOda2GlzgS0TMbZ8Fx /wBa67qM5zbnNe8NbJa7eOPEIWKan9Oydz2te17C1pnc+ew+CtjBQB1trnJZp7fD+vpycgVstEOL W61c9ifL4LtbGHEofa4t3gCCwQHN7SAvFvq1ZQzPoOSSK943EciV6dX1npNLixvruHBJPtI/uTck eA7/AGlMfWBp9gT/ALdt8Py/3pKP7W6L+4f84pKt7eX/ADkf5fRmvH+4fw/i+TM6jWx9rxWDvB0L QQ2TOkob831K/TLfbvL9ABqfOJjyQhW3xVirp7rmOsZqGQXafRBMAlaPpDTsll+1Hes28N97QADP EDaOI7J6uq20MfXWAGvjdpzCs0dCsvNTWh02iWaaOHkiWfVy+hodZDQSACQeTx2UZnjXATajeqZJ AaLCAO06aLa+ruNZ1i8Y9t3teST/AFncu4We/omRU9zAwuLG7nQ0+wfypGi1+j4vo1Nu3xL4LGmL XM53NnkKLNKJjoy4gb1TfW7pTuiWiuu0ukSNfog9gFz+EXNfG9zZPZavVHfa3FzmWbdS1zyJ1KFg txKWk2CwWNM6N3CB4pkT6TQXEerUvc4HSqT0xzzc4OI3OAOzcR4tC896m1zbnFj9J0g8Ls2W+rh1 ZdleytzwNzXSY4JLVn9WyeiG9xbW8gR7p2B3jDdqjx8QOy7JWurx9ltjjq9x0jUp8it7K2S4EOEg BxO3tqOy6Dqp6JdkU/ZXOYxw/Sbp/RkfCZTZbeiXU1Mx3vFjZNjjIDh/JlWTMx6MAHF1eXkgpiC/ Urrel9G6PnstdZe5pYzfEgadwJ5KysjH6c61rce1wae9kfwSGbwKjjO1uXXj7iujxPqXdk4f2uQG TB8U+B0TGyA41ZLXlpEwDtE+Llcy+oHpjhhuyWxMODSSxmndRZM0jsCyQxxG7D/mW7CvoY57XeoA Q0Aukd5haX1p+qWJ0vEZbU5u4DaA4x5/NYD+rOxybGWO4hrjILhwdv8AFQyOsfa2w9xcA1stJ5+C aOM60UnhHV5+2otJmCj4F7MZ270GWOH0Q+S3/N7rUvOJbjtpooc6/cSXNO5paeGgeSr9Kxm5N1bd Jc8NDdS6fg3srXGa2YTEXumyeuZlzK2EurZtIIqiqTJ19oCzxlVV5Hqenvbq0tfDtPH+t5ldt9bc jDrxqqfs7qbIG+W7XFvjHcSuS6bUGuGU+kvpreA+DzOsfcE2MiRqEmIB0Xy+sOtLiLrQ0NaKqnHe xoBALXzA4E6BVaM1mDl76rXisODwQNridCQBqB5FX/rD9iy4ysMBjHuLRSPpM2ganyKxjhv2NeIO 4mGgy/TuW+ClAFahjJo6F2q/rBRUHbA4VusLxU/9JtdESTpu3Sfgq9XVK8n1GPf6VYYXBgkte8Rp 5Exp+VZrcSWWWF3tbABH5zjwIMGOdU9PTrrdkMPv+iY+lrGiBxwGqRkk6mJ1GugudXcK32vMv2+9 jSeA4zt/FSr6vi4jA+lm60EgPtIsdvc2C/4D83nuq3UfqzndMZ6l9LmN0EnxKpX9NuojdW4SCRIg 6c6eSAhCSpSkG3VTVTk17sitzZ2ucAYHaYbqR4Fabep9JwrbLW45eW6tsdtj1AIbtqmNvcySsLI6 a6hzaoPqRLxGje4hwOojWUBuI94LtAAJ1MTrHt8SnmESsEiHbc6zqp9e7LYS5ptNQkDQ/Q2t0BIE 6cBCZoLMxhqrDXCstILq7J50/hwsTa5p0kKbaDYxzi8DbENJ1dP7qPB4qE3RpyXU0E12VMYNHMI3 eq7x2kHt8k56Zdfjb2Ujaw7fWbJ9V1hgDU/kCy66t7mtLtoJ1JmGz30R22vNb2m9wDYLW6w8z28P FHh7KEu7rYfUasHAuxramvcNdrz+9oXNPZwEeKjgZuTa8sxKnBhoAubW7Y12wE73u4GolYBaUas3 MreGFwYYDoJDT4T4o8ARxF1cbrePVVYx+JXYbHSJ9pY7WC3mUbpNVfUWW0Nr9R/LREWk7ddoGmhG v5FgNaSVsP8A2n0ACol9XqskAcllnMHnWE2UQkE0zpudiB2OxlTSC4uNpEl1cnd5GPaBKNj5np3y 4FjC0XCtx1seQJcHO+iXR9L7lHG66Qz0hg0EBrWuJYTO0Ebnn4ncfMLS6azM6Wys24QyKi7fU7v+ jM7mz20/O7cIERCQS47i/pzA/aabS/c2SfVa149rjI+jE+aVTK+nY5NrG2Ourca3NdpXPZ38ry7K 47FzbrXW2YzmnIsnefcRJ1a2e2vdWq8RvVG4+HTj3VeluJe525pseZDojRCUo1uqINubkdMPTqa7 nvLqr6i1hbDSXCCWua7XaHcnv2W11nEpxum4+Fi7H2srN+SWuDjBgbZ7x4Kjl9Zxcp1ZzKXusrZY wgECuYiuG+R1PisP1o3e0agCe4A8CiIkjVBIvR2ek4zOpttsvca2Mr9NtrxLGQPbJHc8Qrn1R6dj 5+SHuc1m1riSSA1j/wA10H83491i0dXc3EGHY0uq9QPIDocQJhoPYSSUPAym47tS4bpa4jUem4Qf b3KbPFYXQnq6uZivpyL68Fzra2gtse3kt5f5djHkqf6LIyWMyTsrZDXFseoGzyf3nIvQLqKb7a32 bRZVZULDO0b4aHQBPCfqfRRjbLW21y9/DQYa0GA4acaTomARiaK48RalWO2y+ym1hDtrgwAhp3j6 M+JPgrdOHY9jrXM9Gz1hXJIbQxse5rxOir5WRW59VtLYtY8lzpJ3kEEP1jkzoidby6Or5VmQ2ai8 F7g4SDZGobt7E8SpALWWWOP0v7V0+y9rC01u1cXe1+ob7WxyNw7q03olr8d4FNjrQNwe4bazSB9J m4hxJ/CFSyMM5FrW1WeqXAS6C3c92p0P3K11DJyMVtFNwey+gOrl4+jU/jTykpEFILVvoppxm2U2 M3AFzgCW2sl2wDd3+HgoVXHFrY9oeyp7gAS0Gt+z6WhmXcfBUjc8bRu0YTEDxR6epubiWYT27mOc HtJ5rsGkt+I5Tq0Wkty/NzM3CB2fq1DiP5LrLCeZP0o8FTxel5OTWbmRDQI9wmZgN/raTCBRX6xN O8NaSILjtY0+JR8LJr6XkN3fpq5/SsBhjwJEA/iCjWmiCXQdmDBpqfh7mX1Cb3bvzifaA3/qpHKW P0bL6m912abWcufZYxxEBsj3a88LHsdW5zjLmwSW67vOD4me618bqoyLRdbmW1WbSWmXOY2xvG7n Rw8EOGtk2Tu38v7L1XHqvw8atllYLLKg4RYJ+kwF27csbILN3psoaHAEmC6WRzM+Cc57c/Prtx8Z jXEiax/Nvd+dz9EO/BavruzHXU5VTm5FALm3Vw7YJ+jb+8wTzyPNMlDVIJefqqutabNrnNHLokD5 re6f0G/LxX5oaDXWQXEkEwOwUcjHzeiW7/TgWVEiyr9NVaI9zj+aQe/gh9M67S3GyMeyt9Ys13U6 tGmjSxxiCfmhOMpLoSEXWz+tOovGWzCAoZtHp6ip5g7X6aLAfnPY45DLIJJgj6W7nyKDj9Ytw631 ARW/aXMcNzHvYZBgxCsvpY7EreKHVTtNjyN9T2Fx2vn6Q1kbR4Je2Bukzt6TG+tFzAyzqlVGW1zQ B9H1mDwMdyDOqq9SwumfWZzrOmtFDwJNbyGhw4GwfvFZr8bK+rbm5FFoux3zFjALKy0iDurd9E/F By/TzhQxlLaXNq3vcx+5m2fpu5cCO4RMZLRMM+qfUvqHTLTWai+I9zAXN9ypY3QMrLs9Oupxd4R4 LVq6zd08sxRl3trfDiS4bYP0Xe2TEchaWB/jAyRcGXCtwLg02Bu1wbMaFqBM1wEC8bdhPpJa4ajl ANRXpef9UsXq7n/s7LD7ANxa89iP3guXu+rGVh2sbls2Ne0w4u2tmNJdBCUchA9SjjBOjzewqbWO doPit5/RGaVMsrda1suDXhwfr2PGngpZXQX4NIstZB1lu73tA/OLfDzS94FHtEOHVS6zQcroMEin CurfXXvIbt3VbnObJJO7sjdMpxHUm9hYXVvDTWZ3Pafz+3wWx1f614GZXV6eKNNs9jprpCiyZJ9m XHGPdyuk4FX2igWNc0R+YAXbokdvvWr1D63Mc/0Tb6ldjQ232NnQxofGO6yOu9exsvKZbXjbGtEG vgExCyMZ9fqhjqiZcBA1dzx803hJ1ZBw1QevyundDz7/AE6GgNFTrHPc7ZqASAPNYWfidOx7dj5r dLXSx3qM2EDz+f4K9lZHR7c0vZXZWzaQ5gEbXwR381iYtorbdj7m7LY5j6Tfo6kHROB0Y5wCNuDi 2mw15LdrXHbua4Oc0cOgArpOl9CxurYFZOfW0Vh1j2Cs72eO9w10WRl9C9T06seyixwY/ca36nYN 5Lp8uPgs3Gvsq2MpY/WQ9ocYtB1ggKXcMJFF0bfsfSy92Llsse0gtcGPDpn8x3ZG6h13Fyqq2fZq 3H0y0wXA1P3Ey0+crLFlbqKqy2HNc47jwWujSIn8UR9ddtW5rPfu/N0Ztjj4ymkgLhb0XTsfpPXi yvEfkY9tYlgI9VoPLjpqqPWfqvl9PqY0/pay5zmvZJbudAg+HCs/U3oX22i3I3uq9N/86Do0RxA1 mV2HTM677JbZlXMc1okF3scfOeUwzqVLwLD5bX08tcdwnaCXNcdv0eRKjl9Lswy3dBDmhwIMgT2P mvVMDEw+sssyHObsDS0gGWkDX/fC4jq2fVdZbjtLPTLvaRJZXxLh92qUckjr0RKERo879kLmhzRP Yxrqj/ZHX7BXVBA2mJO9w1JVzpvVXdP3taGPqeRva9stJEwfxWt0jFws3MoqD27PaXDcYc4/S5iD 2RnMhEYAuCWuLG49e6SDuBMtL3HlvhpAQcjHONtqIIcNXBwgtd+7zqIheodW+pGK8vfQBXDQWifD kQVhYn1SF7xL2iTruE/dCbkyyxyqQXxgJxsF463DdYXPqaQ0n2s/O2u8PEKsyssILhIBkhehNwP+ blxupsaXnTdt0a34Ecz3Qqvqx0/NuNwyXWMPuc0DbY2eXOMRAKMM1hbPGQ8pbVTUQ5jWOFm5xra8 zW2Ja3f8+PJVBVNRFmkmQ7UnQfRjz8V2uH9SXWOqsDm7Hz7TyAD499FvZ/1Jw24tbAPoGS/Ukz2g KSNkWFsiAaL5Q0VupDHNhzS5wd3dMQz+MqNVbbHMbO0GA4uPtB8dOy63Kbg1ZlbLaq6qg6HODS5z mN/eYToXeSFhN6aMe5l1DHOLt1T9zm9x7D8kOPRXAXnq7rmvBdY8hpAkOMhvGk+XCKep5Qe0tus9 k7CXHc0Su46T0GvMYReyhnoAwzVr3F3ubvcewWZkdMx2Pttf6cF7hsqO7Z39p4PwTZSNXS4b1bi1 3Z/peq+57WPD3tJdAe9nMa8qobX5THWuuebt2oM6sj6W6eV24+rld1LC1nrMaJLQCyDxz46arMy8 DpePkiuw7Q9ok6ja6Jj+CjGWui8xPd5EvsOm4/ek9lzWgHcGu1HO0xpIXfdK+rmFl3iptlZafcC0 kmB2Ico5XSaacxmPS7Yd5l5j02k8wEvvBHREcV9XhLjdcCXEvDdNxnSU5oyKdj3Bw3NLmFwkOA00 XRHpeRRk2toYLmslrmgEsc0njTsi39F6pb+sDHhu0tDWz7WtEQAnDMKUcWrzBfdZQAQ4ta7Rxna3 +SiYOTl0vD8YvDgIlp1g6QrLce1rLBuiSGuY0xu+XEAhbeN9Vc57KsN73NruLXtlmgf3PiNE/wBw FZwkF5F+RY528uM+KuYVdmTTc9lwGxzXbXODS4u9u4eJVjrf1eu6Zf8AZ2k2SfbAOruCIVbO6Xkd MyRXYSzc3Rz27faRBka/BPuJ0W6gu9g9Row8G6q5rPXc8bLA9vsdxr5ePZZI6fl1XWVVXMcWM9U7 LBsc0a6agGJ4WRbTcwmojVsmNOOTr3Rh07LuxvtLa5r9QMkRO+NBHPCUcYHVRyW7FeN1Lrt1l1Ti +YJt0YS1oP3aA6IvVOhZeJXXYchrmvaYsfZo9rgXDaDqNBEeKwK8W4UHIksrktB5mwCdunGibPw7 8awV7vUG0FrmyWuadfbKXt67p4tNlU32umtrtxcA3xMDwVjJsyWbab3WN2NgMdPtae0eCq52MOnm v3FxdXuOm3Y4/m+MjuguyXsLLGOMu1Omkg+cypBGxotsjd7vB+q1exttPVKmWuDRtrOsOjw1+Kw8 nNzGOdQ3JdY8WwNpcXOIM7wRzx3Wd0nEyM28MxrCbo3sDAZLhrE6QUCw39PyX7rNltRJ3Ayd48CO 6YIa1a8z0eqdnY/V7fTuusI9JrXBzyfUu43idRrGizcutuHkY/pAU7vcSZcwgGWlzfd4LCfl31gS Q6ffMAkF4jUq/iW5WUab6rmtsqYRLvZsYzvJ0dIPxQ9kxN2j3L6LZ+fkZLzXaG1GdQGenyd0OA7D tKC66the1j3QWN7aF45B8hrBQ8F+Zk5LbaSTYHAB7vcATo2SZ/FMXZHS7qrmuaXkCxpEPAns4ePi CpPbGy3ibVeczF9p3Pa9mrZ2APj2u9vO3zU8PrF5LarXvdTPvYXO2uHnt1WTkPZa+ayQCJO6PpR7 gI7Twnw8u7AsZcwcHTcJY6OxHBHkj7WiOPVv5N27e0TVDpNRJ2tI00k8qfqg1WBz6wASWs3OMOBE lnb3DxVPGde+9mQ1jTutgS2a9/O0jw14Qsj1PtDwA0u3nRglkzw3y8EvbCeN1eo9Ud1H0QC2upo2 sYCS2s/nc66nVUDe57gHwYG0fAfBNiuc3LrO2skvHscJr17O8u0IhtZiZIc+mXNc71KniK5n6Ig7 oQEAFEkuljZHq31ZRxztZt3ncYc4d90e1BtzaWOumtwsc/R24EBpne0iIPkQg4vWsnGxr8Wt0V3E FzYmY/Ik84uRdWX/AKKuA1xrBfO0QXw7iUzgo6r+Kxo22ZWHkWOrYH01uDIaYeXWDSN0aDUoNeeW 21MsLWGo7QS0EATrv/ehA6p09mM57sd77KhtLXFu2WP4J10VF+Pc1oe5pAPBIMH4JwxxK0yId131 gALq5f6T59RjSA0unQsEadoQKstt7HNbuLgC7dpLQD38QG+HdYr5aY5Rqg0FrnMcW/nQY18jCRwx AV7si9BhdXurvpYS21gcDXuAAdB4l30QUHG+sNmI+x1TQ17n7mvBIdXH7vaFmDFGQxvpV2SGncTG 0uGpj+z2QcvHdiPLQ5rwI9zTLTuEpowwtcZyp383r175NNx2gtLng7HWPOslvOmoVSzOZYQ6xznO ILS0kQ3swh2s+az2lorPqOLXNgsaWaOLvpSUWrErFJtyC9gL2hpDZBaQS77tO6XtRijjkW5T1S4W Sbi14MepukNaNOw1Rr35FYbddYS2w6Qdrnj95oI4K5+u1oeA8nbOpA1j4FW8fJzLarWsabGFkGQX bGtO7TwhKeABUchdUfWbKDR+ldLXNc1oA9P2+LfFNidTuysphtL3NsfDg0D846hg4nwXPC5xMRKu 359ZoqY11m8Fxe10bAeGlnnHKJ5cbUoZT3ejH1gysX1zTY4Vh0Nlrd52mAHxxpyqB+sOUQ4B+kzx 3VDGFPq1Pc65lLwG2WbeJ+mBHIQszNq2+jUCQ0uAeT9Nsy329kz7tEnZccsu7rW9QvZsmxpY7QOA 0aTBPnp3UW9Vua61rrWyBA03BxmPa7t8Vk35bttcWh/tBIj6BbIDTPOitdHd61llpdWw1t3AvIDN 0xq0g7vgEvu8QNle6Sd3Trzc3LZvZLjtc5xDTLWNMFxPh8FHG6jk5IDGPAgkF53agj87y00VHpnU bLMobnN/Su22bnemxzXdnEcNUsSnItNlNe0NkuMu2tPpgnR2ny8U04Ijon3T3X23tda1rWvLQJh0 xuIiNdeYUMXqeVg2tsa2S12m4SNw7Km2pzjIEq307pt2dbtrYXbGmxzZDTsZq4glScEQs4iWOVn5 WTa972HcS4uhsaj6WnkhftN5ZtduMEECfb9ycPJvc5jHOaS4hpJJ2mfpEc6cqk8kaAJwhE9FpkXq Ol/XXN6e17mUVua4EO9p2T46aSq+P9Y7n3Oc3HDmkEmsE7I7mNYjxWPiXPxzvNXqMg7mknaQdNdq I91tDKw+g1hzi4PghzmO7AnQhNOKPZcJnu9i/wCtzes10YuH09vqgjT6W7b2HGi024BzsKvNdjhh ZuJ2OAGjv3fLhcE19nT8hjqaXw6TUHg7nsdoNG8/JDGfn9Oa17S9m8Etn6Lh9E6HQpmTAMh00XQy cAdfqPSL8Y5GSMdwqBiX9iT591hZbLangPaWEgHw9pEgqt9svfLHucGnUNk7firnS+q4vT32/a6B cH1lrJJGx/Z3yUsMRiO6yWQSLXfRZsFha7aTAdHtJHaVGrGstDixpIbqYEx8VUtznOO0OdtBkCdP ioMz7qQ707Ht3CDBIkTOscqYY5UxGcbbzwcZwbYC0+BBB+5dx036yfV+lrRY66qw17Hkt3NlwgnT Veb5OdfmWerdY574A3OJLvboNUFzy4kkyTqSUpcrGfzKHMGOz6p+2Pq1/wBzX/8AbTkl5VKSZ9wx dvzX/fJu9tbIjwMg+2I417o2FmW40hhEOEEOaHA/etDE6LnfaLaWU7nsY7e0gGG9yAe/hC0emUNr wLLLKnFhsLXPa1piW6CXa8xwoJzFbL4xNsOjfWjO6cNmyu1o1aHsHt8S0jhNm/WXKyMk5D6qw7eD EHTbwBrwuv8AqxgYxobRl1vDiz2NeAHFr+YjWPiuZ6rkOpttqNLHNaHVNlv0NfzS3uFD7hPQUycD WHW8l/ULLmPrrcWO3CHBr9w1r5cTPZVqLNmZVNpYdhaS4EupcAWxDh9w+S2fq39Xaeq41/rWBhYC WmNrpP5eFzeZU5ljgTJnkmT96fGcSgxIDaObkY7GNyLC30dxqrLRO7dw8ct8QSp5HVs7rRcfVE7B vAaKg/xLiNPv50Vd11vUWVY22XBzoI5cbDx/ctPp/wBUs3Jusx22NZt0c1526fympSlEIFlq4XWs vCoLKLWlobue2xo0cfbtZumeeyp25VtpYftDnDcS395rwB2/jK1Ot9Gu6H+rOsrezTVnfzd4kLNq oBaTU6HNPtJdtLxxIBRE4oIJYWYvp1Oc+wgQ1xaWlpeTwG/j7uEqML1zAIFe9odbJIrDuNxHZHyq 8qytnqF5aGtaS4lw9vAHkFYwsPNxaXuZOyWnYZLbO4BA5SOSA6pGOR6Oaasdm8esSA6AA33Efvf6 lWcTHwbjF1hqdshpIljnzGscDaZUG9OuJIcw+0E6DQBW3YjwRj1vY8aBrhX9PdzDomRP9yInEoMS G4/G+rlJaPXyHAzIaJDtYGukeKBlU9HtdWzB9Z798bXgkOb/AGdfuQOtX3Nd6d1PpkRptDXmGhrT oB4eCzcTKtwbPVqftcAW95hwgweyJitEnYrp6diibGXXg1OG0gt9K2YB8wYKp3Y7M30zQxoE+mI9 rjB+lZJMF06awjdMuyMd1oryGAuhm5x1IMu3NJBj8OVe611On076sW2d7qxZGrLgxvYFojafvQ0T TSznt6c5tNFfouLmvY9zh6rWkRq9hiCe3ZNbk7rvtJZSWemGvDCWtkcx+6/SdESrqWPi0emyoWWu eHB5Y3SGxs13SA770WnrWHRV78Jz7g0AFxb6c+bQ0aIqtrWZJa9tvpVhrLC5rrHG122NwY/XVvCL dl5d7K249La25NnqsMtdY61o2ug9mmTAIRf+dLAAxvTsRrnGXksLW88RPCqdP6hjOyH25AqYx7od W2snawe6a441EJwBRdr9Ey3YDWZL49NjrKnANbv3Pbpv3DVp/vQ8/qGO697ca21rQGNqmNYGx+5w 1DYmIWXl5jslz3EgS6doAAjtwkMit72vdu0bDh3LogEeA4ThFHFo7F8ZgtycgOeCXsb6NYa2f8GS 4686REwlgdRzTfjtrYP0LJYwNO3iXPI/e01Kz8e81VOYGF7tXucHGWbZDXacDWTP4K7jdZz7MP7P jtOj95sa2HDSPphMkCuiQ6uV13O6plMdTusb6p9IuG17nBo3N7gQj5vSLaunPzjcGi0QK6/cCZAL STxujXXVck7MvFz7AdjzO6Btgn6UDsju6hlGh1dbz6YO46wT+bHPmhKBtImK1d7p2OM5lmQz1XWm r0mMDNrBdbILA7gNA1R+n/Vm/MazFyGCkMa5wa+0alp/SQIJbJXMt6nm1Y/oB5DCQ9vIOkjlNldb zMktdc4OLQRJEzKXCSVkiOjufszpeRbXUb7LQ1jtwYPcDtLjHd0OCq3dPws9tHpNGOxo22WOO8Pd G4GGz7o7Kpj9U+04xxmY36QAlrq5Dnay7f3OgVZtmVis3BjQx43RAdIY7mNY1TgCEaOt0zpPTTXa zPNtdwj02MbuLmuEyqOP0rBuGS45OlbQWQ2PULtIAdHHdEwPrJk4mbZnvxq7C5pkFkVgH2yI4R6f rRh3NAy+n02FsBrmzWQ2ZiG6H4o8B7o6oMDoVWS847vUF7yz0W7Rtdu5Lp7RqrvXfqbZgWPpx3uc 1haNriNzrnD81re0fnFb+J1H6vC1nUbt7J/mqo3gQdvbw8OyJmfWbpOFe6173bqZ9NlbeXO7veeT 84Q4Zd0jh6vMdL6GWZNZyaPtG4OGxjts7ZaDMDiJPks/qtXUaMndabPUrcGsJJJG0e3YfILXu+vT jcbceja5ohjiS7YCdfaIb38FDH+tAyWfp7zVay0WMt2l5ECNoAQEpjcLqierkVdJz22NG17TdW5/ 0tvqVD6R8xou4xa+r5uLQxlba6mmK2WAlxDmnnidCuW/5yvvymW3vddtdoAA3dr2PI1VvpvWc9+R Ln27azY9wdL9haNx05EJszIjZIjHu3PR686/YMQkjiWmIBBESf5KH03O6lbeMd+O12hb7iahAPJd 4BG6l9e+oXWfqz3sY7Rp2wT48jxWdk52c9tVbnuDttgLX/S2u1c7UaApAROgCeF07fqBblZjWy0b 3E2hkvFQ+LvFHz/8V9g9V2NaCBAYHkAv8deAms+svUH9OpFdfpsaWN0nda0fnREwSNTKIzDz+tX4 99WOQ2Nzqw81MdDtDHI7KYGuhWGI7tbB/wAW+dTNlltLSGn2geqfhqI1UupfVzF6Q6x+VQLmmuv0 zU01zY46g7TpxpotLH6fZbaG+pZRdSBAfZLLXhxc8bu3Oi1m/V+zJuOTnOczuxtbyW1eHzTDMzHp C4QEdy8j0z6s9M+se9uBbbTcwSa7Ic0/B4Q/rV9UT019IxG2OYfY5zvoiyf3vBb9tJ+qbsa2tpc1 jnbnwNpY88DbyfiVhZP1yfZkuc3c2sWbmzLuDIlsxKjlksbasgiAd9HG6b1B/QPUimu175YBYzcz aDqRPmoOdb1Sya6WMLW7djGxp8+T5qeV1JubeLHF4AsLxx7S87nENXSfVbq7cS62WtdW98y9vvPn pwUJ5qGuiRASOjY6d005eFViPayg1A2eqdHF3YLG+xv+s2Xb9pvh4aSHuIAds0jhej9R6VT1uprx ppxxPxhcw7pjMA+nZbYHAENc2C1gmQJdx7kzLPJA67d+hVjEJjTfs8L1P6v5XThW59ZAsbub39vG sLMNEcr0qy3Jxqd1GVZdFky9p0/Na17uNun0QlZ0PJycjblGp4ewB+yGltdTt3t+PA8k4Z9NFpwv GZX1dqp6fVmMya3ucQDUD72zPZU8zodmK3Hdua43M3bR9JmsQ6V6qPqbhY2lNe5lgh7TDnNbIcCD 2IWJm5eDkWjEybHloO0XEDdXWxsbdB3KccsoGit9sSFh89r6VfdOxhdAJO0TAHdabfqfm1tfbbUd tTQ+xu4BzWOEgrrukW4fTvUsxrzt3NNlbrGw+pv5rSdd06pYv1fq6rS7KDn7rrSxjQ7f+jB4Ouui PvSI0COAROrxnRfqzb1y99NNtYLWzLnRPkPFXLvqXl4Tn12ZFFbgGlzTZBh7tuvw5IW+zoHTLcx9 D7m0soLosb7X2Hwjy8VkZPRcV+Xlhl1llbWE1ucCS90D6RHgne7Qsn8ke3Zbn1b6Zed+BblsFLzZ V9I/orRzsHfe35fNZOTkZP1eD8B9LHMPuLnVw/Xu1/MaIeN0fG2Osfe4GuHEBjgXajRhP5w15XWj K6Z17DZim5zXAfTtG+1gJ9w3d55I7InJCrSMcuj5/cy7Ibua4vbuLQIG/X+SFpXusDGv3F9b/wBG 1g/RureA3ftrGmnE9112P9T8DIw2DFymsyanPO8HV5n2/ALnKOmZvSHCjIDAy5+0gmXa/wCEEH83 4/FD3Ikbo4JA6NS7p9/T/VteMhtLP0UOADt23e1j2zG0qq7HGcH24Nb2DYfVZuEc8V9yONOVr5OF k4Lbr2ZPrVtfG4ncHPjbu2unVviVZfjdNpllGTkuyKx6oA2bDbA+gR3+CMcglqtlGQ0p5ZzDl7Ws YGloOpMF0a6k8nwVvpL7LnPqrDGW7DscQQ6R9IeGrZ1K6nD6Vi9bua/Pa2p2wPc6qA21zh+dH0He MIHUfqRdi5HqOaRU8nWubC0RGmoJ8kPdhS44pOAynK6e37QPUDfa1z2FzWjcD7CfHRdp0b671ZTc fBux2wSK36yxzDpMHg/NYWZ9XbcDG/QuuyGl5HpGpzWk7fpGHdp080PB+rl99ZLdw9xcKSx3qA6N brA5n8JRlKhaog7PTdf/AMXW9wtwBDeXMJEj+qVyP1g+05N5Flj3hg2N3gBwa3QAgaSu76Jl9U6c KcK2qdS2bDodOzuy0c3D6eaX1vxttr63O4BdA5dPcpuktY6ea/UaF8go6fdk2BjA53jtaXQO5gK1 h4OQHud7drA90PO3d6fIA5nVdbf0vqfSmUW4zWEbNLKgW2EEztefmsTN34vq32h7b7Xlr2a/Qd7i dR3KaZ3oVCFao+kjB6s+ivIc9rzaTa4n9GazEDyPmtnOwundK6iHU02Vmlsip7XPF5Gu6f3Y1lc/ bbjsua5t1rfUa71XtGvu1LSNJ1QaOr55Bpbc4sLS2HndtDhtMbuNEALGieLhL231Y6l0ZzbKbAHH IG6xjvcJEnwlZXWaPq9jOpdjtDhLy7Uu3ToB8uy5/F2VOLMWs2ufUGy8Q5lh5Ne0/LVa31f6ZhPf ZV1W01O9Rh9MiHOGveJHmpOKxwsZsyMnmKnek4lro0/KutzmfbcDErw2MeyogvvDdrq93ItaNQB4 +C1/+ZPRsK8vdc99exz/AEy0k7Y8RHyUsD6uUYrPt2NkX4tT5mQHtDO4d5fFExsrRKnnMTExcmwV Y7WW317w6t7/ANHcAJ3Uu8+zeUPpF3S7bL/tNFlcgemys7vd4HdqtfP+r2N1F9d+E0MaTtLmH2l7 YJdEjbOsLe6f9TsGm8ZJyTbYXNe1zm6hw92oHimiAOw/FcZ08v0r60N6HTdimlzRY5roBafbpp9y 6Dqn1ow8vpTrKt9JeQ1oLAd0GHbTEcfBRzvqJX1G3fVlNJA42w7TXWPyrMyPq4/Cr9N+5zTIeAPz tY2jv21RIEBsi7aGZ1HD6dW9mJkXOeRtktG3bMxHYyOyx694rsyW2hrnOLLGAe7Y8au1ER2XR4v1 Roy8jHb6nptfXNnPsePDd4rQ6h/i7dfuuF+pILt/4ndolCMegVKR6vI4LMB72C6x7Q+AXkCGmfdo O238VB7aMa2wgvEQaiOHifpGeNF0Wb9WqKqxSMmuza0uAgNcHwZBsbOg7eKF0boxYMcszA15LiWl u4Vbht7iCT38k08PdI4g3r/rZ+1cXHxmVWes3Qx+dotz6q5rKwXWtIJ0kiVjUdCb0EMflNJcGSHN cW7bJ5+EeC6Ov6ydNx6/SN4ILdHlpI8IMBRe3eTivUMpn+r4a3X6xThdUBZW8eo4kNHAc4dlwmY7 GreWiy9hIcHhtbfpt5aNRp4o/WM/FF4fTmMc1zgC0Mf7JEF/A/BWOmdN6dnXNFOY2yGS+uwOYLDr uLXkDbKQh6uIhXFUeEF5zF6lbhvbYXl22CGyQJ810XUvrZk5ePTj3WCbGkO9M+9lgdpx+RXHfVfp V0WVZRbtjewgvG4HXUfgi9S+rXSHva+jJbQ3dMQXCR5EKWMv5WGMxeBsbkXlzve7aPcSCYPxWt61 fUMWmn7Y5p924WiK2tqHsgidey38DpnR8XFtrOaSbRseQ0y3XTa35HVV7uk9Ow6mnDy/WLbGOc17 Y9h0e0HzB9wSkRufzTEdEv1ay6Op3tr6g73U1kAvMBwGrSJ5Px7IeGKLMtjnXhtZcS8Nbo0ToXkC BuCa76s4XUmOsrz6Wvc4bGmR6bIP6PyA7aJsfpdFTjisyNlV1bW3EHd72EHfpP3aIRjEEX1TLiI0 epz+rt6aAzpzhZIlwA3gADy8lyAxmZuXYMnPqLKySC8Tun3Q0QtboL6Oi3Wbcp37oc6r2PbOka/l Wsfqv0jKrNhtEkElwIGvcwnSHFIgVXmsrhFl4PKza8K/1MawFrnSWsBAbHGrl1uB9Yum9XofjuY5 rGtBBLfcXRrMTAlZ9vSug1zS/OcWNfv27OXQBqVZxKejYFdjMbPdX6w2vdtM7IiEseDHfq/Yn3Jd Gt0H64UdKbZXY0sknadA0wDoSZKvu+vWNlFtjL2Vlwh7HEhrdxjQ7T81x3UMPpWDlemLzfUQPe1r vZ8pGqfodPSPtjhlAuoLoa8lzAG+JA1QEOEcNmknJcrpv5uf0/FyLHtzQYO5uyv1GknzMcIDPr/n tsrt3Fwr9olo26+MKPUD0jByXX4NZsDCA2u0bqrAQQ4nUHQ8Lman27nMJIrc4FzWnQx5eXZPhgxx hYOqJZJE6uxf9YX9VybLsh5r3Nc72M3Q8DQadj4rMs6tZc1rHToTL5JJB7anshZbRjXvNFj/AEzI DnQ15YdIMHwVh9HT2UMPq2F252+Nv0Y9kNnmeU4Rgt4pFs052PlGnHgMAOz1ONwcfpPBmI8lr52N 0c5ddFWYWsYz9NY1hLA9v5wj8oXMY+XgNtDbBYads9t+8t+6N34Kzd13FdlVuZiU+mzSIc0WCIl4 DkPZo7FPHolqbissD6sqNoLgXjafUaONuvPYlVxnMsY0G9w9JrixrpImfos555Ruq4/TnlzsEl2r TDnfREe4f53Co4rMaGi20sd6klwAeGsjmPGUYiJQSQXTzernqGFvyLGGzlgDQXPE7XB5GocOdeQs vp1eLkuP2i41QQZAmR3A8/BV631W2vN247g6NgH0z9HTwlXGjpdexjxc47RvcIbtcSJAaR2Ejz5T xjjAUEGZkbLpXX/si+uvEyosYXMrsaBWBW8nV7u+4GQeyq9Ux3Prx7bLW2nY0FocC+Jdxp5d5Wa9 mPsLm2O3byAwt/wfZ27+C28C3Ex6a31WWV27LBY6A9sjVm0cie5TSOGkjVDg4uMxtjbLbKmW1jT2 7id24aT7m6c6ao3UenHCFWO/Je6ovEVbZsHMkNBInWedZVHI6gMqt7skE2gNFZAAbpzu+XEKrT1E PymW5Be5u4F5aYeR32k90BCcjaSYgU2qLGW2l1IsZtDGiCGzYfbq7Tb4yruHc3DyLQ+tpssriqxh 9JjHRD/paHuD5rAyba97jUXQXO+lztnSfPxVm+7DtB9P1RFbdocQQLNN/wDZOsKQwWWHY6XThMyq 2hpc2fpucGB7CdNu/hzTo7kEStLreV0vF9ScBrybDtLbNtbYgO2tby2WnVcjj5NAotY9rjYS30yD DW6+6R3lafTvq/f1p9jsRsMYWhwse1rm7vGY0UcsdGyvjLSg9I2voVzaAcR1LnfpGubcCS1p9wOu jvAcqngW9DyHWtZW5lhk1usd7BtEncRqCY0Ko9T+rF9bL7qqHVsocRZueHjkAbSOY7qkcJmf6n2W h8trDo37tuwfpHGRwfDsmcAkNyusjoiqY19jhVYJcwk7tPdztk/DlXMfpLeotbtyKhaZcd5cCdJ2 ncInTxS6R0QdWYPSDJaNrpuDHOsefYQ13h3SHSrcVj6rqCbW3Mb9KHkGfa1nfd+8E+R10K0O30f6 mXdSxzfjXMcWxuAG1zXz2J8hKs5f+Lu/FqY97iS5+10CYDuHT/BZX1d6lYb7Mat4rbaCGh9m1rD2 Lz38FqNzcu+p1llhIpbGxz3bnOnbur8YPZVpmYZ4cJR9R/xc5VD/AE63h740bO1rm6CQT59lm9Ud 1bC6ecHKqPpNtlriJ2lmjmhybq31hdkl/qPubYzaK5dMQPdJ+PCp2fWXOswnYr7S+t79zg6C6R33 KaAkWKRiHHrsdU8O4gyDHcK/d9YbrsZ+MQwNe/1HENhxeJ1/FDw25GaRiUDd6r2+0wJc3jX5p7ek W1m2q6sVvBLmkuMaaFjYkEnt8FMeEnVjsgaNijr7x027Be+GlzXMaGN1IOu53I8k+R9bcq7F+zPq ocCwMDzS31No4hwVe/pGQNH1FrmMGgaffJ5Md9UPJdZaKKMj9E2obfomRJkucPFCPB0Txaao83rG T1Fobe+QDIAAaAYDdIHgAtHD+sPq014ma02Y7C5zWNAY4OIgHdCyG11h8F5DZ0dHPmtxvRqqLaDu dYywH+bbusdpyxpiQlMwjQpUeI624RqfaHWNaS1pEkDRs8StLpnX8rp+Jfh0tBbfAf7ZcQPBQ6ic XHrrOPXc0lv6X1I2l4MHbHZU6usWY+lUNnuANw07HlOIMhsgGILK3Obj5DL8VhqcwNPO6HgakfFG v6rTm0O9eqcjcCLQY3DXdvHc+Cyt7C2d3u8IQye6k9oFbxuuetWEgBjWsGyaxIrea+C5vBnumo6p XRvcMasufvHulzWteIhrexHIKf6u9Bu6/kNoY4Mk/Sd9EFXcn6nZePTfkB1b66S4OLbGk+0xo2ZT CYCVdU8MiLchuUG1Pq9Np3EHdHvbHYHwPdaX1c+sJ6DbY849d4sYWFrxxPcLFcCXe1rgONROqVTn tftLNeNZCliOE2FhNvS2fWGnMzq8qzDrawBosrZo10ckeErcP14w3Yr8OjCYxhedpeBZtaT4d1xr aMmm30Xs2uGkHz1XTfV/oFeQ259jg0ehaQHNBG4Dz4PgVBnzAnWtWWGInZ7X6q0YeJi25FpxXVua HbmtALf5Lh4qd+N0jqNWJe51dde4gANLDZPYkdl570/6wYN2O3GycZrfTEb2PLXO83BHH1qxenMr bW4XsrdLanAw0nkqseIHh4WaMY/Nb2vUui9IBqsy30ioB8Gv2yZ0aNq5bOwum1dQZiZOMMWsva5t g3OL6jMEy4xPwRepf4wOmddobVfivqI/0W0x/nALPyK+mdQbXZRm2CyuA77SCI8ILZ0TzAx6aLQY y82p9ZcrC6dFOJSRLYeXBzJM/mgu1B0Oqwv2zZbdU67dZWyAK9xA2+AOsLqPrB0zL6/fW+7JpttI awFpawR25hD+rP1bfg9QP2uhlrG7mlpMtceNC1PjnxQx8RWywzlKg87mfWC3JbSGsFZrEbgSZ1kc 8fJVP2plQ4eq4hwLTOvtJmBPGvgtzr/1XGHa41umSSGhp0Ch9XPq0MzKa3MZZ6OsurEumNFJDmMB hxDZZLBl4qeedY53Lie3KhKv9T6a/DybKgCQ1xA+HZF6J0G3reR9nY5jDtLpedrdO0+JU4yR4b6M JxyunLSVzqXSsjpVnp3sLD4HQqmnRkJCwslExNFSSSSKFJJJJKfQcjrbLbQ+wue7iSXMeNI5CE3q tNVfpAPDC4O2tdpuHeCFULH9RtJB3PP4wum+rv1YfmObXYwD27g4+HgVhkRFDW+zqgk2eisL6yNy HOYb7Q94a2XAF0N4DSOFsfarvSkBrS14A3VzDtPcAO+ip5P1dq6bk7HUiwuMyNAAuxqtxrcdtbIL ogRqdwHYlCMZTkfVVd0ymIRBq77OW1uNbiWb6m79YLAR7j4n4qlV0np3UGAU1Mfa33Ob3fA9zS7z XS4tdGPjOYTEg7geZ+Cw2/V2trDlVWFp3TA03Dw+aklGYrQHTWmOM4yvca6NTE+rPTM01ktNLyS7 R30YP0fL4qpm/VnEd1C7c+xzNs7g/dYXnz8ELMwjkZT3kbRMiNFF3RXY12zQka/S8VEc1x21ZRi9 S3U+hYNmCDW19d7AJnUPPmeyl0/6p49jaMih4sLWg3MeYDT5Qt1v1XnH3byAYdHJA8FZo6FjmAy5 7TAPZIe7sY7rJSxbgpsnoY+z1U0huwGYcONysM6Y3GwnU7GiAfJZuJfluPpkudBI78BbLqLHM2Of JcFPCeKQJETtTDk44UDId3J6P0HH9B5fWYMwCdR4hVP2XVg3VPFpEkH3yG75iAIjRb2NkuMs3An4 Kn1XEu3NsJD4iBwNO6jicXtiUQdOqROUpkE7uL1z6uP6x1PZZa0bmj3bdYAXOfWH6nXdJsAq3W+z dLRG0DmV6HTbZbXrWQQZc8c+OiyesZTrrWivIcxoIAnQfPyUmTLDh4u5TjxkmnzirFdVSXPxS/eQ 1ryXASOQIWhV0Gzqbd9OMK9oMgbjJ893C7t+RWzCFbrKzYx+4PbBEkzoArfTOo2ubZa4MIJBMe0n 4BNM7kI3X0XcFRurfPcn6t3Frnyyr0mtOyT7idCWz37lZlpvwQ/HDnbLAN4Ee6OF69eyvqTg0Vg6 alwkeKq9VwsbFsZYcZrxt2wG8a8z4o+qIJuwNLWiUZGq1fKT0i26o3it5HjHt+9VKXPw7G21j3Vk EEgOE+Y7r1VtjWNuoY2KHtPsPMx/FPT9X+nDBcHUiXGRHueAOyWPITsV08Yju+S233HI+0SA/dvE NAAdz9Hj5ITMW28lwaTJ7Beh3fU3EyaCWudW9rnGdu7e380T5K/0hmTgYIFJrcKydHUncdo3djJM /kT/ALxoKWnDRfMqR9kf+kqD/wCS6RpPlCtdOzxgi0wCHgt2GYG7XePNsaSvT/2dT16lr2trY+33 OJZD4mIH3LHzPqQzGpjILWsDwBY0e8c8gdj96PHMizHRHALq9Xgsq37aQ4te53dxMud5uXQ9Aw+k U1WOzXvNgYDW0tIaHxMeZn71uZH1WvxHMtrubZY+GtIaA0tb5KvmU5OBeKsoN2uHYQ4T3nVQz5iU JVw/ayRwiQu3E+uVFtmb6xFYD2MMV6taI4+K0x9VsrM6TW/1KQ1rHPDvz+PoHtKsZODgsLW+u60u cQA39GRHHY8qVuD07BDXW419jCCXAv8Abu+UIxzeqpfmo49PS8ZZ0bKxMevNILWOfDXBwDtw1+Kr PotxHNLmvHqt3N1je0nnzEhbZOEaLmDGe+xzv0UPljG/DuVQtxS4NHovJP5FMMoYzjQY7rfUeX3O rG1xj6W4/S2kDSCUGrKfvAssLGmz1DtaDDj3jT7kV2EZJbW4fJdN0f6s9P8AsYzOoX7GEkFg+mD2 KPuBbwl5TpvUn9OymZIY15Y4mH8OmeQtenqeFfiU037y71IeNo2Mq8Wd9wkrFzPTbY4MPtk7fh2R ca3DbjWixjzcS303AjY397cFLdjZjIdKzF6SRlurvtbtIFDS33WNPO5UuoOx8a1oxLPVZtBJsYGO B7iJPCoGSZCJVF7psl3xKBEaRqza2j1iXPdsmQ5rfx2lI51zCNroguIIAafcZ7Lqej29Hw8Z4ysM us0Ady0A/wAVbyundEzbavReKRY5zSx4j0oGjifj2TPcFsggXkv2vk3CptljiKnFzNfoucdxPzK6 Dr31mx+pU0Oo3i8V7bbDo5wiIHksvrWO6h/o7cfbVu99ZBLwTpMOKu9F+r37SprsBgvt9PUDbJ/d 15HdNnta6N7Nx+RhnpdL2ZFjchp2E7jDG/ugD+Cza/rR1Jpa1ubZAAaJcdAtH6y/VK7ovuA9RoAJ cBAb8T5rGtwG3+kaDvLmjcNu3Y/uO8jzT8WSQBsoyR4qe96f9dOmW49VWS337Yke87j3MxqeVuYP Un1tk++qYa8eH+viuRwP8Wz8zHN+RcKnEEhjW6CPGSEejpN+Hc2vALrmNO0i3WuQJNkiANeAnT4h UhotgBrEvZvx6sysmra5rvpMOrHfLsVynVvqCy+baJYTP6IkT/ZK0el1v6bd+nzGOc7WGmY8oC6B 9rbJFkBp4JMO+5ICOUa6FMjLGdNQ+VWdDqw7PTvcWOHYiFcxDj4biGEEHSYn7tNF1P1txnDF2x6j +WvgbgB+auKdblY7gIaHCRoOx7OCzM+MxmYmTdxTBjYD1vT/AKwDGDg0k88iVe9LFz8dz3SbHGdv J+5cdVc04rXte0uJ2vaBD2Ht8QVq9D6i/CLHWHcZ0n+KZGZj6Z7fy1TKAlrHd18vKxqcJ9OS4tcT 7faASRwYXMftV9t7TS5z/aGk2QDp4Kx9bOoOz3eoGARofHTuCsPp1Vlj3PZWXFonQSJT8k+MeWiI R4T5vb5RzOjYwyGkHc3gc66hcJmdTsvsdPsBk6ifktTL63kZVLab5AAiDpDlzT63227GkSZ5MDTz KkxgSPgFs5GI1ei6V0TK6gwZVbK7GMc2QG8nlwjyXQ4eDi3bnjdVbLjurBayudPo8gLjvq31nNwr msxnEbnAbeQfkvVrKGX42/MY1riBuPEfNXMQ/D+W7WykHV8szei2YmUbvbZD52vB2v18fNal31Uu +sYGTXQcUiqNoA9N7wYG2DoI5JVPrYGTblONz662iammSLSDpr+KJ0D61XYWNbj32OLIhpa+HsOv 0fInlMjIHW1SiY6ON1X6rZnTrLGNsa/Y7aQ12sxuOnkswYl7aW3h5DXEgHUS5vI+Uq/n9QsJcGHd vMl5MPnj6Q1g+Co5bbG1MaXSxpJAHEnlOifFaR4MK7b63ACwg+RXZ/VW+51JbZT6pLi5rnA7gYgb XfFcLRcaHh4c2W8A910fTfrTk9ODLQ+txkewAyNfzlHzEJ6cLJhlEbvQ9Qa7ArtxbK3Nqe/fs3ak gae4iYlYHT7z0zIbeGlhAIDhLokRMKH1h+teX1uwuDtm2RDeC3ssSzNyy0NdZZHAnhMhgn3XyzR7 PZfVr6yUdNrtrvY17HO3EHmey38L644j6HVOvDd0hhcCNvzXmVOLkXloDS4nidAYU3ZrW1Glzh7j B1kfFPMJDSJY/cjLcO6Oqlv2n1Mux7hGzbY8N5+Kq9O61ecprWPLtzhP6R0/fuXOucA4gEOAOh8V Kp/pu0Ek/hKlMcnCbkftR7gsaPrWfk39TqYbb66WtInWfd8SsLIx83MtLXPJ2Nhry8RtHf5rkzbS GMc/cXh/uYfoFg/lTz2W9hW9Iy3nY59by1gax2rd5PuEgcRwqk8UgLJtnjljsA9l0HrlWHjNoufO 2Br3k/mx4Kz1bDwuvkN9r3DdtE7HkgR7XeAPZY/X+gYnSsOuxjgHCQJdtBLtfmuOYxlVLrn5DhcH jaxgPH725SwyzrgmNmIxhfFF0s36kkud9me64lpMRtc1zT7g6Vzxqtoa+uon3e14Anjt966Lp31x s9Wo5ltrmNmC0APnjcXRrC6TpLug4j3M9Vr94Foe8H36HdyOPJPiJXp+KJmNPJ/VVtvScr1Whjng EQ/TbPcpdWou6hlvyX5DBYT2lvlzC6vrVHRsd1FwaHCx+4hpBJEca8aqnVgf85sqy99Rrqc1orLH BoaAYk+JhMlHIJfN9iRKJGzyrusZ1Wyt1jnEAsHvJ54+5FZk52VU3FDjtlzXN3w1zme4/cuzr+pf Tmuf6jbbPf8ASnTbHksFv1ByLtoForeS4hj+1YHtMjxU0JHqNVpMadX6i9RYAcZ7WneeP966zHYz He6hxETuA+PZcX9XvqZmVuFj7Axk/SaQXOE9l0dmNT0t7X2WlzjuEvggk/RZ4gqaJoXTXMbLuhjW neB2ULGNvYQACTz3WWetuoxX2PosaWD3NHuc34rmx9d3dKsfXbXBHIcC12vCk9yJWmJD1+X0+m97 C9v0Rpt7IWRZkZNRrDDtd7QYE/MLjGf4xG1ZJtDAQREAmPxVTJ/xh5VjprLWt1IESQU2Va0mPi9Z ifU2ot/WPpawW6c+IU6vqu2l27Ror+iWmCR5rnP+fxZTR6drn2EEPlvtDu21PkfWvLFpZaS5xZIZ S9r4jU7wePgozHHWy+5kvaZnS6+pUj13TAGoMBcj9bujV1VMdiVnaBDiPoysQ/XHqDya6i+XPkNI Gmn0fgjN+vVgwbKHVuIsMbonn6Xl8k3JGEwmEpReQvbBI8FLFucx4IJGh4MKTrG3Od+jMToeO/kr tfSn0Xmq6ggtIDvd9GVHIiI1ZACTo9N9WOrNxqbm6fpdCXkSPgtbq/VMHIwm0e1jgPa6R+b8CJXP fV7F6ZbdZj5N8Q8em7hpHjJ8Vk9Yrwm330MvJawE1uj2yNddPzvJQx47rovPDV03HdId1IB9F2h0 00GnzWX1jpOT0sgbnOYRq4cTMKHSes3YG2ukQXWAkOHsIiNVYs+sTGWi1oY41uPFZDHT7fducdPi E+OOcD3C0yjJysfFyslwbU17iQSAJ1DRJ+5Wh0PMGM/KJAY1jbJ3ch7toGnfTha7+pVWtaK8Z9bB /N+5xY19sSARxI1+CHe67MZ9lx6jW525j2wA11lZjXdEaJ3vSvZIxRrdysLEddSbXZLKwJAa5x3E tjt5zp8FYsYaMh1AzWOYGk+q3ds0EhvEyeFj3YeQ22uu0hheYG5wAGse7w+aPTU0Vl9l4Y8OgVnT cwCSZ7fyfFT8N6sWmyCy2x/uk66I9vT8+sCan8A/eN35NUXq3T3U1syWMsFTzo52sOPuDZ/qwl0r 0Q5hfk21McYtc1pLa507HWQlelhBjTXf0vPEzTZpM6eA3H8FJnQ+pWM3ih+3XXtoQD90hXch2S3J NODnuuBaSCd1YcDoQ3dzICjkvzclrQzO3+pU5xabNZMFzInk/ilcrrT7EVo1LumXyaxRZvMEe4OA bJYZj+Uqx6TmAOd6T9CAfmS38ohW8NpdjWCj1TbLXOdWf0YqAkh48QeFcoOHVeW5Ft1lQAeHM+m7 cN3p+GhMylKcopEOJ53IptpID2kSJHwSbRupdYXgFpA2GdzgZ1HwWr1G7EyH1jHxnNDHOLnE+6xp +jOkCFDHttAdYWMIEANP5U/3Tw7K4BbjBEyam0WOY14sA4c2Yd960zbExjVSRBJ17zIROpW1Xsa5 tTGOGjtjdrSI+ZkFO97XZXt6ORVWLGvJe1paJAMy/WIH5V1P1WvoowniythLrPpOaHEDwE+K5f03 AmXD7ldZbGN6G2vdv3izUPiI2f1e6dIgrOG3q+u24nqNdR6dTC3VoY0kWMidSJCsZ3Xun0Ox7KaK rrBt9RzmNALh+doFyWTZXZXDD4aE7vxVmi6mtjS5wGmuhVeUqGy8Ywer1H1pw68lu57en1gH1Jqe dzhEBstb3WZ9Vep9LwKbmZ1W5xEs77T/ALUGvrGG3AtoLS/dMAAxu/NPbgpfVjpGF1CjNsyLQ19V ZcxpgB+h0115jhMo5AbDIPQd2n9aepYnU8jfjY/otgAtB/O8VjMxXTq0juCVrWDHFvp0F5YQybC3 3tfGrQ2dQXK79YfrEH42Ng1tcPRDt7nsDXlxPBjwUkJEAABEgDqXH6lZj5LaG0Uek5rA2w7pFjwf peShjZDcdrqbWNdPDo3ER/BBrcy1wFbAXTprypZu97nOLAwjlo7KThNVWiy+rcx8sV+m19DHjXYX N2zr+8l1PrDOrZYvuHpElrbPTbukN03anVys4OB0zLwg+/OdXcN0VFhc3y1HErQZ0jCyKMrKsljW Ma2kt/m7bGCHOBMaGJTNInZIshF0/wCtA6SX7LrXscCWna0Oa8fRkO3AjxCBifWR9Tn7wXG582iA 0PrJmGae08ifBb9f1ZHUumjKw2N2hu5x4B2tAdz3kcKh9WsHH6rltr3hlsgMJHBHeO6gJhEH0sg4 j1eXzyRkPDKzWA4w06uaJ4J8lov6Nl5eP9pZcLi10EBxLmAN3bte3b46Lb650MV9SZjOyWPfo1xI DAGs1aD24VzrvR2/V7p36plB7bxtfXII7Hz4jRP9+6oK9p4zAwb8+w11N3Ogu0PZok8o56tnWhrf XeYc4g7zPu5790b6v+tdc/Fqe1gyQKnl2rdpMz5Qup+rv1S6Ywk5ebWfcRt1a5rwfE8o5MoBWxhY ebyMU2YbMhuMTLXVveWO2b90te186vPELNpzTSa67amObXulr2kE7uQ6IJ8lqfWXK/Zt9uFgZLjR MBsmHE6zHHPBC57INzHtufLjoSSDBPPuJ5KkxDiC2ehd/puQ3Cua/G+zWbSC3fIdx31ClndV6jlM FDK621us3BtZndaDIdJcXTqubpFuW8tYxzgdS1ok7Rz9y3+gdSwOiZF+WGOe6sfq7XtGrpgF+3QE DVKWMxHdQIk2eq/XDrmLNWTb7nDaSQA9re7fn3VDqHXjk3VdSNrH5G4b69pIHpgAOcTod3dD+sOV k9ZfVkWufZ6jXFskOfofdIbxH5FgkCeVJjjxR1WT9J0bmbn/AGu3c1oa0AQ1o2j7lpU/WzqD3Y7K trPRBbUGNjZu5LfPzVb7PVT09j3VNc51jttgf7oaB7XM7eRVXALPVBfpr2En5aomqOmyuE2HusHp jKsG/Lz8V2RWWBwPqfQsJO6dvAcdfFcL1B1PrONbCxpMhoM7Qe0kLqB1v0enX0WB7g8iCw/SH/Ce X8VzGbTc/IDSdxcARDt0gjTUKHluKySy56oUjx8QZW7a4NhpdLuDtH0dO57KFTA7RxDQOTyt2vHd 0zF+z2vpczKDHkxufVsdBBMewqjk0M6dmwwMtFZB/frf3HhIUwyWWI46Dp9F6lZ02o5lO8+nYASN KgHtI2kOnU+Mqnnbr3WOpLYDfVcBY0tE+HGvkr/Vsr9q0uYMJtF4hzvRGyv0gPz69fcD3XNsrDdz XET/ABUcMceIyXymaAd43to6LvFzvVsvk1lvthrYD93isI5llh1cZPJV/MGW+vHwy5grdD2t3AND 3e3c790rKfU6pxa4QQpMcAsyZDej12Z1C/oldOKKsSwsiz12j1HODhO1zp154U+pfXCloaMOkMmo teLQHguIhx/uXM3jKGPXvbFTiS3QcjRHxOlNzKXWHJra8Pa0VvO0uB5cHcQO6jligaMq0XDMRpFz HO1Tblf/AGYHl5bY0BoJ1P0o8FUdW0fnKwJgsJBYB5CI2940kwVFrN2g5XSfUvpFHU8v7PktdD2k CGgunttn8qbkmIi18IyJc7p/UnYrg65hsb4T+RdP9Xcs9aL6mY/vmWbIkt8NeSi5mLbRh1Y2Tg/o Md5LnSGPs11aX/kVz/F/05rTZeGhrmO9QOkk+nx6cd5WfmOLJG+rbx8cDTQtuyui331m19NjW+71 YjY/wV7Htp6PhszcrqHrOdOyljxMxo4ny8Dyq/1++rQrH2+t7nNt8Zhrv3V57YS3Qp+HBDIN0ZMx g7mV9a7ck++ql3iSwAn7oT9b+tLepOofRjV0GpoHs/OcPziueSVuPLY47BqnmJnq3+r9ayuuXevl PL3wBJ8AqCSSlApiJJKkkkkUKSSSSU+z9H+qRx3suvLGwZggz+C6nIuY+1gpAZt5I0keGir335Nb vfW2ORtJco+s0fpImTMLnPvAx6OpwmWqa3G9R253uJ786IuMWYZaHs2knQxoJWRfm37g6kCBOuph Dt+sOWxrfUqlsw7jXuInulDPEm0ywzMa6O3k4v03hwcdTwgY2NY4hzifaZAmR8FUr643bJe08Txp IUz1/HMN3/dr+ITJczrdFbwZIiknU8A5dwv4AGoA0VO7Bc8tfIg+PdXa82i+30d3unQT8lQyrLt3 pgR7iNzuNE4y9wcWurJiMgK7Orh2WXMFTnQJiB+75HyQ+p4teE0+la8WEe3hwVCt7qS0Oe3zHkrT rWNcHOeGn82Z/DRS+9cKI17rTjqV3oxx+uWUua3buO3Ukbde/CHkdVyTZvDXBjvAj2qbrWbHWTW4 ide5KzMfrN172VfZg7eY9oM/xUJnOqC4RgNeF0ruqua7cxha7QEke2Pir1Wc20PZaZcR7Sq+RVSy ljhe0EkATq3d+6qBZZ1BzMepzHnne12kTqE4+5ilVbraxzHk6GPntwq37jp3jn7lQb1Gp21peQHE 9vyyiM6fe611cAlh176eahk9Fuy9nouZJdLj+40csc3z4Q4MuQVWi+8cSTe63VMLCLg6l7fEye5V ii5pxm0MggGQ6DKx8nHqx8l7byWkRDJ9snThWjmMpHpCxo8G8kd0wTqZ0rwX8FxGtu90kAlxaQC3 Qyld1Bj7dtwAg+PI+S5nGxr7rjdvGw6RMap78Y1vGx0knUjhSnm+GAjS0crGcySXdy7cZzpY0R8Y Va/PzcCtz66wKjMGJKxn4Zoe574g9p1+5Xf2jfZj/Z3vLAQdsaaJsc+plt5JOAAADXzb3TMh2Xiu dbkFkTDYDZB7IR6vex7djg8RIho1hU6sHJ9EVaOPIPP5UEjJqIe+usbCNrQdPjxpKJ5kmtaUMUbP V2W9Wv3MApA8CYbBd81dzi8Ma2/QPIAh33lc11rIz+rWB1dYGwRDTyqlVWXkbWZLrGho+Os/FSHm +EEcVrBgsjSnuManHyCHtcX9gSZ2keCo9SxnW59btoJEFskdvHlZ/TH4+E9oNjyPAkhV8y+kZPr0 2EOkkS7dGqfLmIyxDzWRwSjkOvTqzzGO6Hdc+4NPrA8gOHM9wn61mt6lhtpdQ4N2BweG7vcB9EQf xQOo5dfVn7rS123QAuhv3LOz8VlLBdXdtHZrSD+EqI5qJEbpkGLQGW7S6bg05AqYMc1WscS+wuIB b2EeK3/rB9ldTWcY+iXEMseB7oPlzHwQOhdVZi2tfa4PHAHcz3+AVvNdb1ez18fGD6zpwCdORCQm ZROlnskxo+HdH0/6v5VmG5zMiXMO0MIGzTuT4arlOs9Kz3W3NcGu9Ijdt03b9G7W8uC7PHyM3Bpe wYj2tPIDTr4rneo2soyG2srsDnAe8OlzAdDHmnxlGNenXqsOMm9dHkMzouViWPrsqcHMaHOA12td wTHxViv6sZTsF2cWhtQIAkwXT+6O66Z32ClllAy7Wi0t3tc2d0cBx5WpS6s+h6d1FooADGuJaA0f yeCpzzVBjGB4Kz6v5VOI3McyKnOgO8T8EuodFu6XVRZbANzC8N13NbMAn4r0GwfacSzCdXW4OdvG 14Oxx/dAR8jpnSM2qn7VXkF1bAzTceE7Hm4+v2rcmPhfLarbGGWuIWnd1nKotNbbxc1ugcWgtOnb cJXZZn1N6blln2VzqdwcWucZnaPolp417rF6p9VmYmHVkNt9V8gPDeGTxPmjPhvUIiJAbvMBweZe yZPYwt3pXUKsbY2um1rpnc1+uncSF02P9Uek1vpbbY6XVtJaHGN0SSXdp8Fa6X0DGvbe5rBULDsY NXOqj85vxTJx4tP2r4enVpZZyep49lAstLrHBwa4Bw05lzT2V/6s4D+gY9j8mth3kbfiPitLC6Xb Xay0NfuZW2sGQxsDmQOZWm7AfktYbXatMjTh3ipMOCdXazNliC5PVc93UGW073UCktdYWnc5zXdh CzrmOv2VCwY9DhuaCfdd5vI8Y4VnOwTiZexjDsf7rXTE6z30XI/WLqr6+ol2PHsEN2kljTEaeKWY 5JminFwRFh6/Hy+j/V1nqXPb6pE7B7njy+K5fqv1wd1HL9bFbt2nSZPHdc1TiZOa/wDRUvseTrDS 6Ubp/Sbcl9vqZFWMK3bXm121wPgGjUpcNx4QEcXq4n0PpH1oxBiP+13tNh5MExIXG9WdULnuZdWR M6OMkFU8/FxMGr9Bf9o3AySPTaHdi0E7j9ysYn1dxsp1M59UPYCZIBa7u3VRSxk1Z2XiQF11bHQO ls6tb6TXFx5Mdgug6z9XXdJqa4WboA+Sn9XsarplTrqLKYILYYS+123UyfDRaFGVV1nOFrHOFcAA OEtdA1g+KbPDHgN/N0SMkhLweSyGOrLK/pF4kCDAWaM44bzuc4A+BP3r1PKqwcBwssa3VpGuugXn H1grw/VfYwudOrfBRe17cuGS8ZfcFhy8rrjnDaxpI7lwkn71m2ZdlpMN5PEIstJ7/LVX8Po2VmVP uqre5rRqYViIhjGzBOcpdUWBTmVVWZ9cD0HtBMgODncQFo2dQ6x1bp9uU+0urqcA8l2su8lm19My cpj3Usc9rQdxaNJCjg145ZfXlXPrhhLGtEh9g4a5PFSY+KQcvJyLrtC9xA4BJMKsC7sUUtdJhTa1 7AdORBJCnBAC3UoPXtaIme2on8qd91pYAXaCYHxWi4nq1ghjWENa0NYNoO0RPxPdEyug5AZUBW73 AnjiNNU05YA0V4xyIsNF1t9lbSS0NGghobx5galD3WARuT5G+sCuTDe3ZVnMsT4gFbLRsnJyKtfU cB5KRvtywPUe4jz0CrMI0DgrGfRVjGsNtZbuYHHYT7SfzTPcI8K16LpV3Tm9MyvtVjja0tFbZEEO /L5+CDg9U6NRUPUw3WWSZGm2PiuYc8dhCcWOafFMly8ZLo5CHocN2J1jLZXaxmJUXH3sbJAPAdr+ K2un/VDE6plbMTIL2sdDnFsaeK47E6jfS79HAkQdAdCvQPqd9ZxgODL4c54IAa0ANAE891BmiYEa 0F8PVfdwep/Vh3TS5952iXFoOm4BVukek3JrFjzU1xPva3c5v9Vdj17rf7cvwqLMfbXZYAXOEPAc YIE9vNc/mfWzNoeTRsY2l7g3bW3a2THh3TYeoamwu+UtPK61kP3Vm2WMaGkGTMEw5Ad9cMyisV1t rBDWt9TYDYdji5pk9wquTlZfWbbrtSX62bQGtOswQPMLOZh321Pt2nYwgOdGjS7gH4wp8eKMWOc5 SLYHXMwOcRcRu3TxHv8ApR4SpUday8Wt1dd7g14hw7R81RaGzBjz0UxUHD28efKl4Yjossp2Z1rw 5u7RwAMx2M6eC2MfDyKa8VzLC2rJdtYHOO0FpAcXDiJUsH6lX5l+TUHsH2dge8zoZExqinpvTsdt JuzvYHw5rfe9jf3gAYUOSQsAL4xNNrqfR8v6v22isutZoBax5aGvjd2Ph4rS6X1jquNRRfbm1Flo 2tbe4OceQeBuA0Wf1Pq/1crw7Ksc5Fj3tA9x2gPb+eZ8VznVMvBazGGFv3Cseq53ewkzHknCE/JX HEPo/wBYb6sPEqZVdSW2N0YLHBrXngt2z3WZf9jZj1VXWt3MrdbJl82ECBr2/knuuUxOoDDpGR6j Hlpa01OBDgZJa5nwhCv6rT1G+23I9Ql7DtIPFnaR3CiGOZl4MhnGvF6qvouLkMAxepn3D3Bzo3uk R7ZGkGPihdc6Nfj2vvvyai5hBa0NIlxIAZqNfmuWxerMx2MBoYSJlziSTrI76Ld+sn1mxvrG7H3u NTGVjc1gLod+A0RlGYKwSiejczOj3472nqH7pBJrGxjXnfu3t/O3aKg3Bx86qz0rqQKGjVxDJ3Hs e6zH9Rt6lSzHflWu2vADXuPplpIA+Ed5VLqOKcbJuY0QxlhbLXb2j+0OUhikTrJdxgDZ6v8AY/2r FNuHksNdTWuLWuJcbT5fvePZCzsGyrIrf1MFosaG1bPa3mNxJ7Dkhc415ZW20O2bQWMNZh73tO4F 4mY15Wg67IzKweq3ZBaGE0EmdRppu5B8eyd7YGto4iS1M1n2WxzS7fDiA4cOjSQVFuQ845l4DGv0 q3Gdzx9MDw01T9Ux2synspcHVg+0tJLeO27VPVW92wWNJYHbzAh5bwYd4I6AareqzWVvLnbdGsED dHv01158wjdRtsw73Na4NcHB25jy8cAgbu8I9nS7+i5FN1jRtcBbW1/uDqydN3yTvwWOtsqrc01v kssLHaHkBvf+SmmYCREnZpHqQsIJqr3BjmkgHVzuH8/SCFjZ9uDYTsa+WlsPbuEHyWnjdKzLfTqr oe3Ipc525wAaK2+7UEakHx7J6ia31U5jg9jSA17QS6pm7e4siJ+adxRUYyRZ/W8zPaxrGCprKhWQ 1o1a3udPNVvsGXj4tYFjdmU8g1zBmsiN58NfFeiOyuhdSxHZ2Tjuc6loa4ztfYJ2hxDSFx3V8np1 91T8HGexo+k1zy5rzM/ce6PHXZaA4GVbmUn0nvdNbvGYLPaNe8Roo2dXybXVO3APrLiHgQ9znHdL j3XTZmD0vrLKhizVa1hNrRLh7dS4fAcrPq+rIsY+1toLGTBJDd4bztB1SHMQA1/JecMujksxb8km xmO8g6mAXD4psbCtz37Kq7HuHYarq+oZub9Vqq7acyHW01nYGgyNWkS3T2x+K5QXPLX2sc5h04J1 JmdQU6MpSja0xiC2Lm3Ug03F2hEtc7ggQNJ8EmdSeyqyit23e0B8CdwBkfCEx6M709xkW2AWVsB3 TUQTu3T2jgqtWRZW2ov2ndzH7x1mOUaCm703Bx8q1leTkmtug1aXQJ/ABa+d0Ch1NzcOxj/Tdsc8 D+e/Pbs8HRMwdQs/Ox8TCoFYubfduhzmtPsazja46HdOvwVTIpZjPaxhtdvYx+0t2+5wnjuPApnq Ju13prZF03PyOmW+rjv2GYPBaR4EEFO+y20lzWH3S6G6wJWl0DNsrexjaaw6txc17mFxM6FrgdCI 8eFStOTg5Lzjuc2QZ2gjR41anGYMq6rRGhbTbfaWlwBgc6TCi/NLva0RoNRotrpbHPx7cMtM3luw OA2+pO3cSdRotDG+peW7Kb0+2tlVmrw93cRxI0jwS9yAOyeGRDzerTVtsPv5BGjHTHPh3lGfi3t+ 0+oZFRDZrc3buJ0P8pvwXVdM+otWXkFr8lrq2Vl9r2amtwMFpC1ujfV7HoxMmrJYy2hth2ub/Pbo 9pB/dPgmHNELhjk+fYvRrs1jHMuYXOFh2l0Ob6Yk7p8Rx4oNWNYCHTu+RXY/WPpDcTEbTjihzdzS 187Lmbh72ET7m/FR6g1raMfpgLCKh6j7GMIsBOrmunwQPMCrT7TUo+pOZkYn2mtktcW6cQPzpQcX 6sZWTj35NYhlL9rwT7hr4FdbkfWCno/TcfH9V4Za2Hae9v8AKDudeQsLqHXKG4tf2fftYR6ry7a6 0kna7b3+KrxyzltqyGERu59H1XfflYzLS6v1yXS5pYK4PPhEK1176sZPRrmNrBex5cWOHuftYfpH aOPNWx9dLM+pl7Kg67DYfc549zHe3Rka+azj9ZuoW0DJqyBU5sgVNG0wTEVzO4HuBwpqkTqxnh6P TU/VerPwGZVBcy82TFr42AeOn3J/rr0ZjcjGt9IPIZX6zw2R9LV7z5+a47N+sXVLMdt1zHCmxxEj 2NeWHjTu2VHqn1hb1Uvtm6qh7W1urFpc5z2t9v0uW7uydDDIDVE5gl6LrfVuitF9GLjAuZaGstYx uzg+0Ea/BcgMlzhkuquYxtgaLG2CCRP5mh4I5CqAu6PkUXbmWD227WvMf1XRBBQsi2uxosBLnvLn PBBO0zpr3lWwTwcI+Vi/N08LqFV7g06TySJiB4Dx4Wr1NmXZ0ems2htbrC51JiWkfnz4QVjfVy7H qy6n2hu0O9+8abXaHjw5W39YehZjemMy67vUo3v2NEk7SefmqkwI5QBozRNwQV9Wsx2M6ThZPqMc 4FrmBzfc4QWc8LJryjTksa230yT+kc4fQcD5awqfTr8zpz25tIcPRe2XRoC6YmfFQx2tyLLH2Vvc HBxbtOoeeCdNQO6n9qItjOQmmeV1F11hcXkuk+6VdZ1J/Vsittrm1tcGscWDa0dtxH4lZLWOaQ2A NeSFcwen5XULCypj7In+bbu4TpQgAtEpW9Z0nIwvq3k2Y1mTU/e4bcge/wBIeO3uqf1z6vgW5dY6 e/1WtYNzwCN1n5xg+Ko431dtstAyd9RLXFktgl7RMR4eaHdnYPTstluAHTWGkF4DptH0pnSFWhDG ZE/MWSRlXYLYuDb1EGxprYaw5/vOhDRx/sUH5eVkVOpbeH1kgljGxJA7COyr9W6m3PyDfj1+k3Sa wdwkcn4ErRxMzqf1bxhlUhgryDLXw0nfWe3cQpvbPVaZhbC6kzoofbVh2OrcdoseSx8RDm7mrLfj Mz8plWNIFhAabHbdT2J4Su69mX1Giy0urLzYWcN3u5cqV1L6XAPBBgHXwPCkhiEZX1KyWQkV0dHC 6ld0LLZbilrnsJEFoePAjVG6Q3Gycu1+UfSD22GsNA2+pyAZ02rKbj2Ogtae508lt9FZj04GbbfW x7oa1m50WMc4/TYO48UsgAj4px2S5tWC7qFrotraSZ/SPDO63+i/VWr07X5rH72j2MadpfpyCVl4 LMTDsZfdY2wDXZOp8Fp9b+vt+dV6FAFbCADH0nbTIk8qDIcuQ8MNB3XwEIeqX2OPdVm9Jc5ge4Bz IeRO3a/Xa77lodE6Bl9XqsOIxzrmOaQ5rgA1h59pEk/BYQ6lktrtqFrtlpBe2dHFuoJ+CNg9Vtxv a2w16zvbO8QONCrBxy4fFhMwTo73Xej9T6jm1+lW2w2gsYam7RYadHkt7O/eWPSzLwxfb6Zmhwa9 2n6NxJaND8IQGdUyBcLBkPaZPvEyN3JVe/Kse4jeXAHQ8T5wlHGQKK2UrbDMbPru9jXh7q/U83VF u7d8IQLcS9lLMl7CK7HODX9nOb9IfKVAZdo/OKVmVbaAHOJA1A7fcpKKzRuUdBz8zGfmMqc6lgMv PGkA8/FFz/q9m9PxKM20D0rvoODgTI7Ediqg6tkioU+o7YDIbPtB8YQrM225u1zyQNYnT7kKlafS oF7va4uMHgzyrL8JlrLrQ4VlhbtrdO94d+7p27oGLm2417L2O97HBwJ11bxMroL8zqfWa7M+yitz WuiywVNH0hAaY/BNmTFkgBIOFhnGaXfaA8jY7bsIB3/mzPbxQC0dgt/rfQKOnYmNkMyG2PtBLmDm s/ylY+oPSKes9RZTkN3M1JExMBD3Rw8QXe3rRcau6zJdWBWJY0MBa0NkeLvE68rvfqvk2ufX6z9W NDGiNQwcCQsLqefT9WOrufgs3MredoeA5vgQURn12vqw7RVRUC55duLfcCfDyVPmoTzw9IbGGUcZ 1ew+vmI4V+rxU4AtA0EwuD+r/wBbD9X8wW6uZMOA5Le48FQz+tZ3XSG5F7nxwPzW/ABRv+reRS1p e0gubuEkCWESHAHUhPhghC+I7sc8pNV0dz6w/wCMD9p0X4lFO2l9m5jnH9I0ffpK4txkrZxfq/a5 gtIa8FpMbi2PPRQHS8e30/Tc7dtPqNcQNrgYG13cFT454oD0sWQznu5CS6P/AJtnFLX74J1E7SIP zRb8G61lVGUyqprZcPaGvLXxLpMT5BEc1ArPak8zXU607WiSjP6fkVxurcJ1EjsukHScTfvw3fRA 0LmkugQ486Typ9cdl3mlmRlGyG/om7fotImJkJp5ocVBPtGreUsx7KvpNI+KZlFlgJa0kDUwJhdf n24Wf0+uljW/aHOBJe0VBjWdw887lofV7oFGcy0yz9GxrS0uAdYXdh4oHmjGOo1UMQJ3eA9F/wC6 fuSXp3/M6r/uIP8APb/ekof9JR7L/u/il+q9eT1jLDLMl7Q0H6IA5+S63qfS+n9Krm/Mtp3dy4e6 PLavL+m9Ty8D1BSXAuaQCNCD4gqN+Xm55D8iyyyOC8l35VDGEBfEGxKUiRReoyPRybGjE6jc6uYe 53sawH7lvU/V/pZazfnOsMS6bY3eYhY/1cpFtLacljIt0Et27h92q3c7oNHRm13AF4Y3ZAj4yq4O kjw2B+DLIagcWpaXU/qhgWe+jKII/N9Td+UrQu6I3DwamYrPULns3hz49v5212kLhet9RZk5ldzW PDWOBMiCYPZdx9XeuYPVyKam2B8S71NRHgDKkxi+jHO4jdvYmI3EzGijHYJZ7yXy4cfFa2U0upeN jT7Tof8Acg2Ym29t9TZJ0cZ7BGk+k6eePFX8QMYmJas5cRBc2voeEzFDjQGuDZlv05PmuewXMzc7 HYC+5rWEFheS0HXWJgLezsxl+KanuaA47XAg6gmPaR3WJ1p3Tvq3pglzcgEHa0n3t77tVCBE0RtQ tlJlRBdS36v41ltpsrsbugN2vhjAe7QPxWZi9DPSMx1VGdZWLGjWGvkkkbZVa/qXVs7HN9jhVVaA 0S1xnxGh0QcvF6nTii7EuDnPcJrayXgtHMlMJxiVxTETMdUWf0HMdlhljnEnbLx7WHcYDj4JsHAz sa00Y9gZJ+n+b7Z4Kp9P611XKtDL8izaCC7ThvfQrsqOqUej6NFFjtYB8/3vJQThGzqyx4uHZ53D 691DHc5kNLWgh7zugGOXOA7qjR9fMr1fZTXvdoSN3HydC2euVZbLNtdzwxw2ucHAtcTqQTH4Lnm4 NjbfTY5u7UwQIgCfpQlDJ7YqtVSxmWrZpzv2jaLcwkwS3fBc5jW6yIWkw9OvfXfc50RAJ8O0hY3T 8OzIffWHvYWjcG9tx5Cu1dBJawC5zQQCQByfDxUEjHi13ZY3WjuO6JVc1uQx1jGkH+o4qtV0MiwN ZcXDaXBs+50Ld6a+3qOOMdwhrYBdMn2ng/FSs6Y7pwtsxw02uPsJgemD5eCm+6cYEhsxnmCCQd3C e04o3Fpc6CXA67QO5lDrz/tRioNI2zIG5401geSh1vpOZdnsFsWtdUB7XBo39z20lZOd06/C9Wtj doqfEtkuD4nRRHl6LIM4IdOzrdb3ljMuvTTRp1RcC5rXS4WkFpgzLZXJdFuqqtezMf6Zc7UuBMHz C63o31pw3PIvpDWsZtbsafdH5x+KUsFy8PFMcvpdN32hjPUraYHBI7fFZeT1zJa4t+zl8clp5P4L o+j9TqzGOqcAGBx295HIXLfWPpmXkZrjhlzGNjiWA+fOqUuRx8PFpX7VgzEyrh1dCg3ZdXqtptED tHPcfJNZ0oik5LmEiJLj5eSsdL6xfhY5osY6wyACCHvdPkju6mb8K9zC4NqBDgQAQfAIR5bFWhOz IcmQHYbvIXdbFLtrMcmsGY0G508nxQMv6wXZDdtVAqnk+mHFXrMrCHT3ix59T1Jgth7vgf3Vn29X zs7EubWwupDmbnbR7SBDRKdjxDsiUj3a2P1TKY7+dr/tMA/grDPrDm47gJYfNohHwfq3ZlYDrjX6 j7XBlYaTurcDJJHwUc/po+ruKyhzmm650Wgw702tIjafyqT24nWlglIdXap+smR9mdYzIcDwAdT9 y6XFtrdjEZ4Y57QDoBJBHkua6ZidM6ax9jWPvJgMfo1rwY4BOhCxr/ri/EyXFlTSxrjDHe7TwcUc UskToeIeKsggRro1evuY29+x8DdoCFmbSCLXPmPxRur/AFgf1KihpY1uz1DoB+c6VW6flHIsY1tQ cZ4mJ+9OjjlCC2UxKT231fxR9gsybaJsDmtrHYl2oI04hbWLmuNT25OKBY5/DdGgeAWLhdfy6yan Yz7X7RtDXB21reOBHwWgOuv6FttzoAsY5/p7m72OaQI15JCWKUpEUP2qmABq7Gbl0dHxDkekKpbq Tq4E6Qucoz+k5NlbBc55cZdDTHf5Ssj6w/Xynr5bSWWV0gEuAPuc783y0WR0/wCsR6a3ZSKj7t02 VhxBiNCVJmgJmq2/l0YoSMRu+qswsFuPvHsEEy8wRHiuc6R1V/TM41ZjmknUemZncAQfuXLZn1ld dg00bqxtc4ucJL3E/vLOw3Pstb6bj7tEYmAo1VIqR0u30/M+vOIxv6IEl0wTos/H+v7GU2EM0YWg Ty6TquU+s3QbehNq3Wh+8ToeFgeqdhElW45iWI4qei+sH1nvz7DbVa7aQWx/JPYrS+pWNX1rMfdl M3CPboQzcBx9y4Ou3adZhb/SerZHTKmembWt9TcY+jMR7fNRZJgEMmMaEPV/WbJyemOube99VOwi kUAVte+OHEax4rzhuLde6QHEuPMHUrueqfWi76y4Jxa8Z7tZc5oDiNuogdvNclVnPwra3epaPTcC NdWf1ewKbIm9FaFiOh5h2t9Czc4w32H3H4q8PqllUGMksqJEhs73u07NatHK+vuTs9LH9RrNoEvO 98jk7vNZeJ1Cy+9l5yHsewghxZxHzUUpT+i+Ii1rGMpuIpc8NED3aOmPcNPNd19TwzOxzS+8tZXJ A41dzys/Dv6M7HLcy173CxzwQNn0/pdvFGZk/V1wb6dtlLwYJEulv5FHO5V27Lx6QzzuvZONffW0 NfU4bDImOyo5Izev4rK66GiujTc1pnU911HT83pFLH1+uyykOa5znD892gkqp/zt6ey80Ytwqrc4 CWs/HceAjHDIAWUHKCTo80PqrdZiWXV1gekYcZ93P7q1sHrNnQ6LsewhtMsaLDDjusbMaeAVf6x9 Xs6HkOswMkWNu3AtLg8DSJ0P4rkGPOY97rjzr80IQIG62RHZ7vE+suJ0nCvNOTVbI1Bhj5OkNYAJ Xn+Rni17i4wCewgFEuqYMdwa0FxdAjlZ1lD41aQATyPDsp8UI15Mcjq7vR8LG6tI9VjDvEepY1kt 78/neC6W76hZJDjTXuZ6g2fpG/zXedPpLh8bpto2vfXDSTr8P961GZ+dhO2UZb2NIGgce3wKUjDi q0gSp26en1dKyf1vGcyLDsc90AVN8xyQY4XR/WfqODmYQZWCTtD4Z7XFq8yybrslxdZeXk8lziZ+ 9a3Tqs/1K76JIa0DXRrh+7r4qDKBEHUUe7NA3WmzjZYDXEiY8HGSgU5T6nAtAMdiJH4rd+sH1gty cm0vpbSSILQwTxHdV+h4lHUy6qyxtTvptcQ5zjH5rWt53KeJ9OoY5Gi5DMS7KcYBcewH9wVzH+qX Ur/d9nc1vi/9GPvdC9M6P9SaK6Tc26xr9pG9g2Hx0XM2Z2Pi05bbG+pc4ba3Pd6gDSYMT3Q9+Qqx VqEInrs84/6tGvR+RRv3NaGNf6jpcY/MkfitKn6jnHe1+U8OrkiGHa5xA4BIMLR6a3BqwmObYRc+ 5u+sD81nB17jsiZuay/qNuPk5Tm1bifUIII9v0dojyBUcsuWXylfGEBuHPAw+lP2jBqBOoNjnXO/ 7638ETFy8bIyha6wVFghpbFcfBrUF/UMavGtrdUXOcCGPGjiPCTwssZVmJDaK2wJhzmguh0GNU3h lkjqdUGQidHp8rpuNTl4xyuoE+qA9rw8ve0HUczErksvCt+131VOkNeQATq6CquRbabC52jjBHkV GzItDy42SZ5I1U+PFKJu782KUrdy7o/U/qvbj2veKnWjcDMxtPDgms+q+Vk1/aBkVCq0l5c+1rGk gmZbPPyVbo/VqaLw7Pp+1NII2knfPaCfNU+rdUbc9r6qm1kyXBrNu08bW6nSPxUgjPiQZCms7Isw bLa2vDgZYXCC1zZ/NJC0eo+n1GH4u5xaxvtFewCtjBueYJ1nn71RwuoV0h1lgbY/VoZYyWBrgZdI P0h2Vq3rtxLCwsDa2+mysA6sJksJGpB7p8gb2VHbdnZkvssrtusLvVHuh0EhsAg/JR6zk9NuDfsW O+vaTuL3b5B447hZNl5e9zw0Mkk7Rw3yCsZWex26uisCsu3DcA6z6O0gu8O6Ixm1thruLYnspYd3 pWtdsa+DO1wlp+IQWiRC2cXHwb6WbGOFrA51gc8gPaNoDa4B93KdI8IQHONZLjpp3Wh0BmJVlD7c f0Ja4Ogbncfm+fgU9+A2+yKq3VVu/Oe4vj4mArHVOi19Mq+z+rW6zfLjBBaI4DpiFDLLHa14iQbp zi7HZY72ue33BomDBB2knyWr1LBfi4uO1tDCXM1cY9SSWv7O+Q8kFl+PjU1MdZWXVHcw1NJfvMGX OIgjThV6jZ1TKhkl73SXO9rRuOrnRoAhZK41Fa85GIxrhLd4LSAImIKVAtdQ+t4ID3NfJkHSRp96 v5ObZhXPq2UvDDthp31zzLXK313N6l1huGLMeulrmH0ogBzZgkn4oWa2V6e7Wx/q8/LyW4lFjbnO ja5p9uonX4d1fvxc3onoNyWh+wuNbX+9gAMGAexKBkHqWGMPIsyGj1B6bHMMbWsOyHEALo8rLr6X RQ1mXTa90ndYfUZUWE6ag6HsmTMgV8QCGX1TyMO+5wzW4jBECWNbJ8yVTty+n1MBDbHBhfVaWiWe 5znNawzAHKyut5R9Omwvpc4OdOxm2QHS13aWuCrO6jf1D1m+m0eoQWtaIZWf5I+GiadYoAqSs119 xY/UgN2jTho4Vy/NyqcLHbIhhOz26iTMz8Vt/Vfo1mUwV5TQWvB1HLI8f4Lo8z6r142MxrrPZUA4 6D3EH+5V+OcroWBuy+mJ1OpeAyOs53Vj+sXlokkljYcSRHbsql2I/CscLrG1vpboWS/1HkztkSNw B/BbHW+ov6ddWasf0q3SWlwDt9btNR3XMNvyXNNDSdrnh8Ry4aA/ip8VyFnRZMgN/rdeO15+y2ex lbCSSd1rnQSNNNzZ/BafSsvDOAGDGNt73lhBB0YfzmO8Vh2E9Pday4NfY7dW5jhoziLGuBiVu/Vq m9mDdaHEsqc1zdkeo252ntHcEaa8I5AOBEdZOd9YKcbppqtxGWN7WB42mTJ2yDq0jwWfXl1VV2WN pdW93tYQZYA+d7SHTyDogdRyH3XF1zrHwY9xlwbPEp8it7m1isiLRO3dxs0908FSxjoFpOpdjqFn TuoY9LMU+i8wbaz/ADIcARua46ydNPNR6r9R8jpHo2bq7m2Mc8Q7a0hjdztZ5hYWFiXdStbTjtLn kExu8BJ5hSya7RFVtshuoE7gPgniPCd1hJLr9LxbaGM3Yh1FhDyCZ+i7Q+AH5Vj09PGS22zexhYd Gk+50/u/BGxa3Z9janXOgA7S90NlrdBrxMQrPTenPsf6jKDYADubrB7dkwy4CTa6Mban2L9G0kj3 GBLtWkc6Ld6V0Ozp+TXkC5pc0t2FjpdLxoWiIMeC3OifUYUeq7Pc1pYwFonu4SD/AHrosfLptJrx qxtJaGggex7T+YPioMucjqzQxW4ON9U3Om/IvcKw6yC/2GzadBt5aVbr6PXQ97cMC5uRWGnd77Ky AZcPn2Wjb0x/VL9t7zLj30+j/J8VfyhR0Wpgc4017vphpc97o8uJUUBLLZAoL5GMKF6uVR0unp1F DOoOYRjwWNAHu38mfEFY/VevDqAdj35FbGyXMe6d+09tyr/Wn61dMzsZ1FNVrbWvDhY8eHPdc/m9 fxOo0s+1Vu9VpaN4OmzuNn5FIcMyfDwWjLFOPrJV05ltbCXF4IlhLQQf3p1Qz9bMyyl3rObbWXsD 2QG2ERwHcjRsSueu6uWuPosDRxMAyPHVAfmOsDva0lx3EhsFp8oVnHygA2YZcwS2f2kXWHeTsnv7 iB4LXzOuMyPQbhb2AFwtfM2u3+12vMbey52gVXWNFz9jNZMbu2mgRvtdLGV+jWWvaDvJdIdrpA7a KWWEWKCwZC6/X+n24VrT6jrqjHpPd9LYDADv3fgqVvXPUdSLKQW1jaWgkbhEc9k1PX3lppt3Cp5B eGfSLm/ROvgVVxOn2dUyGY+O0l9hhocYknzKEMZ/TCpzH6KBmSWu081Ku6+QWyRWQ4Efm68z2Qsm h+LY6t4hzSWkeBHKlj5VtDbBW4gPbteBw5kzB+an4QxiT1OP1vD6vOPmMcGuBLXggmqw6usgfSmO FhZ2G3Bc/cWP42lpncDrKos/SkNAAJMeWqI3AtOQ3HO0OLokuG347uIUcMIhsdF0s3FuhfW9rQS0 gO4JB1jwU8YOJgT8uVf6lVn0Vejkv31U2OY0Ne1zA86nbHY+Kyi8kyNPgptSGPiALffR6FpG+C0A lpJndMFvxWvd1vMtrbj49VkV6ukE/e3sFzTbXNcHTrMrVd9auovvsyfXIstZ6byIG9kRBhQ5MHER erJDMBto2+udQ6jghuJk1sadodoAZDvcCsujqQp2ltYDxMvHefJWOo5OZ9YnnKe3dta1jiIgbRp+ AVXMxKcJw2Xtt0aZZI+kJI1HI4KOPHARqkTySMrtsn6z52wsa9oBbsMNbMTu5I5nuj9N+unVOk+p 6F5HqTMgcnuNNOFlUPrqdJZugggz28IVqqvDy7Buf6W6ZJBLR9yNQh+it4pnqy619Y876wWi3LuL 3NG0fmgD4BZp0WiG9NdIc6xsDQgcu81o9Fwej34eS7LyCy1rZpAH0j4FH3B2K3dxMHqFvT3OdUYJ aW/JwgoL7n2aOJPdM8CTCeul9zgxgJJ0AGpJUlAaouR0ZHI3BgLW+3yjd/W8VLNzH51rrXBrSY0a NrRHgEOyl1Tix4II5BEFMytzzAEoVHdVS2WDyO5S3Ed1Zb0290EVu140XQZP1By6cSnKaWv9X8wH 3N/rJks+OO5ZI4cheW1KZd19Svq9hXvezqDAXHc0Nc7aGns6VTyvqjTj5DmWXBrQ4iZEH4KI87jB IXjlZkPIwptose1zw0lreSBoPiuxOF0/otWTW+pl/rMApIeC+t3d0eCxMHNuwMeykuirIPvEj3iv sfgU+HMDJG4rZYOA0XGiURuPY7hp+5XMa2vGvFoax4DvoOHthdZh/XfHxiw1YFNbtzt7h7prcfog O8OydLJIbBYMY6vPdA+rVvWcqvHeTSLJDXuadu4DRvzV1n+L/qltd9jK27aXOa+XAOBbzotvrf1y xLMc4rPVIre2zHfLWFvjv29/BQwqcf6w12XHqDcVpsgsseXWlpjvpuURnk3ZKiBTybOkudu2DdA1 nkFLK6dS1rTSLSQ0bpA0s8o/NXe4HSOkYeNl7Mo2XVabhGx1biNQP9qwstnTx1K3Gx8loqLSWWun b9GduvnomieUlb6XM+rnR8DLt9PPtsqc4hrGho1J8XO0C6X6x139Dwauk2VMYQQ/1GO/nWzpPC5r Iy6MoUNdR9An1LGO91gJ00cNIV66qjOpa8ZJY8AxVYHbGNaCQBa48u8I5SnciLXwNOTl9Vc9wAAg AAyQ4afNXOlZVlttePQ817ngbx9Frn6cgHRBbgm0TsHtA3GPFWszoXUPq4Q6yqyoWfRLToe/Y9k3 9WRQR6gbZ9U6XdjWWU3Q97CWlztZ+Cyxhw7ZtLANHEOG0695XSvzcfNx2uzbMg5GoJc3T04lp3Hn VYOW8WXAt1boTppKEJSBpdKiHSx+l41rHZDmMLB7RtcND8JQs7oF9tLcnY97Ihhlx3NH7vwWNmYr XAGpoDpMweZ8Fo4ORmux2UOy7a62AnY50ME6e34yiIGIviWki9m5X1WjHZX62PcGMgugCNdCVn5O fi5nJ01LBEFp7dl0uZ1D0OnXMxbGZRyXMaWt+mxjANoj46aLnc0ZONU192E6tri4Bzht97NHD5Jm KIkLrXz/AIrpEtLItuxxLLA4Bw0LRz9y1cb6051gNuayvIZ7WkvjcGt/NB+axLxayjcS2C7Uh3u+ YVcXMNLmOB3bgQZ08CC3+Ks+0Jx1DESQXresdMwraGdSY2ummyA0t7PjVgDTyO6wMq2tu30H7zBD dToI81TGPb9n9T/Bz46ToOJ81M3b9u4l2sRHHwQhh4OpKSSWF999tbGvGjdAY/itK76x3ux8aqqm up+OP51g97/Au5Rs3Pyeo41OIykV0UOJYJ9248uce8/gsrIxH41kWTukSO8J3olVgI4S3P8Anf1b /uU/7h/ckqW2v9x34JI1D91VS7vruH1fouDWWX4oY9vBIne4dh4InW34HU66XU0FpedGiGe0fnSF g5H1UybG1W+tvLxLy7kSl1volvRnin1i87QdBESsoy4oU3QAJO31TLs6VRVQXtc6sQxwIOzf3U7H X9Sb6WQ4Fha3aS6YIEErNyPq39lqxi17ib2S8O1906AKHVOh9Vwoqkubt3xWTMAKGUDxEWf5bMok He6l0G9+Njs30FrXNrADdSXGCZ8Vd6R9WndHsaS9oZroYkn4rB6B9XM14Zbc4locSWOcd7IGhV97 M7pjC/KtdaA4OrBdu8Br3Vge3HUgsJMpGrD11RbWznhRtyAwaaz4dlhXfWWxjtldAIdBDpEce7Q+ EIR+tTMq0VjCeZB1J7gTwJVn71AigWD7vO7IdvNxqn1ta6YJkgd/uWX1L6v4/VS1oY9joEOAjRvm s7M+ttWBk1MZW8tP0t4Ic3xACsH64svzPQqcK6iD+lcD2HggZYpbrhDJHZj+xLRZ9ifdYa90tmIb 3HdH6pU36vB1zK7XhxJcWWbRPwXJt+sOfkZbaWZZG50F+oEA6H4KH1m6lmtvdiXZXqBgJlv0dQgP bA03SeMlqV9Voy77GVUXzYCGAWbveT7Zn81dTX1YdLxaRbjuqc3Rz97fcQYOodqvNqL7Md7XscWk HRwOoI7rVvozs3FNzza+lhJJdJaHu1PzKinAL4ykXseodd6f1F7WNsa0EiAJ18CeylX1XCqxn0Br SW8vbJcNeZIXm5vBc0AEwI4WphV300WO2nY4AGDuBgzBjhMlj4SZXqWSM+IcNbPWM6jhW2h4dbuL 90ADaFY+s/WB01rX4NjdWw6RuILuC2e687ZmWVE7XOE6e0wtHp9X7UzKq8gvLHFrXQS4hqfCAxhZ KRmXoqPrXmYdlJfkNe2xvqPLGgmBy13gUOr62dQcz1RkMBJLTu2ztB/d+Cx7enl+TkjFaX1NlocB 591DqnRrelhlmQGtNg3NAdqW+MI+6ToCj2gNXY6h9YndQrJfY1uxxc0G07tw19u0a+Sz2fWKrKb6 lulvDnPtskns8Bp7BR6ri4zq8R9FbmNsYRJg77AQHEeAV3pP1QxrDXZlWAh7oLGjcW9vc4aBM0G5 P2ruA9HL6tmY+T+kpYHvLhueA/cY5dud4q70XqNuPW1n2drt3ta4t1LneJK2m9KwsPIeMOl9jWNc HNfJb/W8oSbbjuw8XCD21gve4WOdI3DvKilOEtN2SMDHVLiOupvtbcwVGse4l5gk/mjxK0WU43oC 9j32tbo9peRq7hccetufcGkF4D/cTrIHgi9Ry7Mq6xmPvZSXN2zzp47U2JMfJeaPV6ZrG/YXNLi1 9RNjXNd7tT4jwWa9+Ph0WtubbvcWESY+lySEDptOdXXbXU4bbBtd4kfwR7fq3l5U3ZFpEAe55DRD fNybxGddV3y+CS3pePRj5NNljC4+m4RD3Hv7TGnmsJjaRXbjCx7WOc1zgSGiWyB281fP7Oww91+c wyeKmmxwA/laNWVi9ewbLXU2vs9Mv0e6GnbPlMKQYc3QUxnLj6vU19WHTMZoZ+jqDQDsMlxiN2ms lctZ1LA6zf6QqeHlxDST9Jzj+ErI6znYb7g3Hde9jSQd79HifzdNFlevW2wkM0IMAk6T5jwU+Pk5 fpSLFLmB0D1o6MRQ+8VzXvNcl7W/pB+aNdVB3QLHY7b7GVVAzsa58WWBv0o5/FcnZcYDGuJboYcd N3fRW8rDux8anJt9QNtn0y7Vro5LfJWvu+IVuwnJI9nVZn9Mr21WYckOIJfcQ0Se+1vZEyc7HrDD R9iq2+4bWvtc4iRtcHz+K5WtxcTGquYHTrepXMprEvscGtExJ+aPtxijiJdKn619Qx2sZVkOY1jt zWthrJmeByPis2/KdkPdY8klxJJ8yreT0SzA2tucwF06BwcRBjWEEdNdk2MpqMvcYaPFN44lXCWt vBPdSABV09Iux7TQ8Q5hhwke0+atv6QxgYd/P0yBo3WNPHxTJZoDqkYpFzABpou1+ojsKh73ZLDG 2f3uPzo7fFc63FwmPg3kgTqG6nwVjE3VB/p2GC2HAEwR4eahyZAQy44EF1ev49fUMq0tftra1rmN P5zXRHpgd1O76h3ek59L9zPbDnDaIj3TPgszApuyHja5wAI+iJIXZH6ysbhfZw/SC3dEvbHctKiE +HS2QwMtafPLcAV2FjXboMSBPC7DpmLd13p9OCNnptdo4iH88rLrw/WyQPVYQ4iY0kH5aL0Knp+P 0Sup7nENHhz4qfFPjPluxZI8H1bPSOi0dAx/RpGpElx7leVfWLorMXIdvtDXlxJbtMCTpBHK7/q3 14wMZj2F1m6NBsIJnwK4Giw9WzA7IcWtJ0DhPsJ8dPvVvJOPRqwxyJeg6Gzp+d0/7DnmuttfvbYH em5+vdZmdhfVzHP6PJsedfaxxc78i1frN0ro+HXWG2Aks2g7t0Dnt4ysWz6oYGLi15l2Ta2uxsy1 gfDiYjkdlEQImiyCJIsO9hP+q7MRot3NLpkvDt4I+C5rIv6DYSxjbwS8jeXDaGdidJWNmUFhEPe5 mpYSNS2efLhUyAPzymmEZLhIh6THd0apjg6XFzXO9xMtc0w1g2t5dyqT2Ymc7e62wOcZLAwQP83R Z1RrYxzjYNzYhpBJfJ18tFebmY+ObjXJcNhYZIDhPu9sKOWIja1wle7vYv1Kxs/EtyGXmp1Zgh30 AYnVx8lmdL6LhW7zk3bACA2HfTcew0KqdU+tmRnghv6MOA3hvD3jTdrxpAVCvPZWWOAfI54M/eOV JDFKtSxyL1nTsvpnT32WX4gILdjaw4uhzeXEnu5Vs3qHTLcr1fQcGO1c31TqSB/J8dSubfmB1zto cAT9EkT8ytHp3TftFbC6ytkv3F26bGhvEAmE+hHdYSXfq+tnRW0V0nAL21giS/3E6SeFTy7vq71L KDmNyqg8mQ3aQ0/m7Rror2Ri/VzpgpFbzfYHgkzPGpkDx4RD9Wbep1DIrsrpFVbtrRWQSNX89z5q LJljHSv5fRlhjJF2899YsXpGC2pmEbXWyRa2zQiNOI0Kt9G+tVnTGNY7G9XaBs3WEBkd1dwPqUOp sryHZYDrBJJEwfNxWg36l09LY4vvZZIj2H3eOoMqHNkxyhZF0yQhIGgd3msuy7rmT6n2SAdC1r+T 5Fyzsis4ZaQNR2Dpha1lbbs1uGywtl+2dw0/BbvUvqTiY9gquzNs7eS3jxhKE+EDTRJhxddXC6d9 bbcGuza+0lw2gE+1vwErOvdblHewGXGY7ytO36rYLLHsGaCARB090/NWemfVYX3Mrx8kF8yCHAEA d+Ufcx8Wm/1Scc61eexczKxbmPaCHscCNO4T9X6nk5eVZdlA+o+CZG3kaaLoh9TbjdWWWiXF0ku4 290Wz6oXuqNrsih7nOLTYbN7ixw2xDh28VMJimGtXnuo9UZnMxGVB01U7HSI924nRWOpNGQK7ceo saKmNduI1saIcfmugu/xbWH7QabATWG7ByXkgFU7sPJ6JRjtfWQ6CXBzZa0tOnkdFFknVUPtXY4A k28tccg0zZDWNcD7Ymfjyg5NuCbbDV65YCNgdE7fztx/Iury+i29bx3CoMrLCCSfaDpwsHP+r2X0 3DGVa14a520HTa74EKbDmjMV1WzgYtfqWRiOxMX7O3Za3eLJncfdLHTxx4IX2C2xxFtldZ9P1BLp 37hIGk+4rOtvc8y6T21RR0+2xm8zx4KxwiI3pj4rLeFdfpCuzY1wk7td5ngKQw3VbXV7i7RwLR4d xos84V+khxPbyhORk1nb6rpIggEpvD2ku4vB6I/Uq4Y5zMnIqrYXtaSXbiC/WTt+9VXDo+PLdjrS W6ObYWw4x2LO2v3rCtuvALHucRzBJhCfTZW1ry0gO4Mcx4FOjil1kiUo9A9Jgv6ILh64ua0ESBDp Emfv0V9/WejdJzXnEY51fG92pg+Df71xlYsscANSSIU8rEuxLX03NLXtMOadCCmy5aMrBJVHMY7B 6zK+vjfRbTj41YDSS0uEv1g6n5LH639Z8jrrg+1tbSAB7Bt0CxthKn6Up0OWxQNgKlmnLctvFsde /VzRJ181o4tlvTry+skS2HAEjew/SaSOxWRjsfU8OAXU25Qz3Mdi4zqnQwF07tWzuMEd9FHnPCfB YNXCyMqs2uLWem2SQwEkNHgCVrdU6xVfi9PY2yTXS5rh+6S9xg6eCrWdJD3F9m6XGdTz+CE/pdY4 B+9AZcZC6i7+TXh04eAM6whmyx0Ulj7P0hBbpu0+apVnpGLjl/rXG5zXbK3Vgsa1xIG53fTwWNZ0 6vtP3o+P0yuqttr9zidwaCPb7RPKR4CEgllc5jw2bDoANdTtjSPALY6Q+naaW5QZuLXEkQZbxtdE jlc7bT6RHnr8PJWsewU+6FHkhcdCvhKi+xfVzAbjsFrst1n9qR+RafUc4BvpVPAsd9GRP5V5d03r +Syutm8hpd2PYeS7jCy8Pd9oyZ+iYcZI0UGPKYD2xpfVdKHEeI6vNdf6tn5Fwwcuhhex0NIbqZ4V 3F+pE0Gx7XeqWGGtO303zofhCrdT65U655aHF28ObZI3NDf3Fp9O6oMOu2x17qWvbLTc0udYfIhM EuKa8xIho8v9bfqs3oL6nutFrniTJjjme6p9AzsrFZkUUMDq7W7X6EhoJ0Ongum6l0676zvdZW4W MqrETprHP96ufV+2vFqsxLWhjnOa1pYIDSO5n7045QdB+KwQmNnmfrL9Sz0ltT6T6xe2doGojlYf URk5zcfEfU2v0WloHDvcZJdOsrtetYWb0+1tlWSPRudt9Rx0EHn+T8kLrduN16/GEuYxpAuucBLj ETPwCkGQx/tUIHZzukfUNl+K12RZ6Vr3RWWkHcI42+J8fBO76jUy7Huf6V9Ye9z3H9G5v5gHmuiz rW5FtLW2tmhsNLRO5vYiBzCr9ZxndVuY+sGs7W7y4klzmqGXNgHfVmjy9uf9WOiVdKAszMch3qtL XTqxgbunb3Dl0uEW9KxMizDqBbZY4MJjdr5Ku3Cy8qmulwJaydriNuh8XFSYcDpNcZOUxp/dYd5/ 3ppyZZyuI+uyRCERR+xfG6d+gD7LAS4ncCNW66QVq1UtxmE49OxmjnPd2I7t7rDP1x6fSCcah9zm jcS7XaPGFzf1h+tua6ut9jia7gS1ocOAY1a3j5qTFhjHbU+H8T+xGSZkNdv5dnsGddwW47nB4+02 hzQXSYefaPguW6Z9b8jEfZidQPqM9zQWwHsOv0fOVyl+bkObuIMHUR5rPfbYQ54YdOTrpPip8cJk VowTkL0dzpWc7HGULMZtxsA1sGrCDMhE6lmY3UqrK2dNppe8Da9jne0g8wfFAwn5OJhMsL9jMl72 Oe6su27B9Jp786jsqfSb8rqOVVjG1lQcdoe9oDW+ZT4jICapaeChdpKOnuq6XkMfjscXPG24n3V7 dC0DwKwvsVjToV0Nl/VMj7VSLWvro1t27QC3dtLm+KH1+/APo/s5tgIZFpeIl47gdpT8cso+als+ DpbiM6c97mgmJMK90fpFV+YxlpJqD4eRpA+PZRy3Cq3ZTaLWwCHBpbrGog+HCvdJ6nkYVh1bsftF jDBa9oIdDk7JOdbsYMbdPreDgXZbMrKY6im1rWhzQIIr9jnho76SuWyb91ljq7HOa0hrX/RcWt0b +CtddLs3LsfS32OcdrGyWMn81sqo7HIqeLWPa7T09oAZz7t38EcUaAs2mRJLVta1x3B8zrrz80zW loGx2pEHsrNXRcux9bBU6bG7mA6b2+LZ+CvdT+rT+j042RY9pFwJDQfc0jkOHZSmcRpaBAnVoOyr m47aNtYaCTuDG7zPi/lU3NdyuivZ0zq+QTTOJWKZIdLwbmjj+0pfZsIdKbbfi21uIe2u5plltoP0 Xg8QPBITrogh52us2yBMxKsHErfYPQLrGe2Tth24j3CNe/CHjHY/3Etbw4j6W0+C6b6v/WLpv1bu NtIstkAEPY3sZkamD5oZMko7BMIAvOXYPoavO2ZIkH7kL7O+B7TDuDHPwW51/wCsTfrLlerkuLWN B2BjG6TrHZU8jr12Rh04biDXQ4ur9o3CfE+CUJTrUarjGFtP9n5TbfQ9J4sP5m07j34VYgtMFaF/ Xs3KyhlvuebgABYDDhtEDUKk53qEl0knU/FSC+qwxidkaM7EubtljhvEt0Pu+HiogBbI6nl2DFFl mmP/ADMj6And+VCc+FdDGDu432ezf6e07piI1n4KT8W2l7q3sc1zdHNIII+IXTdSybhk1dSa91mQ 473/AKOGseDp2gyiYberl1vU2Vki3cyyyxocP0g90g/govvGlrxgFvOYuHbva/ZIBBg947LocfAs 691Zrun1MoskPbWw6NLBJIJ+9an1K6GbsiyixwLLW7XBw7TPtPY6aFLqfS6ukdTezENjGgna5pBs kcqvPmQSWUYSBo1vrZ9WLMN7cq60ZD7iXPeBG13fcRpK0Pq39XsW7Gc+R68kV1xrZPgquf1mz7Ec QOtcC7c9hrEuI1nTwVLP60/pNWM5lV1VwLbGuf7Rt/k+IPioiZ5gANmSPDj3ezruLG04VlW2tr/c 8N1b4ie/wUepdawvqxdvDxaTrtLCZB0nwXIZH+MK3qG5lodW3Y6DURvNvYku/NnlUj9a2ubi+rQy 2youD3WEubc13AcPJMx8hOwZf2rpc3CjX9j0r/rC7Pc2rpNddj3gu9zfc3uRBXL/AFj6dnGmjOyr GOFwO0B0kbTqC3ss1nUnND2VVgS4v3Mne0RxP7qp25T79HknwVzByccJsNXLzMsm7F7y4gawNB5K MCPPwT+0s77p+UKYqfcN0D2t7kDQfxVvZr7tp3TWjCbl+vXJeWGqf0jYH0iPBUtfHhQKPg4v22+u j1GV7zG952sb5uPYJVSjIFFv4nsr2DRZ1F7aamTY5waNYEu45VZ+G9rnBsO2kglpkaLQ6T0F3VKL rK762W1kbanHa+yedpOmibIxpQJS037z6bzXWa27TE+5ze581o9Kd0nqlFlGZYartXV2Nbu3Eaem R5rlnB1Ly13IMFRc6Uz2QTa7jbd7XYN9jHk7mktII7g/FPn9S+2NaxrAxrew5J8yhjAyLKHZDGPd W0gOeGna13gSq7nAgCAIH3p4jEm1pkXRb9ZOotLCL3ewEN0GgPbhWL/rXlZpHrtrd7Ws+j2b3EHn x8VjbBEzr4IlV+yJAMCBoO6Bxw7JEj3dHJysp43Ou3aBgkT7RwNfBH6P0izqWXVj+sQHnmPLzVRv V3VYtuMIc2xzXGWjc0t4Idz8k/TOqvw767Wue0snVjth1EKKUJ8JpkiY8To9d+rr+i2bX3l0SRpz CzutXYmVbWMJj2t2NB9R0k2R7j8JXQ/Wz6zdP6rVU3Hqe14G5zrHbnGRxMlcnjZXo2iwtD4jQ/7E sEcgj6tSnLw3o9L9S+hOvzG/aC+ljfd6gGjCPomVds6uen5edUC3LbYHNFlpl2v5zZ0kqn9X+t5X uxvX2VXkB4OvtPmeAEb6zfVTJxbbG0Pa9jHNBdIZrYJbAPZQTNzIkWaAqOgebz8cyHOe06aNb+b5 FG6ecdlNvrMJdt/RjbO6w+fgjY2Rk9HNz666w5rDXYSA8bX+2fcqmD1GwWU1PsIqbYHQfotkiT+C sUZQYJaST7WUScmra5ugrAEud5+C1+lfXLC6ZUys4DXhlnqAOg7nceC1Oq/WXpvSOtX5La6sxlrG jQQyC0Tz30XBZ17cq59rWhoc4kNHDQeyZDCMvzBJyGGz3Q/xj4hx3Ujp7CS5zvdDtzn8yfmqDs7p XVXm3PacWK9rRW3cHvYInT8VxxdIAgaLouk9PwOq4P2etrznOf7SSG1emBJknunSwQiNFozFsbfq /wD9ybP8wpKP/jfdT/dr/wC3a/8AySSHtw7lPvnsHuOr/Xfp+ZUa8euxjtAHR27hFr+sWFuY8UZT iGcObu4gzqOFyXUvrm7PJaaW7HHcQGBh3fELSq/xmZFRrc7HDi1u3mBtIa3/AL6oIYhK7AC8kxGh TdY+tWRmXstYwjZoGRtaI/FX8b6zdT6jkMeaqt7drWNf7S4uP5q5rM+sTs7JfnDEis2ydTEnXYSN J0Wxn/X/AAs1wecJ4e2Njg8Atj4BMGI2V/ECHqMrJ60233Y9DXaCQ7z+HisLqt3X7cqlpdSwlx27 Y2hwbJ3aeCFkfWu7Nos6hVi2bWlrHvNrYa7wDQ3uuPu69mW2eobHTJMz3KcYSMjqtFAPcMyOo341 VD8KmzeHbXT79Oe+nOiNjdYwsTCBJsZc5xY4mS5gGh2k6Lgx9Ys0BoD/AKP0dePggv6nfa3a4k9/ pd++iaMR7BdY7vT53UG3Zfqm5pZI9zySdo7O5P3FWX5HSrS212aGd31tY90T+6XHlca3Ltg+fwKK /qeTcGtefaABpA0HwS9pPH4vQVWYeTmObTbFQkNe9uuvAcPDVa7/AKsUu2WDJZbujRhHtnmQdYXD 9RyKvWP2Vr/T0jfG/jWY81HBzG0Oc+9j3jaQA1xYQ4j2mR4FOGIbo4z3ev6l9XMLp1trbrC5hILC 0thxPZxBO35q51DrGPhYvpC97922ay5oPs4HtnwXm78gmZJ15809d4LhLvvKE+WJO5pdDNQ2fQMT qWDmbn/Y6DLtQ7UtJ/gtrpv65j3UY+MwVEguLYAJGvdeddM6tdg7zQWk2MLDI3aHw81cxMzMrG1j T8NpVeeExN2yxygh6bKbhdMxqbra3DeXCAxpnasujqeM3M+00mxj4AYQNR2/IqeV1h9tVbLbQzbu 9pGoM66LPZn0Nsh97to7hp1KbDCdwDa6WUW97h5zeh4ZcwNeboc4bhI17hZnU83CyM4G6r1WOALn AQ7Uat92mhWMOsYDcT099hLnhxIYA6Y+jJPCpZHV6rGkNFh8C9+n3NCcMeQiuijkiHoqs+g021Ow wf8AROGmz8qezrNgqoa1jG+kdCBJJnv4rFx8+j7BfeXxa2xja2aubtdMnX4KfTquoOa7IrefTJa2 wtjSeJA1CbLCQNSoZbdbPyM5j7clznneIeWCBtPw7LKyRXhUV3M2uO4+3cC5veSJW71n6ruzH1VY 2X6r3Vlx3vMNDRPmvPbch2M4tIBgwSpMWAy3KyeWnaxevV1OPr1tcNSNrQHfMlauJ9dK6GiujDYC T9KxxsOp8BtXH/tNzWuY2tkHjcNxHwVe2y6nVwLSRI0j7lPHlY9gxHMe76h9aut5HS8Ol+LmMDrB 7m1tazb92q86zetZOU7ddkWPPm4lUbMxzoBMiAFWLtVPiwkDVZOdnRvDPMEEkyq4ubul0keAQjW6 N0GPFR0HZSjHELDIto5TW/R/FROQ13gPkqxSJR4AjiTtsY06uP3I/wBqaAIJI8DqqTQTwpQO5+5I xCQUnrEk+HlotDpud9jsbYyQ4EFpBILSPArOYN2jQSUUtdUedUyQB0UH0iqnpHRqBd1FwyH3tD2i ZdXJ1HKxeqdSovzRnYbC1zXNMtG1rdvl2XO42RQCBkb45loDjp8UC23Y53oWv987gRt07d1WGE7M xm7XVch1mRY4uG5ziXEdyde6Cx7bPpkjy3GFjufYwy+fn3RvXrsYPbrPiU72KAR7mr0TemYbwHsy NP3SNQt3ovRcKzX151jTRcLi30i33tADtCZcdo8Y7q9h5dbAP0jhx3VfJglWpJZoZY9nuOp9AsqB sxrgQ6BA7kfBYj8e8H9YhsSdzf71q9I65W+lg3eo9ohoM8+EhGr+sjLC5ra/VLjrjvbDmtjUssGn yIVYRPl5sxmD4ubjUvpDraLWPcI+l2Cvv6jfksYLHbmhoBHPu8QqxyMN1pfXj20NB9xiR/ab/ctK /qXTqarPRDbSWtJ1j3HSA1KIIKidNnleoYBudPA7Tws3JrvqcRI4010jwC7JuJQ/GFz3S4auazXa 3xPj5wsanEp6rktxXObWCdbQJbtie/BU+PLMy1YpwiI6ODZmvukOJEgDTj2qy8ZTsAWOyd1TbNgq LzMxO4M8FtZn1eHS+nO9Stu19vsv13FoEBob4Hlc96LQ3+c1kiIPCtW1jYZ9J6lf0q021Ma8ljmA PG4e4RPxQz0nKOOcx9f6IPDC49nHXhXMajGqpa4bzcLN27/B7AOIjmVrW9Jz+sP91bib3erA9oM6 bgIgImVBERq4hxa8Oz18S8PLHN2Ashx84OioWsvBhwPtkRI0nldH9Zvqq3oLKi8gueJc0Gdh8J7r mjSezYQiCN0mQQvbPM/goBvC2uifV27rljqqY3NaXGTGgQR0a57vTZW4mdYCRyxChjJaFWMbSABJ 8u6u5X1fzMOll1lZax87SdJheg/Uz6s/Y6XW2OZ6r4DBAc9jm+4GeywvrfXmXEst9UhpJAkbQZ9x ACj94kjsWT2gAe4eV6ZlHp9hcWFwIhzeJ+a63A+umLRi21P3hxa4NG2R7hAEq/0zrGH0/BpqfhUv saPcXNBLhyCT4rk7epdPsoeb8MOc57i3Y41hsunXx8An5MOPJR6rIZJR0bnT/rU7p9QptI2hh27d dT4qn/zjybXNdZa4DdJ2hoBH3LIdi73Aikta76IJP8UQ12sLQA0CI/e4TPu2IG6Xe9Mt6oAV+oJE u0eQfu3eKJblU5HqOyHlzgJZ+cS6RoZ4ELqfrPls6n9XsT02t9RtjQ7a0tawhpED4rhm9NveZBnx 0R4IXZKDx7U7XTMCrqDLLdtbRU0EtcYJnT2g8r0T6pdCxKqjkNqaHEAB0du64zoH1fzbcimwuA9o iRpDj5rd+tPVMnpgbjMDWFhD5Y77uVFjkPcvcL8kTw1sXumY1Vf5re/YBcT9em1hm2i2urYQCB7X z4fBc7h/WTqIN9tj53MLRJmJWdfn5HUxOT7i0QDI1jiVbyGJjo1oWDq2eh/XDK6G93q2OtYTO3cA CeNTEq51n/GNX1IQcJpAYQ3c/hzu+g1XF9RbtJI0IPCqtDnwCTqmxxRIXGZBdZmbblS2mokRJaNe FSuzbHAV2TsbMN3HaJ8ArvTrcno7zbj2Br9jmExPtcIPKq1VWZdtdZJftMNaBOhMwAjHgGyiZFG6 htga5rQNOPFM5rGj3OIPhMraxfq5c8G25wrqY4bp+ntJ12t7rTwsPHNlVeDSX5G9wrsfG2wPEDc1 2ggKP343va+OKXV5mrp1ttAyGhxq3isu8HET+RdN0+vpP1efa+yxmS9hBaf8G4RqPFEo+ruZ0zKr rvbU6HMA93sYTH02jmOFzv1i6WMTqF9ddjLBvJ3N0br4BDiGUmN0vr2xdL9ZzWfWDMFtOMyoOhga DtZLR3cdFnvuvzKK67Xu2sBFTeWt3GXfBamJ9X7rMB2YLGljHhrmgy5s/nEeC3Ou4fTuhjDswXh9 waDYCNzXBw/ipfcEdAxcHFqXkmUfsyxzb2tsDTtlruD4ghPkUuJNhHqB7N4cXbiNY93noukb0FvU vteTmtOM4MDq621uDXE+AV36q2dPwsPLblUFziBt0J+kYHPGqZLMB5phit4Vt7qW6sEqwcfJ9D7W ws2S1pAILml26AW/2StnG+rLs62u8sf6fqhlpLgdsnkR2jv4rr6P8XeOcr1a7f1cva8VESSGnhxR lzGOKvbLxHROu/s68fa6w9gmQGjdPbVepdK+s3SLsP7Ts2NB2uBYJaYJ1+MLL6n9SMPOyH36M3uk NY2APJA+sP1fxcfExmVNLDu2O2uA3jU7nT3CqyyYjPirVccJI3a/W/rV05ri/wDZzXtcfbZvc0OC q9T61jYuJj2HptcXAvYRa4mAYh0arQ6phY3UMerAps3U0tlhIDXeo7Qbj4TysPpeN+znZOJkVMcH jaXkyGBpmWOS48VE1su9mVhmb2Utodb0pgbc32Ofa9rXeck6Ks3qnTRWaWlxIJcwtaS1jntbI1My 0jnuj/WK9mazHw5s/RNG3WWBqXSsWjp2RTkV0ucGgb2vOjnDkpCeLgtd7MhLRpdS6FXh3EZl7nW2 NFrRU0PB36ndqIMrTo+pmDfiPyvtF4axm4tLGtedfzQXKpY6qnIsyQ5ofyG7xweRz4IeXlNueXPy WM00AdIj5I+9ORFbJOGI3R9Otx6Lmi2u11LCSZ9r/joSF2LOvYF2Ja2vHc5gaQNx1k9/kuHzOr0t eHGz1CGBnsEAgBJn1iopYGtpc4eDnQPwCbPFORsD+X1VGUI6EuxZ0DMux6sprNzHEn2ncWgfvRwt 3JzKupYuNTcx7TUA3TuuMr+t/oaMoYB2G50fhCjf9cMuz6PpsH8luv3ulKXL5pChomOXHE2dXuMO yrErN9DnBo1ka/R8u6vN6jRk1PtdQ5zw7ducNjdeCvNGdT6llU2PZZa5jB7y0na3d4wqbutZDjDr HHtqZQhyeQAi0y5mB6Pc5OVV1K30MsiuphJI3S3d3UerN6LdSKvtbgBw2saE+crmuo4tjHYrKsll zshrfa0xsc4xscgjKq6W3LxszHLrR7GkH+ae06/FPjyZBB6scuYBei6V9asLpOM2oVvteCdXGBE6 cJZn+MDqFLi1uOyo6R7dYPB1XCDKJMCB5Srd31gyci5l1h9RzGho3iW7WiACp48oIljOe3oKeq9S +sdjmPyNsMc/3uhp2ido8z2WKRkXuIAcfkSqdXU9DvfHgAEGzqtskse74pwwSvQI90F6nop6h0w2 +i149RhYT6cy0/HhNZ9XMrIADKdp8XOaPylck7quQ7m15/tFCdm2u5efvQ+65ib4gu9/HVU+n/V9 n7Kx8qnNqY9rw0giHk6gQ3adNCVmfWjp2P05zhhXn0bWjc0kAktOgI7wuDObdEeo6PiVB2Q93Lin w5WQ3IYpZR0ekHUL8SnHdTlmWOcfTIltbuJE6HcFU6f9mdkMOW6wVOcQ5zY08wsPeR3S3E9ypvZN brPc1eq6V0YZxstN7WUVP2vs3DcGT9LYdT8lX63lYteVsxnmykADcYDnEckeXgueBcdAmLSgMAuy U8Y7PU9O6p0Zl7334zvT2EBm+TviJB076rPd1XGNZb6DZkkOkzxAb8O6xgFZzum5HTXtZfW5hc0O AI5a7UEeSPsQBV7h7O31DrNebjY2LU1rPTGr69HWOcfz/gtbJxcjOrd0vPu9K7FYX06t9Ms27i0l upc7sZXF0tsaZbotrrl2FbVTXh1WBwAL7bHe4kgSyOIB4Kb7YjoFHISgGPbTTXkXNugaUuglntOs E+BQuo25ufaMjLLv02u9wgP7Tx+RXOmdbzukmtzLgW1iBW8h1e2dxbtPmgdV6xk9bLWudLWuc5lb B7a953ODR4Jw3QCS5bw9pIB08kQZ+SKmUmwmtji5rDq0OPJhAhxMeasZeAaLjVXY22ADuZJaZE9/ BSadUUWvc/1Du0k8gCAkaHhgs2naTG6PbuHaVefQbaK6xSGlm4l/51kng9tOymatlbaX2kM3bgCS Gk8Ex49pQ9wBPtlp4uK29lrnWtYWN3AOn9IZ+iI7p+n10uuachrzUD79n09vlK6mno+A3pj8k3N9 ZpG2vQl7HcHRZVGPYHttFTSxsfSPtI8DwovvIILJ7FU0MegVXtdAcGvna7WQNdY8e6s5NNbrX2Gn 095nYJDWEn6IntHCao49NrHPJLd3uLQQG/Puutsw+l59gs6e4sbH+Elw3NHHzPCjzZzDVkx4hLRo 9Q+q+LhdOxstu8ut3OIjQBvgUTpv1g6dn1YuJmsYymomSBFrgf5SP1r6xV4GE/p9rPVscwbHh0Ck /nDb+VefuOqbgxnNC5HyXZpjFLR6HqvUMOm0Ox3PsEHaXOPt14I+C1av8YLRgjENO2HAyD9LTghc Qkp/umMiiwfepg6Ou760524OZZtIMy0RPxTZX1nzcpzHlwa5uocwbXE+ZWZbUK9sOa7c0HT83yPm oDlPHLYh+iFhz5D1bf7Wy9SbnEmZ18eUs7q2V1IVDIsc8VNDGT+a0dgqr4JJbx2nlMniMRsGMyJV MpJJJyGTLHVyWkiQRoY0PIUUkklJa7AGubtkng+C6Grp1fUehuurbWx+O/8ASOL/AH2h30drT4LD 6f06/qTnsoAJYx1hBIb7GfS5ULbt5ljQwQBAJjQROvimSjZXAlTDR6VgeH+pLdhBGyPztw5+Cv8A SemYeY31cvLbU3cWloBdbxIdt42zzqsqUbIy3ZDa2lrR6bdo2tDZ83RyfNOkCdlAgbs8PGF97KvV awPdt3uMNaD3d5J78a3Gtsprd6gYTLme5rg384HwVZzHVnUEGAdR2K6T6oOxcj7RRkOe2x9ZFJYY h/g6PzSmZZGESV2OHHKnDy7abtno1uZDQHbnb9z+5GggeSAXkt2zonvpfTY5jwQ4GCEOITxVLTYL rdE6rXgsyK73W+nbWRsrdDXO/N3jwlVczLpvZWyqn04A3Gdxc/uRxAPgg4+I/K37I9jS8yQ32t5i eT5IThtJCHCLtXEabvS+onpd7bq62WOEiLGhzddPoroOifVpvUMPIzrBWw1jRpPJceQ0rm8HKGK8 OaBu4Dj+bPcKF77KnuZv3QSJaZaYPIKjyY5T20ZITERrq7vU+j4wrY7GLvoj1C+CQ/8Akx+asjLb WxkNAmYPigUZLqXB0kx2kwVYoy8Z1zXZFM1z7msdtcR5EyhGE4nU2mWSEh2Q4WxtrHWtD2giWklo cPCQjC2nEL2FjbNw5/dPkVWsvDpDWgBNVjvu0aOVJIXusBrZv4LvtDj7g3jkwFvZ78umoZePcL2A bXwfULANJs5gdgsij6pdQvputbWNtIBfLgIBT9D6q/6v5IkCxhI31T7LQOzvgoJQhkNg34MvHOA2 anW8+vqWS62qhtDSANjSSJAgnXxWeVodZ6hX1DKtvrqbWHuJDG/RaD2CosYbXBrRqTA+JVmOgYJa leoNc4B5gTqYlb3V83ozun10YdLvXD/da72ywDiPNZGX03Iwbn49zC2xhhzeY+5a31U6XVl5IfY1 tuzcfRcY9SB5dlHlnCA4pHZfjxykaDgCJ14RReaC4VOO0nmIkDhXesdPGFc727QSfbIO2eyztBP4 J0ZRnGwtnAwNFJ9st/eP3lJBSTuELHQqFrzoZ+KuV0usMbQXdgJJUOlurtsDHOie66ih9DrnbQ3c A3aRoZjsQqeWRB2bUBfVyMTpeXm76aGg7Rvc3dA07x3Q2dIyDa1ha0S4NmCeSrrH3MyBfjOFbqzo Yn3N7+5aY6z1rJaQ7NJaIcRtYO/wTBljWp1SYSvR6LA/xXD0iLso69mthvzkrhut9IHScu3GIn0z E6CfNdU3699SxwG23yY7VNP9yDnO6P1fFsyLn3HLcdziBtntEfR4Rlkx16VvBMHV4hzWN5AC3/qx 9W6evMvc69lRrbIn86fjCAMHHymAMftI3E+o4DRo+HfsgGgFx9IubXAkmTH3eaUMgO6ZQLSspYx5 aAIE6jVQLKgJkz4Qu8+pf1f6f1EvdcHWOAaQQC0Md3lbGT9T+iOc2x0RvLX8iXeUIWTqqqfKtjCY BU34zQAQ8HxAJXpGd/iupfZOK5wYddXAwoWf4p2FkNyYfzBHtT+GfYo4g+cjG3AEHnzUjiaHuQJP kFvZX+L3qVbnBgDgCdRMaLLf9Wuo1khrZj91wP8AFM4x3X8J7IsamokNcwntoQPpGNFu14fR8aw0 5LsmqwcgGfyKhjfVfqdjRa5zWAOAlzho7srd/RL3W2PysqpzxG4ucwTp/WTJQ4jv9iRMRGzpZPTe iZAD/Wt1n6TPHzVM9C6ZkEinfPiHtH/VKq+cal1IyatjtSPUB1+Up7OoYT4NzhAbAFRJJMaTI7KA 4coOhLJ70a1CU/VyvHaTcy3bMy0tcfyoOLdj4NOTSaGWmwRW9zgH1+ceKrO6vj2MdW6psudu3tDg 9oiIABiELHz6W3ND7HtbBEubug9tD2TxDIN9Ue5E9KaTmnY5rWx7hOs+KPX1jPpxzjV3PbWSZa3Q GeZXSDHqyqnGm/HsDaw9+5gYf6og6lYtWdUx4a9oM8hp/vBTxkl+6tMY90PTeoX4txe17h+je3/o Fqx7WPdqF1rLun2uJDHlxBECDyI8krek42LS3Jtpt9NxLQTA1HkhDmOE/KUnESN3jQxzTJWr9ZOq WdXfQXgfo6K2aD90LSFHT7IIdAkTI7fJXT0/pVuS/INgFQj063Bx3wPoOeIj4qUcyCdlvtEB4Y1u PZIVldz9YMDpF7Gu6aWte0QW+6HeJlzjwufx/q/l3OAbUXCdYI/vU33iI3IWDHI9G/09+EzoeWLK wb/UrDHeAdP9y5g1knRdv1H6sv6fXbVjVuvbNbg7adTDp08lU6Z0O/qOQyq6j02NBc9zmlu1rdTH moocxGzS+eOTyZp2jVa31X6bi9Sz6qMp5ZW8kFw5Gkro/rP0XpeFhVPxC51znO38w0DtquXwGPry GEAiCfyKX3eKJWiFFq57Kq7ntrdLA47fMdlWkdgrbcY2Akg6BRGOAeJTxIALSLViMcXA9idVv9e+ rh6VbXVj2esXUtucR+aCN35EX6r9Mxbq8u3JaCK6iWjdtO88ED85dH0Xr2P0L1fVa20urrG7wG0A DhVs2epaMghUbfNnBwOoSkt11XdY1mF1vq1PrsZsscGkD2CIXOdYxKzkWCloDA9wBmdJ0TsfMcQF ilnCatFl9NdjYWNmG1rvXLwGD6TNhj3KlcRUdlgE6HSO48lbvx7Dj06y0F4Hhys92O4cqSBB6plY XrsY13BcNdEX0rS3ftO2eeyt9CGLjZVb8usvqn3NB1ctnN622/pr8OqoNqORvZp7g0gwCUJ5KOio xsOBi5NtRGxxbGuhhaeH1DJstlxdY4gNBM7vKCEKnpdljfUAAEdzytf6u0fYbDZZivtgHbrtDXdn fJV8uTGQdmTHCVssq3OwiW5DXNMSA7R2vwROk0v6hcypvtLyATB0J7lb3UOtUdTZuzsd3qBgbWY+ id3JWjf0x+LXXZh2OklsNaze87vduce6rcMT8rLxSG7y3X+gO6NmCsvJEAg6iR8Fp9UycfMrp+yU OBrr9+1o13dyujyLMdmPYeoXV+qSdpfDnNb29jZ1VXrfUsXpWMzMbWLvXAZtAFbS1o7gawrJx0GI SDkYVuT1ttOFbLKQDBIBAPbQKj/zZyWEuyvRx2A/StcGkjyaNVe6P9bHZGZRW4NppcSHV1s2fe7l ZWDTi9T6kXZNrvTc4k7hw08S4nROiATSyRoW61WN0XBYybPtD4mAfSZz4u1Wz0/6xC1wx6xVW36I DLBMeG4rmfrZg9Oxs2uuhwDC2O5G7j6XEBXMHoFnQG2ZO2u6zYPT9w9jj+dCfXCWI5Lel6/9Xsd1 HrGs2urDi1pI9xd4k+C8qvxb/Xixu3XjsAu4d1nqN5rquFdleyLRY4Abpnd8Vd+0dMse31xUABw0 j+9Onw/orYkk6uJ9XvqZm3Vsva9rBYCQJMlvC6jrGFS3EbW8bLGaDZ3aO5RK+v4uLbj4mM4OaWlz nHRrGA8qj9afrjj4W0Y5ZaQYtEa7T2BUGTHDgOurZxzmJDTRBgenhhrzkPIaZ2hhn4aBY314z8a1 zK66LLXhgcS7c0NDvcZjkqz0n/GBi0lrnNh2yHyNC6fzdsqp1vrOT9a8tjMSiS1hgN+kQ7UkpmHF 7cNd+y7LlMpabPL39YsA2V47g2SQJOnkqtWDkZNLRVi2lwLi90S3XiBCvZVr+n2ubawscDqCNQV1 n1G+udFNgxrmOG/RpHu17aeamxyMulMUxTy1N9WVmYbMsOrpr9Nr2ukzt+kfKVpMb0mjrOQwuH2c 7gxzAXgExx4r0Hq1nSeq0E30l4mA4V67h/KWVfg9JuZTe6qHVHSutu0nUauSyZIw0sfaux45S1op +k9MDMF1VzW+i+zezfo5zeG+3sYWX1mvF6aTRivABcd3BcNfPhbLOs4zHANqtcGGWOIPt00EeAXP 5mK2+x1nqAbiSZaQqHMZYEUDbbxwlZL0XRuu473MbdZW3ZQ3buIbLpM8rhvrLku9QvpyK7d73SAR LZRuo9KpsDD9pqG1saq19X87B6Q14trbkuP0Sxv98p8c9xHf+XgxTxmJNPLuvyoglkDsHNQHDJyA AKyYMyPPRdZm9exb2uaMGtjtdSOPltVTpb76DdlU2hoa1u5oaNWukCGlPjnkd40x+3fVxs7pT8mP RxbGDa0Hc4H3AakHzUepuxLMbGbjYz2PqBFr+Q90q87quMQQ/JtPaJQ7Op4dTRW3c8bjDdxjj6XH dPjln2KjAdSGx07pWH1Chzm3WNuawOcx7AGHXUMdPgh4zTgdUnDrsqMt9MWauBIGv9pTsy24tgGP VW9pAh0O+6CV1fR+lZnVx6zhW2AJlvu8ufJQzyzB0G/RZPJjhTx/1hz+oZmXZ67ALGuLTtHEeELP xun55tbdW1wcCDMwZ8l2vWeh5fTKbL7bw0/mtgS/4QFx9l+Y+xgvscxjnCSXahvjAUmOczsAPNXH E927+zc/MyDdYRu3hxJd7nGVB/1dNTxZY6tx9QlzHOgOZM/SHiqVuRVjZNzWudfXMVvMtnX6Th8E PGord677Hvhm1wboRtLgHSSQeDpCeIZQd/w/tXGeMjZ6fprcLB2F1lYIbtdB9pE7oPjr4rRq6t0j EyTkb6XzEgtLoI8NFxD8w4VuS3DBsptaWB1jAX7JmfIoDm31UDJLZYHbJ2gN3RMT4pn3M8VmWq48 wOGqfYB9femPaXHdth2pHtO0SQCe/kufzvr102xrtlLwwCAW18HkayvPm9czTUKGuAZuLtpAgGIP 5FvdL69ecC7DtpodU9rjIO2zf+a7+yeynzQOQVMsWOcYH0tj/nDR1G5tVFeS4vMBrYbuPgiU/wCM RnSiWV47wRIO46/PRYeNkDBJZX4tPqDR7NuvsMhDwelUdWfb6+UymGl+55J3mePiocfLYb2Zcmed Vb0df+MS7IY51dIIrG5xknYCYkwPEoF/1vbm7Te2stmeHPie8SFx/V2Y+Pk2jEe80zDZ0Lm+ceao HJeRA0Cn+445DRj+8yD2dv1xfEMYyOB7ANPmVRu+tNx4IHiNo1XOhlj2zu1/d7qyMG/MeBRTY+G6 hrT27ojk8MeiDzOQ9W9b9Zskg7XkE6aRELLyM67JM2WOd8SSgupsiYMTHzTCpxPB+QViGLHDYMcs kpblTX7eB96tNxMi+h94YTWwhrnAe1rncAqfTcene85NNz2bHBuwQRZHsJ8p5SozclmPZitc5tbi HOZJAcRxI8k4kLbR4tHqOa2YBIE9lo/WPpNfRsk01XsuG1rg9p01EquzOyKsV2INvpusFnAJ3gRz yqb/AFLHQ4Ju5u1JOnXU1ZFT8hm+trgXNmNzRyJUcu6t91hqaWsLjtBPDZ0C2em/VK/qTa3Cyhgf qN9m0xMahD639WbOh5DMewscXNDg5rvbB8T2TRlgSnhIaWL1nJwqbcel7g20BtgHDgFF2cLKq6XV tAYXEOAh7t37x7gdlUvBoeWhzXQYlpkfIpiwv1HCk4QjVtssa2XOLeNIkmVDKz/Xbtj4nxQm7Wzq fuQ3O8CfmE0QFqpgJcfaEz94+lKv9O6lf0sudW2syWmXsD9u3w3eM6qGV1F2cQX11g9y1sE/in2b 20VTRAJ4CKytpB3SPgFcNWOKf0TrvU7jYNhHxlDowcs6taY51QOQV2UIlqBgkzMfBOWaafetrpPT LrslpNAu2ul1cn3RrB2rOz3NvybNtYqaXEhgkhg/dEpRyCRUYUGm5hbym2nmFvdC6ZR1O9tDnsrH 0i+w7R7RMT58InV68NmcXYVTxj7m+1xDnfyv9iXu6reF53aVczuk5GBXRbY0Bt7N9ZBBlvH5Vt5b MPJvtZiNe2sulm9o+j4HVa2N/i56he1rr3srYBIJMQNDpPkZTDzIB1XjCS8KyouI/iujzWY5xG4e PSH7Xb/XIiwhw1YYkQCtt/1Lqxi9zbK7xW2Xu3Q1hmI8/FVPrGOlbKPst4qO0NsY2TJ7uUMuaE5A AMh5cxF2843p9bRLrA2PFSzsuzMexrrX3Oa0MbMn2jholbl3ROlehjXY2UbHmfVZtPtAPPzCP1r6 s7sht/RarDW0NMu0cHxxrHCR5iMT6j9ui0YtLeX+05OMXN2QW6EFuo+Mp831TRVc69rjZumsaOZt /eHn2Wuzquf0yzKfkV7n5DXNtNgDna9x5+awfXYbml7fYCJA0MKaBEjYCDGISMbR9lc11bvW3gte D7AyNQR4z3XVf4t+nNOezIe9g9OT7jE6fR+a5XqDqLLCcYP29t3Mdlc/absOhhx6nVPdIc/dO9sa iITcvHONDqvgYxOr0LMHpWT1Oxt7SyguLgQRLfAfesx12N0XLryBX6lQsJAj2uA5EwsfK+2PFVlj HAPaXMIB97QdXD4QgB11rBWXOLAS4CdA48mE2HLkbyTPMOgbnW+snNyrbKJZWXHY0fmt8FmF7ngA kmOJPCd1TgeFKmo2uDR3MKzERgNGE8Uy28O67KtrDt1m0Bob32jgfKVe6r0fMwcRuRfLGl+1jfEa rVwunZH1Lz6rbmsc4MD2yZaQ7uY8lhdc6g/rGZZaPz3khonaJ8FXEjPJpszmIjDXdzm5FoqNIcdh cHFvbcNAfxWh0S/OZaGYrjuJ0bG4E+Q8VUxKnes1oYHGY2ld59WekZpyWDFYxtjAXtc/6Ij+KPM5 YgcNXaMMDvezw/V8XIxsh/2md7iXHcIJnuqBXYfW77Z1XJffk1Br52ktGjtvhK5a/GfSYcIUmDKJ RY82MgoEk8JoUzDSkkbFYx1jPU+juG6Ods6q7k4+E++4sc+uqHGsEeo6fzWuOnPimmYBpcMZItzE lItEd00COU5ZSyvdProNd7rg4u2RWGkAbyeXT2CpsYXFFtrsY0EtIaeDBAKbLXRfHTViKtx9qIcR 3p79BGh11SwK6bHu9c2BoY4zWNx3Ae2Z7Tyh1PJdHY+J0SNpBiejevxbcihmVXjiutobUXNna+wD kz+cQoZlwzn7rNrXBrQNoEe0RGn5Vpv62endPs6a2uuwWFtnqjXafAKX1YyOji+epB7W7Xat193b RRcUiLryZDQ0eebSbTDRKZ9L6/pCFpPxWZDMnIZawCpzdrHHbY9rj+YO/mqVuS23cdsSfbB+jr+K lBkxERbVrQK6jTuc8sLbNx3fDb3A2q307oPUxTZm47C0UiS4ctHiqfSurfst1hFTbd7C33z7Cfzm x3Wthdf6ttfRSzc2wEmsMJ0jsoM3uDavqzYjDrbUwMI5jrMvLsaW1bX2Me7032sJghnms3PNFl9r scFlW4ljSdxDewnuhvrtsc72uO36WhO34p8VrGuDrQSzWQ0w75TKmiKYpHiY0kvIZIE9zwrmM1mH Zuysc2scw7RJZJcPa4HvBVQWMYwt2yT38FYy+tZWYymux5LaWbGA/mt8EqNrbZ52D9jbSQ+t+9gc dpnaT+a7wIVmvG6c0sbfkxH0ixm6NFkWXvt+kUTFrrteN5dEidurts6x5oShpqVDUtnqObjW21vx qBWGNaDrIsLfzyDwXdwh257cl9tltTS54gbfYGHTUAeSJTgbbCLIY0tcWmw7fgVWZZUxj2uZucSN rpIDY507yiDE7J1DdyOmehg1Zm6oixxbsDpsbHi3sFpdP62zpnTNn2eo2Psllsh1le2PzfArnnXb mbIHMj+5QkxygcYkKkkz10ei6j9dsjPxmYvpVta06uAiywfyysfOy2ZthsZS2rQCGTt0ET/eqa1f q9gZGflMbj4/ruBksMw9o5BhDghjGgSJSyHVznluhYCIAmTyVbzM6rL2v9Flb4AIrBaPaAN3PJUu pYxxbXepU1hLydjSYZr9DXwQ86wZz3XiplQP5tYhgjSAOyIIlRQQY21rr3WmZPEansFFljqzuaSD 4gwVYqwbHAuge3WCYlVnt2khPBBWmMhqu+11plxJPiUxY4AEgweD4pgrNmZkPoZQ9xNbSXMB4B7w lshrQknkpIq0fVqOmYvTWh2RUxrg4ETW10j4F8IXV+oYHTqzcXViT7a6wwWO+LRMLm+sdez+tWty skQ0e1oa2GN8ljvO6e/xWcMVxEZV9GyZkaun0/6xtrFtLwRXY/eNJIPGvC6Lo+NT1K5jPUG1xEuG u1caGBvZdX9TukX5zrnVPDfTYXR+9IhRcxijvFmwzOxdL6xfVa3B2WUfpmu0BZqfHUNWd036uZeb ZW01uaLNWlwhpjzK2Op9Dz2VUU1WlzoIcxhMtHIJI8U+JgA9Lu3vi6h8t195ntyoQRtt4Mhid2p1 T6qNdksxcKSdhL98CC3mOJWbgfV2/PLm0svcW8jaGjTxkq502jN6i6/MxXy+g79jvpunkgd02H/j F6zij03BlpnlzPd/0YVjHGMo66MMyQXqfqxju6GHY7Wk2kNfZLhtDPA+a0cn6x4TXxZjOdx7g0Fe ev8A2vm2fam1uY60+oNrYD9YG0fwV/pAvxrLD1Jlu18Q87mlhPeO/wAEPcyRHCCPqu4YS1IP0e1d 9acevGNldbmwS0NIiPA/em6f12jJxn5tji1zAWlu5pLo8AuPfS8y2nqTmgn6RaWiZ4naqlvQsvKc A7qte2SZL4g/DQo482WZ1RLHADR6Cz/GFTWwAU2NIOkH2GdfdOq57q3Wn5mXvxqmFrg1xYdBryJV B3ROo5jnVfbGPY0kgusAae0jcUm/VO90F+bSJ0/nB/elIGdWdvBQIF09Z011GJj/AGhmNT6mTcGC sHf6THe0iD8Fxv1mfPUbjfjsqIIGxsBrYHkr+N9Wa6ntbZ1WtrdwktJMHx4RrOh9G9Qsu6jZaAHQ QySXngzHCMYm7/sWkiqav1dt6dTbuyKA8Bp0JkeHELrrejdIzsD0sShkkt3WmAaS46biuE6phYNE HBue4Bw0e0tgRrLvj5Jmsy7mEV2h/DnNrJPzIHgmEUd1wAPR13dGxunZXoVe7JFjPRMg0uE6kz2T /WD6vmit2flhr7LXGW1lrWsdMajwWI+63HdW8va8FsTyG/yU7MjMxG2MdSXtsbtIJ51lAcVbrzXZ 6T6jdOpz6M2u2lj/AGDUmNsfulcf1PAGLc9rPzSQTPMFbX1f+tuR9XxcwYW9lhBiT7I8NCqP1n6t 07NsbZi4t1TnEm3cRBJ/dU8ISuwxSIQYP1gt6bVXXRW3dW8v3PaHcx80e7r9/Wt4z7n6b3Na1g2u e7XXiE3Quv4eCJyMKy8g6AEbQzz9pldBifWPpeVa3b0hzCTMkgADx44SlEj9H8UX4vIVvIZsc3R8 Qf6q1se3IspZh3CKm7izjaHHk7jz967L6xdV6AccehY1pAn9GADtPxC5zC+vrceMYFhpALfc0dzJ Pu8UMkJWQmEhVtSv6s32VPvAa6tkbngiGz4wj1vpxR6RpZZ4OYSD/enr+tuLX61NYj1WFpaDFTXn h2h1XZdE610KnEpF76fVa3WYJJHdQezkyS4ZMvuxhGwHkjljGYD9luI7fpHj4qh+2ff7q3kBxBBs fAB+iOey7zrP1s6HYWAsddtDo9PRuvjqFxzes5DmXYlWHU2u5/qAundW50fn+HxT/u8YHUj7VpzS lsFst9jGtsfjvqB1BLnQfhuSFfUGCqza5ldhhrnNEGfDRbP1gvz+vYrK3vxqxTBDWFzy4ceB4WWO p9VzsOnCsrLWVOlriw7vbwPgmHHijeqozySZ9eou6VluxRFgaBqa2tc6R4KFvS8rEqry7aKzU+QP aNxPwR/rBXd1bIZftuJ9FgJIiXD6XCO7CvvxWHIFjK6vbXUSTve4TM6RCjkYWeEMo4hVosXqWLWw P+xAggiQwEHt4q03LqzjFfTQ8loMQ3hvz7BB6N1tvQ8c024rLGmwmTzxx8FHE6Y7Md6tLnNssLoY yQQ13bnhM4IAA31Ucki6nTD0jIovyTS2o0xo4NlzufasLI6/0940xBB/qhNVjtwnWse41ifeXtL2 7h4DxCj1PqWBlYdeM2r3VgbXtZs3TyXKU4oSA0WCcwS1beq4RaK34zAGzAk9/kj4Zw85za66GknQ c/3LNuwmOIOxxG1pk8ahbXT6Om4WGMh0jIDgWM50nnRCUYcOl/b/AGromd6tnreBR0a1gfhsBc1s N1dr3M/FZ9fUcJxcyzHqrgEiZMuHA+fiujs+sVGV1Ci91L3bABH0pPjCx+qYeJfkZGQ6hxG8w0EC dU39Xeq710183Nwa6qgMQNfrvM+066bUTHtYysWOqIY4wDqGk/FbuRi43Vq6Dk1hnpuDAxo19L98 nxWnlPwaG4tDW+pVW4xWRrJ4JTZSxS6qAmC4uDiU5bbMhtMspILw7g+XKodQ+sdmLS9tdm1uvs3O BHlC3KraOmWXNcwe8ksEw1rp0JlY2Z0SvKuruutbYbn7rgwDc2D2PmljnjA7JlCbxrusZRe50MMm dWytjDw+ufWVlbGMArZO0u9jfctLK+rNdWW847Saw4FsiYb5r0THwqem1VgcGJPxVmGWEyeEDRr5 BOG/V4TF+ofV6iLBdj7hxIJgrI6z9VeuY3vsixo71nX7tF7MGNER3WV1g0Ptqoc4Nc46KeUJYhxN cS4zT4RkW3Ne4WbpmYMyCno6hkVkAvcWzwSV6t9dOg42XXRi11tN73e06B/3+C84zuiW9OvfTYPc 0kacaInKNpbroYzVh1XdXxep5NTWYoYzaxrhuJc53j812OZgY+NmMxXYjXb2B1ZYI47EDwXMfVX6 s3Zj25DQCKntcR3Oo4Qvrb9Z8rN6g6yv9C6gurZsJB2g8nzVeUI5LrRnBlAi3tcfo2N1Rpc2oDR1 Z1O7TUiPisPK+rTcel9/2eG6g+/X2iUD6jfWr7KbKr7gGhheXvP50rYy+q43UcW25mTWWguaATtn TmFWywMQKBtmxy4pdKeAfkMkmihjYlx3uOseGnKhh9fzem5IyaHbHce3iPgVXtyqhpvHPmqb8phf zPy/vV7HDwa2SWm72PUPrMzqVrX5OPQSSN7iCXEDk8wg9RvwG222Yb6wxpbsEQ/g/wBy4zJi60uL oUDXsAcx24+XZEcqD11V72mz6/0LoVN+PXZk3V+5pe5m8bm+BiVk9Xv6VjZJazIDPSAJBdvFnkAy R95XnrX3WDdrr5hV7i1rodIPyTvuuOWnVX3gh9DxvrT0i8HeQ0t4mRP3Sj9G6n022wtNjAXuIAJk mXacry4uZ2lGOe92sRxqNOFFL4XDoSu+/S7B9X6hidPZa8bDsrYQ5g9/0QRudHmVju6+MCsHHdSB ZILC0udXtjX5rgmdUvqDwyxw3ja6HH3N8ChtzbG8OKI+HC9TaDzZrQPa3ZuT1FmXXR6B/Rkb3N2v sG4a1+Dv4LEHTOp4DS0At3QdHD5arFbnW1mWuI+BUz1S9x1e4/2ipo8tKAqNU15ZTI2S7WH9V8/O 3uDQIBOrvpO52jzKt4v1O6pY5oFUT3JXO19YvrdLHEf2ivSPqfm0VUNy8vItdP5pfDWkTMjuoeZl lxAWRr4JxY/cOjW6bhP+rOV6mfWLqQ5zG7fcLHDwPku86Z9Yab3AFmwlvERAAkSVxX1m+s2Nk4tF DLGEsMjZ+WSsxn1pqyGn7QbXENIHuEboiSq3Fl+eA/BbmxUd303Oox+rYzrXDfrLI1/Bc5mdNq69 ksrspdSXghp27Wu2DxWR9UvrecfZhYtJdZa/QOf7d3z4VPrH15yXWmq0OHpvcREBzXfHVGWAylxa 3+f1TgiInUoLOrY/1ery+n/ZQ91jyC8ncWx4LFyLmvLGNG/eGkwI2uP5uvgi3ddwbxudQTYTLnkz PyVrJyel5Fo9G5wa2je4uAZNgEljfPwU0ISA+U2zHhvQtzL6LZ0MNOYRUx4Imv8ASPiBPtHxXMXd UzMqlmKX/ommWtAjXXU+eq3M763YObW1r22+0QAA0fis/o3Um32Px2Nqh53zY2f5oEhu7zTsJnGJ JhSskY2AC3cr6m5XTunWZORWBPpOY7drD59u3zVM/VjLb04dS09Lft51n4JurZGV1T3PIa0QA1sh g04Wdd1fIrpGMXzWDO2fb9ylxmUwx5BEHR28T6vdR+tjn5DTWHSJLi2oEAQCB8kVn1J6y+kPrpqI JgOD2zMx4rmburX2tra95IrbsZ/JZMx+KC7Pudw5w+BOik9qZW2E+dXZjPdXcC17XFrhpoRyrWF0 6/Lw78luPurZsa6wR7DPx7rJtc55l7pJ1kmeUXHcZFRvLGuInU7fiQPBScOi231r6h2YWRjXNY6u t1VrgxhbX6npR7SXPEnnlZP1noz+iONrepOiwvhjCBpO4/QPiuK6n00dJeQ3LZeCYDqXTIiZ1VfH zCyZD3Ce+qrnEd4lcD3dbp/X8bptDq7MSm8Ofvm0HdxxII0Vn/nR0vc57el07S4EN3va4DuNCuWI dP0D4KNoNLix4gjlTezEosh6Xpv12f0yvK9L1GutdNTA+a6xzJkEkjRYOb1XJ6g6bnlxkngDV2p4 VbePBR3AnhPGOIOyOLxbOJn2Ym7bB3CDuaHflSfmPcS4EAnuBBEJqnFx7fNdT9XvquOqNFzb8eSx xLHH3M2EDUeJnRR5ZxhqQvjEl5+jquWwlwueXRoI3A/GUaep9XcQWWWbjPB5Xf431Mrks+1V75G0 NbAdP8ohG6I3BxLmtvtgguBmwafcqOXnhEXGLYhy97l4G76pZmIQLXVtJ7bhIRaekvqr9EnRzgdw brInRrj21Xq1fTsB99myzEcS8kEu3OgjiJXJfWvEPToxW5TXtc71g1oktf8ARiR+RIZ88h6lcGMb Od0z6r25l7ccPhzhMu26c6FV8jpBxyWvEQY1aIW/VV03D6e+x12/IbBaBoSPAqh1DqnTcvpArgnK DpB8R31KihPJMs0hCIa7qMD7PXUcObHua31d7mt5k+2I1WD9YMVnSb3UM9MkGd1Z3tg+DlJtGW6l gba5reZcfaEC3Ee6kve5pLTyDMg6K5iHCdTbVmQdg7VdNVHTDlubBIaGtfp6kmDs8YjVYtXWMwWB 1Ya0HTaG+3me6NR9YcqmirHMWV1mWseZa2TqB8U+Xm4tpZ6lZY787Y4bfkERiESbF2g5CRvTpdM6 v9hqtyGtcMw2S2xphoa4QW7Vz7cex73PsB11k+K1sHMxabDkMta0idHmRER9GNVnfbHZLjtsgknQ iZRgZC9FlBsdD6fX1C8UuyGsL37QHaN+Jd2XX9W+pbOn4LL6Hmx7g4uAjb6bdZn5Ljn5jGNj0WA6 e6J1H96m7rV+SBX6hYwNja0lrSm5ITlqvEwHTwx07pb8a7JsNzbZ31skPq8OdOVev61jY+cHWZDs nGazcKnnsRo35LlGBr3bXO1PGq2cPpr8C2u7Jo3tBDiHaBzfDVMyRheqY5CNnn8rOttc8tO1jnEh gJ9onQJ6uq211uqJBaTOoBg+M8rX+s/V8PqOTuxsWuhoAADe8dysB22w6ENVuIBGzEb7vp31Qxem nCJ6gGtDmHY50s3/AA81pUV/VzqNjK25dgc8RsF7xqO2q84Z9Z86vp32AOHptfuboNzSfByp4vVM vGO6t0HsYEqp90lqyGYD3314+pOD0rp/27HfaSCB7jvHuPK8yDC5wB7roh1rq3VyKza+wn8w+4Oj +SsjOxra7D6g2+UR+CnwnhPCStMSRbCxoxrNgukae5uoEqNr2+oW7i9gOh8fMJ2YjreFvj6nW19O r6hvbsc7btn3SnynGO6hAyaPR8c9SyKaX3mmsBw9RzvbW08/Izqut/xeYnSa7MtmcGP2fQc76JAM Ej46Lk8jo2Xi0Myyw+i8loIPJHLUzHOrY1zNzQ7sT4JhmFssZL0n1iw+jDrANTd2MGy9tZIlwGrW krJ6X9X3Z+U0UM2jf7NxjSdNULqT23CgVh07NzpH5/eDOoW70L6xnLZXj2srYKz7XRqZ7EqvzGXI IGQ+xnwwiCAXR6z0CkUVMBcHMEXSZkt7NK5PPw6t4NVYY0aaf3r0XMswraLC14DmNB2u5ce4C5D6 xdH6uzFdkmqttIAcCCNxbZwq3KnJKfg2M8sYj4uD06tj7rC3aXMBfqY0HPPK9K+qF7sLCys7KLQx ohjvivGtzmn3NmOVts+ufUfsjcPcPRYIa0NHt/v+a0J8sTIS3pqxzCqTda+s92be7WWMcdpHBjRZ /Vur2ddvD7IDoa2A0NENEdlZ6N9YMfp+PlU30NtN7YDz9Kt2vub96x7AxhmsyT5cJ+LBGGgCyeaU iheIJ8jCudJbhPe/7a57W7HbSwAn1I9sz28VomrpJ6MHueftnq8Cf5uO/wA1n9FxcTMyW15dppqP 0ngbtvyU3FYY6NtN1m7SB5LoumDpVvTx9sllrLWklrvfbS7RzWjgFviVk5GFi1i0syQ4tPsG0+8T HPbxWeRCBiJBXEYlPmtqbfYKN2zcdu6N23tMd1C+sUu2hzX6Ay3jUT3R8bp1uSy17XMHptDiHODS 4THtnkqv6Dy4NgySAB5lPsLC6I6Q44Dc421hpea9u79ICBP0fA+Kjd1vKysWrBfZ+hrJLQQNC7nW JVfKxsnAc/HurcxzXe5rhqCq5cPBABNpaxZUT6b/AKQLTtJG4Ht8011LqdHjaQY2nQj4hQZYWODm 6EGR8l0HVuqZPXuntusxQ412fpMoD3PLho15/IkSQUgAoPqlgvzsvazHbkEhzRW4w2XA6z5cqjZh XYFzvWYWFhOpH5w8PFT6Nn3dIyGZNTQXMIIBEtPkfJQ6jn3dQvfa+RuJMCdrZMwAmVLiPZdY4Wtu ZJLgTPhoonb2MJK3ndRyM1lTLXNLa27Ww0N9vyGvzT9bW9F6sNjqPWGRXu37fTMh8RO74LZwOpdX uyccVXH1KmenU5oEtafzVg41bSHbgDI0XRfVHqlGF1Ku3IbNYO3TnyIHioMpkAa3ZIAdWOV9WMnF yTXfY+tz2kuaB7jpOuo0JVDJ6ZTR0+vJ+0sc9zy11IHvYB+cVu/XvrjupZNt1NkV6MbJ1IjwXGVb XvAeYBOpKGATIJkVZKB0ZjKNddlTYLbImWgu9pkQe3yQWgSJEolpaXQ1oEfOUq2D6RIMH6OsuVm9 GOtWD2w7QRPAlWacbIr9zGPBI0gTIQsiu2twF0tMAjdzB1Ct/ty99fouLQBEOa0B+nmmTMqFUujw 3qivx8m4l1gsMATLTp/coOrGSJqr2itg3mSZMxuPhK12fWnIoxn0+q2wXRv3NO/TgToFhut/R7A0 AyTu1kjwPZNxmZ3FJnwDYux0boV17LMwPqFdGrt79sn90eaqZnVGPdaMettTLI9sbyNv8p2uqzZP CSd7Vyso92o0FSVrdL+sef0yGY1or1mQGtP+dErJSTpQjIahZGZjs73UOo3dRJbfXQbJlz9/ucT5 zCrOxHMq2ltbQTO8S533rKV79osqrYymvbAG8udu3v11A0j4KM4jEellGUS+Z6Pqt7x0ijGsprbu /SMtgh9jeOfBci8AaAqxkdTsyY3taYEDQ6D71We/eZgDyCWHGYBGXJGWymCXAImyxzg0zpwOYlKt tTh7nlp+EhGGPB/R3g6ciQnylSyMLW+yu/dd9ySl6Fv+m/EpJnEe7LXg7h/afoM3fzU6Tt2T5z3W U7dvdMzJnwSSUMPp9Ey+rbdt3ieIE/ivRvqH6n2DL9LZukc/SiNUklBk2+38mXH/AC+1Nd9s+3j1 tm+Rzv3bY7en3XB9U+0ev7IncY9Pd9KdedUklW5f5vt3/az5dv4Nvon7U932T1vW7RG3bHu3blU6 V9u+31+l/O+oNu6Nu/znRJJWo/RgLv8A1e/5w/tF/wBn3bpO/d/Mxu1ifbzMQu+6z+0Ix9vo7Nzf V3x5cbvmkkrMfk6sMvm6N932L0XfzWydYiN3965HJ/Y/p2zEx7J3c+cJJKtzW8fkZcHX5mrgfseb PU9D6Hs/nPp+e7sqvVv2fvxfs/o+tu9+z+Y50nf+KSSjP+D9GQfX6uh+j+yO9P7J63qHdt9Odsfm 7vbCrVfbIEbv7Hpf99SSUWT6/wCCvjv0+rsVej9o/XvT37DG7+ZiBzHt3Kp0r9nzd+zvT9T03ept 3Ts7/S0SSRl8v8rSPm/lTi9Rj9lsjZ9n9Z2zjd6nfjsqPUf2l6dfrb9mu2dqSSiHT/ul0t/4OLj/ AGv1LYjkT/qFrUfbZ90T33f+ZpJKXNv0WY/q7XT/AFfSds9P6Xu2bOfOELqfrfpd87tpmI8PJJJU /wBNnOz58/fuH9Ufcq7olJJb0XLV7I7IrdkD4acpJJSSjfv848kWr19NnrR/J3JJJHZd1dzB/a+0 +j9oiNeePmtXH/bntj1kklQyf4Lah/hPU9F9b0Lvtvq79p2TxPyXPD9oes37R6vp7vd47fJJJV5b dGT7WeV/Sj6W/wBCfbu+lHn5roPq/s+0H7PG6DEzvjv5JJKL/KD9i79A/tbb/wBkbX+v/Oaz9L6S wrPs3q6+nt7eMfNJJR5dh+zf6rsO53+ruZv2b7Dj7/T2a7Yifmudy9/qV/Zvs+zcJ3/ShJJPy/OP IfkmHy/X9rrU+juG/wBCfnKXUdmx/o+hvg8zE+aSSiG36KTv1RYG6Bu274ExMT5blYHoeqN07p0h JJMG687NLM/Z+927dv7+KrNj7KfS9Sd3lu2z28kkk4rA6x/aH2DI+w7f5e/6XH5n+1cZif8AOL7Q z0vW37h9OfT+c6QkktDlf5sbbdfM/g08/wA5/Yns/wCdH2lnr+tu3D+rz22/wXW4Xq7bPW9b19vt 3Tt39+f4pJI810/kP5dk4Ni1ui/at+R6uz1vTM753z/J7z4LnL9293rTG1+7d9Lf+b80klCdvtZI PVfVf1/sNH7M9Kdr9+76W6fz/Neb9b+0faMj1v5z1Hbv63dJJXcW/wDLwa+Tq18Cdl3P0R+VH93p jjhJJPybsIc630/8NMdkOj0vUb6m7ZInx2+SSSnjstK+Zs+0WfZ59Pcdm/6W3tPmoVepB3Tt/Ojm Ekk7otRd3+hO2O/Krme6SSkitK61cL9nfYb/AFt/2iW+lEbInXckkhk2SN3KdCZJJPWlkNm0zyoJ JJBR2Xb5KzXv7zH4JJJs1BfWUWvckko5bLZJ690t9GZ3aR9OYHh2R8ePtB+0bvomZ54SSUOTYssP mDXyvsfqH0N+3T6XMxrx5qnbO8xwkkpofytR3Rt2a7540jxVvp3o+6N/q67Yjbtgz8/BJJOyfKUx 3TO+1fYzHr+h6g3c7PUjSfOFQZ6O/wB+7akkhHZRZOjf+jiO8/R/FSq9edNv4JJJHb+KurWP0tfF Xcb0drt8T/DySSRybIjuuz7Jpu3/ADXRfV39mfbcbb6cf4T1d3p8d0klXy/4X7GaH0Q0/s/7W31J 2b9edsT96wev+j9tt9D6G47efozpzrwkkhyv8512WZvlc9IcpJK8wOh0f7P9ob9q3elru2fS40if NWOlev6j/su6fKZ2+cJJKvm2P8g2MfR7fP8AQnp26d/pjdEx6k+31JWT9Y4+2ZP26PW31z6Ment/ P+aSSoYP4eTan/K3oPqF+z9tcbftPqu275/mtp5UsD9mevfu3+p636T93059u1JJM5j5T/LsuxfM P5d0lv2D1bZ3en7tsfS/k8rhuqer6h49OdIifkkkm8n83RPM/Kqz0Ps7J9SJdMcc910+N/zd+zu9 Pds2D1d/058vnwkkpsvy9d2GO/R4S37HN385/wAHx4/nfJUHRKSS0sf1as02J6O53q8RotTpHrfa q/sHpbt7Y9TbG6dPpdkkk2e/8dkBfqn2z1rftHozvdO3bs3d9saLM/Rbfzt3aOEkkh/KkFvdGj1j v2cCJ/ekL2n61en+wn+t6X8234dvopJKDLvLySOj4flehvdtjyQavs8/pJ+SSSmj8vVd1eqq/Yv7 H9+77Vu9v9XtuW99Wv8AmzuHr7Z9MT6nG/vwkkqsPmZ57PV4P7A+10/YPS9WTG34KH1j/Y/rj1/S 3/ncTPmkko+Z+WW26cPzDfZpM/Zvofofs06zun6PyWJ170vXxp9P0tn+Bn0+TE+aSSrHYbbfo7tj 7fq4N2/Y6Z9HcdvOzd5TpKhk+v8As2uPR2bnf8ZM9v8AYkkpf3fMbsXfyeh+qv2L9n2/atm/07Nu +N3H5srjKvT2jZz3nxSSQ5f55+azNsPJ3Kv2r9ms3Rt0iI9Xb5LP6p+1fsON6270959Lf4f3JJKb l/m/R+jBl36/VyOp/bd12+Yhnq7fo/yJhZ9e/adsfx+SSSv4/kGzEd0R5XTfV77H9hs/aHp+h6on bH2rdH5n8jx80kk7J8qo7uDmfZ95+z79s6b4mPkhNidJiUkko/Koburd+z/szY3ep3/dlY7uUkkz Bsd/qvzJBHafJTumWxPb70kk/qtOzoN+1Sd+7dAnf/tWdlzvMxPeEkkyHzlEtkQ27TPOkK7R+0Ps Vvp+p9m3N9SJ9Pf+bu7Skkploa9Xq7vbzHfhRdv3Gee6SSZ1XMff2Tt3SJ4nukkigvTdd+wfaa/s HoRsbOzds37fd9Jc6z1vW9v0kklDi2P7WU7Bhd6u4+pM95UCkkpxsxHdikkkitXdPefmmSSSUmxd 3qV+n9Pe3b/WnRW+u/aftuR9p2+p6jt+yNu7v9HRJJDqvGznJ+ySSK0LKT0kklDZikkkkhSSSSSl J0kkkhWqSSSCX//ZDQplbmRzdHJlYW0NZW5kb2JqDTg1OCAwIG9iajw8L0kgZmFsc2UvSyBmYWxz ZS9DUy9EZXZpY2VDTVlLL1MvVHJhbnNwYXJlbmN5L1R5cGUvR3JvdXA+Pg1lbmRvYmoNODU5IDAg b2JqPDwvSW50ZW50L1JlbGF0aXZlQ29sb3JpbWV0cmljL1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDEz MzE0L0ZpbHRlci9EQ1REZWNvZGUvTmFtZS9YL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNl IDgzNCAwIFIvV2lkdGggMzk5L0hlaWdodCAyODcvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCv/Y/+AA EEpGSUYAAQIAAY8BHwAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAgIDAgIDBALCwsQFA4NDQ4U GBITExMSGBQSFBQUFBIUFBseHh4bFCQnJycnJDI1NTUyOzs7Ozs7Ozs7OwENCgoMCgwODAwOEQ4O DhEUDw8PDxQUEBESERAUFBMUFRUUExQVFRUVFRUVGhoaGhoaHh4eHh4jIyMjJycnLCws/8AAEQgB HwGPAwEiAAIRAQMRAf/EAUIAAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEA AAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGh sUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYCOwEAAhED ITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2 dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x9fn9//aAAwD AQACEQMRAD8A5h7ULUcKzYEEhURswhTXypBDhIEhJVJ2q1TaWqmx8ozXJkha0utRmuY2AUPLzrHt 1OipB5HCTnkiCohiF3SKQWvkoE6qw+oO1Zp5Ku5paYdopo0uCRlh7o7HByqCQiMJB0RIQW2GozKp Q8d4dDXLWw8J2RY2uobnOIAHxUGSfDuglpDHMcIdjHMXdVfVrAqYa8gvstb9JzTtAPg0f3rA670g 4FgLTvqsksd305BUUcwMuHqEPPSCnStZB0Qw4jQqwNQltVPLStXByzWQ4HhYrHKxXYWjRR5IcQQX pz9Y8rFrPoWbZHEA/lXMZuS62xzyZc4kk+ZU33EiCqlzTEjUJuLHw0NaG3gpH6u4w5IieEI8p2vL VYpLPana1zeFNkWccq7hYNuXcyilu57zDW+JQlKlNQCUzmrosv6qZlGO69rq7NgJc1hMgDnkCVz1 ssdtcmQyRnsbQswNJEroehvay1q51p1Wn06/0ju8Es0eKJC2YsPqGPlV2VNAcN8RtJiVw31xc37U KZBdWwB0fvElx/KoO6tZsPuPksLPyn3WGxziXE6k6o+7PMICcQDD9Lv9FGZnwgjWPVz7pmQgi0jQ or3h/PKC5klWoLwzncoWVhw1UmMcPgj+luCmjIBOzRZUQ/VegfUXEx82q3EyG7mMPrATySNi4l7N pWn0rq1/THi7HeWPHBH5Fp8oDkxzjGXDKQ9MuxWyIBBI4gDs6f15qx8fIfRjN2V1PYdp/ecyHEfG AuMdZqtrr/Wm9RLQGbHE77nEzufxPwhYL9dQrGY8EccbsxiBI+KICyTVAnQeCnGeUIy06KQPYqQE qEeosmzp/V7p1XU+pU41xIa8PMDTc5rXOaye24iFu/WD6sW9NwhlWUig6gBp3AxzP5Vh9FyDh5lO Q36VT2vHxaZXa/WzrOH1bpP2uizY2prq31O+l6lkBsDjx1VrH7kZY4gA45WJmtj0+1ZPhNkkiQrh Hd8+bca/olV77XOduOqTnQ7VROqbPISDG9EiPVi3XVv3K9iYd+SCamOeByQJhVGM90hekf4vsDFz +n3Y+S2RTb6rYMTvAbB/zFHxRxxM5g8Md6+xUuI0I1Z7vNdD61l/V/JNuPAJG17XCQ4eBUOo9dry evY3VKaywU212uYXSS5rw9xnzKl9aq6sfqVjKSS0k7SeSAS3X7lz5MvB81LMiJsDWURr1rdZEXqe hOnS3StbqgOCuW7X6t5VV7SDquVidGUFFCUKZCaE5LGPBTa8jlLaltQKila+eFKZQQCDIUw7xQIW 0y1CRh4hw+acapoQUjdSRq3UJmhGGim1rHc6FElVr44lwXZfVBjft7HP4AMfErlaAGOEifNdL0PK bXa0gQquefDUqvhIP2G1pNEHsXvW49Y5aCSSSfisH6zYjH4dzWj+bLbWfftd+Vb1FrbaW2AzI/FY /wBaLvRwbbDpvDamzyZcHE/cFc5rHjlhhkxxiNRIEDoQev8ALVlyAcAI/lo+dZFJkqq6qO6uX2Bx JBVV0yoIXTGGAaW8IjbAh6piJTiFUmLpCiXEIYLh5qQ14S2Uxexr9RoUEtLTqrBam0Ojk61I6Q4v AC7n6jVVnJsfZG/0yGHw8YXHVNa10jVdP9Ws6vGymOdwDr8FHknwyhKtBIE+V6quiD4va24NbKi+ skOaJAPGnZea/WPCZi9RurYIYSHNHgHAOj8V6c/IbfQTixduEAAx98rzb603ss6rc1pDvTiskcEt AB/FPy48cMkThAETHUx+Unw6H6LsgAI4dnAJLD4hWab4boq71DUajROqwtItvnIMaFV7nCzyKG23 sVKJRjEAoqmq8Fp1Uq3AmHfeiub46qDaZcI4UgOiQ7fQui2dVy247CACC5zzqGtHJXQ531Nxqccv xHvNoEgPja/TgQBBQPqWfQzGuHDhtPwK7fOj7M6ROoiPGdEoesTldGHT6LwOKJN7Pi2V7bCOEA2E cLR+sVbGdSyW16Nba8D4BxWKbIMOWhymUiIWkWtdLtQgBxaVYJlDewO17q3xGShosAH8K9i9Jzci r166iazMOOgO3mJ5VKhhD9V6j9UOlYfVOkV2ZIkYzfs4a0x9EufuP+epYGGKByZATEEDTxURKREY 1Z7vm7g/HeWuBa4GCDyEO7Ise2JMeC1PrQxrOoFzDuDhz47SWg/cAsSZU2WXBoNiL+1bHUWWO6dC kAQfJItnjlHwxttY5w3BrmuLTwYMwoYDikB3K87JRjWsaLHMIB4JEBa3Reu5XR3mzGeWk6Ob2cPA hdj1joWHX0d3US4+plxsYYLR6uoHyHC80e/3EKYSxyxmUNY2YSEh1DGRK6lod9C3OudTHVMx2Q1g pbADWAkgAeZ8Ss2T807vcmaCQZHCikeMroxERQb9ji06FRF86OTWGUIrmohcAn0PBSAQGuIOiKy0 HRyJFKSbVINTjXhSa0lNJVbEMlOa1YZUSjfZzHCYZ0q3P2kcJw/sVYsqLeyruaiDaN1wVIeSFq1T a8FFTZpsLStPDv2uBaYWQ0qxU8t1CiyR4gtL12N1uyloh0ELP631u/PAba6Q3gDQLKbkaQSgXOLu PuUMMRjpZq7q9PsRXRBa/WQVAW9nKL5QyrQGi5saHhKEBjy0qzWWv+KR0Uu1kp/RI1Cs007it7H+ rGXbV6jyyokAhr5mDxMDRRTyCKreXdI0OiGVqdU6fbh2upubDh9xHiFkuDmHyT8chIWpk1xaVfxM k1mQYWa14JRWu0RnHiFFTu/t3JorPo2OY4iJBXP5NzrLC8mSTJKKbJEFVrGE6tQx4xDYKAWFgOjk +3uOEEyp1vLTHIU2ykra5Rm0vA4kImLWLXANHPZdvifVfFooaM1htusaHENJAZPYa6lRZMnDrW2/ 1QS8G5uiE3Ry3frD0k9Ot2sMseNzHRGngfMLn90Og6FSYZ8YtIeg6Nm/ZniyforoX/XJ1GOd7BcY 9s6QexXDV37GxKVmTubEp8cZ4rBItQsFDnZPr2ue8y5xJJ8ys+1so2RJJIVcP8VcwiqC4MBub5hE b7lNte/jVbn/ADVyaq5ue2u4ATSZ0JAO1zux1Wly+IzWTmI7mnCaIK6LoX1jyOkNdXW4iqyBa0dx 4jwKwcit1NrqrAWvYS1zTyCEMvMQrAqFwnESB3BVuLBI8Q2ut59ObmOfQ0sqaNtYcZJGpJJ8SSs0 gjUJWgzI4UWP1hyjyz9yVroihTNupR6jscCj9N6dd1HI9DHA3BrrHOOgaxglziVbz+kW4VQtkPZM Fw0g/NS4sZIsbrZTAPDe7fP1syf2Z+z8r9MyoTjyY2PHBd+8BK5dxky1TeeyCQWmU3LMVwgAC7Na apA1sm/Nm0yYRwzQ/BNh0HLvqpZAda9tYJ4lxDdfvXX2fU57XtoDiyXembHsMHXbIifkliiDuQCd rROXD0P0eWsrc3U8eKCVb3qD6mP1GhXLgrwWunCd1bmc8JgnJS1vLTor+OWWRPKz2q5iCXhR5Nlp d3p3S7cy5lNIlzj8gPErp6/qz0wVOZZue9nNm/bJ/ktGib6lUsLbbT9LQD4Lphh0bNpbqeT3UOPl 8vMR44EbyGprYadD1VGBkLHi+c9d6IcAh7Dvpf8AQdGvwPmuetbBXpvXMRj8HKx3SXNb6jD2BZ7v ySvOMhnuKGEyFxl80SRIdiEDTQ9GkQlCIWpemp7XMWuI80dlngh7IS2+CB1RTYD0xcUIOI5UwQU2 kKdtf9LnxQn1ka8hFISGiINKQBqJUDIhT2Ndxoi1Na12qUjop3Pq1S2zqNDbRLQ4Ez+C9B+xVusc 98kk8dvJef8AR7mV2tcDB01XoWLkMux2WA8jX4pcmMeXJPHkiDtON+Fj9q7FRJBHi819bOnMONvG rqSCD/JfpH3rhL64JC9F+tVra8K15BAe5jGk9zO4x8AF59e4FxITBEY8k4xFRBPD5WVp0kR06NFz I4SDyNHKb0IqYapSbpCYmEPUcJw6eUqpFLuDX86HxQ9hBRYTjTlG1On0dg9Zh8CvVsOwX41dpGrm ifiF5NgWbHgtXadJ+sAorFVhln4hR483sZrl8khR8D0KoT4JWdix+vFdZxg6ILbBH9ppn8i87vaN xXY/XHreJlenRhuLmgmyxxnVxERr4BcdY4PkhPxj1zI1BkTptqr9I+JQG1zdDwn3yFFwUNpH0Vai upkdUF9f7v3IzddDykWqfGdVJOns/St+M/Nev4uLg5vTDn30tc6+svf8Y1/IvIMZ+x4K6vp/1pfi Yn2S0ufjn6TAdp/su7LSjilmwjglwyjK96uPVYcghL1R4gR+Lzn1jZGcXyS57GucTyTESfkFjh/Y 8rS6z1BmdnWX1s9Osw2tnO1jRtaFmvaDqn8xP16dgnGPSLX5UDXJkJAlpg8IrRKbDVds7/1OtZj9 XodYQ2t59K2eNj/aQux+vtOOzDbTU1rWiqx52jXTbE/NedYt3pODgr/UfrDmZGD9ge7dWSCSfpQN ds+CsjGDPFmEq9sESj3u9fMWxykalCvmI17OHYYcQojVScQ9QALSq0zciyDZv9ODRc0nQAyvWsnr +Nf02q/D/Smva+9oEmtrWncT4Lx6l5aZCtHOuAAa8tB0IBiR4J/t48sY8WhgbHY33WmUok8Na91i oyQoiwFSkFc0uZB3ikamu1boU0JAkIKWDHMOqt4hhwQmuBEEI9DAHS37kyZ0QXuPqllei7b2cIXa BwInxXmnR8k0vE6Qu1xut0em0XcjvyCmcnzUeXnPHllwxl6onpfVOOYjYOyusPYasiwcV49m4+Za WtH4rzG5zXOIOhXdfWbreI/Bfi4pl1v0yBGgXnuQ47iQkTGWWRjISs8RkNrNbfQD6rTrI1qpwgpg UMXHh2qkHA8J9JZJSmTpJWS1HCkGypiuULUjD+xUpTuqQzLUhqimcojH+KAHypgpEIdHFuLHAgro cHr1mMAWOEjkESCuTreW6hWBkFQzxniEokgjYjQodT6wdev6ptZYQG1zAboJPdc5ZaQdEa57jqNV TedVLAHeRJJ3J1KfFlvDikQhSptsjRyk2SyDVMUyOESpgfqFr9L6NkZ5Iqbo0S57tGj4lMnkEQq3 ELC3lRkLoOqfV/KwKxZYA5h03s1E+BXP2sLToljmJ7FG6amzbqrLctzRoVmttjQ6KfqJxgCghllW OeSTqqLnkFWXP8dVXsYDq37lLAUkKFgOjkWuvcVVghaXTK/Usa13BKkMuEWuGjexvqz1PMo+0UUE sM7SSBMfugnVZeTRZjuLLWlpBgg6EL2LHwKrKa31OLKvSY1jGiA0AdvmuD+vGA2nJbc0fTLmPI7u ZHu+YKfjlIEE7HZPCRvsXkmug6JOuMQhPlh0UQ8FaWHKQKtYYsLQTqEJry0x2Ryhvrky3lSGzqkJ aaje9rKxuc9wa0eJcYC3L/qzbjB9YsDrazte0D27hoRPxWT06WXMeNCxwcPiDIXrWZTiu+rdueWM stvpFhfAb7nGdI8CpozjhEOKPF7kuD6mkGJmTRqhb5C47HEcEaEeCi47hBVjq1fp514bp7zp+JVN r507p2U8MjEKjqAUbg5hlWcOn7VkVUk7fUe1pPhJiVDaHCCjYoNdjXDsZB+CiAuQvuuvR1s7oL8f EflVV2NY120Od9F2hPPwCwt69J+sPWsLM+r2JRhRs2h9zY+hsaRE+O5ealvuBHinTmTCMjDgskAe A6oAAJAPE2CEwJapkJiFza5drweUQGUHanBISIRScDwRq3lqrseO6M0pkggupjZO2FeOc9rRBWGx 0FGNx4VeeIErSEuXlPefceVn2PlWHvDxB1QH1E/R18ipIREUhrkpmuIKk5pGh/FRAUqUzLPFHa0O 1CqtRqyWmQmyU2mVkq1TivsO1jS4nsBJ/BPhM9UtbGpMD5rv+n9IbgUV10tJe4brnt0c7+SD2Cgn ORJEQSR2160kAl8/yMV9Qh7S0+DhB/FUbGQvSuq9NZnUuotbts/wTjyD2E+C8/yqDW9zXCCCQR5h DDlskHQg0Qpz3NSDi3zRHNUS1WLQyY8dlLeg7SE4JHKVISFxUHNa7yPipaHhMQkFIHMLeVGDKsac FIMbyE61JcJhkea9N+rWPUek1sHO4ufHJK84xCA4doXf/VbNrFZpcYkSPiooyiM8BMDglcTe2o0T EjiF7On1DApfjuY7Vtg2ODtee/yXlnUKDTa+s8tcWn4gwvWc1wexoAMTuLvzQ0ckrynqd7b8q6wc Pe5w+ZJTskIwzn2xUaG21qmAJabOTYFAPc3nUItiGQpwlW8FMolncaKQngpwQtAJWh05wZY0lUoR aLNjpRI4gp9a+r3Uqr8SvGmbWN0HiFyf1/uDLacd3teS+0skEtDjDZjxhYdXVbax7XERwszqObdm XOuueXvPJcZOnCdj4qjE7RXE2AOzVs1KC5vgn9QjnhTEOEhXcQKLRBxGjlOFYow7Ml4rqYXvPDWi Slk4OThnZfW6s8w4QVfx4iRdLDIXV6sKHbHArfw/rPbi0fZ7x6+OAQKXn2gnuFzYdBTl+kKWOQRi YkAoMbWyMl19z7bTLrHFxPmShloOoUXs7jhKpx3R2UUyZyJ7rwKCeqsuRSws1XUfU3o1PUa8l+xt mQw1+kx/Aad290eOgCj9bOjHp4a8sax+1pcGcQ7+IIhPiIEmF+sC+H6WxmUgb4Tw/vdHmLcm/wBF 1TXEMd9JoPMKnvPBVhyGawSCFBkkSaJ2ZYtshNCmmhYCWMJ4TwpBqBKmG1TaSE4an2oEoZteibkD anDiE2kEJCm3EJt4KXKQCmUteIdqoupjVuvklEahOHxyipgBrCPTU550Epva7lFqL2GWmU2RNKd3 pGHabWO2H2kFekUQ6tru8LzLp+dcxw9xAXc9G6ky2rbY73Rp5qLlcvtcz+soRlGr6AjVfjlRru38 2vfWHAatK4TruC0ZlzxoHOLo+Oq7nLFllX0wyrRz3SQ7aNSPmvN+sdRdfmXWg+173Fo8BOidzceL mOOFiwLv9Kr1H4IyfM0rKWtQXNaExv3d1BzpRiD1K1ZwHZQKclMn0piZGoSD+xUw2Uxr8klLHVNJ B0USHN4Th47pyGzRZBErawM51PB0WAwo7Li0cqLJjE0F6XO+s+X9ifhteC142k9wD2XH5FhLiVat tDxBMKjcCNe3ijigY1ZJoVrrokMPU7OUoB1GqCUmvLTorCU7WSUX7MSOEXBr+0PawD3OIA+a9Exv qxhYtDan0DIs2g2PcCRJ7COFDkymO0TKuyCS+YWVuYhh8LqvrT0SvAc27HBFVsgsPLHDlv8AcuUt bB00UuHIMgtI1XNh4UHOB+kh7yNHJi6VaiuYWNI4T0SXp5UqwA6QrWDcIOz3f1FwqcjHzGTtyLfT a14+k2sk7tv8Vc+tvRPQwAHu9Ulr3MJGrXVjdA1Ojmys36l9Up6flh9ujXt2P8ge66H62ZddmBZn aCiumxrHE62OsGxoaPmr/wCshzGMD+bmB9vDVfb0YqhPHI1+sgdO9Xu+T3MhxIUA7sUe0hxMIDmy mZDUiPFkjqFwpMYN0hDbI0KK0pR3tRe2+omfTgZhdcQ1j2lrie3dXPr2+p9L8tjmFmSa20lpnftk vd8tFxmLlOp1aYQ83Lst0e4kdlOYw4xmsiQjwkdwxer5P0b4mm+QZCdurSfAJg7WHfIrU6d0bJ6h Rl3Y7QW4lDr7XEwA1on79FSySo6tiIsNYpBMLAeVIeSw1trgKQCYBEYECUrhifYiNaiCuUwypFtY sUS1W31QEFzUhK1NchNuIRC1QITgqlw8FS0IQy1IEhKkUlAI4Ra3EHVCa4FEbCBU3qHiR4rYw891 I54XP1uhWW3EBV8uLiQ7mb9YMx9JoFx2OEEacfHlczk2FziUex+8Kra13PKdigIp33QkpCwhMVGF OpM1zXfFTDSq4VihziYOqB0QnrpLlZs6bksq9V9T21nhxaQPvhdF9UOl0ZPqZtzA/wBH+baeN3Mr pXYmSWHczdI9wJBBnyUEzloShCUo2flBO3knXcAl8ptrhVnNXTfWPpbMLKmkform72Dw7Ob8iufs ZBUuOXEFIA4t51RG2g91BwUCPBS1aqSudKgXFQ3kaFPIPCIFKYuYDq1DDDugoqcEHQp1qdTow/WG EdjovW8K318Wq48uaJXj+C/03gg8Lt+jfWNmNW2m0zX+RQwzDBm4pXwyHCa6diqEhCVnYs/ru1js G7TVtlZB84cF5rcNSuy+uvWsa9jMTDfvaT6tjpmXRDQfguJfbJ9yfg9Upy6GUj9pKgdSfEoXhCII 4R3QeFAtVyK9g10qbTBTen3Tat5U+KVFaQ36Mp1WoMFTzep5V+O3HdY40tO4MJloPjCzw9IvWjDm Tw1bH7Yu0ZeQZCk1wf8AFQc2eE1YO7VRk8RXh0un9MyOoWOrx2bixu954DWju4p8/pWTgQ6xo2u4 c0yJ+IXVfUCqq+zJwbGhwyWscSSRpU7dGnxWr9b+jYeNhuZSYLqnPcHa+5nua4fkUsJQExhIIlIX E9NlsuOuMVwg0R1fNA/skXSmtZ7tEMOIMFMlLourqkawSF1X1fvGP0vqbQ7b62HbWR4y06Ll2HVa WNkmvHtZ+8xw+8KvliZBkxmnPUmuIUU4WMVjYY8HlWK2zwqbVax3QQFHPRBbtVJKvY3T77ztprdY 7waJR+kYbs26ulo1eYnwHiu6qwK8djcTGbDGAbyOXOPdyrSM5cXCCaIHmT0/akC9nz3L6ffR7bq3 VntuELNtrgwvT87CruqdRe2WEfMHxC8/6piOw8iyh3LDE+I8UseQ8RhIVIdEag0XIcEMhGeNUIhW QUsE6dKE5K0IjXEJmhTDU0oZseCig6Kvt8ERriOU0oISEqMpbgUxQCGL2Nf5FCdU5vPCLKcO8U4E qRNrJV7DxHuOkFVhB40RaX2MPKbOyNFPf/VOqyip9TgNti6UDa0N8AvPuidTfRY07uCF2uPnVZzY peWOiTxIKfyOeOMSxTPr4jweIl0H1X4pACjv0eY+t7Jppc7Qh7wB8Q1y4u4CV0v12za25VeFQ7cM dpLz4veZdP3Bcm++eUzHDhJA287/ABWdWLghlTJlRUwXMCFEtIMhGAlS9MlG6UgDuxThEdSguDmp A2imxVZtMq0Msjgws1tgUt6RgCUUkyrHPkn71RedVYNhQXsDtW6eSkgKXBEHEItUPKC5plWMVgLm g+KmBpLu4f1ddkYTcu1+xthPptAlxA0LvhKz+rdKfgObrurfJY74cghejfVTEoz+ms9ZoLKWmoDv qd0z2WD9dsbGpffXR9Fmwiex00/FTYyCEAGr6PAOBadE2+eUV41QnNUsJppeVJvIQgSPgptKmhJD 031Z6oem5lWQPzDx4g6ELovrT1/CzemPyRYPWcw0V445Befc5x8AF5/VcWJX2us1lWwcZMchHrho D4dlkhI6X6TqQwc8OdomLJQCSDKsUP3GHBQ1xS0XbBkyp4EgSEYPhpb4hdr0f6sUXdKxbmU/aLMm s2WOJ+gdxaGADwjUrAzujjH63RhAOLLbmMDfztXBpb8VL7cJxIiblHcfWlgyESoxIB2PQuJqFJpR i1r+QomkjVuq5m2W1MVvHbLwqjdOVcxT7gmT2QXs/qeAM8bv3SAu5AifMyvPfq9eashjx2K9Brdv YHeIR+GzHFlgRqCJ/Qil+I7hFl1h9JPdolcJ9baQMqp45sqBPyLm/wAF39ri1hgbidAPGVwP10sD c+ulh/mamtPxJLj+VLncURmGQbmPCfO9PwBW5RqC8xbWQgFqM/IPBQ94PCZG1oLH0ylsUg8pp1Tt UsmtClAUQiNCaVLAJ4Ug1S2oWpA5qjuIR3NQnBEKpjulJRLU24jlORTNErshCBBUkihvUXFhlphW ndUuayGuIPkVlNeQpG1RHEJGyLVSPJudY4ucZJ1JKpvKtPa12o0KrPYQdVNAAJDAOI4RWPadDogw l3T1N1le7jVaeB0nJziRj1l8auPAA8ydAs7Ca4kea9P6Dg1M6VjhkNc/3udAMu85UMuKcuCO+/02 /aoWTTwfUeiZmC0HIrLQ76LgQ5p+YWJdXtML13qHTW2Y7qbTvZb7TIiHHh33ry7qFJrtewiC0kH5 IYzkhMwyDhkP5dFag0dHKe1Q3lvKO8ITmq0Fy28FMVEt8EtxGhTwpRE8olJ2OkKEpwY4Txqh7P6t fWOzprTUHhtdhG7cJjzUPrvm0CgNZf69mRtOgA2taOTqdSuUbe5vBVfJse8y4ypIenZVfgj9QE6p +UByTbS0qWJXJtkpjWW6hXOn47s7Jqxa/p2uDRPaVtZHQMSHMqe/cAQ17ohxHl2BKu4OWlkFxOzH LIImi8yH+KkXSnuqNbi1wggwR5hBJLUCTEmJ3C7fUM3AO0KJjja4BBBlFrMFHGdQUHZ9X+oOfj/s yzHe4NfW7cAeS0+HzWJ1q5v/ADl6be4OD3ZTbCCIdHqtDdPPbouYwuoW4wBqcWkaggxBQsnq2Zkd RZn22Odex7HCwnUFhG37oVn24Y8k8wlfuD5ex/h1YrlIRhVCJu/tRqbXKAMpwuWLMlG13KNTXDgW lVgSrFL4TJDRDu9NtNbxOi7Pp3WG11Ct5lo48QuAxsgBaNeY5rdCqcvcxZPcxy4ZBAJBsaPcZPXM OmkuL/dGgA1XnfWst2blWXvOrj+HZFy82x4iVkX2lxMqUTy5yJZTZG1aBJkZHVBbyhEwpvdKEVOA pm2w90Vrg5AThEhTaa0orAq9VhHKv44ZYfNRzNKUyouRm45hanS+j25torrENGrnnhoW6Pq9hCsg Ps3fvmI/zYUEstJeItrLVXc1b3VenWYlprsHm1w4cPELGtZCkxzsKargoEIzmoZGqlCmBEcJB5HK kQmhOQyDgeE5KGW+CbcRyhSqZlNzodU24FIlEIRuq1lqjtg6ohJSkHlOS3cKNzV6Z9Wbw/CFU/Q4 +a8vxztIgrp+jdYdiwJUEpyw5YZQL4bsdwUA8JBe36g4ek1oPuLhA8+y8r649juoZOwyPVfH+cV2 /UPrLhMwnXAg5LWkViPduPeV5pk2ue9zidSZJTuMZ80sg2oAJkeKVhG/lDISNh7p2kO4VgaJY7ZT GuUdrCVZrxC4SkZiKrcw1kcKO7x0WjbjFo1CpW1wn48gKRqjlMT4qBlqbcCpwpi9gPCGGQ7VGSgH lSxCbdLoV32fPoyG812NcJ+K9WzsDB6d0O191frPdUKy4ATLjI2/AleP4z/SeHdl19H1lbl4P2Pq WQ9tdTIZryG9vj4LQw45ZI4wJcIjLimOpHgxmQiSeHiJFB5rrlYr6jcyIcCNwP70Dd+KzS1Gz8x2 Xl25JG31HSG+AGgH3BCY9rtChzFSyyrumGkQD2YbSOFJpjlG9ME6IjsOzbuLTt7GDCUMcumqjIIW 2EJyZMnsoOBYdU25KUiBSKbQkcKTX+KaE4C59fSRpRWOVcacKbXEcppCKbtb4VgXkNiVnteih6il G0Nk3TygWta/UaFQLpTFyIjWykT2Ob2keIQpKs7kxY13x8U8FVoAptUvSI41U2MHdIlKmCStPApJ MqrTWwnldD0ijCJBttA8oVfNPhCHrPq3jNZ07Ue55O4/gtQ49REBsKt0o0No2UmRyryu8ljx5OWg ZRjKwbuj1LNADhDzv1hw2vxHaS6l0g/yXaH+C4nJpIcRC9I6rbRXj3OtbIa0bvmRC4bOy8V7yGiF QyQ9nMYR9UfDzP5bMcqBLjGo+CG6tW7LG9kB1gUsSVttdzCo7UZzwUNPBUx2qJaiwltStTWczwUd xHKsOaguanApY7gU6G5vgkHEaFOQnY4g6K3XkkBUGvHZEDk2UbQ2b7n2DmfJZ1xMmUcvKg4hwhwl GEeFQahSDoOinZUQZbqFAN11Ui5v4U2FocOV6T0PolOL0+m2usWXXN3ueQDtH7rZXnnTINrPivV+ gOFmDWSZLBtHkoOEZswxG6lE6jodP2WgDilR6h536zdGpuxbMqqsV3VDc8NEBze+niF57kMhxC9k 60GmotI+lW8H4EFeP5UbijhicOWeIniETofMWoemRjvTnvbqhFvdWHhDIV+JXo5I5TghSLUNzSOF LAoSBxHCkXkiEEO8VIFWseQhBDB4KhrOiOoFkmWo3ZVbo9HrZbm47b9ajaz1B/J3Dd+C9Myug5GT TdkU7HU+/ZVEDY0w1rWxEbRovMemv2XNnReuN63jZHQw6guNrqdmxgJLXRt1jzViUskI45YhZMuG XUC6YjHHORGQ0ALGtPk/VsUY2W+tmrNHMP8AJdqFnFuq2vrG9repWUnQ1BrHDwIAkfJZ4pDmGwEQ NSm82OGZI2NH7V2IkxF9mcJ4TpwFzrIoBPCcBPCBUsAnDiE8JQgilw+U8qEJtQlSqZEpByhv8U4I KKEoepyHcoQUgm0pMxp5aZ8loYL3MOuizWOgq7TdGhUeSNgqe16Hn+nGungukqyarfonled4eUa4 gq8/qjw3QkEdxyocHMZeVJjACUCbMT+xMZmPk631tzm144xqyA553PHeBxK4O+wucVezct1pJcZJ 5JWXa7VSRJyTM5DWR+xB1JPdibCO6b1AeVAlMpQEJeeE4aUIEhGqfJgpHRVs2slGGOSJhXOnYD82 5lNQlzzA/vXW1fV7ptLfSsYbntEOeSRr5AKDJm4dfGkvBW0loVR7V1vXeiNxAL6JdS4xry0+BXM3 sglPw5BMKDTcEMtVhzUMhWAUoYjhOLCOVIhRLUVMg8FMSoFscJtxHKICKZyltBUQ4FSCKm5g+x4I 7LvOg9abj1em8+08+S89peWEELQqz3N4MKtlhLiE4GpROhC03djcPe/WXqmHj9Msvqv9W2xhrqYC NC8QXeOgXlV73SSFo5uU+07iZWY+xpKmxAmRmQAT2v8Aba4am0PqA6FOAChW6GQnpLlbjsuTtpc/ RoJPgFC2hzNHAg+B0XW/V3BY7BNjdotseWuc7SGgSAD8VLr3R8imj08mnZYW+rW7QkgdpCmgAVW8 S5qjq1HeNUMtT4mlMQ6VIKJalqFNEoIbFT9pHktfD69mYLS7GsLXRHyWEHIgeVbx5uEVuD3Y5QEt 2OTa+2x1jyXOeS5xPJJQm3OALQdCERwDvih7IMeKiyTM5EnqvAoOmnCZSC59cuFIJgpAJpUtCeFI NT7ULUjIUSEQhRIRBUjIUYIOiIVEhEKUHEcojXAoacBIopO0o7HKoHEIrLEwhDoU3FqK7IJVFlin vURgLQktc1415VWyt3I1+CIXKO+E+IpTWMpwjkMfyNfEKPpRxqnWm2ABKs41Jc6VGsMB9y0MK3Ga 79I3co8kiBoEF6P6o4zW5ge7naYXYCmsAgtBkkmfNcv0TOwxY306w0jvK6oOBAI4Oqm+GmGSOQSi OISuj2IA/YyYqIPdyus4jH4ttIGljCfgW6hecZlJa46L0zqmQ1lVp0LaqnPcfDQwPmvM83LmwqCc RHmMgx/JegGw2uvqtn82jRsbCC5Gsta/jRAKnj4oDEpoUoUg2U66SiLVBzVa9InsourhISVbULY4 SDyOURzEMhPBtSRtg7IgsVQyOE7bCOUiLVTZdYq9ga/yPiFLeCFBxToikBrvY5vmFOg6wpEpmgAy NFKNlz331ByMVuU5mQWj2ksLojd81ofW3KZl2tqrtaa6mv2ADQuAHdcHgZ7sVwc0wr/UvrBTbgOq rrDch42GzwB5hS4iI7i0Wa4XnHPDjI7pRKA4kFSZaQdVLGiUp/TTGowi1EP4XR1/VHIOOy3ItbQ+ xu5tbgTEiRuI0BhXMeISDHPIIbvJlkKIcRytDqGBbhXvoubDmGD4fJUXNQlEwNFMSJCwtMp1CCOE +5Mu11Opt8E8IIsIRG2A8rCKkgCI0SosAKOxiZIqtTWSpemj1UkmIVtuBa5m8VuLfENJH3qKWQDq pynMQnNV+6gtnThVHthPjK1NchNCm5RUgSxhSCSSKlwnCYJ0EMg4hEFnihBSTSFEJN8ppUPgluIS pFM5SDyFDcE6VISB4P0gjVRMtPyVZErcWoSip2+n5XovC63A62xrGi5xLB84XBU2mVb+1ua2AVXM Z45ieMmMvD9qgSDYej+s3XcV+I7EwiCbDNhAjQdlwWQ4kkq7kXOdJOqz7XAlTQ4pHilqT4V+Cbs2 UDimDyE7lCFOFJ63tdodFaqp3RGqoVsLnALe6HjC3MpY7Vm9u4eUqPLLhF9kE06GB9VsvLpbc8tp Y76BfMu+DRqqXVuiZHTSBcAWu+i9urSvTTiNc8Oa4s2tDWBvAWX1jp3rYV2NYA7c0urd4PaJCZkx 5sJ4pC4XXEPp+ZSYyjr0fK7WQUB4VzJbtcQqb1PjNgJCIhNCkUoUgSjII4UdxHKNtUXMTgVI5BTS mc2OFHcRypIqpKHEKD/d31TByaVIFMC08FQ2mUWUxClh0U3unVB1rQvYsLp+N1CgZeQwFtoa6uCQ 4AMa3Uz5LxnDsdU8O8F6b9W/rFuwGYIc31AIrLzHntV2UZzwA4rEonXvwnf8mEyjGd5NYkdr1eZ+ uGIyotc07vTssoD/AN5rfc38q5NzV1P1yyDU6rDc5rrWufdaGGQ0v+i37lynqidVJzEbENbPCjB8 ugoWa8rVsTbNUVsOVyvp99tDr2VuNbAdz40ECTqmQxGWzJKYjvohAUgFEFTaueK5IwkK/iy4gFUW CVqYNeoUOU0EPTfV7pFeROVktmmsaD95y6FoIaY0AGjW8DyT9JxwzplTGjQtbI8STJWqGNDdsCPB Q4uSnzYEuPgHDxbXdkgdtqXiFjetHjvrD02u7HOVWwNsZq/bpuHiuLvbBIXp/U6mVuLXCWWafAO0 K846hUKsiyruxxb9xhNwCWKc8U94GlnykhznDVQRnsKFCtgpWSTwUoRtK4UgEwCm0IEoWATwphqf aharYQowi7VEhK1IyFGSEQqMIhS4eFNrkIhMJCVIptseiGwwqbbCOVMWghNMUUldYgvbW/6XPiEi 6UMlOiFI31ubx7goNCLvKR2u5CelnQBK6PoTKm3NcTrIXNNaZ9pWt0241PBJhV+YiZRIWy2fVsZ4 fQxwMyFW6iWw0GZIIEfjPyWT0vrdbGNquPt8fBL6ydVwsTp9j6Hh91zTXXDpgO+kQPgpTzMc/LCG gkOETjI66V8vdkMxKFeVvm+XaDY6eJKqOg8KWQ6XEqqXEHRPxigFoSkJw1Qbd2crFbWP+iU8mk3S za54CZ9J8Fv9F+r+V1RxFIDWM+nY76LVf6j9Ursag30WC8MEuAaWuA8QDMhRHOImrW8TxT2Qguat HJp2khUrArOOVrwbazm+CjuI5RXBQIUwKd1plOowm3EcqWBRTYrfBV6nMdUPa4iOFmBymHq7gzGC ycOJLl5Fl7y+xxc48k6lU3SjEzzqoFoOoRnPjNpiANE2KwkgeK9GZ0+rM+rwOPIqxsF73tA09QNJ fPmYXneI/a8T2Xo/QusYv/NbPwrXBljaLiyeHbmO0+9SSM44TPECZxI27HS6Y5RjOYjM1Hu+eAqb U5pPZMGlvK5ss1tiorY6efc1YlZWvgPjaoM40KC+mdDuD8Nje4A/BaS5n6v5jWgNJ0XSB7XiWkKf 4ZnicPtEjixkiupjuGTGbj5Od1VvquorB9zrIjyBBK8268R+0spzeDa8j7yvR+pW1YddmW9+51bD tHZv+0ry3NtNtr3u1LiSfmqxJlzGSRABJF63sAOnVjn8xaxuI0Teq0nVDeeUElTgKbm5pCiVWD3D upttPdHhUnBU2oTXtKOxs8JpUkaJUw2VOqolXKMG67Sqtzz4NBKilMBTRLNENzVq34NtOltbmHwc CPyqhbWQUIzBU1HBRhFeIQ1KFMSEykVEpwUsU0KSYpKY7iE26U5CiQiil0lAgg6Jb45RUlYYKt0X wVRDgURr4TZRtBdduc9g9pVLLyLLJcTMoAtUXWpkcQBulU1rXSUAlWX7H8iD4hAfUeQZCniuCPnh X8OqYHcqk0EHVaGC+HBDIdFS2fTfqhQxvSTVGpd7vEzC18jEa0G2vTby1Yf1Rym7TVPIldDk2sFT xOu1NwxxZOWkZgcUOIX1BBMhr9VRETjJO4v+L5V9Z8NuJ1O+qsQwncweAcN38Vz1g1XUfXS9p6va 0fmNYw/ENE/lXLWWAlPwXSIoiFEhTJBTAaq1FejLVEtVgs0UHMIUgVbXLfBIOI5RCFAhSRkQrdfd KcIZHgn3EcqWMrQQnY6CtGnOczHfUDo5pBHxCymuCIH6FW8GYwY5wEt3RBUhBQ1ISuaK5mKmnjRX 8X2wqLCfBWqXOngqPILCnoenZhpiVt1dcNTezvIrk6bHwJafuU3vt7Nd9xVKWH1WLB8FA1s3uu9d tzK/R0awaw3uVy1z5Kt5RfBkFZ1hM8K1gxiISEb3Icp3KGqsAJZKQUAphEqZtCsUOduACC1WsYN3 chRzOiHa6Viuyrq6W8vIErvMbp7MGluPjNPG57uSVy/1WZWM2skide/ku8EdlHy3LjmjkuRjwkCx 46ldCN242ZiV5NTse8HY76LjoQexXDdTw34l76X8tMT4r03JDDUdxAPb4ri/rMyr12PkbnM94kSC OJ+SizYTymUQvijIcQ6ddkSjwl5J7UIhXrGMPDh96rPY0dx96mjIFFoCoohA8VHRPBUtCQCkIUgA laEZaouajwPEKJa3xCQKmuQoEIzgPFDITgUoo8E+8jlOVEpyqZeqEi+UIpvcOEaVSQlRlR3HuClK KmYIPIVnGaAdD8lUCLWTOiEhYQXq+jdROLB4K6Z/1swKsMuvZNzB7W8gnsvP6Lb2jRjiPgUr33OH uDh8QVWjjnCcjE1xaHr+a0WDp1a3VMp+Vk2X2GXWOLnHzJlZdh1Vu/dOqp2cq3iFABfEIvULUeol xAjUoAjdqreNG8SprpJ0e56f0OrF6dS6ql1tttXrW2Abon6LY7Bc/wBe6bVXWMzHG0ExY0GRrw4L 0H6pMN2BVbkOLHtYG1tJ2nYBzHcLC+uz8Wz7QaGBgFI3xEF/jA+SngbFVuFcJq7fOyFEhSJJ7FJG KmG1RLUXRIgeKmjDRNoYhPuPCkQFGE4EhD//2Q0KZW5kc3RyZWFtDWVuZG9iag04NjAgMCBvYmo8 PC9TdWJ0eXBlL0Zvcm0vTGVuZ3RoIDEwMi9GaWx0ZXIvRmxhdGVEZWNvZGUvTWF0cml4WzEuMCAw LjAgMC4wIDEuMCAwLjAgMC4wXS9Hcm91cCA4NTggMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9J bTAgODU5IDAgUj4+L0NvbG9yU3BhY2U8PC9DUzAgODM0IDAgUj4+L1Byb2NTZXRbL1BERi9JbWFn ZUNdL0V4dEdTdGF0ZTw8L0dTMCA4MzggMCBSPj4+Pi9CQm94WzM3My4xMDUgMjIzLjUzOCA2MjEu MjE1IC02OS4xNDAxXT4+c3RyZWFtDQpIiSTMMQqAMAxG4T2n+C9gmzS1NbsgjuLgAUScVNT7g8Xy 1sd3UwziTBMadiYJYuI4ZIhmF7uEZ6MFJ93kh5mxv1QHFdMILtUxamsZvxWyqGn1JLXFXA/y48Ho L5pKnwADAG91F+QNCmVuZHN0cmVhbQ1lbmRvYmoNODYxIDAgb2JqPDwvU3VidHlwZS9UeXBlMUMv TGVuZ3RoIDEyOTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJPJN9UFRVGMbP3eWeuyN6 S5ZLtuLd6wdYChbjNIGpiCsu+IEFoaQJrrvXbXXdxd3lQ4I0o1J2MEYoA80YE9xRjFBAUEnR0Ric svGrbKJa09XaSp2cee96dpjOytjcP86Zc97nuef5nfcwKEqFGIaR3sjNNhqXTc+S7aWyx2Y25cgl cvJS2WIr2WhwOiyRmonKeEZ5JoqkEvujPY8WsxMQetc/BuxPwfaxh+PZkphI0fsGZ/Fml836lkd6 zvy8lJKW9qKUYXGulaW8zW6PvNEtZTvMTlex02XyyJYZkpRht0u5kXq3lCu7ZVcpXf3/FJLNLZkk j8tkkTeaXBsk5zppic3h9GwulqUMo2RyWF5wuiQb1bpL1rptFpvJZZPdMxBi6Ic4hMYwaBJCU1Ro GkLJUWimGs1CKJZGRiqkRgfRABpinmVcTDtzlflTpVJlqFyqE6pHapP6ivp+1NSofJ7fXxXIKw3F XotpBmQNwvig77a2E04p8cJXrezXHe293+ogenLLclHbljSvIEFuNh+w6FvNrLaz0MbmrLYsmaOb 10N4SPv5TFtXr6h1dOewMAZPg3j21Pe7b3boGlKqOHnrmgqnSObDB8LbzWxZa0l7u+5ER5NP1HZ2 tdD4xQ6XW59HEgRIIGtYR7F106rx2a/3XTxzoLOzTc97YRwzCFg9GNdXiYvKHfb3xNe43/e2nP9J B+MI5niyCrY9YHqgSd0D2wRoekCaML+huRQMAXgYZLYpR9SQCfuE3+AhW4uHyEOWANknQDTuBQML Mj5O6BCNyauhQpYkUm2VX/nOH9MFGDyAiQqw9q4SCw3CFi5768Skl+XzUAEVHad/FbX3h3Z+np6t 2wL4U+7aFphGikh2HtGQelJ/jmggS9TehdmnIQYEfRPH13n9ylE/c4Eal9FEkBHSCH/gf45kktVE tixN1idjgl8SoIj++CAkghWsTkgkHj0pwnymNwjlQVgZjOjVF+IUMUjaoBwagqQBVsKBYDgO82So uTRUWMb005L+OMChQoIxL3mDynAZ00sXe+MUXZD4lOHIOqQ3lyoBGE0dkTIOEHWlk0AthinhABuk gxJga8MBQNRnPiZPh1vYHZjEKC0sWYj5/V5YpCCYHZFD9RN5N5Wbw90s6KkIhX1UYFZ8LNFjvu4x WCYCdnsk/6EqAVKvgAbqod4AGvr6Ug0j8K5QeKl6f5QxvwtqoLq/69KlfhOpJjX5JqOeL6CXe9IP 3hGUK56gvIoDh96cm7J8fY5+FgUZHivQ3ZP3MOiu/wKxwC/zkwl6Uor5Kqof9EPliN70GCedDN7F N76wzanV166oMX+0ZqezruSTdzQg4MqPK/bu+HJHd825mt4P7607umCXppa7sbvz8h0d6Gb1TRVJ HaaNclmAyr+4623mdMPaovn6J33UBngydS8AnEQ76ar2VhtsEiq4qcfIKNqXU+4MQtLfRWcT28W5 B1ntj+k++6EB3Q8nWk9d9smLxErAe7hr5dR9MdHNNJC4hJ78f83ijWJWe+tiecf6ebrl1gLDbPn4 TfEzjp9J73M4yMCCCJIFNJMyDK8Ewyumw1yausofiitj+uhZZLrfFyoUwl6OpA0tgwkQP/QNpImK l2Jr4FKsZuNC67HbotLA8ZkjHQVZEc+sCKfDGPIUI0vok3mKDJDRMMASLYYlYSPLVzWGChtJbiNM asTQsuvmrvDZes4/ClA0VMcqJ4X/BBgAcuWcuw0KZW5kc3RyZWFtDWVuZG9iag04NjIgMCBvYmo8 PC9TdGVtViAxMDgvRm9udE5hbWUvWVJJR0dPK0hlbHZldGljYU5ldWUtTWVkaXVtQ29uZC9Gb250 U3RyZXRjaC9Db25kZW5zZWQvRm9udEZpbGUzIDg2MSAwIFIvRm9udFdlaWdodCA1MDAvRmxhZ3Mg MzIvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy0xNjQgLTIxNiAxMDMxIDk1MV0vQXNjZW50IDk1MS9G b250RmFtaWx5KEhlbHZldGljYU5ldWUgTWVkaXVtQ29uZCkvQ2FwSGVpZ2h0IDcxNC9YSGVpZ2h0 IDUzOC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDAvQ2hhclNldCgvYW1wZXJzYW5k L2NvbW1hL2h5cGhlbi9BL0MvRC9FL0kvTC9NL04vTy9QL1IvUy9UL1UvWSk+Pg1lbmRvYmoNODYz IDAgb2JqPDwvTGVuZ3RoIDMxNS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckdtqwzAM hu/9FLpcL0oOjQuFEBhpC7nYgWV7gNRWusDiGCe9yNtPskoHMzj6jC39yq+kbo6NGxZI3sNkWlyg H5wNOE+3YBAueB2cynKwg1nup/g1Y+dVQsntOi84Nq6fVFlC8kGX8xJWeHq20wU3KnkLFsPgrvD0 VbcbSNqb9z84olsghaoCiz0Veun8azciJDFt21i6H5Z1Szl/Lz5Xj5DHcybNmMni7DuDoXNXVGVK q4LyTKtS6Oy/++wgaZfefHdBlTk/TlMKxHvhPXMtXDMfhY/ERRaZAvFOeMdcCBfMWlgzH4QPzFKz 4JqF1CxizZPwifksTM2XWnrT3JvOhXNm0dWsq0VXs64WXc26WnQpsAn3v2U7aGrw8NrcQiCb42ij v+zs4PAxfT95oCze6leAAQAnhJmtDQplbmRzdHJlYW0NZW5kb2JqDTg2NCAwIG9iajw8L1N1YnR5 cGUvWE1ML0xlbmd0aCAxODEzNi9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMi1jMDAzIDYxLjE0 MTk4NywgMjAxMS8wMi8yMi0xMjowMzo1MSAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlv bi9wb3N0c2NyaXB0PC9kYzpmb3JtYXQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnhtcEdJbWc9Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9nL2ltZy8iPgogICAgICAgICA8eG1wOkNyZWF0b3JUb29s PkFkb2JlIElsbHVzdHJhdG9yIENTNS4xPC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6 Q3JlYXRlRGF0ZT4yMDExLTEwLTI0VDEwOjUwOjAxLTA0OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAg ICAgICAgPHhtcDpNb2RpZnlEYXRlPjIwMTEtMTAtMjRUMTA6NTA6MDEtMDQ6MDA8L3htcDpNb2Rp ZnlEYXRlPgogICAgICAgICA8eG1wOk1ldGFkYXRhRGF0ZT4yMDExLTEwLTI0VDEwOjUwOjAxLTA0 OjAwPC94bXA6TWV0YWRhdGFEYXRlPgogICAgICAgICA8eG1wOlRodW1ibmFpbHM+CiAgICAgICAg ICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291 cmNlIj4KICAgICAgICAgICAgICAgICAgPHhtcEdJbWc6d2lkdGg+MjU2PC94bXBHSW1nOndpZHRo PgogICAgICAgICAgICAgICAgICA8eG1wR0ltZzpoZWlnaHQ+NjQ8L3htcEdJbWc6aGVpZ2h0Pgog ICAgICAgICAgICAgICAgICA8eG1wR0ltZzpmb3JtYXQ+SlBFRzwveG1wR0ltZzpmb3JtYXQ+CiAg ICAgICAgICAgICAgICAgIDx4bXBHSW1nOmltYWdlPi85ai80QUFRU2taSlJnQUJBZ0VBU0FCSUFB RC83UUFzVUdodmRHOXphRzl3SURNdU1BQTRRa2xOQSswQUFBQUFBQkFBU0FBQUFBRUEmI3hBO0FR QklBQUFBQVFBQi8rNEFEa0ZrYjJKbEFHVEFBQUFBQWYvYkFJUUFCZ1FFQkFVRUJnVUZCZ2tHQlFZ SkN3Z0dCZ2dMREFvS0N3b0smI3hBO0RCQU1EQXdNREF3UURBNFBFQThPREJNVEZCUVRFeHdiR3hz Y0h4OGZIeDhmSHg4Zkh3RUhCd2NOREEwWUVCQVlHaFVSRlJvZkh4OGYmI3hBO0h4OGZIeDhmSHg4 Zkh4OGZIeDhmSHg4Zkh4OGZIeDhmSHg4Zkh4OGZIeDhmSHg4Zkh4OGZIeDhmSHg4Zi84QUFFUWdB UUFFQUF3RVImI3hBO0FBSVJBUU1SQWYvRUFhSUFBQUFIQVFFQkFRRUFBQUFBQUFBQUFBUUZBd0lH QVFBSENBa0tDd0VBQWdJREFRRUJBUUVBQUFBQUFBQUEmI3hBO0FRQUNBd1FGQmdjSUNRb0xFQUFD QVFNREFnUUNCZ2NEQkFJR0FuTUJBZ01SQkFBRklSSXhRVkVHRTJFaWNZRVVNcEdoQnhXeFFpUEIm I3hBO1V0SGhNeFppOENSeWd2RWxRelJUa3FLeVkzUENOVVFuazZPek5oZFVaSFREMHVJSUpvTUpD aGdaaEpSRlJxUzBWdE5WS0JyeTQvUEUmI3hBOzFPVDBaWFdGbGFXMXhkWGw5V1oyaHBhbXRzYlc1 dlkzUjFkbmQ0ZVhwN2ZIMStmM09FaFlhSGlJbUtpNHlOam8rQ2s1U1ZscGVZbVomI3hBO3Fibkoy ZW41S2pwS1dtcDZpcHFxdXNyYTZ2b1JBQUlDQVFJREJRVUVCUVlFQ0FNRGJRRUFBaEVEQkNFU01V RUZVUk5oSWdaeGdaRXkmI3hBO29iSHdGTUhSNFNOQ0ZWSmljdkV6SkRSRGdoYVNVeVdpWTdMQ0Iz UFNOZUpFZ3hkVWt3Z0pDaGdaSmpaRkdpZGtkRlUzOHFPend5Z3AmI3hBOzArUHpoSlNrdE1UVTVQ UmxkWVdWcGJYRjFlWDFSbFptZG9hV3ByYkcxdWIyUjFkbmQ0ZVhwN2ZIMStmM09FaFlhSGlJbUtp NHlOam8mI3hBOytEbEpXV2w1aVptcHVjblo2ZmtxT2twYWFucUttcXE2eXRycSt2L2FBQXdEQVFB Q0VRTVJBRDhBOVU0cWxubVBVNzdTOUpsdjdPek4mI3hBOzgxdVVlYTNWaUg5RU1QVlpBQWVUS2xT Rjc0UUVFMG1GdlBEY1FSM0VEaVNHWlZraWtYb3lzS3FSOHhnU3h6OHY5YWJWZEl2SGtwNjEmI3hB O3JxVi9ieTA2VkZ5N3FQb1NSY2xJTVlsazJSWk94VjJLdXhWMkt1eFYyS3V4VjJLdXhWMkt1eFYy S3V4VjJLdXhWMkt1eFYyS3V4VjImI3hBO0t1eFYyS3V4VjJLdXhWMkt1eFZLOWQ4dzJtaXJieTNr VTV0Wm5LUzNjVVplSzNGS2g1eU4wUW5ibFNuamhBdEJOSytxYTFwZWw2Vk4mI3hBO3F0OWNKRnA4 Q2VvODlhcnhQVGpTdkxsWGFuWEVCU1hqRXZuTHo5NTNlYTI4bm92bDN5dmFrcEpxY2pDR2kvNVV1 L0QyU0w3UGMweVUmI3hBO2pHQXVSWXhFcG1vaFBmSVdvZVdQSTlqZFdNdXVTYXhMZHpmV1o1STRH Q0xLVkN2Um1KNWNxRGV1YXpMMnZnQjUzN25iWWV4TlNSZFYmI3hBOzd5enZSdk9ubC9WNVBTdEoy RXAvWWtqZFArR0k0L2prOEd2eFpUVVR1MWFuczNOaEZ5RzN2VHpNMXdYWXE3RlhZcTdGWFlxN0ZY WXEmI3hBOzdGWFlxN0ZYWXE3RlhZcTdGWFlxN0ZYWXE3RlhZcTdGWFlxN0ZYWXE3RlhZcTdGWFlx OEw4OXlEemY1N2g4azJMaXk4dGFFSHV0V2UmI3hBO0VCVVVwOGM3MEFwVmVmcHJ0OW9uSm1RaEV5 TEFRTTVDTVVWYVd0NTVvdmJmUjlJdHpZK1hMRXFrVUVZL2R3eFZQN3lTcEhLUnR6dWEmI3hBO2sv VG5KenlaZGJsb2ZSOTNuNzNzOGVQRjJmaHMwY2hIelBjUEpsR3EvbHg1UDB6VGZYdTdpN2pRTXFQ ZEFxd1F1ZUlabENmWjVabVomI3hBO3V5OEdPRnlNdmY4QWdPRGc3WTFPV2RSRVQ1Zmc4M24rdDZL TksxRDBFbWp2N2VRY3JhNGhZRlhIVGZpV29RZXExelM1OEhoeW9FU0gmI3hBO1FoNkRUYW54WVdR WUhxRDBaeitYM21yVkVsaDBxOXRXV3lhcVFUbm44RGRsL2VGang3ZTJiZnMzV1RCRUpEMC9jNkx0 YlE0eURrakwmI3hBOzFkUnR2OHVyMG5PZ2VhZGlyc1ZkaXJzVmRpcnNWZGlyc1ZkaXJzVmRpcnNW ZGlyc1ZkaXJzVmRpcnNWZGlyc1ZkaXJzVmRpcnNWZGkmI3hBO3FUNlQ1VTBuU0dYOUdtNXQ0bEpQ MWMzVnhMQ2Evd0RGY3p5SXYreEF3azJnUnA0UDVNdUpKdkxYbXpYbnExenExL0ZidE1mdGNXWjcm I3hBO2lRVnIrMFNLNXIrMnBtT0NoMU5PejdBeGlXb3M5QVM5Qy9LYlZVaXROVXN3Z053aS9XNHl6 Y0ZZS09KRFBROFFEVGVuZk5aMk5tb1QmI3hBO2oxNXUyN2V3RXloTHA5S3JyZm5tVFVQSzk3OWMw dDRZL3JLV2pvSmFWSkRTMHEwZGRoSFJ0cTc5c2xxTzBEa3d5NG8xNnE1L0h1OG0mI3hBO0dtN01H UFBIaG5mcE11WHc3L041cEt5UEl6SW5wb1RWVUJKQTlxbmZOQ1R1OU5FRURmZEVRalQ0eUhrbWxa MU5lTUtoUnQwcEl4cVAmI3hBOytBeVE0UnpKL0g0N211WEdlUUh4L1YrMTZyclYzK1pPb3BwQjhy Q3p0ckc5dEVudkw2OEhPU0oyQWJpQURScXFlMGZYdU03clR6RXMmI3hBO1lrZW9ENTNxY1poa2xF ZENSOXFiNko1WjFHMlpMbldkYnU5V3Zsb2ExRnJiS1IvTGJ3Y0ZJLzErV1dFdFFESU1peWRpcnNW ZGlxQS8mI3hBO1NxL3AzOUUrbWVYMVg2MzYxZHFlcDZmR2xQcHJYRFd5TDNwSDRFdXhWQmZwblR2 MHEybEdSbHZraVdjbzBjaXB3ZGlpMGtLK21TV1UmI3hBOy9DR3JzZHNOSXRXYlVMQk9QTzVpWGtD eTFkUlVCdUpJMy9tTlBualMydC9TbW1mOHRjTzlRUDNpZHV2ZkdsdHM2aHA0VU9ibUlJeG8mI3hB O3JjMW9UN0d2dmpTMnVodkxPWnVNTThjcmI3STZzZHRqME9DazJ0YlVkUFdOcEd1WWxqUWdPNWRR cWs3Q3BydFhEU0xWVm5oZDJqU1ImI3hBO1dkZDJRRUVpdmlNQ1YrS3V4VjJLdXhWMkt1eFYyS3V4 VjJLdXhWaXV1K2JQTkZqWDlIK1VMMi9BQitNM0ZwR3BwNENPU2QvdlhKQUQmI3hBO3ZZa251ZWIy bm11Njh4NmJyL2w2NDBhMzBTOTBqMDcyR3d0azRIakV4UzQ1allFb3JMMEdhL3RmQ1pZQ1IwM2Ru MkpuRU5RTDJ2YjgmI3hBO2ZGQitVTllUUi9NTnBleTFNQ3NVbkFOUGdrVW9TZkhqWGxUMnptTkZu OExLSkhrOWYyaHB6bXd5aU9mVDRNbTg2Mmw4dWpYRnhNc24mI3hBO29UNmhMTXJJdzlBMVlyR3lx cW5aazM1RmhVazljenRkQ1hBU2VSbVQ1ZVgyZFhXZG01SWVLSWlyRUFQUHo2OS9TdGd3SE5POUFt MmsmI3hBOzI5NUxORXRwYnd4Tkl3V082dWFFVkpwdDZsVUo4T0tGdkRNakRHUklvRDNuOGZ0Y1BQ T0lCNGlUNUQ5bS93QXpUM1EyY3AwWTJVamUmI3hBO3ZOOVc5RjJNanhGMjRjU1RLbnhweVA3Uzdq cm5hNDRtTVFEekR3T1dRbElrQ2dTeFhUL0tQbWF3azh2TmI2Z0FMSldPdEI1cFpmckUmI3hBO3Nv aUV2RDFVYWlmdWp4SHcwcjIzcmJ4QnA0U3lmUjQ5WlJMbHRWa2plVjdpUnJkWWZzSkJzSTEreXJW b0t0VXR1ZXROaEVzaGFQd0omI3hBO2RpcnNWU0QvQUtiNy90MWY5ak9TNk1lcU52Rjh4bTRjMmNs bXR0dDZZbWpsWitnclVxNmpyN1lCU1RhZ3c4M0twWnA5T0NnVkpNY3cmI3hBO0FBLzU2WWtoUUNr V3FlVEwzekhPdDdkYXBhdGJ6UjI4Y2lXMER0VVcwN3lob3B2WCtGdmo2OGRqakRJQ0xHNFdlT1FO UzJLMkg4c3cmI3hBO2x0Y3d2ZnBLWjdDV3dFajJxa2xwWFp4UElPZEN5RnR1SEQzSjJwTGpZOENy UCtYaGxlV1FYRm9yU0hUbVQvUXFoVzArVVR2L0FMdUgmI3hBOzkrOWVYZ050K3VQRXZDM04rWGFT THFNUXViY1FYTWQ4bGlqV2dZMjdhZzBieU1UNmdEOERGOEZBdFBmSGlYaFY5SDhqdnB2bVp0YWom I3hBO3VvUFRlM1dCN1dPMmFQY0lnZHczck1nTE9uTDdGZTFlcElNckNSR2loTGI4dFk0SlZ1amR4 VFhxMzA5OFJMYnM5cVJPWm1FWnR6TWYmI3hBOzdzM0xjR0RpbmhXdUhqUndMdEcvTHlmUnRWajFH ejFDTjJ0N1VXa0VNMERFRlZoU09yc0pmdGNvVk5WVWZEVmQ5aUV5dFJHazg0ZWImI3hBOy93RGYy bi84aXAvK3FtRFpPNnllVHpUQkUwMDkxcHNVS0NyeU9reXFCNGttU2d5TXBSaUxPd1pSaktSb2Js VGt2Zk1FVU1VMGwvcFMmI3hBO1F6RlJESXl5QlhMZlpDa3kwTmUxTWljdU1BRW5ZK2JJWWNoSkFH NDU3Rlg0ZWIvOS9hZi9BTWlwL3dEcXBsbXpYdTdoNXY4QTkvYWYmI3hBOy93QWlwLzhBcXBqc3U3 dUhtLzhBMzlwLy9JcWYvcXBqc3U3dUhtLy9BSDlwL3dEeUtuLzZxWTdMdTdoNXYvMzlwLzhBeUtu L0FPcW0mI3hBO095N3U0ZWIvQVBmMm4vOEFJcWYvQUtxWTdMdTdoNXYvQU4vYWYveUtuLzZxWTdM dW0wc3NjVWJTeXVJNDBCWjNZZ0tBTnlTVDB5TEomI3hBOzR0K1oxaGNhYnJkbitadmxoUmMyOFpF V3FLRllSeW9CNllrM0h4eFNSbmdXWGJvUmxnM0hDV3M3SGlDQUdqMjJ2UVI2dDVWcmQyRnkmI3hB OzZwTGFEZWEwbWY4QTNWS3ZYaUQ5bCtsUHZ6bE5kMlZQSFAwQzRuN0hzK3p1Mm9aSVZrTlRBK2Y3 VVRyOTAxeHAxanA3UjNDU2FkTTEmI3hBO2xKTHlaclJ6SDhJWkFkbGtwMUE3Wmk2aWZGQ01kL1Nl SCtqL0FHdVhwWWNNNVR1TlRIRi9TRi9vUUd2MkdtMmVwRFRkT2RybzIvN3UmI3hBO2U2QXFaSmlm aUNLRDlsZWdIalhmS3RSamhHZkJFM1hYdkxmcE1zNXc0NWpodmtPNGViMEh5QjVGUzI0NnJxbHU0 dXdRMXFremJyVDkmI3hBO3Rvd1BoUGhWajlHYnJzM3MvaDljeHYwL3NlZTdWN1VNdjNlTStuclg2 MHU4NVJXRCtlTDRqNmlrbjZLalYzMUMya25pTXhrYW5GbCsmI3hBO3pJSXFiZ01hVUZNNkNQSjVx WE5USytVSnRlMTh5Vzh5TE5wbW4vbzR4d1R0ZExLWXBlWDFlZ0xpWUlZdVhFMThlK082N0lleStz UWEmI3hBOy9wOG12Q2I5TXgrVjUvcnMwS01aeGREaVY0dDlrM0F0dy9mRDAyNzE2Nzl5aGFXdXEy K2c2OXBtbVF0UDlWVFRvNWRWMDZPYUI3cTAmI3hBO1dVdE1vaUkydWxoZHZVS0UxclQ3V1BWZWlh YTNGcHpUNm9kRGlDNkYrZ3JsYjhSb1Z0bXV2aCtwaFZweE02NzlQaUcxZDZZQjVwUGsmI3hBO2pk QjAzVWJQelhwZGxkSitrZE10cmE0bDBUWEdBZHpidnc0UVRQMTlTSUg0Vy9hVStOY1NkbEEzWkgv MDMzL2JxLzdHY2owWmRVczgmI3hBOzhXK25KcStoWEZ6R29TUzRaTGxxZmJqQzFvMU4ycDJ6VGRv eGdNbU1rZGQzZDltVG1jZVFSUDhBRHQ3MFhwdHA1ZHVKTlVuMHlPa1MmI3hBO3cvVmJpSXFSRTU0 aVNvUnZacUhiTE1VTVV1TXdHMVVlN3ZhczJUTkVRRXp2ZkVPL3VXK1Y5VWdzZktlaW95UE5jWEtl bmIyOFFCa2QmI3hBO2hWalRrVlVCUUtra2dERG84d2hnZ09aUElCT3V3R2VveUhrSTh5ZVFUS0h6 VHBzbHZKSlNSSjRyajZtOW13SHJmV08wWUNsbE5mRU4mI3hBO1QzeThheUJCTzlnOE5kYjduR2xv WmlRRzFHUEZmU3UvOGJvUFZmT0JzZE52N2c2YmRSM0ZrRUhwVEl2QW1TdkZ2VWpaMEtnOWFOWEsm I3hBO3MydTRJU1BESzQ5L241aHV3ZG44YzRqamlSTHU4dklnRzFlNzgzV1ZuQkJMZDJsNUExek42 RU1UUTFjdFFHdEZMRGV1d3JVNzBHVG4mI3hBO3Jvd0FNb3lGbXVUWGowRXBraU1vbmhGbmRUYlhk S3VyclIvckZwZHczTnpKSWJKSmthSW82S3l0Nmc1VSt6MEcrUk9waEtVTGpJRWsmI3hBOzFlM3pa RFM1SVJ5Y01vbU1RTG8zZnVSTjM1a3Q0UFhhSzF1YnlHMWYwcm1hMlJYVkgycXRHWldialg0dUNt bVd6MVlGMEpTRWVkZjImI3hBOy9jMTQ5R1pWY294TXR4ZjltM3hwTkpZb1o0VEhLZ2tpa0ZHamNW Qkh1RG1RWWlRbzhuRmpJeE5nMFhtdmx3ZVdUcEY1RHFNZk82a3YmI3hBO1pMZUVoV01pcTdLaWNY NkRpVDQ1ejJsOEh3eUpqMWNWUFM2engvRWlZSDA4QUo3dThwNzVqdlBxdXMrWHRLZTJsdkxVQ1o1 WWxSWDkmI3hBO1l4UUZVb3JFQml2TGtmRGJNN1ZUNGNtT0JCbEhmcHpvT0JvOGZIank1QVJHVzNY bGN2MDhuUTMwVng1eG10NXRPbWtndExlQ0syak0mI3hBO1NGSVN6RmpKeEorSG9vQkg4dUNPUVMx QkJpYWlBQnR5ODB5eEdPbUJFeGNwU0ozNStYNDcweTBuWE5EVFNaYjIxU1dLM2U2a1QwNUEmI3hB O3hsa3VIZmRWVWxtcXpIWWZxekl3YWpFTVpsR3dPTDRrdU5uMDJVNUJHVkU4STl3alRXcDYvWmZv L1VvOVRzTHlDQ0NJZldGS0E4NDUmI3hBO2ZoK0I0blpmbjhRcGptMU1lR1FuR1FBRy93QWZNRmNP a2x4d01KUUpKMjk0N3dSK2hGSFdiUzNTenRyYUNhNW1uZ0VzRnBGeE1naFUmI3hBO0FjbmFSMVVB VkEzYmMrT1dmbUl4RVl4QkpJc0R5K0ovUzFmbDVTTXBTSUFCb2s4citBL1FoRzg4YUtJTEdaRXVK UmZzeVFwSEV6TUgmI3hBO1EwWldBL2FCN0N2M1pVZTBjZFJPNTR2SnVIWm1XNUQwamc1N29tdzh6 MkYwMThrc2N0akpwd1Y3cU82VlVLb3lsZy93czRLMEdXNDkmI3hBO1hHWEZkeDRlZHRXWFJUandr RVNFK1hEOXpoNWpCa2lVYWJlOEo0Mmx0NWZUUXE0UmVWTm41SVNPZ2NMZy9ON2oweTM1YmZ0Kzlm eWUmI3hBO3g5Y05qUjMvQUdiL0FBdER4ZWM3Q2JUWWRRaHRicVNHNG5OdEVpb2hrTWcveWVmU29J eUExOFRBVEFsUk5mamRzbDJkTVRNREtJSUYmI3hBOzg5cStTWWF4b1dsYXpEREJxY0F1WUlKVm5T RmllQmRBUXZOUVFIQXI5bHRzendhZGNSYXZmeTJGdnA4OGw4WTBzSTRtTnlaYWVtSWcmI3hBO3Z4 Y2dkdU5NQVNYa3VwL2svcVZ0ZEo1ay9MNitrMGE3bVVTblRaeVVXai9GeEIrS2cvNHJjRWU0eXpq NkZyNE9vUU56NWsvT0MwMCsmI3hBO1RTdFo4bXg2bEJ1Uzl2QzVxMWVSZXRzenB5Sk5hcUFjcW5w c1U0OEpIcGJzZXF5d254QStwa241VStaWDFMV05WMHpVUEwwR2hhbHAmI3hBOzhjTWlSSkV5VEZK QWVYTXlmRjBLRWZQSVIwbVBIdkFBTXA2ekxsMm5JbGtFT3RlZERiYXRjUzJVUVNDN2pnMDBMQlA2 alFmV2pITk0mI3hBOzhSZmxKd2dJa1VKVGx2VDJ1b05ObFNrOHdlY2xpMG8vVUFIdmxuU2JqYVR5 QkpVdUkwZ1p3SlY5RkpZR2VRK29maElvVFhiRFFSWlImI3hBO2NPc2VhRzh5M05sSlpxdWpJWlRi NmdMZVlrOElrUEJnWEc0ZDltVUVTQ29IRWpjVUtUWnRMcmZ6VjUyL3c3Y1hjdWpHYlZSSGJHMnQm I3hBOzBnbmdWcHBZdlV1SW1SMmQrTU5DQkpXakdnRytHaGFPSTBuVWVvNjlONWh0SW80MWowYTR0 VGRPWmJhWlprYjRRc1RTK29JMGNsaTMmI3hBO0VwVUJhZDY0S0ZKczJsRCtaZk9pNlpwOHcwME5k M0VVN1RKOVZ1QURNazZwRkNWNThvT2NSWnZVa0pYYkRRUlpURzIxYnpPL211V3cmI3hBO2xzMEdp SzBubzN3aWxWbTRSUm5neFpxQTgzTkhBS3VBUUtGZHhRcE5tMVQvQUtiNy90MWY5ak9QUmVxRzgx eDZsTHEralMybGhOY3gmI3hBO1dNNW11SkVLQWNTQUtMeVlWT2F2V2laeVFNWWtpSnN1MzBKZ01l UVNrSW1VYUhORnlYOTlKTEtMZlNKNG81STNlNmtrRVlkMlZPRWEmI3hBO1JoWkQ4UjhUdFFaWkxK SWsxQWl4dnkrRmJ0TWNVQUJjd2FJcXIyN3lkbU9SNlBxMGVsZVhyaVhTamNuU1BXaHZkUGtFYk02 VEFEMUkmI3hBO3dTVmJqVE1FWUppR01tRjhGZ3gyNjlRN0k2akdjbVVDZkQ0bEVTMzZkQ2p0UzA3 VW5pc2RXMHJTVnRYc0xqMWhwMzd1T1NhTms0c1cmI3hBO0NWVlhHL0VjanQ3N1pibHhUSWpraERo NFRmRHNDUTBZYzBBWlk4aytMampYRnVRRDhlbjQ4MFRyemF6cmZsWFVZVjB5UzJra1JQUWgmI3hB O2xkREs1RGhtK0ZkZ0FCdFZxbnd5elVISm13eUhBUjNkL05xMG94WU5SQThZa090Y3VUV3V6YW5x RWVqeXhhVmRMOVh2bzdxWkc5TGsmI3hBO3NjYXNEVWMrcEw3REhVU25NUUloTGFRUFRrUGluU3ho ak9RR2NkNEdQWG1mZ2lOZmp2cHRYMEs0Z3NwcFlyYVZwYmhsNERncm9Vb2EmI3hBO3NOeFhlbVQx SWtjbU1pSklCc3Rla01CanlBeUFNaFE1OTk5eUMwVnZNZWl5WFdsdHBiM3NUWEVrMW5lUnlJa1pX VnVYNzB0dXRDZCsmI3hBO3A5dkdyVG5MaEpod2NXNUlQdjcyN1VqRG5BeWNmQ2VFQWlqZTNjeXVX Vm80V2s5TnBHVVZNY2RDeFBndGVPYk9VcUYwNm1NYk5Xdy8mI3hBO3l0SHFPbmFYZFd0L28xMDdU WFVsd3FKNkxDakZXWGN5THVDdWFuUmlXT0JqS0VqY3I2ZnJkenJqREprRW9aSTdSQTYvcVZyc2Ez Y2EmI3hBOzc1ZTFDYlRwUUxNWExYWWo0RUlMbE9NYTd2OEFFeWo3ZjRlR1dUT1NXVEhJeFBwNHIr UExyODJ2SDRVY1dXQW1QVncxZC93bmZwOGsmI3hBO1ZaTGZSZWJ0U3Uzc1p4YTNFVVVVVTlFNGxv ZVZUOXF0RFhiYko0K0laNVM0VHdrRDdHcklZSFR3aUpEaUJKcmZyOEVrajByekYraWgmI3hBO0xi MkxwZTJHcVBxRWR0TVVBbWprTGZDcFZtSElCdjZaaGpEbDRMRWZWR2ZGUjZ1Y2MrSHhLTWh3eXg4 Rmk5aUU0MVM3MW5WZkxtb1ImI3hBO0RTSnJkNW9URkRHN3htUm5mWS9EV2dSZkVtdnRtWG15Wk11 S1E0Q0xIeC9zY1BCanhZczBUeGcwYlBPdjdmeGFYM05oZlI2anBtcXomI3hBOzZPMS9hL1VGc3Jx elpZbm1oZU55d2NLeDRtdlRZOU1vbGprSlFtWWNVZURoSTJzT1JETEV3bmpHVGdseDhRTzlHK2lL MU8xdmpKb2omI3hBOzIyanRCRmIzZjFtYUNEMHFSeDhTbzVVS3J6UEtwQzErZVdab1N1RlFvQ1Yw Sy9GdFdHY0t5Y1dTeVkxWnZjL3FRbXBhSnF1bzZwNWsmI3hBO2pTMmtoaTFHM2lqdGJsK0FSbnQr b05HTEFPUlFHbVY1ZFBQSlBJS0k0Z0tQdS9XM1lkVGp4NDhSSkJNSkVrZS85U2VhRnEydTNJaWcm I3hBO3Z0SmUwZU5lTjFPN29JeVFLVmlDOGkxVDhnUEh4ek5ObXl5b1NoVmN6K3B3TlZneFJzd254 WHlGYi9GQWFIb3p3K2FOVDR1RHB0dE4mI3hBOzlaZ2hIN04xY3hqMVArQlFtZzhHeWpUNEt6Uy9t QTJQNjBoK3I3M0kxT29Fc0VQNThoUi9xeE8zelAzTXJ6YU9wUUdzNkpZNnhidzImI3hBOzk2SGFD R2VLNTlKV0txN1F0eVZaQjBkSzdsVHRoQnBCRm8vQWxKL0tsNWVYdWx5WGwzSExETFBkWFpTQ2RX amRJa3VIamhCVnFFVmomI3hBO1JUOU9Fb2locnZRVEY1MnNQTUZxaDVUMjB1bmFqeDZHUGFlR1J2 OEFWYU1wWC9LR0c5cVJXOXNoeUxKMkt1eFYyS3V4VjJLdXhWS1AmI3hBO3FGMy9BSXUvU0hwLzZK K2ovcS9xMVgrODlibng0MTVmWjcwcGh2WmpXNmI0R1RzVmRpcnNWZGlyc1ZkaXJzVmRpcnNWZGly c1ZkaXImI3hBO3NWZGlyc1ZkaXJpS2dqeDhOc1ZRbWw2WGE2WmFDMnR1WENwWm5rWXU3TTNWbVk3 azVWaHd4eHg0UTNaODhzc3VLVC8vMlE9PTwveG1wR0ltZzppbWFnZT4KICAgICAgICAgICAgICAg PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC94bXA6VGh1bWJuYWls cz4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvbW0vIgogICAgICAgICAgICB4bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wL3NUeXBlL1Jlc291cmNlUmVmIyIKICAgICAgICAgICAgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyI+CiAgICAgICAgIDx4bXBN TTpEb2N1bWVudElEPnhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMThBNkQ5ODMyQkM0NjI5MUM8L3ht cE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4bXBNTTpJbnN0YW5jZUlEPnhtcC5paWQ6MDE4MDEx NzQwNzIwNjgxMThBNkQ5ODMyQkM0NjI5MUM8L3htcE1NOkluc3RhbmNlSUQ+CiAgICAgICAgIDx4 bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ+dXVpZDo2MzJCNjU3NzQ0MzMxMUREOTM1RkNCRTc5QTEw QUY5OTwveG1wTU06T3JpZ2luYWxEb2N1bWVudElEPgogICAgICAgICA8eG1wTU06RGVyaXZlZEZy b20gcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICA8c3RSZWY6aW5zdGFuY2VJ RD54bXAuaWlkOjA2ODAxMTc0MDcyMDY4MTE4QTZERDk3RjUzRkY5RDM3PC9zdFJlZjppbnN0YW5j ZUlEPgogICAgICAgICAgICA8c3RSZWY6ZG9jdW1lbnRJRD54bXAuZGlkOjA2ODAxMTc0MDcyMDY4 MTE4QTZERDk3RjUzRkY5RDM3PC9zdFJlZjpkb2N1bWVudElEPgogICAgICAgICAgICA8c3RSZWY6 b3JpZ2luYWxEb2N1bWVudElEPnV1aWQ6NjMyQjY1Nzc0NDMzMTFERDkzNUZDQkU3OUExMEFGOTk8 L3N0UmVmOm9yaWdpbmFsRG9jdW1lbnRJRD4KICAgICAgICAgPC94bXBNTTpEZXJpdmVkRnJvbT4K ICAgICAgICAgPHhtcE1NOkhpc3Rvcnk+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAg ICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmFjdGlvbj5jb252ZXJ0ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OnBhcmFtZXRlcnM+ZnJvbSBhcHBsaWNhdGlvbi9wb3N0c2NyaXB0IHRvIGFwcGxpY2F0 aW9uL3ZuZC5hZG9iZS5pbGx1c3RyYXRvcjwvc3RFdnQ6cGFyYW1ldGVycz4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NUVDMzkyNkMyODIw NjgxMThDMTRCMUU3RTAxNDg1OUY8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMTEtMTAtMTFUMTI6Mjk6NTItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIElsbHVzdHJhdG9yIENTNS4x PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4v PC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAg PHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDphY3Rpb24+Y29udmVydGVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDpwYXJhbWV0ZXJzPmZyb20gYXBwbGljYXRpb24vcG9zdHNjcmlwdCB0byBhcHBsaWNhdGlvbi92 bmQuYWRvYmUuaWxsdXN0cmF0b3I8L3N0RXZ0OnBhcmFtZXRlcnM+CiAgICAgICAgICAgICAgIDwv cmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA0ODAxMTc0MDcyMDY4MTE4 QTZERDk3RjUzRkY5RDM3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6d2hlbj4yMDExLTEwLTE5VDEzOjAwOjA5LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbGx1c3RyYXRvciBDUzUuMTwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RF dnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0 aW9uPmNvbnZlcnRlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6cGFy YW1ldGVycz5mcm9tIGFwcGxpY2F0aW9uL3Bvc3RzY3JpcHQgdG8gYXBwbGljYXRpb24vdm5kLmFk b2JlLmlsbHVzdHJhdG9yPC9zdEV2dDpwYXJhbWV0ZXJzPgogICAgICAgICAgICAgICA8L3JkZjps aT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowNTgwMTE3NDA3MjA2ODExOEE2REQ5 N0Y1M0ZGOUQzNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Ondo ZW4+MjAxMS0xMC0xOVQxMzoxNzoxMS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSWxsdXN0cmF0b3IgQ1M1LjE8L3N0RXZ0OnNv ZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNo YW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5z YXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54 bXAuaWlkOjA2ODAxMTc0MDcyMDY4MTE4QTZERDk3RjUzRkY5RDM3PC9zdEV2dDppbnN0YW5jZUlE PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTEwLTE5VDEzOjE5OjI1LTA0OjAw PC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9i ZSBJbGx1c3RyYXRvciBDUzUuMTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6 bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPmNvbnZlcnRlZDwvc3RFdnQ6YWN0aW9uPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6cGFyYW1ldGVycz5mcm9tIGFwcGxpY2F0aW9uL3Bvc3RzY3Jp cHQgdG8gYXBwbGljYXRpb24vdm5kLmFkb2JlLmlsbHVzdHJhdG9yPC9zdEV2dDpwYXJhbWV0ZXJz PgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFy c2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8 L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlp ZDowMTgwMTE3NDA3MjA2ODExOEE2RDk4MzJCQzQ2MjkxQzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0xMC0yNFQxMDo1MDowMS0wNDowMDwvc3RF dnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSWxs dXN0cmF0b3IgQ1M1LjE8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwveG1wTU06SGlzdG9yeT4KICAgICAgPC9y ZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg ICAgICAgIHhtbG5zOnhtcFRQZz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3QvcGcvIgog ICAgICAgICAgICB4bWxuczpzdERpbT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBl L0RpbWVuc2lvbnMjIgogICAgICAgICAgICB4bWxuczp4bXBHPSJodHRwOi8vbnMuYWRvYmUuY29t L3hhcC8xLjAvZy8iPgogICAgICAgICA8eG1wVFBnOk5QYWdlcz4xPC94bXBUUGc6TlBhZ2VzPgog ICAgICAgICA8eG1wVFBnOkhhc1Zpc2libGVUcmFuc3BhcmVuY3k+RmFsc2U8L3htcFRQZzpIYXNW aXNpYmxlVHJhbnNwYXJlbmN5PgogICAgICAgICA8eG1wVFBnOkhhc1Zpc2libGVPdmVycHJpbnQ+ RmFsc2U8L3htcFRQZzpIYXNWaXNpYmxlT3ZlcnByaW50PgogICAgICAgICA8eG1wVFBnOk1heFBh Z2VTaXplIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgPHN0RGltOnc+OC41 MDAwMDA8L3N0RGltOnc+CiAgICAgICAgICAgIDxzdERpbTpoPjExLjAwMDAwMDwvc3REaW06aD4K ICAgICAgICAgICAgPHN0RGltOnVuaXQ+SW5jaGVzPC9zdERpbTp1bml0PgogICAgICAgICA8L3ht cFRQZzpNYXhQYWdlU2l6ZT4KICAgICAgICAgPHhtcFRQZzpQbGF0ZU5hbWVzPgogICAgICAgICAg ICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT5QQU5UT05FIDE2NjUgQzwvcmRmOmxp PgogICAgICAgICAgICAgICA8cmRmOmxpPlBBTlRPTkUgNDMyIEM8L3JkZjpsaT4KICAgICAgICAg ICAgPC9yZGY6U2VxPgogICAgICAgICA8L3htcFRQZzpQbGF0ZU5hbWVzPgogICAgICAgICA8eG1w VFBnOlN3YXRjaEdyb3Vwcz4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxy ZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8eG1wRzpn cm91cE5hbWU+RGVmYXVsdCBTd2F0Y2ggR3JvdXA8L3htcEc6Z3JvdXBOYW1lPgogICAgICAgICAg ICAgICAgICA8eG1wRzpncm91cFR5cGU+MDwveG1wRzpncm91cFR5cGU+CiAgICAgICAgICAgICAg ICAgIDx4bXBHOkNvbG9yYW50cz4KICAgICAgICAgICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAg ICAgICAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAg ICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpzd2F0Y2hOYW1lPldoaXRlPC94bXBHOnN3YXRj aE5hbWU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOm1vZGU+Q01ZSzwveG1wRzpt b2RlPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp0eXBlPlBST0NFU1M8L3htcEc6 dHlwZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6Y3lhbj4wLjAwMDAwMDwveG1w RzpjeWFuPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzptYWdlbnRhPjAuMDAwMDAw PC94bXBHOm1hZ2VudGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnllbGxvdz4w LjAwMDAwMDwveG1wRzp5ZWxsb3c+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOmJs YWNrPjAuMDAwMDAwPC94bXBHOmJsYWNrPgogICAgICAgICAgICAgICAgICAgICAgICA8L3JkZjps aT4KICAgICAgICAgICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnN3YXRjaE5hbWU+QmxhY2s8L3ht cEc6c3dhdGNoTmFtZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6bW9kZT5DTVlL PC94bXBHOm1vZGU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnR5cGU+UFJPQ0VT UzwveG1wRzp0eXBlPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpjeWFuPjAuMDAw MDAwPC94bXBHOmN5YW4+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOm1hZ2VudGE+ MC4wMDAwMDA8L3htcEc6bWFnZW50YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6 eWVsbG93PjAuMDAwMDAwPC94bXBHOnllbGxvdz4KICAgICAgICAgICAgICAgICAgICAgICAgICAg PHhtcEc6YmxhY2s+MTAwLjAwMDAwMDwveG1wRzpibGFjaz4KICAgICAgICAgICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpzd2F0Y2hOYW1l PlNtb2tlPC94bXBHOnN3YXRjaE5hbWU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBH Om1vZGU+Q01ZSzwveG1wRzptb2RlPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp0 eXBlPlBST0NFU1M8L3htcEc6dHlwZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6 Y3lhbj4wLjAwMDAwMDwveG1wRzpjeWFuPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1w RzptYWdlbnRhPjAuMDAwMDAwPC94bXBHOm1hZ2VudGE+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx4bXBHOnllbGxvdz4wLjAwMDAwMDwveG1wRzp5ZWxsb3c+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx4bXBHOmJsYWNrPjMwLjAwMDAwMjwveG1wRzpibGFjaz4KICAgICAgICAgICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgICAgICAgICAgIDxyZGY6bGkgcmRm OnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpz d2F0Y2hOYW1lPlBBTlRPTkUgNDMyIEM8L3htcEc6c3dhdGNoTmFtZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6dHlwZT5TUE9UPC94bXBHOnR5cGU+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx4bXBHOnRpbnQ+MTAwLjAwMDAwMDwveG1wRzp0aW50PgogICAgICAgICAgICAg ICAgICAgICAgICAgICA8eG1wRzptb2RlPkNNWUs8L3htcEc6bW9kZT4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6Y3lhbj4yMi45OTk5OTg8L3htcEc6Y3lhbj4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHhtcEc6bWFnZW50YT4yLjAwMDAwMDwveG1wRzptYWdlbnRhPgogICAg ICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp5ZWxsb3c+MC4wMDAwMDA8L3htcEc6eWVsbG93 PgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpibGFjaz43Ny4wMDAwMDA8L3htcEc6 YmxhY2s+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICAg ICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHhtcEc6c3dhdGNoTmFtZT5QQU5UT05FIDE2NjUgQzwveG1wRzpzd2F0Y2hO YW1lPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzp0eXBlPlNQT1Q8L3htcEc6dHlw ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6dGludD4xMDAuMDAwMDAwPC94bXBH OnRpbnQ+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOm1vZGU+Q01ZSzwveG1wRzpt b2RlPgogICAgICAgICAgICAgICAgICAgICAgICAgICA8eG1wRzpjeWFuPjAuMDAwMDAwPC94bXBH OmN5YW4+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOm1hZ2VudGE+NjguMDAwMDAw PC94bXBHOm1hZ2VudGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4bXBHOnllbGxvdz4x MDAuMDAwMDAwPC94bXBHOnllbGxvdz4KICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhtcEc6 YmxhY2s+MC4wMDAwMDA8L3htcEc6YmxhY2s+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvcmRm OmxpPgogICAgICAgICAgICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgICAgICAgICAgIDwv eG1wRzpDb2xvcmFudHM+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICA8L3Jk ZjpTZXE+CiAgICAgICAgIDwveG1wVFBnOlN3YXRjaEdyb3Vwcz4KICAgICAgPC9yZGY6RGVzY3Jp cHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+Cjw/eHBhY2tldCBlbmQ9InIiPz4NCmVu ZHN0cmVhbQ1lbmRvYmoNODY1IDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDAuNzg5OTkzL09Q IGZhbHNlL1NNYXNrL05vbmUvY2EgMC43ODk5OTMvQUlTIGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0 R1N0YXRlL1NBIHRydWU+Pg1lbmRvYmoNODY2IDAgb2JqPDwvQ1MvRGV2aWNlQ01ZSy9TL1RyYW5z cGFyZW5jeS9UeXBlL0dyb3VwPj4NZW5kb2JqDTIyNzYgMCBvYmo8PC9TdGVtViA3Mi9Gb250TmFt ZS9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQg NDAwL0ZsYWdzIDk4L0Rlc2NlbnQgLTMwNy9Gb250QkJveFstNDk4IC0zMDcgMTMzMyAxMDIzXS9B c2NlbnQgMTAyMy9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY2Mi9YSGVp Z2h0IDQ0Mi9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNz4+DWVuZG9iag0yMjgx IDAgb2JqPDwvU3RlbVYgODAvRm9udE5hbWUvVGltZXNOZXdSb21hblBTTVQvRm9udFN0cmV0Y2gv Tm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTMwNy9Gb250QkJveFstNTY4 IC0zMDcgMjAwMCAxMDA3XS9Bc2NlbnQgMTAwNy9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikv Q2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0IDQ0OC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xl IDA+Pg1lbmRvYmoNMjI5MiAwIG9iajw8L1N0ZW1WIDEzNi9Gb250TmFtZS9UaW1lc05ld1JvbWFu UFMtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNj ZW50IC0zMDcvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50IDEwMjYvRm9udEZh bWlseShUaW1lcyBOZXcgUm9tYW4pL0NhcEhlaWdodCA2NjIvWEhlaWdodCA0NTcvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTIzMDggMCBvYmo8PC9TdGVtViAxMzYv Rm9udE5hbWUvQXJpYWwtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9G bGFncyAzMi9EZXNjZW50IC0zNzYvRm9udEJCb3hbLTYyOCAtMzc2IDIwMDAgMTAxMF0vQXNjZW50 IDEwMTAvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcxNi9YSGVpZ2h0IDUxOS9UeXBlL0Zv bnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjMzMiAwIG9iajw8L1N1YnR5cGUv VHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjI3NiAwIFIvTGFzdENoYXIgMTE5L1dpZHRoc1syNTAg Mjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgMCAz MzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAg NTAwIDQ0NCAyNzggMCAwIDI3OCAwIDAgMCAwIDUwMCA1MDAgMCAwIDAgMzg5IDI3OCA1MDAgMCA2 NjddL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9GaXJzdENoYXIgNDYvVG9Vbmlj b2RlIDIzNDIgMCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoN MjMzMyAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjI4MSAwIFIvTGFz dENoYXIgMTQ2L1dpZHRoc1syNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMzMgMCAyNzgg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAwIDUwMCAyNzggMCAwIDAgNTY0IDAgMCAw IDAgMCAwIDYxMSA1NTYgMCAwIDMzMyAwIDcyMiA2MTEgODg5IDcyMiAwIDAgNzIyIDAgNTU2IDYx MSA3MjIgNzIyIDk0NCA3MjIgNzIyIDAgMCAwIDAgMCAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAz MzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCAwIDMzMyAzODkgMjc4IDUw MCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAzMzNdL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QU01UL0ZpcnN0Q2hhciAzMi9U b1VuaWNvZGUgMjM0NiAwIFIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVu ZG9iag0yMzM0IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAyMjc2IDAg Ui9MYXN0Q2hhciAxNDgvV2lkdGhzWzI1MCAwIDAgMCAwIDAgNzc4IDAgMCAwIDAgMCAyNTAgMzMz IDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMzMyAwIDAg Njc1IDAgNTAwIDAgNjExIDYxMSA2NjcgNzIyIDYxMSAwIDcyMiA3MjIgMzMzIDAgMCA1NTYgODMz IDY2NyA3MjIgNjExIDAgNjExIDUwMCA1NTYgNzIyIDAgODMzIDAgMCAwIDAgMCAwIDAgNTAwIDAg NTAwIDUwMCA0NDQgNTAwIDQ0NCAyNzggNTAwIDUwMCAyNzggMjc4IDQ0NCAyNzggNzIyIDUwMCA1 MDAgNTAwIDUwMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0NDQgNDQ0IDM4OSAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2XS9CYXNlRm9udC9Z UUFUTU8rVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZpcnN0Q2hhciAzMi9Ub1VuaWNvZGUgMjM0 NSAwIFIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yMzM1IDAg b2JqPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHMgMjM0OCAwIFIvQmFzZUZvbnQvTUNL WkFNK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9Ub1VuaWNvZGUgMjM0OSAwIFIvRW5jb2Rpbmcv SWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjMzNiAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5 cGUvRm9udERlc2NyaXB0b3IgMjI5MiAwIFIvTGFzdENoYXIgMTIyL1dpZHRoc1syNTAgMCAwIDAg MCAwIDgzMyAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMCAyNzggNTAwIDUwMCA1MDAgNTAwIDAgNTAw IDUwMCA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3 OCA3NzggMzg5IDUwMCA3NzggNjY3IDk0NCA3MjIgNzc4IDYxMSAwIDcyMiA1NTYgNjY3IDcyMiA3 MjIgMTAwMCA3MjIgNzIyIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAw IDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IDUw MCA3MjIgNTAwIDUwMCA0NDRdL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RD aGFyIDMyL1RvVW5pY29kZSAyMzU2IDAgUi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9G b250Pj4NZW5kb2JqDTIzMzcgMCBvYmo8PC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250cyAy MzU4IDAgUi9CYXNlRm9udC9NQ0taQU0rVGltZXNOZXdSb21hblBTTVQvVG9Vbmljb2RlIDIzNTkg MCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlwZS9Gb250Pj4NZW5kb2JqDTIzMzggMCBvYmo8PC9T dWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDIyNzYgMCBSL0xhc3RDaGFyIDExOS9XaWR0 aHNbMjUwIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEg MCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1 MDAgMCAwIDUwMCA0NDQgMjc4IDAgMCAyNzggMCAwIDAgMCA1MDAgNTAwIDAgMCAwIDM4OSAyNzgg NTAwIDAgNjY3XS9CYXNlRm9udC9ZUUFUTU8rVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZpcnN0 Q2hhciA0Ni9Ub1VuaWNvZGUgMjM1NCAwIFIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUv Rm9udD4+DWVuZG9iag0yMzM5IDAgb2JqPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHMg MjM3NSAwIFIvQmFzZUZvbnQvTUNLWkFNK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvVG9Vbmljb2Rl IDIzNzYgMCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlwZS9Gb250Pj4NZW5kb2JqDTIzNDIgMCBv Ymo8PC9MZW5ndGggMzA3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyRzWrDMAzH734K HddDcZJ1DoUQGN0KOeyDZXuA1FY6w+IYxz3k7SdbpYMZEv2M9JcsSR66p87ZCPI9zLrHCKN1JuAy X4JGOOHZOlFWYKyO11v+62nwQpK4X5eIU+fGWTQNyA9yLjGscPdo5hNuhHwLBoN1Z7j7OvQbkP3F +x+c0EUooG3B4EiJXgb/OkwIMsu2nSG/jeuWNH8Rn6tHqPK95Mfo2eDiB41hcGcUTUGnheZIpxXo zD9/qVh2GvX3EERTPVNwUZAhPjKTsNk9ZCZDvGfeE6syMxniHfMuMcerFK8Us0rMWpW1XEulWopr qVSrvs9Mhphz1ilnzTnrlLOumes2tVgV/NIit3jtJTVLO4HbJPUlBBpiXlyeXpqbdXjbrZ89kCp9 4leAAQDp25MsDQplbmRzdHJlYW0NZW5kb2JqDTIzNDUgMCBvYmo8PC9MZW5ndGggNTE5L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyUy2rjQBBF9/qKXiaLoFd1VQzC4NgJeDEPxjMfIEtt RxBLQpYX/vvpqxsyMALbR7T6+vSFUrrd7/Z9N7v05zQ0hzC7U9e3U7gOt6kJ7hjOXZ/khWu7Zv68 W76bSz0madx8uF/ncNn3pyGpKpf+iovXebq7h007HMNjkv6Y2jB1/dk9/NkeHl16uI3jR7iEfnaZ W69dG04x6Fs9fq8vwaXLtqd9G9e7+f4U9/x74vd9DK5Y7nPKNEMbrmPdhKnuzyGpsnitXfUWr3US +va/dVVuO56a93pKqgIPZ1n8iaxkBW/JW/COvAO/kl/Bb+T4R1XJnBI5ZU7OwQW5AJfkEixkAXuy B9OhhENpZAM/k5/BK/IKvCFvwPQs4VnSrYSb0EfgI/QR+Ah9BD5CH4GP0EfgI3QQOAgdBA5CB4GD sCtBV0IHgYOwK0FXQh+Bj2dXHl15+nj4ePp4+Hj6ePh4+nj4ePp4+HhmemQqz6g4ozJTkanMVGQq MxWZykxFprJzRefKfEW+8ryK8yrPqzivsnNF5/pCfgGzB0UPyh4UPSh7UPSgdFY4G3sw9GD0N/gb /Q3+Rn+Dv9Hf4G/0N/gb/Q3+Rn+Dv9Hf4G/0N/gb/Q3+K+QXWQ7nlZB3y+B8TghGKE66+5rP5jZN cTSX18Eyk5jGrg9fb4xxGF3chU/yV4ABAD+dCFwNCmVuZHN0cmVhbQ1lbmRvYmoNMjM0NiAwIG9i ajw8L0xlbmd0aCA0NzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJXJPNauNAEITveoo5 Joegv5nuGITBsRPwYX9Y7z6ALI0dQTwSY/ngt98pVcjCCmx9QtNdVZrpfLvf7cMwm/xnHLuDn81p CH301/EWO2+O/jyErKxMP3Tz59Py313aKctT8eF+nf1lH05j1jQm/5VeXud4Nw+bfjz6xyz/EXsf h3A2D3+2h0eTH27T9OEvPsymMOu16f0pNfrWTt/bizf5Uva079P7Yb4/pZp/K37fJ2+q5bmkmW7s /XVqOx/bcPZZU6RrbZq3dK0zH/r/3jvHsuOpe29j1lRYXBTplnhL3oJ35B34jZwaNjXX11hfl+QS XJErcE2uwZZswY7swEIWsJIVvCKvwBvyBvxKfk1s2ceij2Ufiz6WtRa19oX8AmYui1yWuSxyWfa0 6OmYxSGLo38H/47+Hfw76jroOuo66Dr6d/DvnsnPYPpx8CPsL+gv/FaCbyXUEmgJtQRaQi2BllBL oCXUEmgJtQRaQi1ZtJhdkF2YXZBdmF2QXZhdkF24v4L9Ve6vYn+VPhU+lT4VPpU+FT6VPhU+lT4V PpU+FT6VPhU+lT4VPpX7q9jfFbSqolwth/bzdOL4pikzX7PR3WJMY7GM4jIPmIQh+K9pncbJpCr8 sr8CDADjWu5kDQplbmRzdHJlYW0NZW5kb2JqDTIzNDggMCBvYmpbODMgMCBSXQ1lbmRvYmoNMjM0 OSAwIG9iajw8L0xlbmd0aCA1NDMvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJXJRda+JA FEDf8yvmsX0oSWbunWlBBI0VfNgP1u4PiMnoBtYkxPjgv9+YIy2soHCaTDnnDty02G12bTOa9OfQ Vfs4mmPT1kO8dNehiuYQT02b5NbUTTU+aP6tzmWfpNPh/e0yxvOuPXbJYmHSX9PDyzjczNOq7g7x OUl/DHUcmvZknn4X+2eT7q99/zeeYzuazCyXpo7H6R99K/vv5TmadD72squn5814e5nOfL3xceuj sTPnyFRdHS99WcWhbE8xWWTTZ2kW2+mzTGJb//c8KMcOx+pPOcyvu+n1LLPZcqZXSKE3yENr6BUq oDfoHVpDW6iYKc+gDZRD75CFthAuDpdcoBxSyEIeclCABKLB0ZDT4GjIV1CAKHIU5RQ5ivINtILo c/RZihxFlgZHg8VasLZYC9YWa8HaYi1YW6wFa4u1YG2xFqwt1oK1xVqwtlgL1hZreVhzK8KtOBqE BsetCLfiKBKKHLei3IqjT+lz9Cl9jj6lz9Gn9Dn6lD5Hn9Ln6FP6HH1Kn6NP6RPMFDPBxeMiuHhc BBePi+DicRFcPC6Ci8dFcPG4CC4eF8HFP1yYrme6wnQ901Wm65muMl3PdJUGT4My3cB0lYZAg9IQ aFAaAg1KQ6BBaQg0KA2BBqUh0KA0BBrWD2v/WVVkX38p5hXy2BX3ZTLtPPO5qarrMExLal6M83a6 76WmjZ+7s+96M526f5N/AgwAgcg69Q0KZW5kc3RyZWFtDWVuZG9iag0yMzU0IDAgb2JqPDwvTGVu Z3RoIDMwNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckc1qwzAMx+9+Ch3XQ3GSdQ6F EBjdCjnsg2V7gNRWOsPiGMc95O0nW6WDGRL9jPSXLEkeuqfO2QjyPcy6xwijdSbgMl+CRjjh2TpR VmCsjtdb/utp8EKSuF+XiFPnxlk0DcgPci4xrHD3aOYTboR8CwaDdWe4+zr0G5D9xfsfnNBFKKBt weBIiV4G/zpMCDLLtp0hv43rljR/EZ+rR6jyveTH6Nng4geNYXBnFE1Bp4XmSKcV6Mw/f6lYdhr1 9xBEUz1TcFGQIT4yk7DZPWQmQ7xn3hOrMjMZ4h3zLjHHqxSvFLNKzFqVtVxLpVqKa6lUq77PTIaY c9YpZ80565SzrpnrNrVYFfzSIrd47SU1SzuB2yT1JQQaYl5cnl6am3V4262fPZAqfeJXgAEA6duT LA0KZW5kc3RyZWFtDWVuZG9iag0yMzU2IDAgb2JqPDwvTGVuZ3RoIDUxMy9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSIlclN1q4lAUhe/zFOeyvShRs39aCILVFryYH8aZB4jJ0QmMSYjxwref s7JKB0bQfCE5e30s2Obb/W7ftVPIv499fYhTOLVdM8ZrfxvrGI7x3HbZchWatp4+7ubf+lINWZ4O H+7XKV723anPyjLkP9LD6zTew8Om6Y/xMcu/jU0c2+4cHn5tD48hP9yG4U+8xG4Ki7Behyae0qAv 1fC1usSQz8ee9k163k73p3Tm3xs/70MMq/l+SZm6b+J1qOo4Vt05ZuUifdahfE+fdRa75r/npjx2 PNW/qzErV3h5sUiXxEY28DP5GfxCfgFvyVvwjrwDv5NTaFlwZoGZxZK8BK/IK3BBLsBKVjAdCjgU TnYwfQr4FPQp4COcL5gvnC+YL5wvmC9CFjCzBFnCLEGWMEuQJcwSZAmzZM7akDfgV/IrmJ0IOhF2 IuhE3shvYPYj6EfZj6IfpbPCWemscFY6K5yVzgpnpbPCWemscFY6K5yVzgpnYz+GfoxZhixjliHL mGXIMmYZsoxZhixjliHLmGXIMmbZnMV+DP0Y+zH0Y+zH0I+xH0M/xn4M/Rj7MfTj7MfRj9PZ4ex0 djg7nR3OTmeHs9PZ4ex0djg7nR3OTmeHs9M5XbAsH1uBtUnbHT53sr6NY1rH+S9g3kNsYNvFz3+J oR9COoVv9leAAQCflAWtDQplbmRzdHJlYW0NZW5kb2JqDTIzNTggMCBvYmpbNjUgMCBSXQ1lbmRv YmoNMjM1OSAwIG9iajw8L0xlbmd0aCA1NjYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ XJTLiuJAFED3+Ypadi+aJFX3VtkggtEWXMyDceYDYlI6gTEJMS78+4k50gMjKBzy4JxbeNPNfrtv m9Gk34euOsTRnJq2HuK1uw1VNMd4btokt6ZuqvFJ8291KfsknR4+3K9jvOzbU5cslyb9MV28jsPd vKzr7hhfk/TbUMehac/m5dfm8GrSw63v/8RLbEeTmdXK1PE0vehL2X8tL9Gk82Nv+3q63oz3t+mZ f3f8vPfR2JlzZKqujte+rOJQtueYLLPpszLL3fRZJbGt/7u+yHjseKp+l8N8u5tuzzKbrWYKkEDv kIcKaAFtoHdoC62hHbSZKc+gLZRDH5CFdhAuDpdcoBxSyEIechDWDut8ASlEg6MhX0MBoshRlFPk KMopchTlH1Axk8VT8LR4Cp4WT8HT4il4WjwFT4un4GnxFDwtnoKnxVPwtHgKnhZPwdPiKU9PzkE4 B8c5COfgOAfhHBznIJyDo0/pc/QpfY4+pc/Rp/Q5+pQ+R5/S5+hT+hx9Sp+jT+lz9Cl9jj6lT3Dx uAguHhfBxeMiuHhcBBePi+DicRFcPC6Ci8dFcPG4CC7+6cKsPbMWZu2ZtTJrz6yVWXtmrczaM2tl 1oFZK32BPqUv0Kf0BfqUvkCf0hfoU/oCfUpfoE/pC/QpfYE+pS/QVzzM7ONvMZNAFBUK8ZbCQ7yl eE7CM7dpCT23zWMdTVvTfO666jYM05qbV+u83x6brWnj5/btu95MTz2+yV8BBgAfkkf5DQplbmRz dHJlYW0NZW5kb2JqDTIzNjggMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9y IDIyNzYgMCBSL0xhc3RDaGFyIDExOS9XaWR0aHNbMjUwIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDUwMCA0NDQgMjc4IDAgMCAyNzggMCAw IDAgMCA1MDAgNTAwIDAgMCAwIDM4OSAyNzggNTAwIDAgNjY3XS9CYXNlRm9udC9ZUUFUTU8rVGlt ZXNOZXdSb21hblBTLUl0YWxpY01UL0ZpcnN0Q2hhciA0Ni9Ub1VuaWNvZGUgMjM2OSAwIFIvRW5j b2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yMzY5IDAgb2JqPDwvTGVu Z3RoIDMwNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckc1qwzAMx+9+Ch3XQ3GSdQ6F EBjdCjnsg2V7gNRWOsPiGMc95O0nW6WDGRL9jPSXLEkeuqfO2QjyPcy6xwijdSbgMl+CRjjh2TpR VmCsjtdb/utp8EKSuF+XiFPnxlk0DcgPci4xrHD3aOYTboR8CwaDdWe4+zr0G5D9xfsfnNBFKKBt weBIiV4G/zpMCDLLtp0hv43rljR/EZ+rR6jyveTH6Nng4geNYXBnFE1Bp4XmSKcV6Mw/f6lYdhr1 9xBEUz1TcFGQIT4yk7DZPWQmQ7xn3hOrMjMZ4h3zLjHHqxSvFLNKzFqVtVxLpVqKa6lUq77PTIaY c9YpZ80565SzrpnrNrVYFfzSIrd47SU1SzuB2yT1JQQaYl5cnl6am3V4262fPZAqfeJXgAEA6duT LA0KZW5kc3RyZWFtDWVuZG9iag0yMzcwIDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVz Y3JpcHRvciAyMzA4IDAgUi9MYXN0Q2hhciAxMjEvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMz MyAzMzMgMCAwIDAgMzMzIDI3OCAwIDU1NiA1NTYgNTU2IDAgMCA1NTYgMCA1NTYgMCAwIDMzMyAw IDAgMCAwIDAgMCAwIDAgMCA3MjIgNjY3IDYxMSAwIDAgMjc4IDAgMCAwIDgzMyAwIDAgMCAwIDAg NjY3IDAgNzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNjExIDU1NiA2MTEgNTU2IDAgNjEx IDYxMSAyNzggMCAwIDI3OCA4ODkgNjExIDYxMSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgMCAwIDU1 NiA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9GaXJzdENoYXIgMzIvVG9Vbmljb2RlIDIzNzEg MCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjM3MSAwIG9i ajw8L0xlbmd0aCAzOTYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJXJLdaoNAEIXvfYq9 bC+KiZrZBiQQ8gO56A9N+wBGJ6nQrLIxF3n7zvGUFirofrJz9GN20tVuvQvt4NLX2NV7HdyxDU3U S3eNtbqDntqQTDPXtPXw8zY+63PVJ6mF97fLoOddOHZJWbr0zTYvQ7y5u2XTHfQ+SV9io7ENJ3f3 sdrfu3R/7fsvPWsY3MQtFq7Ro33oqeqfq7O6dIw97Brbb4fbg2X+Kt5vvbpsfJ9Spu4avfRVrbEK J03KiV0LV27tWiQamn/7uWfscKw/q5iUGYonE1uMH8mP4Dl5Dl6T1+ANeWOcM5sjm0/JU3BGzsAz 8gzsyR68JC+Ni2JkW4xZX6C+ELKA6VPAp6BPAZ9ZPrItxszOkBX6CHyEPgIfYb2gXvhfwX+FWRmz 9BR4Cnsi6InQQeAgK/IKTB+Bj7A/gv7IlmwHUXr2yqNXnj4ePp4+Hj6ePh4+nj4ePp4OHg6eDrbg cH9OEcds0+h+Z6i+xmjjM47sODeYmDbo71T3Xe8shTv5FmAAVdbDzw0KZW5kc3RyZWFtDWVuZG9i ag0yMzc1IDAgb2JqWzI5IDAgUl0NZW5kb2JqDTIzNzYgMCBvYmo8PC9MZW5ndGggMzA0L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVzRS2rDMBAG4L1OMctkEeS3EzCGJK3Biz6o2wPY0jgV 1LKQlYVvX0UTUqjAhg/pH0Yjfm6fWq0c8Hc7iw4djEpLi8t8tQJhwIvSLE5AKuHuCn8x9YZxH+7W xeHU6nFmVQX8w28uzq6wOcp5wC3jb1aiVfoCm69ztwXeXY35wQm1gwjqGiSOvtBLb177CYGH2K6V fl+5deczfyc+V4OQBMfUjJglLqYXaHt9QVZFftVQNX7VDLX8tx8XFBtG8d3bcDz1x6MoieqgA6kI So5BWRmUxqRnEuVyymVZUBGTClJK2pNy0om0J51Jh6A8ITWkPKhMSFSzpJp5ScpI1GdJfZ4aqlJQ XT+E+21v4/CvBo9Zi6u1fszhacN8b5NVGh+vb2YDPnX72K8AAwDaMZlsDQplbmRzdHJlYW0NZW5k b2JqDTI0MDMgMCBvYmo8PC9PUE0gMS9CTS9Ob3JtYWwvQ0EgMS4wL09QIHRydWUvU01hc2svTm9u ZS9jYSAxLjAvQUlTIGZhbHNlL29wIHRydWUvVHlwZS9FeHRHU3RhdGUvU0EgdHJ1ZT4+DWVuZG9i ag0yNDA0IDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDEuMC9PUCBmYWxzZS9TTWFzay9Ob25l L2NhIDEuMC9BSVMgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgdHJ1ZT4+DWVuZG9i ag0yNDA1IDAgb2JqPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHMgMjQwNyAwIFIvQmFz ZUZvbnQvQ0xQQkJCK1RpbWVzTmV3Um9tYW5QU01UL1RvVW5pY29kZSAyNDA2IDAgUi9FbmNvZGlu Zy9JZGVudGl0eS1IL1R5cGUvRm9udD4+DWVuZG9iag0yNDA2IDAgb2JqPDwvTGVuZ3RoIDU2Ni9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlclMuK4kAUQPf5ilp2L5okVfdW2SCC0RZczINx 5gNiUjqBMQkxLvz7iTnSAyMoHPLgnFt4081+u2+b0aTfh646xNGcmrYe4rW7DVU0x3hu2iS3pm6q 8Unzb3Up+ySdHj7cr2O87NtTlyyXJv0xXbyOw928rOvuGF+T9NtQx6Fpz+bl1+bwatLDre//xEts R5OZ1crU8TS96EvZfy0v0aTzY2/7errejPe36Zl/d/y899HYmXNkqq6O176s4lC255gss+mzMsvd 9Fklsa3/u77IeOx4qn6Xw3y7m27PMputZgqQQO+QhwpoAW2gd2gLraEdtJkpz6AtlEMfkIV2EC4O l1ygHFLIQh5yENYO63wBKUSDoyFfQwGiyFGUU+QoyilyFOUfUDGTxVPwtHgKnhZPwdPiKXhaPAVP i6fgafEUPC2egqfFU/C0eAqeFk/B0+IpT0/OQTgHxzkI5+A4B+EcHOcgnIOjT+lz9Cl9jj6lz9Gn 9Dn6lD5Hn9Ln6FP6HH1Kn6NP6XP0KX2OPqVPcPG4CC4eF8HF4yK4eFwEF4+L4OJxEVw8LoKLx0Vw 8bgILv7pwqw9sxZm7Zm1MmvPrJVZe2atzNoza2XWgVkrfYE+pS/Qp/QF+pS+QJ/SF+hT+gJ9Sl+g T+kL9Cl9gT6lL9BXPMzs428xk0AUFQrxlsJDvKV4TsIzt2kJPbfNYx1NW9N87rrqNgzTmptX67zf HputaePn9u273kxPPb7JXwEGAB+SR/kNCmVuZHN0cmVhbQ1lbmRvYmoNMjQwNyAwIG9ials2NSAw IFJdDWVuZG9iag0yNDA4IDAgb2JqPDwvU3VidHlwZS9DSURGb250VHlwZTIvRm9udERlc2NyaXB0 b3IgMjQxMCAwIFIvQmFzZUZvbnQvQ0xQQkJCK1RpbWVzTmV3Um9tYW5QU01UL1dbM1syNTBdN1s1 MDBdOVs3NzhdMTEgMTIgMzMzIDEzWzUwMF0xNVsyNTAgMzMzIDI1MCAyNzhdMTkgMjggNTAwIDI5 IDMwIDI3OCAzNVs5MjEgNzIyXTM3IDM4IDY2NyAzOVs3MjIgNjExIDU1Nl00MiA0MyA3MjIgNDRb MzMzIDM4OSA3MjIgNjExIDg4OV00OSA1MCA3MjIgNTFbNTU2IDcyMiA2NjcgNTU2IDYxMV01NiA1 NyA3MjIgNThbOTQ0XTU5IDYwIDcyMiA2MVs2MTFdNjhbNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzNd NzQgNzUgNTAwIDc2IDc3IDI3OCA3OFs1MDAgMjc4IDc3OF04MSA4NCA1MDAgODVbMzMzIDM4OSAy NzhdODggODkgNTAwIDkwWzcyMl05MSA5MiA1MDAgOTNbNDQ0XTE3OSAxODAgNDQ0IDE4MSAxODIg MzMzIDE5MVs1NTZdXS9DSURUb0dJRE1hcC9JZGVudGl0eS9DSURTeXN0ZW1JbmZvIDI0MDkgMCBS L0RXIDEwMDAvVHlwZS9Gb250Pj4NZW5kb2JqDTI0MDkgMCBvYmo8PC9TdXBwbGVtZW50IDAvT3Jk ZXJpbmcoSWRlbnRpdHkpL1JlZ2lzdHJ5KEFkb2JlKT4+DWVuZG9iag0yNDEwIDAgb2JqPDwvU3Rl bVYgODAvRm9udE5hbWUvQ0xQQkJCK1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRTdHJldGNoL05vcm1h bC9Gb250RmlsZTIgMjQxMiAwIFIvRm9udFdlaWdodCA0MDAvQ0lEU2V0IDI0MTEgMCBSL0ZsYWdz IDYvRGVzY2VudCAtMzA3L0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCAxMDA3 L0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9YSGVpZ2h0IDQ0OC9DYXBIZWlnaHQgNjYyL1R5 cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0yNDExIDAgb2JqPDwvTGVu Z3RoIDExL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWoACDAAAIEAgQ0KZW5kc3RyZWFt DWVuZG9iag0yNDEyIDAgb2JqPDwvTGVuZ3RoIDQ0NzU3L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGgxIDgwMjM4Pj5zdHJlYW0NCkiJXFUJdI5XGn7eu/x/JKXWxKDyxy+LSCSxByVEIsROEKOVWJLY Q1UxWlq1HLHVSS1zrONotGk1dKht2jDVqaqidq3t1D5jGaPGHPx3nujMnHb+59zkvfd7773Pfe97 nxcCIASzoJHYq19C0xpZg0ZyZC9bzvApk32BxAv3AKkHeM/lFeaP+/N7L3BG0EPAk5Q/dlrePyu9 ngw8Hw2UBheMzB3xffKYncDuJM5vWcCB6ndDp7Kfz37DgnGTp247lFDEPluLvmMnDM8N+qzqXODu efaHjMudWlgz1vMRJJJrwjc+d9zI4vToZPazAXO0cNLIwuRrX1WGxDbinmnQuoUshUWQ/b1tRpaR P//X65GnqotVyqOtsUqbS4h15ZjakatWYkP/Hqk+pMDnntiFgXRp5o2QPSkQ5xxnF9vuFbvD2MUA 7XC2eroYdQF3me0K241AN84dA39gtLuka9D/o/80IBLLsQ4NcU+SsB/l6Ib30BG9UYwuOIKPUQXT 5BAM/OiMzYiUcCikI0wsVuEshmASruISYpCJC1Kd66ShEKFIdjf5NxPz3S56BSMVW7Bbxko/JNDO UHHSmDsv4THDEOMOuzPsrcFVaei2IoPWNVRDNGbiHVTHaHztnlTcCIahRGbITUQgB0WmuVngxqAt tuOkZNLqgWn2TKXtGMtZGyVMyt1Fdx2fGcFIrvQW5pPxNpSrJjrVrmfEovAieiKXX3+Hs1JDknSK i3ad3CqOluC+aqy+1F7yaIyuGIpF2MBonMIV/CQh0kLWSClxTO7YM+SWiVcxnXm5htErwYfYJUmS pMJUGKMVhkbI4rcl2MT9P8FRyZRsKZd9epNNDHRwNV0td513GYtBZLgO+7jHA0mkD3fQDfRkU99M tk2fvskTjsBqHMUx8rjAuP+ERxJLXFZvqJluoNvsrpJLEMLRGn0wGBMwBa/hD7zV/fgCf5fHqhI9 j5gDdrq955YxtlHoRO696N2PaxfxlrZhJ3GKp6wmPp6itfSUvpIvS2S57JSzclZ5VISaqG7pMn1I /2BaWuvacKVQ1Oe+fgxEAW/gDUZ7Gc+7GQdwUGpJlMTzRKc4/6FqqzoTG9URdUHP0UvMEzs3cCnw 18BjtwBeZlkXxuFVfMAo3JVQcmgko+UV+ZHMl6o/6iq6qvbrFrqj7q+z9XxdrL/S35pJptScs11t ri315gbGB465TPc2YyHwkFc04tAcrZg/ecymMeRXSEzCDLyJBVjMfFmG9SjluT/HQZzEefyNNwCJ IOdR3H0cs26OLCZWyYeyTw7IQbksDyugGhAxqqXqoFJVuspXc4hidVSdUjd0PT1cz9SziLV6hz5r YIxxtimRYYtsieeQN8ab4R0W9M2T209jn2Y/vRBAoE7gt4HlgX2B626Am0b+kYhHEzKdR5armIOb iA+YiTvwJb7B6Wdc74sSy4yvLX5mQxxvrYN0ka5ED+lDZBEDZTCRK8OkgJgps+QtmS1vyyJ59xlW 8myb5H3ZQXwqu4mTclGuyS25r5jESjObI1W0SlDJPGmq6qJ6qb5EvppAFKpJagpvqER9onapU7qG jtTxOldP1Kv0Fr1fn9D/MsrEmQTTzgww+Wa2OWKOmTPmsQ23abbArrX7PXU9zT1ZntGelZ6PPTc8 T7web2/vMO8M7wmvC4qkWv2F596OX/4SPEfkFVvTTFUX+S5q60I7T7IYMY/qr8fqxfo7myf3tE/O yQI9So9xG3W6eqQnyAD1uTTQ4baNzsNCOClVl9UDdd3Ukv7qpsSYd+RTNUGnKk/FJva4qWVm2xuA Oo026nUpVwf0bD3b/Qlt7Fq5aNeqY/CZS6oGLvJVz1MrOOlbNUoVYZBpbh9jFOP+vp3KeLdX8yVW nzBrcVX71T/kniynahyWbqahelklSykV96nUx22ZiEJ5FymyR87LTohs1iXSXT3H2ypTlaUVi9ph HSEndDCyKzhKlKolvdU9laX3eo6yzghV4jtMFy2JzJ3//gIYzxdQrKKpaWlUk+PSFLWxgnr/ILC3 QrHtGVvEPNug49AXiXhJHUIbvo2rxCDMRVPsZg7OR6JaiRluloyg7vegfirslNFIkBCqZRi5zWS9 CFUNqIVDuesj6v/XVP1MuYPXxMeXVY4YU/FloUmjMuVQf4uIEXiJvdVY5tluj6OXhLGK+gJrmeU/ 4GXWnB+5fx20I7/B2GDiyNpHZZ7IGasDGayPKWR4SBReJ+f2fOe9TQaVd7kbzROOYo3qzpp4EKPc CqTy7vq62a4IQ90GNwT56Oc2U3+nuG1oiXk2Ww2wjU1zauxB+YL16Hspom5n4Bz1KFJq4xaxhfzb 2z1YYE5TOzu4he4kajEeDRihYayiVzAOdxi3DF2OZoGeaqtL14WsUBfRx5W4cAlGgRtL5d2LTV5L 7ZmF+nYTc7fI5KlE8m2EUEng6BC7LqVTVv+UDu1fbNe2TXLrVi1bNG/WNCkxoUl8XOPYRjHRUZEN /Q0ifOH1X6hXt85vaoeF1qxRvVrV56tUfi4kuFKQ12ONVoK4NH96jq8sKqfMRPkzMuIr+v5cDuT+ YiCnzMeh9F/7lPlynrn5fu2ZQs+8//NM+dkz5X+eUtXXDu3i43xpfl/Z4c5+304Z3GcQ7UWd/dm+ stvP7B7P7KXP7Mq0IyI4wZdWu6Czr0xyfGll6VMKFqTldOZyW0OCU/2pI4Pj47A1OIRmCK2yMH/h Vglr/2/GqzW4iesK37uSVpYtyyvr5ZUEXnmRhCX5IduSjPFjsSxhI+xi4zSSi7Es2wQDwZAUUoNT TFteawiQDq7TSQtNCbRJKSvbHdYkBZo2yZSZDpNM6I/+aAnD9EcaT+mMQ6cNtnt2jR08nel0Z/fs edzHued8Z/deLDOEJVKVJlBGNjglWNmGiECzDZIHgsIZ6e4VNrXGIw02hyNR5BNwuIdNCYitF3K8 chMUlqcRyLCglqdh+qXVoBEm7bvFnxQplEp6tb1sb/eWuKDoTkhz6L0wb4NgOfAg7ysRBs8Nx489 bbUp+EhePyOJPH+MES60xp+2OiSaSMAYAuGMJvkoTHwSQhjbzMBcxJFEXMBHYEJGWoe0poXV9bER SZPcwQgatp7dzu9IQmKsvIDaBh3jVis3NX8PWSMM3x5nHUKdjU10N9jTRsS3DU7QHEMvtxT50pR+ IaxpXc4TRpv9NNO3ZJM5ubnExdqW4oolj9gmgIPA9DDgSZyFNVVKpK8S8T2V0AyuBIZeQi/ko1/Q hJM8VQV6SuovqJwUy/BfIMg/O/35ck33Ew3ppL5AEiuhZAloYF/kBa9X8HgkgKjDkFHwsVaWA0W+ /SIhsHsoBl4QPrQJYtudqCqB4DscUnpHRA6lQBCGW+MLMoNStnHElXgTApGULLcWLaZnJMvwomWp e5IFHE8i6cRiEjJcS3cOZTZEtlcJ2Pw/zH0L9thmNtbaEWcifPJJbGPty6QFe+WS7QmHFwwQcEHp hEg1sQC9to64pIBb5Yyykf5kI5Qa+CgYwnGFjUgscIRNIQ8F+N2yNLIkxLXSWEonKeO/V1RnAIBl DWaiApVsXKCJTIfj/+wkzj+Uesmvr7o9WZNQ5V0ur10mL3NPyyvAYaWLiLV38HzmMlsUPlY8H2WZ KJ/ku8X54RTLUCw/pYgr4vyeSHIx/eL89RGbED2ZgEVsx1UAbQLVp1l8vDXN4eObO+JTFByzjrfH xwlMhJP1ifQqsMWnGIQ4WUtIWkkpCYwkwB8PqmKcyJDb26Y4hIZlq1JWyHKPiJGsy1jUYdQjEgs6 alFHgE65oONknXRJX4pwe/xpDMiFlShCBLbDxsWugvMhbKmb0wR+h7gBW2E1cXMcqZQicWNSgTLV EvMrjOgMUnUT7ARS4EKkwTvxVpTnpR5Vz1a3UDPVzbPVqA546jEQf6lD79A7gWC7Ej1mFLcecyr0 JWyAbsFcu+Z7Fa+pbsBvzIcC+HTaHhLxOS5h6A+6rSWh45aTJSdKVVUVsYquim2+Qct+ep9vf+lg 4IRqdMUV8or6qvGq6TflHwT+pfp3wJBJYy7D7VIplY5AEZ2nZMymMmeRMuCiVUpsMJvytG7dTXwW mQga5SAdPo/cuGcyJ0erwu/iXyAl7kEO/NpkQUF+NmyjTkl1hk9NXDVio4jPcOay+xfs2G5FIcyE uFAydC+kDOkYUeHmNNnIkXTscSgcIpE77rmvEfFnnJaC3UYXnKiUiA5eh/0yhhBBdDqbZ6ZnOuVI de591NkMwjQ1DfGiHkxPA50F6YE+d03umjV6i0SxJFgkIU1K6ZtC9PzDCU1uhQvqgMsGRkUBCUgE eeFK+EvDg5yn2L+6cMXKzKxSf4mfIItXlqXw6ixPCvlXFKXQyvziosJMN6jcWVpEVVPVXplgr9dz GC60txN3eg3lZrNF73K7AhXBUKDcZLaAyLpcbr3ZbDKSahMbAAHrSdJkNBuCoSBsNVzuXb6s0XOf xgLX3uLaKlf81J09MvL49EfXua1vpHCqtzt+Jba6ct3XfoRbTryqIxpHdm58/qBo2LJFpVPXzt09 /33dnFK4PMR/TA0PK9nVCiv+SPtcS9Ohx2ey89i9XP3+XRJGY/Ofqr5U7UR+VIOacIJzodi9GEHF MKnT2LIYs87G0OvI9Z4B28DqgfKB+gM2UlmGY+L8rQmjuUJ6cz5dbkUhV+4ujYXdKXXSnixMlvXV 7Cn7Zs2fGK0222sga8vWFdq12YSHJEW8kSuotRtra+0Kpa+4qLREjcvtHtLnrTWs02j8Y4gYgwyL itbJyiir0IjEIS6LWn/HbKay/FBdIi6dQBEX+Wv8E1SLP0Q0KiQ+uGavy49ZLNZsEX+XM9D5Luw6 nAzgwDtr0wP5e/KJfBEXcbaG6i56gD5En6bP01fpm/Qd+i/03+lMmt4Qg34TjvaOPK+3ZWYBSXC/ QM22RPoa/tpMzUxL9yMoRKkeKQBW3fSM/AY8YXiO6Yq9L1O/kxCml/AGD/V7fylk3isD4IW92GEi SUJtNpeXBUMWkmQLXG6ZSohwAQ0Fy8tkLJgtkHy3y+2UQcAWyJBwSa2Bgd5wVrr47GZhd+Lk+kjS 6HRefL7t571DH+59871fPiwp+Hbq5ZdGz4qHeGGluXDuO0MHE/XPJgr+8L1tNd8a5PfV7VP0O9V1 c+/x2zfHmmynjiZ27H5GODD4j8Pbj9S83RE99dyOC1333/34TPEqmypr7eiWxq2DVf7BWXry0sHI pe6db5TBiQe1z20ghlSvIAOq4thR/WU9cVR7Qk9kjmn0aAwb4MeaqfmZrmATiclhY/tW6YPWOT1b LUcPIueH4w3uxCYoByJAoZAUGJPRspIghn7Qd+Z1XPbo4I9bHNYNL88NODduO4v5T3AQz+/2NHw+ N/r+H6/yl38IPhSDD1+XfVjDrSpUejIaVQqYXA9OGODUpskEBxiylORIBTlsil/8bydwpyEAdZhr opA6EAzmQtCLieKxvtOvz93558HzzQ46NqTq9cS2vTr30t2523N4tzPyN7zz/bsCf0ny4CyxCY69 r8Bx7TPulKn9SM43glO6m9aJ6LW2O9bfRv9s/SSaEVKt1VXmVFnXugKhYLS8LcO4giqgqo3rjPXG sM/mi9TYaiIttpZIl60rMpj3ov3F8GDj8byj9iPhE41jeaP2c+GxxrfyLtnfDL/ddNt1O8S0Nv2H 6WqNbeo8w9/7nZuPb8d3+zjxLb7k4thxEtvg1MRfwmXNhQWBWgZdlpBVJLQd1ClFg4IcqnYZFRA2 lcEGI2EtqC1M3AaY8IMNsa2oP4K0oanaJqItndi6bGiiYgxs9p0Ts06Wv/P6nKNz/L3P+zzv8y7N sC29yRVp1h2tDXmcJtanNaDadAurjbK+XHxnTbYIl0nQkuzbKSB02HDbnvTdrj2cvp3L+XsTvTO9 t3rZ3rfXvLRDTQnVyVLpfonq5v37pewcrWBnpYTV49NQxSzfH4UFDauUqiJUlVCpW1XLlMKO1NIf aqzenV6kXH9a7MpHuaXyHAf8g3XVNId88RS/qHFZZ00g1vnWytZkz/aemNfb1V6/BNtDiaqw1x7X c880doXd1TWJ+vqqwfZn0j1veGIxb6B7M2tbvmwoTN/UEju+LNjSF4n5wm0es6PK6Ois9TY2dDVH M0u3ResWeezxxHhrS21itcMUr5YXWfQ2g1wlue2BpqpYQ0Gp7s3lU3AYfYycaA2pXYfXOW84GNE5 KN+SGRGQwLKSxoIuWYhex7ZJdp99zM7Yi9BAdD5pQMKS7Dr6fqU/lfppWufnLBlYSCEt+rw1lVbp Hax5mpCFBG4ezouCoAtbbM1tPenO4YnyqcaaiVVWg2gT21qbV7w2MHxO+XdrYAx/DTupcueIH3Nj nhfTBY4KJkZnGQZhE6yilvwATMEt4KlYJi+iMVYRNqpe/UrtN83TVVUma8AeWIO50iPsPKQ8+XtP 5mALuo50KEqqEeF1DBFJW0okudSACJPiGRGLb+sXyiY/Go0qe2tOhFsqoNOdAGoiHfF4R8d1dY03 EeW5zJM53E55wqDVRETcJ77hNCWo0u4NmLFhTP821XUdKoKP2PxMghlkXmWmmFmGZ67CT/EnbBG2 nLujvFURZaq/uew4p8ptcyIKEATcXravgs+5/f95nvuIPgt1P7nLXOZGkAmF0PT5DRp/EfjzHGdX DgaDuwgSsYhuFCERTCKDkanIbISNmJXTRsVnFNAEmkIcksPT4P3SbcyrPmPlfEU+qDPohVAwVBPC PAYGMC+Eq6s8Vd4qhrdGpLAu4pKdMuYDrHkI+Xj3ENiMNHLoaRQC/xBUaehiMdmHkKyli2I4QFka 1G9Dw25r0qI0BafDbMMqlRaZnGr7SJuV/qCWEO7eu3X94NGdR777m6Hru791Y3kmn97qjSdCmfq2 Zalnk/jYXehb3TH5y/KZv5cvHfzsFw/Kd88d3DB6GjJ3j7yWCCxZUz5KMbpHrQBPM+ZAh4iNuAZd U65ZF4tcxIW3oe8gbOywwibooA51CtVQr6rEGhoHKcD/RhJsQg56BsG/iBEkCYsYOFGjxwyahgf0 9i5iMRolYk4lpIJ0QJqSWEl2TuMQzFWSG82upGZN7a65rFkhTAZ9Mf8YvohGK8pjDbeabdRE2QOp dpxSEqDs/x50B6zZr5fx4GKHVgi7w53sr48/Gh9d7MXhMPY078B/eLfB7/UpddhI93iK7tELI+RN waXLOF3VS5IuQhdZWSSvw1EvZIUu4UOBJ/4X2PWaF5zrXS9rtpq3Wo7qfmz8ofm07rTxJnfT+bHr U+enrln/Q/ah024HDytzVXbZITs9LkF06lw6T1L+irzHOeEXXDLGTresl3kDI2OOdynCKFhZalVG iCgSmz43JoJYZFqp0eXcEzIo5gTL00wrTdy+C4D13iLsIwbE/6nPOmDdYi1YWWsRBGJVBhY38hP/ mJ8Z9E/5sV++Cg8pzwxAiG0Ab8EFPIGv4Rl8B/+TTjmybxr2f1nPc9n5inN+apznS/35bK6UX7DH lydEuCbOiBj159dF5yoNQbE4GWxauOVnu+R9Mr2+zpgdN3G7bhgpJSE/2k8Ro0WMosAEUggtuBgh WOkVtBVgIdBCuwJzauDxLGwA/7HNL05GwvLMkRN/THSffNgOQ6+sXeEGrvwoDJ1w+MPdJ1/PX/nV bw8MD//kYvneYlNzTFFCyvLnKZ4t0HsFaZ/MntdnRMWOZvWZDnG5doWup4adEaG+fnE9SQ4mZ5Kz yQdaASWhQywEd8Q/Cl0JTcdvxu8E74R/H/9bzV/D+i5NfRH2XqirM6EinrtwKwGJIpO8yHAmBziK MHnRQ6JNSU8Rll4wGerrrsIIsiER/5noVlEM8AEVA4rkhbN60Cujjm5VbCyGD8SmYjhGz18cEAp0 70X8GdGSJEwlf57ESap77ZeJ9ZoVW+VWRXDu/g8gFZ35/vx9ZZmj8yCVnuj8aG6+f96SaVrQoHS8 yRvRSixfEwgGQoFwgOW5sDES0VJxaWJjQ+CVaBTQ0QlFK8b5xBD4DB5FbRZmlOjTMUXh2CjKR6PW tKo5FCeHClag0qRod1fVR/WmlHxBhYcKssJI27m33lvbOb1r7NXvlz/f882mgOw2f9sZbth4KOj2 RX/wVX/f5LO7B4+MsN17Dr7Ut/7dY82X3ji7+4NltZ5GDZfjdcde6etZ7Knr8Gq/8VbfcOGkouF+ ytYrFF0tMqDfkTqHASS03EAkhkjQoAe7QAUXGJHjgdXrDIjVG1heb6CsqiYWQWMTBI2GYQVer0F0 CDVchaOIRzqYJAYOeFHD8xqO1evZq9BF+aKBjUQnihIDk8wZBjNFeEBckFPpJcEg1atZiZF4IoAg G/+PQ/msilCWEoiGfzGVKEC5TJMy/9HZoDSaNWfMKmHG41G2Mh5IkkQVbZQa4Pwo2IPmoDmQglZ6 AObKpROl6/j1zSfKIbi/v/wj2DjGvPl4Lz5eGlD0a4jW+3auFwXAS5a+z4JlnXeTt8AV+IJnL7vP I6RwKvAc85x/beDl6m3c9upx/I77ner3mA/EqeBsUEJBkExmi5XOnhob7byMkiqzP0BbLusPuKuq GcH1X6rLPaipO4vjv9995OaSXHJJgLwhD25CEuQVEjBauYmWx4KAWlG7UhFXoWjHF4qgbiPF+sAW 1t063XHXTbdVq467UhRT6ug4U9126z663V3rznSHMlhLZ+1fdKerEvfcm1g1Mze/3829CZdzvudz voei4dPfjNhsdt0YkMRA6kSIKZ5AxITdjiig+TxkxtUXokxM0jH+DnTsxKKz1Uk4oUD+N8oTMTu2 Sz8isjaRj/EEb3SM4TfwlByxyRbAPN8iRUeW9uQP05QsaKC+RJl9ykIfDeFC0kkSNCK3BW8httj6 cB/RZ1MAcSTQAGfmr1wuqtZTG7U/ydlEb7LSLSvAZDF2hpL9p+IJj5USr+Q8MdnTkOhYgdmje5f1 L9ra07ux0GlyF9Ut3DZ8bOClS5ii60+Puo/tj68fjbrLl5RafLy9bPjlnf8IzWIIjaTO5ZCLYVCn AeWjB6J3G7s9rTu9j70lTAkKBYl3k71Ub/ZePTVXma+gSacx36ggbauUWAnsGLXBeOrSgDl7bcSA aMmcjGg4DMEVpRyJWpUJeUUvIXpbvTHvuJfyGpNxh0tIx+tsumKdqBvSxXSMzuh5bFEegOGcTHkU GRUAdIgqzLHSkPo4ludVCrOCkEMI/CiwCKzWasmxEIoMgXMJrBMIwZvbkD0ddnlprjZs0drakEMN b+iRR5GgISMDZ6WTzCOuSx4lo0ybF/RjaVZ9FHGAP3mk/+Tb6/OGfjZwo33XjYHVlw9jzffrZ25o q6v8tcsO7N/tWkZ3CFzjb/9wYM34udOHTq8cwdZRXJNYPrNg35LWLyNF77x55p4NqqD+4SR5HKpA ha6+j6iH4yM68zw6/nBc9MHGqMQ06WUjSORauRj3R/wx8Tn+nBjnIKRYhREnciRBU+Aofy6aSCKT JAmK5GixOkBPYAUsigkMMo/jX47GVFhlVNNjxNeIJO6IakTxlEg1UTGKpi4RXyF1Ku7SVDkp43pa 6qA+/q4v6U/3pe/+MCVetovuUvTT/QoqJVzokFsgjuDAwb7awcYx7j8TNxNzN+E3EgObi5/zW+l6 173L1DVzYasKQIh2gd4Ogt6MyIX8uFccWwEjrj/X73Vv9Pc6oqqoOmqKmvuEqOug/5ThuOmkMKI+ b7ro+sB9Le2a6iaXzaA0rOAIE+vO5vQmgRPS6/Ah/Aq3N/0USp+DQrgO1eHa/FX4x+6V/k7UiV8k 2l2d7g7/TrzLvb1gl3+QGqSjTFTZl9GnHcwczH6TOqL8RcYR7dHsE66z7rP+ODWqnFJ9o55Kn3JP lXoYjnWH0GxcUUovUCK1yU3Jb7xe9uIKepa06DhrmAWus6B86SiGPQ8s5lFADBBioDUQC4wHqIDz ElwgoQa8UANpxXpRP6Qn9cayMfxtCiySPZ+WoXJ3cjrp0CXBY2nqApGX+opyHBnZlDJLsNNOsOOM tQ0XZHrbUKEWOqKDghaZI9lxX/asNlSUMSsp9ZTWpf4owWazlDXX45GNeWrIFYIprUvK1ymkJdUt 8YG3Wm6ceuejDWfOza7/1/DVDc09uGSHuH3dumigJLik6bWXNvS5qokz/bHm/ivvbak/tn5/w7rN g5/0rN76/PA/N+xufLF7e2NZR1HiTtXx1j1He5fVzO4EBi2CSngXNKFHbqwW/Tvdt+ibjltuqoPq oXcre9lu9Q6uR9dtG1C+oktjlYMeYo6SdhvsbgNN5ggUYugxvAYZsHje3QSdDcgkskXCRgGcM8qR 0pNOA6MOndfrEWeQCGTCmotIy2ttWlIbx2uBRh7RE/WQoqfVE/OMeygPlhhmh9vEtCtpRJox/yk/ czdpaGaS1K9MwYmfhlTJ3JetpZwvrzlPmaF28YLF5XTlcvY2ZNVIY5MSdjZVDsxOGfDmYIUnkSQl Su4J+kAwqC1Pkr88ZWYIoBOWEpTMkIymDX3jn3p+/fLgjXU7r5/sPvzv629dJvzaSM/CFa+uCK8q /KlFILbhvN+v/eLiewOnDp65P5Ho2dNJvN/XsPrLHbFjn3U3F0AWzj2cxEPkOeCRHkWGSWMcC6KV aw8OGWMw/ImIUQPQNWIWKbJlQ1mxLCLrEhagb/wNoyQ9pmXvLY+UuMWHS5OSkhSle2KP7YXhcCEc BUXhiLSS5+RTOGZ0keQuInWm1xNncJwchudxojWi2S5czWgPXtd86CDUnFmXxbPqUYNaeq7MONkg 5uaIBhVYKjaXJdigmQ9p7Ln2qJ20f2Q25nX2yolbOAPjAVhQVDkDT1nET8p5klOFNz/1wGQgKAte Gkx/6LtwFZtSD/9C+2aWYVSCNrMkVBeMtA+Sw2Ly2cV79wocg006js1kQ/6Sqq2r2ofhv1mdqGIK 6NdRBD2HvxA7T6AT4f+EScCghTdmWZqMSy3bsxnMo/yv0Tfh8eb/PkstbzqRdSL7r82Urcm2yLZ4 lYGyIxsGX95IdaC1RLt1H6J60EF0P0wOK8ORiD+CGheXRMIEolSUydsY9hPUfDOKkxGR5efheR1o Pp4PZxcjmioXijCWD8gI/H0zWX2hfk8wp0ofJxeJQaaqsCyYtridqigpWdqsqvJWms7azMVm0Uya Tc2zKzS10Vqi9l1dyOYodoiOJgflMC5tjuNbI/ZfvWCI4/K9Pl+DVCIQ6wYQhUQziHLRzG1UOT0D Epn5ir9dWXmX/65lpuW2XCzJmoGb+I/38elz5bqZs6Cu/Bm6uLqmqubZGlIxJzQ3RCgKXKyQ5bIJ GUKeKx9a/IJnartQXXmtFSmKKCtSzlJ14excGCm3jSCD1QTrRWwxG028IH0mWlG6G+6oCc3vwj+q qLciupixojQf04Uy7Xr5W0ZLctU6NbBewGqPpgujVFFK1Sk5Yt9TL683CVXpVVEBEyYmHyFTGygj 8pwOisjK1FJ+G9L5CWR35BEBXov8pZQWijlV24rkqi2X/V05IzXS1I8Ey6Vip6PbwhafrfZPh48n Phu9k+i68wne9HfM4FNdoecTrsSn3yY6Jr7HV+7/BS/83dsPDvyf7LKBbeI84/i9d7bvnMS+9xx/ 3p3vfPY5NrUTm5wNiZuR47N8NE0qmjShWEBhpQLEYocFaJclnToc0Kow2BiBQakoGl0ttUsacGCg gtg0qLoNlVWUboN2I4U1rtBGK6CL2Xtn2nVakvd9dI/lU/R8/v6Ptth+MjLvkY2nft7z1NwuKJ1d 0pJpe/iRaGrgR76GRcTpUubaFtkX3QUWjrwO/Ps/LyXuTJQGzwA0GUuflfIfgQN3AAXOA/B66fj4 8dLwqwtnNzw1uq5/3Y/Bs5ml8+dvrG7d9Judnc2tnceXv7xmzmOowiGGGd80rsd4TMTdv8J1XrAB UcAFL4aoDPOKALGZ/TTxMeZCh0SngvhYdVE4LxA0xTu9mNgNBgAOAEXjFBZr1sbqu398NxbT6gMW i59Nglj5B/blzp2D6EzXKpOy0rQFVghmsU0yOehqyDIsx/Fur0kq3H97JJjUzGi8M6HbSJ1uR6aV 3b6aspsVym6X7h5x6Eb9GaxOWOhK9PJGejG9AC4SWqUu+knYbu8U1tFr4bNCLxww5Kw76BzM2bYL g+J+ej8cZvYL4/Q4PMWOC+/QF+DvvBeED+nL8FP6Brwh3KXvwLveu0LUTC/hcBHRFwoS5hUE3myt 4MxO3sU5KZzkKAdj5xxbBBr6oMDzfgbamW4GMJC2Wgv4eZXBBTuOC6L3CIaVA1cAY2oVBWnC4XRS lJniC+CeaqbRd/AjVpUp4PHRVgEIBXxStfpUa5v1lpWw/sK3foc+vz0s6lk3q0maorbY0C+6byOR M9WUs5aVTC5trXNHcsa+cxE3BosAvv3/dw72nWsim9CfLm2+7hSQRZpG0uva5ZCSqLBnAgU4yw/a uK3Eidem/rXc//DTpfZ2jzIL/CUALjeml07dfLwxvHFiEvz2/daQGCODQdod321Y/uXewceNwaCh ToquABZcnvqzRph+DDNMIK4WsAjWgPep8WXYMmE7NihsV4bZA6E8mw/dZP8R+iRW1YA9F9qq7Ksf Vo7Iv1Qus5dDl8MVhlQB/2SUXjsjpVUF709oVv2bw5VQVCmKLo+QqFcDYXRx3sQ8eV5wO/sBeF++ olwPkgYZBC31kHCYONYuOGVn2BGvq58vL048CTo9y0J7cAZiMNUOlskrU92pgdShFMXG2fo2jIAk KwthT8xgwgnBJbQqg/I++QOF9KXUVFtqNb6aWGlcaVpJroz3mnrYHq5b2CT3hJ4Lv2jaxm0ThpSB 1IXYldin8j3Z00XRImeW/FDknFJAkTHCEMWSEVEm/NMaogpR5w8nk2bntLDL5cTrwlql7ERKTiv7 VFI3czQzMNo8O6E9js5doFvVjvyPruBBhRDncb7dEBEbotO1D+D8pE1FigLtnkOGawbCoDkrLEwC MwCfASCZclENRk3V1Xh7tIqmtdtiQbcf1TIN8Xbapz3SBxtTvwYXMQlbBdyIKdAiiUSaWoqodqbS mUg6M7dzHJtO1N7kdFPsQuO4SavQbFEvsGwZx9DRNk5RXyrolCVjJKIvltmxRCDsFgDJch4ON5lq ZISJSk3YXaOAGDldAQGhRiESYLpChLhpCogb6xQs6PUrmFBPJBWklNACaPoGqmkCEi0ANPez2SyW zXyN2xgCOFAGa1NASir1aJAzGlMEkhIiOc0fdOoTXqdtknkgMjWuI4mRlxasGrh6fWpAaQ+6vKEW BV/86uo9B7839XxwReOu3Y+dPbGmbVNm7HTH2aFZnRz+ljBn+Q+/Pd4enBHIEhu+L0WDbvn45mde oUmy+Qctm486v/wOd3hL664nDEYMac/F9z8y0mhWywBX55iFGIjhMSIm7qGHhcP0Ydsx+ritkhLQ fw/6iOcdW5wvETucB4g9bJ44SZirCKsB9y4kughjjIKMjBgDGMdwDoATiDaWHPPtM4Z5AhTwq2NM 5E0IYIGYPTZkedmCWwpETI3ZzXgeAwDUw/wbDBCZZgZnWBUVoLnJ5wa0W3Tjbr083IuCa1br5BZJ Z1sQTqS/yGYQUGQ0gsvcTt+eaC5O3kYjR1NM5/X0+hycqYoMsjWVNc6giTPXYlUOdFEeYy2ocFlq NcoG32TsbCYNqgN60LU1reVgpstkCPg0KWSTNebWMjfTcFEUZ028krvS11vc++KFreIzpVsnS2+M 7zgGmk/tHnrIxtnZSuP6kvKHY9tLl64WSv/cmTlqHzt678S/3wFPnFzorObiGtUG0JbciqaTE6kL Qu2q5Cq92+BP4Z+gsRf22nNwb/Ww4zx33nsJUm7GZvcKBOkAOXZQwMOUSeQQP5AiZ5ECLskjhq1W C+4JO50YxTe12kBZ0sRtqs1oK9z/6zEthrZFAa0XZzUn1QDwBUB34FDgWoAISC69G116N7r0cLsQ dVRB1I0m3WliNafpoH/VgxxovTil30j9ZCNf6En5b8s1ftViPCvQDhi01wg03wFYB7q8jNgBuGpP x1fhf+EFjZSy6Yzyv43hQ1QESZMUQlHH0KxEfRFQOmQnr3VAGMTBt87kz5S++2F/xw1QX/r9rWU9 wZlSD7Gh3xcN7iidfq90/fSlp3mwALiAB8zzarX+ENoHb6GIK2CG2qwm1/Kb+f3x19z5+Mn4tSTV 4ek2dZP9VL95wDRADlFDZrMscl7JHxS5iBSgVC0glGS1imaOIrVQSpqHlHBcNHEkDzkcBBB/eBXs SKQOq4W1eG0Bfw+timgEFdQRL3eD572UOU9Rpnwz2U/iGAnJVpJA75pQ2/R39dbloxGxNoa+uoHN +xDRXEW0vbQt2Z08lCSSGNRTBfWsQD1V0B+U9VTJulPWUyUfTFwbBzldjGlp0nOFeiZdvJ3++xRK V7rYBPWETaKNjkxJX+1oVDZNNWlSCBYnMfh5BDywWjrRCEsDRtI6QGECNSHUKBJjR2NL6xPkI8qD 7T+EV31sG2cdvvf12T5/3PnsOPY5l+R855w/4sS+JBe3SZzk0tRLWWENI91WILRR09GxTnWytmtX TQsSUDaKVol1okgLFdv4AzJIP7HKaMPXJMQqioCWSUMNUoVWukLpCh20dvi9r5OmHZqQfXfv3b2O lOf5/Z7n+S0TSHoJVmgGNe9ImA5dF4TAg+sr58Xkyr88udXoG0juvHXFMNLRcF3TiMHW+hK1He3J LXZcfjeW2VFJbq6PJSsDn06Eo9m+Zyozeli0NtsmvtiY1CsXHh+u9RFGVWBUAUZbUfORZLaEGq0V +njOxbrcs1nbN9On0m+m37b9Ln2Zvey+xd5yu4r2ouNZ4HjKPuV4ATjmnG5XM3aqXm8JxS2ek50N ihxWNQeQSp6k7LJDoN7ZqMhxNZZuSbo5L2vHQDXAH25lYnEmKSZxkjCtJxJxHApziXRyhkkhJmWk rFQxxaYOOByKE61zojNO5CTRLMMIlEmBkiZQJgWtsYEy2UAfNlAmG6Yz/9N0N6Dn8pDSJsqXgEJg 72+jd8jzkxGK2By0YJW98tIVKASFA/dEfkIZkJjBsZg/GAZn6uiovcuXlviD9+iVm+vX8bqOEoXV N3l3tMVoK58yRuIS71agKGz/4GN1hS1fANKurN1e6Vx3v1556PNqJCDpelv0adu26rpyfuOGJOFr DbjN98BtTDRqjbjZ+zI4kqhLYlESIzias3Kbcru5olSM7G4+IB2IzEqzEU9rdpdnn8cm5TJ1w7li bj/7OjufY722r3jmcrY1HPAiva8FCGsxk/rPMeo/6BgkwLXWYNu3WsKSpDmSLTYhqblQWmn0EuQb KciNDgJyo+b3DwcOBLAvsC6AiXY+G1gIsAGWsBEAAb10nApoCX9gedz54TjyxZU4hiB0zRLJn4mL 5H38Y53jzy9yBYIIfZZNU6ooa8DV1f6rhCVxyakWVdKMpp0ipycTqURzwubwQhDxqf4eFFVEvzPt bmX4GJzEqNDDuBKOVuTRhVbmniG0uWphadqjJHoQIwMWoyRiV53MT+JEp1oLMuqo9UMOobYGjUvn TLqFvQy0j+w5XSnvm3jp/am1+weUgQcxH3mgIfjk/HOVp9469NCjRw/++v4921fW1Mg2sLiRw5/c efb1v/+sMncwrqOvPtqvxuOm/kRlrK/79k9uHnv15489LKVqYx3APHG7l6FTC+ip6kT4oyGLgMbo pYV/nSCM6GZp4bYVIEuT1r5JKTJrYINVQx7XII1yp9F+0UoL71q0YTS6UasbEGGSbICjBY4sHBnG C2cXHP1w5GHG9PQyTU2ZXpypd2OmP0sny7MwUL73Hj2hLLGkubNpcv1Teq7NSMvWRHHo8NC5ofkh tmZout7KDcMSQ8V5VE1T5HpVMxU5o2oFRe5TNazIbjVWo8iyGgPjaFVjnYrcq8YAgVhTk9zX2+vx uHGmtbW+XuYCNRq2NHRRQ1HN0IraYe2cNq85tBKOWnXi0KahuSFbdAgNFXStc9jcZGJz+r6xd6T0 J8QbkyAGeXFikopBOb88pcGnKgVLqRRGr9E0IgPXcm/TMoA6+HDzqx8tB4s/Qa/hXaADacPAq6l4 gxC0GEb5DeNT8Uj5efqqrfzjRYmAN7gAIEKQu4C+tLUqDGFxYPz2wWWVQC9XNt+lGY/ftY1oRgeE pd1QOQrzU2u7Sl1YpaWjWsnOiDrmH89xioxVTVLkgKpFFBmpMZci+9VYwA9CzUkRTKomwpEqibDk pxHNVeSmuHnOtsAhgxvmNnG2jdwcd46zcSzZxtEK5EoLHxwnv4VFxWqgAWAsWlSn1HnVZqjD6ibV NqeeUzEh5QFggso0NP3E5KJWU4GuskDO+kfgusQE3v0h6ABUCql+j56S9e0X6ZrmmoU/2/yAUIy5 bPUUAmhjzcYgHg8Xw1/2ft83p9sDEjJ0S8d1XBWoBgpRSKoXQxGMsBG0gng4iIIlm/tEJMm7GupL C/+h/zcsbhwneJCFpRJM6jWXy+As7gXu29wPOfsZ7iK3AKjhRZj+agUpTCGKX51+EVL/fJNewm3H 1PnvkEnu0igNJaMTkB4XMbp6dXSiP0/HszvZUayT3d46b30P8rhlT6SHAR/LU52bhHFqomYZORAz jWrZkpItofsWBVAafHXH57ZF1JZoRyLcJGcpnvYEBbH82KHTXx/Nt0WU5s/kVo3Ypu9gqoFe/REw HcSzVmmvcFrA2xj0LLMT7xV2GXs6n86dcZ/iuScYFGALGSjBHF6Pt+Ap/Jx1AB+yjvHHhVMdpwb/ wF9o5wMeZBOwA9vbv8bsa59mZtBh4bftnAcmHwbbvYqrkW9mdJR19bvWufYzb5pvM9dNn8sT8Rio E3dYq6zhwnfRK/g16yQ+6Z5ddZZ5hzmHfo/P264wV9A19E/3Ne91Xgp1hEyz3TBH0CHmRf6l9oOm 64iDKK2lZn1aY76xsLqWqTWwYDC2hBSKyJJD4lJxOdGTwEQ+yr+kJ38g3DVBiciW87LV5eCdsoO4 rKplFTmpavmBXjlvZ1nZ7qOuqyhyQo31mN1yD2IYTeCDMIwMMEwJ/8oaMcygYZgM4s0Be8FgBky2 m0fY63G7nE6hKJwRsBB3sk5nKBSZkfI9Pclkore7O5WKzySkcNjhsCewnct/gxUMI8tO2VHRjuwl vNLyWvwwj6d4NMsjvoT/bbVkfTRR+agX+KhD+DQwe1KNi2ZPe7pxenXhDZSH6DiGIgwpyLuiFYSq yTJUJlFRERy7X6wuy3lx+VO9AYRGs4AVfBEc+4RM+hnxF3CRyFViRPD4OXBocrnnZgMIMow7zMTk 4COWK9vROpBd1TrIjm4YTQ9+9hHLnZNCfL87GuxqLy3MnxS7LFHoQuB1R4UuBp4cpXdzR0VyN3cE LlWZhzSwgYyxkPFQKBQGoYFGMOMJ9H8l3Z9bwawge+kzATsdTjyObuz9wcPlvd0dNZ2VFtoymfLp u6RpVSbbokjBnSjVJze3K+h6y5qtHw+dwNcqvr0bIOwnJCluot9U1t6TBjWpquzWeGXsv2xXDWwT 1x1//3d2fDaxfT5/3NnnxHfns31OsH0kBDAJ9TFWIKUIVBhfbTQh2ixtgUAIHwnbFEppSFZRtKlN 202MsZaBQGpKSoCVCioNto5Oiqap46PSmAQtg1nVNkbXEpy9dw4UKuL4vf/Z0sn3/v/fl381cE/q 1UKcuMtQYXbgBEFdmvj5YwR1Mho0JQ5xICMZTHUp/gHejPvlN+SD8gm5EtTjsMus9zw95Xv4qWpM uJ5R1NBUyTdDdcUkTonLMRkZyEQM+jzq43A0jhmWwG41Po5/Z+ZCDwu8TqfLGhWX9anLGhXXHmVl yzfmu8xWN2/S4ESD7pUWSlZUXzuIvoLAKA8m2GByXGKtjDTF9prSefuz+iWJoBVhW1cvlbnKuu2r fvHjNtjsKO1OTJM7medpfE1Ajdk1enhRLBjIbixzUcW/yakY8JF5zSuCB7GCJ+zWvWlvjc1w8DNg Rm652A5t4ppclzgAb+bOiRfFa3BDdLtFcAkVxmyDmSJOMeaITMhIiUmDqRDthiAwtShNrhrRdCEv NoQbjELdgro21I02iV3hTqMf9Yk7jDfQgHEQ7Tf21g3WfSx8JJ6u+1S4II7UFYXr4vXw5bpb6Gvh SyMxF5qF2bkVsFxYkntO2BI+K54xPhE/Ma6KVw0PYQqnosoxKaKoWYtFiE9ilThnZSvFYhBq0xEE kBhGEBZFSh+PGLmAIQpGTsxBjvx2IRIOC9jJsggZRkpnjSeJNwjnsqosK3uVQYVq8WWlQtlj1kEd YHoLN+eVvT7CBXsmWSJNekmd03yu5VYLLYjq5EqkoePgLhsoAmlfvpfN1toppFkCaVqI3/gpovDr CYJbKGClHBeoLEB54fKi6MuLHJ9HrJgXjo+NHBXyghHIE3jWovJ7ORABUyxcPohKatAB7nME930N zOw7N6XEQqOkG0u0UMAzbxH0wD/hCvTklmqhaGJh7s5pY2k8dOe/to2jm34Uq0kkJssdzKYVelUq cfuSzboc7b/3Rf/tnxCdG7s6dp0kssdRCj405/XzwL8CgM0FDa9g4KswpHDGP82/xf86/hseww6/ qvIcdbiqQh2uytC+xgO0r3Ge9wHGKq8GeF4lCN1nelOHweV0ApYiLO9krH5U8ot8PpkzOJNjOEJn 7/lIc7i7NoMWwxR63J40YTeTKzSYaZDTsDd9OY3T/gC9RVBRDBVOqyQNWO7fimAqDWMuKxeE9ZX7 7qK27DJou9d31Fq2g9SfUb9cKPe6WOwttxnxechbLXZwTZMM1ELpWXfyYT4NBZTnF6DH+O+jFXw7 eo7v5n8OB+F9OMqfg6+B/wIDTV7L0fpaWE9G4gTCYweGqvkCJs8wRNicRMhrw2SozGielkfGN8na hsN54lFped708nk+xOcxFyTvcJ5En/NHJuTJbUbK2/+OBvLY9N3lfEr61h+dKtTCkKGa/ICrjH97 ypKU+iVYx8ygEwPn6Sxpoy9IyQVksOggNc5orGq0Pz7qYDx3R+V2n+27ox/cG5x3Hp3odyKM5o79 3b7F/jyqRBJ615w0wB9wHHQd5GybocvRCzsdtlmsW0dMUK9wik0xJsdgxHCMzBiMydiZ5ira30ih Qa4yq3CVr4lzyk7sdcac2NkcfXqV1cCWjvnF+dz62lu0IDaxULSsYR1I3sSEZCTpT3oqfRkkgZiB gINUITupOJc7A2FMFp4NZpBgI8v9h1W7jQCYKIuPQwpdp04RyGH5OOodeR+XSuIisLC91F26UbpW 2v7pqS+H1/btWjN06qu+tST0tpf+UjpXaoNd0ASzPn63ufdA6WTpvaGdUAMz4alDOwklUca21VqZ ZSJsOYGy5FF/Nr0hl90odkqd0R/q67KvRh1d4jHtt/ol6VL0olYRTnFZPZlP5FONupFdkXo2tS7b k51wFkEkmo7Oi/41fEmyH9Dhj9oF4aJ2IXVev6FVRM14lc56KJWqEJMcSpwQbVCJoyp5Yk2VXogv iON43BGs0UOhIGYdLI8iXMSImJF1EXukOUtb8EihAWXBzA5m8S+zp7MjWSY7ESyBBEsKwRJIUL0e C20e60OPpY+ePZnscdg8pKxc9S0fNY63lvmzCBiSTOYfkrUVl1t5iCsS85RrKRKPyZcVlDQ1qqWF qJjQk2khWQ9alCypcE09JKR4PRpv3rZtqHkxiQbVhH7ijTa1Wm4kLYwhoKRNQLDNMkAd0EHhWPsQ hqXQqCNnEaCRIRWywsJkwruqA96KJudPvvM+0eeARPQZ/jX8592X/jCpY2bDE1VtA3NfXFy/EG8t beyJEX2eFutkVtNq3pHu/SOeOS7Xr3qWDczzU1SU2u1dBBVBlER3zPSjsMzxKjAVHlhKqlbYBC/B bvQa+3vvVeS0eU30HWCWsMyA7TgeMXNsSOcYVH2YZal/WYd6kA09wbJuplZtivlzfoz8nF/2G37T b/c363cRpJs61iNNnFt2Y6875sbu5tTDEHSFnHqxheCoqVDkbpaxZDqTciKanFDpqsQVYkKLJ+K4 IhZUM1DljBDweMmS9JFLJVCdIU8lVZLNyYY9oQzEebIQV9tE/60G1ZDXeBda7NSFJjWNuk3cUMZa AME9qE2dYmke81JrcaC/dLb0eevuxd290A/EssAOgr3u4faXd609enJD72P5D7yD+ytl+zNDz0yf uRKkD8GAn5bWlP70VWmn7foLvy4Nlo4d6evbB03/2d/TRREYJ/mtjSBQR5MxNo9oIh3bhDW8vSrw O5Jn4mcyTLP2mwwWY0K2VWOc4EwkE3PQMmjH7dpW2Io3xDbIm9QtiX7olV/PHIJDiWPJk5kxLVgh vwgvay+m3tTehrfwfu2dzKnMeeOLzFjGzaMQRDCvE5RNmp6dbrRqz+ZcNSyORiEYk7yKihK6hNiY 5FHioZgUVeImnpjQNBVDAGPQDmMZO2rSb/+f76qPbeI64PfO9+mz785f54+L73xxzh+5xL7EPhOn NDmpg1FISdAiIGlMmGgpHUwkUVaJVRm0dM3aTSp0XccyaVB1W6FlhbSQGoYGbcekSkyl2z9ofwyY Osa0Zk21TNpEk+y9F9LuQ1oi33t3Z5/s936fLNrcKPq6rMz2sdtZzyH2GEuyhHqyoVwHh12pPZdM NpCSKMIayQUN1Am2Omhw1/Q6hHHKIHthKCKNs3IFuJWRytWKp1LmMLM5vA4cZjbXqEQwsyP4YgQz O/Ij58vncD1aCb+Y1nJtbL42almI1cVlVhfvsvpueJqdlSGta2NFC7WkeEKeXWlEIFhNxO5WIGtS pid+2WbHEO9b27S0bramiyXQpsFDobGlRKSb7FR7CRAryHriCTAGUTWGI9c5woQ9yId60Nwb4WoO 9aQwNkw4nTsrV21ZghYJlp0Rxi3LMgyAKf//JIFFvQm03xUFqAn0rsUXF51Syq/JDZkeB4sDDu/g r9d+/dzLr4HY9mf3fnpvqIF/5/LRg507yK+TACw+9p8S0X3iaxP1zOLjT2/1kS+A40/uPxqCuYs4 sHSToqFOdJBb3Hjwey1AAhIpeAiJyhF52uoFvSQf6KyDte7VSkcl4VGp4dhwfDgxrDK0nxaJ5kud 1Lgw7h8XH5NGtBF9pDhiP8M9LUz6J8WnpEnrOHW8JAf9JX/Z7yRLyXLSgRGabKVSWkrP51tLXaCL 7KbsuK3Zum3cW77XWedf19wvbPZvkTfnN1tJHeikWtIdtdIf64/3Jwbah0pD5SFnqDK4SvQIQj4k qPm0kOq8J293jgXHQs80HWGPFH9gHy9eyr3d/CvrUudcZ3gj16ESe0n1FHgfkGA/AOA8UfdscP3O VFuDmtyrq5p2PomulONTYSgeq31i2OcTLV+zSGV4PDBpsAAbUK7Nk86FefIkcLXGMgB6BmTqIO3K xcDFAHk9AFKBU4HrAU+gTk6+pZ/ULBkyGr1BP1oAFwsfF5agtblfdNzC+/DEQxRSBRsaHlW4ANYS VbAWxJbhXqtZo1Asx+ZnF6CJLYxVi9Zy9sC+haoBPEBUWyLqBIT80TyE9CxshWhWA/Lo7F1prTTZ bCiXEVr4EpGXkKmF4IG14am31VciBF+LlZWhxUlivtkMQpvjigzCvIXtDB+WMwtEP8R+DQZSfoew 0/+IvMOiagM1AD2WGCVwC/EJMalK2VK1ZEs4Hg6AQLpAphuZCIR8VCOx56GO0ciw6UBJI5dhns00 ZTJOuVJqR5pcWeV5zQzWTg7t+pbV9edffHvDxxfuKevvJuJJ1jQTW8/umTi8qjO7+OPv9tz42Z59 HdGE4YWJyJo8tm3/pq7ShomdX31h09R1nu7WiuCD5w9vf2qwfWeL9u74d/qf/60T14sI+V0wG53G 2egTt3MQDJKDyUFtN9hN7k7u1rii0W30Gkfo76vH6Z+qLAmSGpRJ2WjkkXqm2Via0ElZ4ow6eckN 8cAi3KjYHZTg4/qIU9Av62TOTXA81jkeSxqPdY5vjCq6pSF9FNEnCE3WhrVjGqWdJ3OEsvSRKyAV VLD+KfDpb6YeqsUsGZaG+RoSPA0KrOCgB7whSGW4wNaH8mosi/N4ZwhXcOBr5dYtHHUWVsPoIr8n v4daI0wloXQG7UH6v3QIpXW4LSHqJSkjhPRH+i/CRF5ceBvF85eHc+X1bEamexbf6W/qXHVnfiWK Uz4xtGcIdKFVFZZu0NNwVQvg4DnChrWjuVi2Uf1INeHR7Vcayjmmk+lh9kmUmTaz7en27Jr0muxP smw+W82Sffa48Lg0lb2Y/UeGWS1CiyKNRl1X40Zjs64CIx3S1ZiRjsdi0KdIM+fnm2FH++QMWjU4 uYULHJ6gFcyjpibzPOf6qpwLQwpncyQH650bCIeR92AfYtCH0dUZbEgJ/E2/0O3INhixj9mn7Rs2 ZespvJkpvJkpvJmpxmBwfwjsDYEQ9q6QiO6FNHQvFC/Of97/UN/Dm7QRRlLcAK0aDqj4IuI1ti4L x9ANm/ZNr+IgdTNGzhtoNNIGyUhm1mwSU62EHMj48q1A8Bqy2UrkBBO1CrAcfmDyQRyFXCRGEWXB Zw0szGDfyUCv+fdiFsb8u+tAng/AjVKfFdk0e+X3t+zUmgdK5Ppyf1M82fPcrm/+5gHoOHTWNO/T Rxd+d+XmS1NPDvydDE5sNE2naWxhuvfK2Prxs9dIc3+qBeIgCFvZ64hdZPCMV2J0cpok7+vfekYB muyve/7wlqiTCivCIFHsDla75YWrVy+BYputur6gbACFE6onFIDTRAyniTdLThmPLUU8ugdT6fLf gnf0OcNzPnou9vPEaeOfLH0ifjJxgZ5hzrH0q/QrzAn21cgrCv1D9pB0KDilHDLoRyMPRcepfd4D Bj2obIn2GQ8zj7L0g+wA96B3mzgQoV2jj+j3bKG/xNApo0x1RNYS94u0yeTZHJeL5BQaJkjDNrYb Vw16mkE/ym0gRCPlVRJKs+JRWD/6iaoIfZzldJFE/KvJC5cvX4ZtowZVu1pV3TBBA5WQIrIqiRx8 sx7VVL2+NOkGFJZJcSwL01AYpgGaYRCAHSUKz6K6BGMWQbIMfycKon+yFVc5pMwplHLbjriRvsjp yFyETkW2R0YiByJUpE7+ZSZlvGjsfjaGxKMWn699WCNiuPrA/0l62TvgGMMTC7oIikX/exyAsjFa +/wPJxrYbMaQ5PPeWLAqucEqVV+6PSNXOS5UhbHx2kyo6s2F0NVr01J1pfUOwBwEIgwLlycNkAhl IRgZ5A4ALBtB1qFfX2c6+cWsuUhl5fj9XWTzto4CGABusXMN7aN7TL/R9vCdb1CHB8N6mjZNvtDU /pVP/+gJjLcmHQGKAlIidekmOwERWPVoy9ib4UFHPhMOQPS5UrBKZskG3lYpIUgKHFGEMIxWuzEQ P4NinGf8rI/z8qzXazNVNijGQlUffKkIiBxfhuMBNDbA0b0NJxXe+RfjZR/bxHnH8ee5O9+Lz8Hn Ozu27xznfI7vLvHLnfOGLwR8LnRQQkNK2y2hDaUloLDSEaBlvJQuUoE0W7VVK5ug0ka1ipewSm0h AwN/FGnrVjRN4h8m7Z+JSohNmqoxKavGS8ye52xYtmnSzvLz3D13PsnP7/v5/X5fazU3Qg1zpzha p7NsjjcDpmTK7UqHaRR7aUfutlfSK5gBfpXyDD3MDLMj/uHAsDxsP1PcSo8x2/hxeVx5uWs3tZve zez27+H3B/bLe5QDiT3qa9Yh6m32u4m3rLfs6eIPmWP8u9K7sWPyUeWI+SPriH2aPcOd4c/Ip5WZ xJmWU9Y55hx7wV+VZ+3f2HfYO/z9ljvq6nFrsz1enOaokrItub31W3lqM7OZHefIAW5N6ypzwKJG lG9YT9nkEDPErudJigF+1GYlmq2ORHtrkXF4rqH6FiAu6VNsLkHxofrOKiLL8JBnHUPEske67/eE j6XvNSxY+jkukWA5zp9AfVcyyQIagSDJYUUyrXbFFAPoLUZSVwynWFKc6oOJcwrvV6sPtrthm2XU AM9rCnpakROJJOf3YzoiSgItJKwWltVsK2zbVpFmGHwnYRfRZVESDdN0HBEQvN/Psgy35Kf0iSKK 2Vm3p4hTTJ83uXre7raLk8V3iuTa4gvFjcUJ7+JG8XaRLf6Z/RO3jld+IfOXCBXI8K7Lu4GhwLUA GTjVt6RKfPNcHbSvRr+8GRduxoT5Oc+kZOdvPfIl3lQnb2rRgTp5/zphDyxg8X/DuHBkhEX9LPow Qj9m9CGfKP+j5I+7Ngxo2DSbm8pJPKg2GlpjIl/2HsCmZARGtAaODSLr5cFDUjIMvf5ZsNjgNN3D HOh5LBnO1g6btd/WftdWeyUfCD++BH4V6ynlIP+FqSIXJ8XjUjshtJW685CCRK6lWV+KCNa70wfv XSY33f8JteWNqJ7JZGwt/cY8Q0ztfK5Tl5pElkZL7V3fmW8l/vK6HTXZRR7VQQB8HyGqy2SuUVFC FBNTENOzdN9iM4PhFvRQChQoPV4idCLO0iwoowNL0Cszwv1HgAt7Q7Apzul9cA/4dsonohR8w10U dCwh7AgVN+tWyAoWxg9a0927wZ7QPm0iuy//nnYsfRKeFGZSM9pM+mR+xrqcvpy5rF8qnS9/Lnym fKZ+7lypXBevq3f425WEaAmqqKltWbNgWUsFW7TVJalew86uBE0iqKgVu3KtQv06D1/Nv24dyk5b 1PLsSGAkRXLpeLp5WbkyIC83aDFcgG2FzakTqRMFqkGgRskVtz2kF4gQSBUoJYO3QpFpmcVboegl HWPoIdiY8CY8rEEDBdWC+ZRqCVpI0MQygHmxTAuMQssqeouRNxGE5T7F8UFK8cXFmBLXNfxWa7FS ymuCoMF8GMI8ypwihm2ZaoVV1SqkQoDyBqg5pRISECHH4zTtY8fLsJwFEFlMFdrwebgRTsCP4RV4 A96Gflgl7rrBFerT6phKqp1Ae18jtCrxy/Nu5ccPwZobRVYIlbCHOOHRyyx1I+SRtKiB1P+Fz8Ix iA7EEBhFXfRZtDMIDIwS3LF8+LwF2zVrGYm8Du6wt6bGstutjRXsfVANzAKPsuAWY2uJ6IghwNJC k0OgYuhKAScd450C+qZXNTu63YzXr5xvdjSzGVfGG2ebnTCazvNOTBDxzdsuLzp5VnQ0VXRK6CVn g45Rn0RUSdGk1qdsfVr27+X10QG80fsXAA0QtQ+oze9djJo91OsZJMQ199HaYggXVGJJqj9VX8GW gFwB03tfWz9/qS8RUTjGvlW7mRd719RauzLLJlZBt/b3V45uInYNLbGv/a1DCgQLq+AXTlvv+nXE X2uDsy+gGg15LiNFo6GV8PnakT4jonaQmYxPkIefg0fg1PFN6IosJDIra1dhsdeMRIRICKKlYHRw K+ZeQtzPeL7i+qwPQNHr0E+Xe1x7Q2xDfMimctH90b36XuN70WmDjvviNAHsCBMxVXvI9vl86F+Y EYJKARW2MabRZmYKtv016NpPwWFmfXLYHLJ30buYXeaujgl7Ek7SB5mD5mTHpH284wP4AfG+/auW 6y03bPUQPcVMmSRkCAXWDWGrriqtwCwooG4Nk7EWJdmmx6JRZHPDSP4My2I8NMNEV2ZMj1omY7Mm Y+gxX6sAAWhtTWIrGW2uPrg7iy0GOpnzbAw+cYOeE9RcliM8G4nWLnhO8kPVwLsgNvWohm24xpAx YUwa7xiMUSWOnrMwNHFhbjQrI4/RL8caTmMhNzgR4O8U1WgFqUb5gaLTACi7AJH6eT35zPbpfQaB pOWVnR07ADIdcCfEKFwEPpxGEQjQxJUGDzEs4QDuC/GEBf1JwMEaxcLFLaFXXVAV+g9HimX5X7UH WZVr8A+yPLauv3Yxoa/LzV/BDrX29mPW6rBOrEhaa5dCBfr7W3p7Ua0pfP3F+fnahw/tKqwQpbHO tD+TyeXaNtQG4M82FBK5OFaZDAB1BqksBIlZ0UWuDu/vS5LcXQqWhBW+1cHD1HTTBe5i8KLAZeAg eBwO+seol5iN0qvUTmZCOky9yUxKM2DGf6LpU1CFn/qrTeGggNTnI0k65KN5lP40zh9G/Q8nsH4I 0CoHuSrpul2sn0+HQgC52jSSDMeqtE279HGaomVLKktrJVIKdaoCFL7PxkVpb+rlUZQUB+eeRF09 MpW3RgUc3CfncXzn+4VbIg5vFId3qpBFIQUozt6KcFW4ioOG4pXFDfwsEFAoUOY5G3b81Qf/+CTs 1IMCU529i6NkqgemcGjSEvXe/UNEbnK6J+Xe+5jcUhvc9mJXRE/41tyjJ35O145lqN9bI/vg04AA Tzz4kpwmPwKdYCn5RL1Su2rZxbotu1jjEYUpZFieJ57NBPBqBgS66tlPJJ7tasaPoOs/zgqCdzLn RrD4u7xnuxzGm5l8AQdI5dBPCl0gSbXn7H9yXe6xbRt3HL8jRVISKZl60bRNWkcplB+0TTuWYtNR KqVy4rzjzXEeyLQIbZEMQ7taDhYsXbMoS9IiCdq6KJYNQ4M0Q9ZtLbC4zbvZMG1Nm7abgawIsPyx oMHgDVs7DR6QFAFSN/sd5bbADJN3PN2Rd7zv7/P9MS3lfXBTKa/r9ByCn6RLD27kW2knSfLsV7Hq tqpuD1U2W4VslwfZtVwNsq5i2LEpOGfseRoYN6wZbMOFC9Nq9ZZlXZVvzPT1WlZL/klRO9rPhMeW 4DCJO5XcL30X/GzYCu9D+/qfQcfEYxleDytDcq6S8/i0ddw6fgVZkVg3lM8d0b3+oEBQYjVe618t rs6sHSgMrV62RdwlHvYd8h8SGzYpBxUmntuRY0refpTO9nR0p69AoiwhCezD50jtoiPRtTcPZWTI QhmaipYklrjFHskjZSHibuY7RGejukN9UmVtdb/KqD8A4NAV92bzWQaWPdFd6Wa6M/DeLrEr8yGP 2FPtxt0lE/UHJCmdhhf/GewAP95/Be9Ci5BJnxh0kBk3K+aU6cmbcyZTMbEp007mFaaABBSDhDru xC7hXfnWFtvpE/JBhwijQkVgZQHPCXhUwELhocJ3VGsD4Kk8OWmtr92pWfK8BRdWdt5aSJPlT4sg 6Tvzs0W5Vs7VJsH8rZBD+1iWXafQm6yEgUE12Cu6XX29hb35kcxSLclFBgaXDDK8z+v3MryRIAmG z4gOQSE9oqFwpCEe0HAiuZRzNDToTROcSYthTdZwMAGnIT6rUTjBJABQcIJ/q7Oz88CBA8A4YB0u TyKaJ+TCrsNayA2kPlhpDzV12S0uBJ0BEqR+TZlHaG4pgs8T0WmEQ6NqbxYdP2zlQDst/VD6ofRB 6XPQ/xn6NlinCTaWTKQyaWrZAMJkQuBjjdF625L+xY1KoxILRRWFwnMgRtvbQtTAwer7FzMjzy1a smzH91s7/vjvLWM5M8XYKdOePvnUhqVa2N/YIEux7MTOviH8466Nw5sH1x16ItT0w28X+oa/t3nR kZ2JRNdQz+J09+apjvjD1uHP3z+4NCoEsoPHh1/CxWxTV8lZtQMh5sH9B7PsZe55pKBF+MN65L/R ytEIlmksc1EJqX4avSoI+B+u30lUZrTJrdA4l2j/AO0vSWoj8jC+CM3sQ9G8D7pFY6jF9InGNkZA OYjb3C2r5vqZG6e3rKr8LgQtJPgLeTKYMWLhFjCOjqFjWzkuZSIVMMKPqwxVL53OvXP0Gir/uUib JCllhlwgQOBXaW1m4Xkz9HH0C2KvnMKn+Qv8eeHjuIdLFQLFJST1XXaP5xn2Wc+r7OteYUTAQ95o W2B5pDU6rDZKyNOiINnAX86kL85NcUyJq8CHDct9IikIqYskSQ6MBiYCUwFPBU7TARYF5AAJ9EK1 GrgeEAIQ/RezmUDJ/MNaN5Bo8GTXU/QD/4uTNXemk7lQo3O39hm+64ZGexNhRSFF2FaCm/2qhppU UdK8cBX3GAQ3iS0a0vkWgurOTIMQKgcOgOBB4+Dv27ZhkJkSiwp1bVEvTghtZn8oREW3ZEGTeOnh nz734c+OvT76880NRNU6gzjS3f+Es/3EiccymXbm08v//fOdH1WGhtjzL69qlpMT8+3zf13c/97v pn/bEgUfXgkaWgPuYeC7b3o9+Av/YJp5iWqCl6hGeNcDeMVs8AklY8JgDHgl56meDB2Ify4SZcah 8sEF6ih6HwuIB3xbxdzVmiuUmatUIeEkxejuzu40StLdawxs4Rgtsskzxo3xm4StLVs1YRe3h6ug inEOPu2uk9vo75xvAI/gzeq4tiNZUkvaHnVSOxp+PjIVmlJfxaeZM8mz+Pf4mnCt6V/eWe1jcger PLMmvCV8LH6MVJJzSSFE8G8e3EYEjjgAA+mIArgXdFEyKgaDDNkgxqhB1zVlvGJMG1XjunHbmDMC xk79owbccE0xfYJOvwGiDi3yg2EHFikaf4pLeKP0gsRItox6UR6V0ASaQtOoim4jH21g0Gu7mw82 M6PN+GQzbr6EpXx4jseIl/l6zsHxhUThMvMicoU1WV5fK06W58vF2bIrK8vK1WplF92z4YUQ84/p j+q7dfYlHXhc3gaxMTg4iAdxmaYZkwiQXc80VKcFuHch4nCy7GB49cBKIGP1DbkOPGyBxMrwcZJM MJk0crUG9TY3DaS0i9bZxq4xbx58+Z8Yn3v2131dS1tDYjL50GPLvnbqyCMbBtL4G+ffxvxHN3Hw hfUpOxXbE29d88ip0/cLPXth9cMPZj0cECqOupm1C9pK2XmqrA5edUXlrQvMFRsiuuICSxEJxVKI 6olIVGjE7Q2t9/KuJIlKRxDtLfZvSKdGDVd6PEzRJUfyviAzHokiEzauq4t1Mw5KLhsOvJBh3IL8 ouqKE3KML/D19TCMQkRkWTpUm9BxXi/pjB4X4Tai4jJM8VBgwQyjtCSehgY4M/QXQuyeDrePuzh+ nOftHpdqM1YdblZ1Br4X6WSKxZlcDcgGgIPYuIzsB9WzIyNpm4bIw1ZPumQ/7XmaO+qp2Gfsqi3k 7YrNIFvpjFnj3Lh3k3VcEFYJmNgD/hH/Zv9PPL/ofMUWqvacxRCCiPEWqF0EF1yRJRvJN8lO/+Pk KXISnSSvCZeFdzvFlDfSJi0Pt0aGY3qbslxr1YfjMEz0dMXctxbvwl1dcVaMI9GQCE0wwrGSUlHO KGxcmVIY5ZOOUR7mera9J03LiyMZvtBT2F/nI2QZ85PF7HyW/kGqDHCsUTzKLh+R/BUmm1OWx9tm prwdBFkeOLULJsGdXJcLRlxHYnGQKhz0XcaT5SL4M7hz3YjDYMSZr8hYt+NGLpkJ9TBfapi5Vqis OX773tt7NwIhm60ADnU3GEpLt/j5XA+ffdTeumL79OPbd61cdv+dd/DI+l+dcEF5/9apES2ULL+P bw5POBu/9d4HfwFFrwNejrHTKIp0dt+Cotu9Cvid1AASREG3CLrADMZ68wgTQMP/qK76mLauK37v e/Z7z8Y8Pz9/x8YfiZ8xGIMJthMTGr8CodSEQhLaAJ4LSiJNnTQBVpNVkabQpVlGWwmUqeuIphBt bTe1fzSlTutUSkMnlK1ZWdE2RW2mNqkUddIapmyNomkbzc65JltruO+ce9/9fuec3+9whCjwgIti sRIV3WazgUZqfJpNJKIiciK+xtEii67QTzRU7l1lI0C58jZ6g6G1poYFBmTQYEFoVcVikZk1wHHL ytL/wbjOOU3OQjjiQyw68dVNVFeUcBE9giasiCHxnMgTcRyI41nRIJ4y/NywaOBxKRGOhp4YRXN2 OIIBOCeqcFowezwtCMg/oUmWg4FvQnh8ZRVRvLhcLMa3sr3CTtHcda865il6x8m44ypv9Ib8QNP8 WZfuzwZxV+aufEoKIkQEmYnFUqx5X2Nzyid4TcP2x11j7lFPYZNIeZMgmiSL0fmwMMM9L5y0PKuc qPsF95rnvP1P3MfWa8od7kvero6L49IknG7G9J74W+ttEZBOrH2G403oJwL4ST5j6uEeMg0Eh7gh 0wGuxM3YZ7zz9pdML5kr0nnTOfNvuL9wNyx3zA5pVaREXBW5KZR4d3NwaedEQfy+wUGSLidu1a5m 1THnMeeC87rT4HT6/mig8AVXAUAMSFHtKD7Se9Us3vG3fBS/iPiB5Ir5slYXnXAdc826eNcdh2Na oklpTuKS0qx0XeIVSZfgJNI56YYkSK/KTgOZQbvim3Q1KevyoMwTWZFDMn9bpjLuxAR3KXcFujaY C6QA/etTSFumiiDWgOcrCDQlNKl4yQafCLj2hBO4NqQHHYA8AD1ZlsNu306mirRruCwQynFTIyw5 wB9j5BeICKvVbMla9ES2FoqEiBPLilWBMWLRV635qu82auZqzVytmVhNl01Zp+LNekO2bC0UFgq+ wdJHRkbsght50Db3BoKpiGBaGNALwoFwjR46dHL0RCLovPLTl7/4+1unL6+fpL8yKt6DmX3HuR0f PPnkwaccM59R+vEXVPzdq+3Dke3608CHBgjhjxqfJ3FO2vBuLcHwKqEj7CR0dGxfnCqyQCW5gUpY pyrc9V91FR1UVpnrM5CSBYQnE2CSWYpoATch1gZrhfoWVUEiLbm1JWUpt7KmrFVBaQnp9LJyGf+W MfG9D0sXiJWNITBUr2sQIjCT1ECZI1IBPZAyXs228ZFew7yRtUP9GuPXspxoug9Bn+ADll9ZQd6K 7rjzudC8cz7Kd/Pdll7vCf6ExXjaQFsSx8Jzwpy4IC2YzihnbOcSJkWAODXWOBbn/JJcDkinNtNy QKzwkh7cElgIXApwAVtEc9P4oEKVZGODahMk0ayAgVfo3jdnIeGtcHcXaWO8QhW9NtZAVatNOWW1 0gga65vj4ykm29urMperykgrk7rLH07NyRRNfEyelJfkVVmQvU3v8AIvVhlUsWqU/Wtguiyz7QDx efFmCVAoB2C0XurIrUNmCxfB8EfV6h2uqOaMaq6Yn9Q7In66gToINQQKkCSbAyytzRlOg7ll0rYt 6TZIAVkOyBhTlTBB5udsc9JX/NrOfeufNMQ6vYuLw+ennhhuTwXcbflgMNqs+2/xu9dfmd7cFInE ug9wo70dM+8e7k5sD6TD37XbW799tbMXzI888FUP/2fg5DvIw2SEf1H/geoafDE6n+FJQilwRxqP 7ONIo9As7H0uZMhtGyhMbDscnSzMGmaNx93PeGbTz+48vmu274cDL7hf8MwPVAwXjGV32fN+6v2+ pcJq4UbhdsG3KeRsU9KOTLBg/KWUz+R8xMVnwnkf8XapNsUq11pqzCaT3e4wSdMaVbXKvU/LKuCQ hp/DYcmh1GvUmtyC9rp2SeO1Cj1zfjg+DckWdNVrsa+6EH49fCnMhzfGMAlDwtBX98zlaV6H1rwO TfkmdJ38oIM6KlTS7RMSPSaBYoNppLQw30W7KnyrbvHmzS1eOuid9nLei9wfiADO1U864JVZEL17 6J6mJmv/u3wS8C4Azyzp55N6UEnSieRsciHJJz2Ir0kLukQynW3mp4foEJ6tFrwVlCtlxcGUT8vY BZTburkWHGlIC8ZojNmge1NqNkYHYpOxpdhqzBCTsSe8ulNGlwflb7qKASN2OFRIFvTCWbhzYwGH +mssqYI8+5Me2qPgoJ7WkItaXZOuDyHYV+79Q7fhOJcFiYGL7dFV4S7q9vkczbUm+UGeG+Qp4RWe 4/EqvXUpJmFWHpdHmozK23hG/onRwjv0KcjrzG/MeOLxu+gWEMvXSutMWYuXbirxqbusEi9h9I9P KTeBu0FCq6xtgML65wgROWWthFlvEQT2h86AEuUPw9fDHOBE6c4akLI4tmjXNWgpoePZgNxCxMFC UcI/87ijffvbd0XS/jq3hxqj2tbWttZUKy88GB2INmuN0ce0IT/17wj4SV+6P0Q6aS5EHjDm/GQw 0e8ne+NDIdrt6fHTR+v3++lj++vafdDdt4Psbs2HaF8+ndG5rhDE8Z2GDj99pGWPn+xr2BMiu9xd fsIQROmI4/buP5i3/+/XCI6PP1oqIthNMWjTzc0K2GhaUbPNYBBvqCx/GqFRIKAYBQB3MBKIgENb NnIoAZmnm/2xN5hWpVOQTGW2sVF0M3Rg8JVO1Uep8PUa1NNDoytnj4//Oi7zgpG3xr+3ffnl7oea guGkf/L3DxQnvvOzf793oq/GlhbHUvEsdeYPdacGdx/Y1fbVP1uS7Ycull9rS53+jD7S8OORHy3r RsHk3mQ2Cr2T0285olmHLSQaeKOpdnLv1MFT+7dmPB6t03Qw2Brc8jh38sjRM/s7S0cXRjv/83Tb sJaM7DzWm3K5DAD6pBaC05eQzWW42Q1srNuuo+MqZpuZAaHZE8G6ZxNWPJCsMZ8A5YbOMjyPjEbq iSJaBrEhGk6l6xM0bLBYuEfDbI5wwoNzJCr3/lXGVlDulvFF4r6PgXJLtzJQZvMlKGRhD5oBalUo GpQYlHqSAuC1pnUTjE1nSL2trskgglm3tGAuCKh76xYY5UY+yEirsnx5q7Icr7asQIK4/LXccDil okum2RNWrE/BpDil7b9cV1ts29YZ5qEkyqKORFKUTVKyRVKirQsnynEtS4yVikqcZHWXxGviZMHm Ru0uBXaLbWDAsOzi7SUvQ6Ji6AY0A2JgQFHsKXXTxME2zCiCYA9z5wFDtgHrEHRDtiw1ZgxpHrZE 2X8OpSatYZ/z+5CUeMjv9ud5ar88tVye2jKv0iWVLql0SVXrNWTSZZMum3TZhN3sULWB4j+XyQEo Hlwlx8rleq3n2tS0e/UmCV2wC2gjNyXKKwBx2qvUvVKVr7chNwujwthKvVMPXqpv1LfqAZtDc/V2 fZEseXVkDKjFjLQeEDwpWy5m8rNZvpgRZ3NmMTO2Hoh7Tq6ad1qTmeoMMvJTDN0lxCpJEnlNtSId Hl3ikcAv8hf53/FBnojUaJkxLUcvz5Xb5cVycKXcKbOXyggcq7xR3ioHy+3aa9AdivdJoCTJ8qE/ gy8TJsJeGpLr0saQPHwqFcnUcGiAG02PDYe0YRQeSIVHiD0DaalBLy0zCwjEyyYWTfyY0JB49VDP q2tg1rQ55MK0NYTVidpUfxE6RnTo9A9ahxfTcpwf97pPD3oTfECfGd/15dlB90B3955cUhX01GAl jhKhcw9f/Nb+45/zft795QlDHbas/Jh4GM38+PnK5JHu8POOblkyXz8e2ON3jwzE8gYMYeBLlMmy z/iMucZYYAQjBM6JGIV7zFQJkk2VINuU1UAEHIRqORS3KPAjpAskh6F45wo5OxJT+4oPxXuXe3S7 1afbzbco24x1YIByxDxtfg9sOHsaONzmEEeTLEnkV8kHcFlOhjR4E0R9c0F8128lAWT+CJQAzbSv E4z1mRAzKAdMOpLPufzss72i1fILT6vVuHmPQwy3yrHkSxnGMLNhmWzvvjdMroxErFyM8iHGEtjH KB/Iznw+qIT4lD+wctWnkJV7ggN+jwn3/u5mc3OB9iM9KmgdC7WtRatjrVo7Vsiw5izWI4NFDHNi YpLO9d3+XB7359wonT1HS00CQeTZbKyYSQAt8lrLyJgzWMNyB7biMkwWh+UE34mgiEs8eG1flUye 0KwGvoJxTItZqme7KllLTe2e7KhoTkVtdVHtqKvqjhpS13JrP6N0ILe9TTgA1rvtx1RwXtia2CMD 3RL8ANQX0DJgfaIXO8FH5A9xTWGd7+O6WJqeLpUa09/VdrW6+/Y56Ug4kxouxFEydI4caJRK013z oXHcBSCnGvPohVc+YWiCtciwjz7fPYDOh84Daovoek/nowWZNkGyTt7fvctEoGnRg+etPjz/5Mk+ Pn1s82Q5pq8/6tJLoHifXgLFX+glOrkkQi7RGa6YJ3jFBViA+FQcSr8jMpXtzQpR65ubPVjadh+Y 9g3oXa78NIU4DdnkSTdr1Zi9BvLn2XN2x349/vrIqs0Z8M+KHRBhZcsOpAYKeaOVzxRmNLIlbl5O RUpa2iji8NA6insxkWFwGL5ZuCgjeR295DVK/mv2DlYDjq0oKXi/PmqDFLUDFLWWrncMJBiobawa O0bAMMgpxvqjD6BjhBOMtZL9e5O8c/vwPZrEGodEEsUah8X9X5y5fegevH0IW+BPzabPs0vcZvoy xdv28kkRBNKVaJRK2C5DsUFFUhzOxIWR0WFBH0aZeJqkHNTvX8AmoIH5GGB6FWlfhp76GG4KdqNh AzxWfrP62c/sMlNp6QVTdYYeo+c8PVyyG13jwZfu/n1vLjcRC58YPfEy+8Of2CZFEGIkhgli0L1a 4Nc9/Ngpav8aHQ1MICDREdERVggChsgI2eCfFCOk8Gw/JEzlHR314kGQCiVHA4ND/d8ZIuBy+jnB 6ecEhygp+QAoup5Il0Qk6cExXkmNFugXkcj+C0gLY0wVsJeYomlhqsaMaZjeGgZIXongGIV34L03 eA7ekL1t90LEQ3tjY4NE3SdihL1xA1QT8AnUZXzqEk26Jri6yyY4EcHvjyKv8J1oB18QXpUuJF7V L7pv8ryrualT4inplP5V8bR0Wr/ARu5mtnV2JfL9+I3ADeEOe0fYlv6dGGhKTbWp142me0BY5r8h DFTYkmiMGmMVt47qYnhQnEfPiceMYE48gU4It8UPxNAz0if1tyNv83/jQ0pkSNRHdH0/u1fgopIg x1J4RMjEde5oYD54NHRSPCYdkzlNGBnJ6EfZYE/2K1MqxTQSA3y+Cs/o2xjhM8ANntPyGMNX99IN pukGHvptquMkNFMdh+K/VMcdx60/zjU01pA8swkGRCONQiNN2psXBcRKCVkWNT2V0RyIKvksz0Yy PEkq+dxUvtKqZqZmmAoTBd2xDD1pINbQIRuOIzaJEIsMxtBlFMyzAi+KKl9jGGUdve99SsW/jUZ5 DpCvaSofHccrmN3BaAvfwuwi3sAsrijKRRWpKd1FLkQbxqpUGEd0LjkbzpYTmnPQitNxWKddd9fR N980X/s6pfbS8gIQG9LlYXH5PinvLUDi+TDmNMihZkMjWyZNEQBHbDTOxh3Vjn9HvH52oFcwcILa cwBxG4kb/niWHLseDp+E57O8vLS0wCwsowX6wywxS9CsXGNEoE0S+hW9AJ0X/I14ALyC4LLEp6Ju lEySK/hTxJ8wTG+AuhCw9iF7EoF0SKRnqU6O5avmIMeFwzLtaYjjTJFmBRH/UfxcVXsyWB25M4sH zDF07rmvte7efTE7bmlPd/eNpQvdf2jOoa5zIDcYFeJGarAkITF07sHSH2YSGCdHWMNgnek/d/94 xqzEectCg7LyFHqpu3WyriLLkqKK+enA3osH01KOKM0eSFgCKM0germfrxSIFzRfJTGHwohqBqKa gahmIExiNpENKP5FOwzcj1CYBC0iGFD89S1yDQ79CsRhAP7CjAwCEZWTVCGSg7BAJGCCNBKo3zHY pGcQbzzRNeRlmpKSSeo1cBnDhBENOoiSBVETITflhx7sixct/NCDsTL0keDfBI74OedqR9lQdpSA QtJL88Akmb3d7vQkUtZiX5iaU5CnzCltZVHpKKtwYhgXM+HZLCpmuHwumY+15ExyBm4pzPEMsmK4 9zGYxpbq9GQHozmM2ngRd/Aq3sEhvDb0RGzx43uz8TioLKAlRNSO5pSPZpM+Ms5okwe7zaaTiutq qiAhKXTuf63j9RGaQwLehYN+eqYuwo0H/s921cW2bV1hXpKWaEqWKEui/iXK+jNNxfozrcr2aqpJ 7MSSYreJHCutM3cwlq3JUDtDkiZLE6Nou7UrNmMvexjQbA/BgAJDHCAtnGLdjGwLVmBBjC0Y0D30 qcCaLu6AocCaIZF3zpXkpNgE8fLw/hxd6n7nO9+5whzm/tLOIp4GrTYbBp6Vx0GP1lGvZjt8n8UD xePDHsOOZ5zV6CwtV5zozJrozMIeI4qzJsqTZTqvTIFSpkApV134a9XOumonv1Q7DsD4j+HDuVUR 3VQ1ulyjy7UiHKBhwY6ihMvg+Y5hwXXFIDqG58+MCE4tsnScRR9FB/XhoD4cCuZA6kPJ0kS5vn2j 5UMZQB/w/DfDglMVtj3+ADAKfhTZl8nv3YeCSpk8VDdwTqZOpusv1i/WufqsaTLnTaQt5rF0lxk1 x1YGM9r8PAirhxv46SS0HcX1FbMNdWgB7xq936RVgraD/DFwD94t5i7zofqs2ZubdFDEOxSephHN hDDXaJ9WLNOnMn0qV+E9PqPgV5Q5+J++pKFBDZwFxr/oaLE4V8Ucj53VTgSB8SUdrVYbc+3Acey0 EuycXvAKDH3nW+PjSMqA3rWeyqG53zIT258ye+HKwJXd/vRdv9fn9XqfaH0aASM4ZN5s/FPmVgDi jQWQm1oPWW0QRVDUsHedfXCtr6iGc2AYlr6qGp6c6nOoYc86Z7sW09Rwdp3ruRYrq+EJMIwnY/VU rXwoXN8jqMWaUVL7BcacmJw9jAeTSFtFi9nEd5knJ3JZr0dsgPqUHPFoViFLyprCKutEN+xFdVCL P5EtkqXiWpEtYp9cO1yOV6uR2kyNXamt1limJtXYGsT1ey55qLYw11hnj0DOuuhdJ4uvUUnaVqRQ h4Dx8JPWbewAalMIcvyM02+NJjAqeeDPZdqxr9HaC+Soqy9utfckYsm4NRokNnufLREESpDGtJYo ZeY1Apq0QSBfgAaVPa1WdjtcnhZdFDq5JAWMASnH84hHdrrNJvP/r3wKZGaxd9e3CrPn3cd+VNm/ HJV7xOGvNceco1GPyAdSs/rxKsu6RyaauWrJ0hVNTw/rB3f5cpXm6HjeT3Vuyk5cGntv0Z4cWPz6 S5VKfeR88/SsIkficY8Uc8yQN5cGDX2fRWtWjg5CJ2SlZ6AvZ4TSxab7yHAgHg+M1snRn6Y7etjK MNy/gckK7A6T6ZTJslQP52hrE+xyDClhEJ9iobgqUEoSKB8IlA8EOY7LZD8OyFaMc7lDT2B8TFkJ jM+NJE6XmRBdHKKOQtRFSPWiC5UKZ7UjkNWWRKNGi+RU5DYRV6hMkI1nkUi6c7Qyy+V7fgMJUYKr D64EjsTt8bzZn2Ypl2QykBPv3ZNAIANEviqNH+MPCQkEG2SNHdo4mpExivGvMdVz1KYbyLX82+MC zZ4CZQqBsoYgs9gl0y5ZwC5Z1oeYEJ0Zoh0hOhiiL4q9aocuVCQTnKGq+tAjUdpSpTs5NwOvhcq0 RJUpyvkR3RjQBR3jP6vP6Av6kr6qd+3iiUHtFXha001r+qbOrulkATo2dC4kyGrYvs7ZDUefqobj U32CGrZNxUJqOAYEYQzGcqmBcjac2xNkYvkCfeN4LGa320SPHDevCmRNIHZhSbgk3BZ4YZ39wAio hVB8IKLOqAvqksqvqKvqmsoxqqSyKubxbgh4dWEIQh3SNo1yiPGHrXtHlWJAl0o7oUwDudfr40x8 wsd5gqTL5O3yd8IYonh+Gb7MPAENgJH8PwHc1oIQkY93PhIBBVL5xU8qJxTZZsk91Rx1GgWRL9fO nLbYMBBdEzl7pBOHWzcqs2Pnm2cPR3zBeDyVtE+TMy8vv9IMzcshiLTJRXLo8j4/xhkLpP0Jdx3i zM6EWGs70oIgA6mis1I516rpJIsFWj+PsYODaBhO7OTpNN6TECxSgmllRorfWxS4oLs6OO3GcZzn x8UBxJSfd1HEuawSVXASlW881QFo8nzYao2EEVg0FSG4IBfRHwHHxt7eFTf5pfye/AfyYffvQx91 m3r/LpJ93Xvlw+7XyFvdb9g/CpgjRl7nI7sBdpci5Kb7Qz9rRMh+obObXh4PXQP9Pw1Q5MkmtjP8 Ar/Er/JrvIm/ZzVg0LBeghJnd3h3xasdkL44qdW25lHTVdb6D1bWZp4+ctUa3n81wu9/5sjcB4x1 e4Ph4Ypsb2AK3D33a8bP5RmecXH5u9LdwGOPkB0a7RcCEA2TUG/ClmQTwaSYMCUddpfChIhfIXI3 WF4zWM4eSSEBDhq3xaMwvi5oWgXIzgfSBkG9Cagju+cMxyn2lOmceM52rvcl+ZT3VFCYb0AhBMWP 0R2UHKUAXG74069aSuipARDNAz5dJlOsL5XUh4aHPX0mk9vVi5iEzMEymxeOn7598fa5Yy//6aB+ /KlLrzx/4duT3JW3v3/lew9WLv/wVxfunymPv33+j82Pf/67L95agKJj+35zinsfsJZiSmxfG2vq qIGsmhcH8CaaEEqi1+ljFE51Ug52KjIVZ0Cu1zp6jfKugiDqocKO69d6eZvJ/z5wqwdLDpAfgwnb cMNkTlEWZigLMwTQCQwLym2LEi5NyZkW0W5sSDeBWDMUsR1qvc7ktx+8i0DMi4hJL5qiODoCu6O4 dVKOdCqtHGDCTX1uBKhYU2BWv8mWYojPBpux4G5wA3jS41KLGUmLMYE8N1vkeUtDVF8QRxGtJWm/ 9Kz0hoN/PU1G0+OjlfSz6RccL6S/K5x1nE2/Klw23xXud/dkR+cKjaETQ7wxSjIC16/2OkFW+V7v c4K4SsWYVHQ6FWb2sL1aP8cPSsMEd8KacU8+ry2fi4irIrsgrohXRE78h8I618kxI6AoM9GlKLsS JUxUiq5FN6Kb0a7owsiNSruYGZMoK57cwoJmC17rpMNTktqMyNkk1D8U0UpGN/cIiaGkNZlN6Oa8 QjI90BS6hxWSswwqDLMDXSDK5ZPzzPI8QJBLFNyodBCHZorDVEfAFOTiowKpq0WYIIH0ttBhiT85 +ePpN59b/sHSO1PD/XlPqdJUfMWU0y3Fwt4EGeq2fefg4pNPP2fMZTNxrnTyr2efP/Hqna2fXXTb dzXvHi2EEwkiW3KL3DcaWa/tYvOdF2Mjcwe+ef3Pywe8vYBlZk9zimcAyyFGI3faWPYnKVUm3TLe 3CZiDhMKYWLDmsSBIuK/fJd9bBtnHcfvd+f3tzvf2c75bN+dYztn+/ySxH27UZobfVnbrUoRaG3G vIS2Q4xVa5KCtmmUWqC9VLw00Gld6LRUgKZJE+uIVpqCuqbCgqEuaxGjCKSy/RFVHdRsTGVCq5Ly ex7b3SYkIt09T+65e+7x3fd+3883RDkkRDkEj75Dayl2/nOSSDrkJAr2oGIFd8rFq2ImJ7sKI6Lf HWrrBiWD5N3q4MGCOU8V2xbNfKJISmiiSHSYKBINKryi3i1wUKbIrcvG9jJrlxvln+WPlx39Sn96 qLjGHBZsxU4PFzebO/ntyoi6PX1PcdTcJ+xSdqX3Fb8pTCgH1Yn0QfNx5fvmc/wzynPqM+lni8+b L8ZeUF5K/tw8HXsNV/BX85p5wyzq5f25/fnD0lHpaGS+7P6CBL2eUEF1G71QUF1GJiHzqsZllAKQ n5XJpWS32xVKJBhNCxHZVRkNpoAdgwacAA485FfAP/oGhOj2KHs2eiH6XpSLCuRodH1p/UFaic2J yW2tJbNO7Jl8RESPa1tDS0SPotXxZjmbl3qyPX06k5dwl4tldDAiBb2tPYLZWA9RfGtMZpJUQLil tUGqNVIJsRAylL9Xc23tYUVE4a3iHpRrW5cHpTWpiPylp7Y8/geI/MYa67tt5XeMPUPjx3+6/zP3 cidufGXnYDKXE/wWou/e4Q/Ovws5XU9ml6rwMvr1a+dOz9cYJN8gyusUKisPJzu6yhdpjXRpPWGD wqkhaxCmyvpU8tW6XKt1iVQj1ShMJKZFiPo0irAaTbz0RBA4ORb/NYpOZvpQdqFhY59x0OCMvFsO cFisFkjCbWG+/R8qFZq/7ZJo198zZLo+vHaf96CX9eIEsgtXSgtlmCZYssaPaKHEzt9pCCWdU2RM 04qFj2ES52eqQwsL9VsMmbD3YXzjB9lB3mZt/tsOt12E0SJopMrRvPhExjD02/tUYwPj8xfDEV0A h9zwgtcSAhAY4TjGjYlw1AW2C1wVrQhFJpzVNE2Hhj6ls4wuYEKc1y/qTn2s8MJDVFy3Mt7k4sQk VZbQmmzVw+0sZzHdgoeMO4l8h8YZJXCH1ol66aSuDs91Q1qH6OCu/Y+u3rwim9kRFaPlfin4uXXL 5qbeuM8ZzCia4YMod+LNN9eXjFUbI4X7lrfcZSC8ZWM0T+0+/tkkATjUy56bi+yfUC8DjhUdvRg1 qpeaTeiMBZm8f5DJ+wY+oXiMADlupPlu+eGJkQ6ScX7A7TH4tEM0nfCoE/Y6wZmrAkDRHX9Yhd0q qDldgTFlXGEV0c8MNet1ZKAqttjU0UyHiESQ+xbeWhDeajvpLXUMpnnD4yjGVLHiZIsD7vY0cfFO JzzofMzJOnNF9wYV9qhfV1k1J/qBrPADWyFq4fnaoOIJ0RRjiKQxjNpgxzGb7baJDFWvk01oNutD QlO0cAAXRaRT8JbiJVYUK7bfKuX9lhwZCdzTd0x4Ouv0uX15X2GsNl5r1Fx8bQ50+0ksl+eD50PN bDP358yl7F9KVxxXMley75b84lCpXnqofKB0GA6zh7lGtKE0Eo3kofLhSpAHnvVx3oAr6Su93vv7 jCfJxSJiMpaKFxKlae+075h+JHMk6xfNYL60tTRcG609Unik9EToxcyJ2lXuSjJQ8AyozBlWBQ2q wMIcmLPMmcocKHa4KKvxMwlV0RQQFB2fHBmMn4mRwV5RzGaCfgdv0Mapwu+YSrU4wDDkoSrfisfl OW6THYlVyYNl3xABxAvpt9Pvpbn0HBex/eM8jPHj/BTP8XOwyo4bSryiecBTmjFgzBg3GganG/0G a/wKdGYQ9F/c2f04trUmr9NwtFRfv3P2ZhrqI1YVuXL2JmAX2aC1iONoXSQ2LQpt5CI7pFIf5rRs 0B8JBv1Phipm6IDQHJEZ4dr1Vn0ShNb1VrtPu20RvVrRvcEVjDlCa3oyX9B0Iexya+F0ElwFTxI/ YTXJuPPOJHQLO8leeC/vDfeHwofhG3lHfQQmGfxU8WB8BmbYGW7G/+PgVHRKmUpMJad7j2ZmygHE YxMmiBXgaf5qppr9bulY9ljJWR8h0BzO63HLm49bYPssFrcERohZn6WQJBH3WRU8VKKb1woIqjgU 0skOEXI2YdEmbmURCmYlK9NuAtj8UrJKstSeS2zPxYt4CxFvIVolXSTXvG/zPJ7GW5wQxPsEyQTv 22IQ7xPEc3CTw3RjzP/3h89mhJarcKbjZD2xnp523aIUlQnXCFUhVPVlaQQgJEZyKjuV7nv43k13 69roj86f+cYX96ajPcF0Ovn8ro07vrz8t3L52GOrttXCghjgTiy/fuRrW8tr8oXKHbt/cmBa9Slw x/d+8Hlr431Tt1k7Jp7t4UMy1rDIzX+xax3nmAQsdWpYLmWLWMNSNilQ/oBM3CsQlcAp0a5EjUxC bqKGJxHno2GBPIsAuUbye0p8LOKYg8QsAy50sqWLC9VWs+Nhl5H2q5+uT/GeALGhGN1HP9HH93H1 VYpT3U6c8FyE9Mb94OcTEH0gAlsiQG9noxTx3v4EOGk4cHqIzTmpCzpxgf+kU5CVUv/DzkenaJSQ UsmP/c+8uEAy4dLFen1eWBCadTQYunJ8rYnTTBAXcHvAGoVRlh1KTYen42ejZ2Nz8atx90wKDikw HBgOjgZGg/+WnS45KhsyF4vKcYUDsoskjgMX7e+slutnWXAFVpJFxy5E36aMdX8k8Qbjn4NrdklH 86xUU6+k2BQD4HA4s5HtEjQkYCRBekWaly5K70guaSz50qFuNFgiX/taoX4d2aGFdWItM7S0SKxT aOHQIqB9MpTOBvoR9inzT5pEjLVoJkyZanWNElffynBm5Sr0zdWw9dKlWj69LmxkGhsqO4s/XL2/ 3FNwnFv+46all0fWFfK7dtdGd7NfTcce2Nx3P3FG9uYit8Q9zeTY/o6qYoZN1OPpYLlfz5N/9Vs8 pKudhLloSzRYKvRERUyS88Su3MRuFsXO9ZPkRDHbjZ4hOefy6yHZlSqF/G4PfsMnSfT0+JjqZXMB 32gb4a+1dbhg0mb+svlJjtrhtj1j/2W7amPbNs4wT18kj7JESrJEUhJFWTp+wBLpRqJtCQakrvny mixGh2ZLBiMdtmLIgKGxgbQoEMPaj9UOsMHDkP1ot8FBgC7dj2FJnDhOjbZOsQ354zY/lqANEGwY sm7F4iILsqJAY2/vkU6XYZPNe+9O1PHjnud5n5c7xoU5LOiCnKiSHKwaLClse2JMsYN8UCFdjdCR 6lssFdM5NcVxhu4jT4/5haluwN3e97GXov6QfkU7PvZSKdPYxp5EW2jEdRj4zRoFYgdA6Bsx8IPr NKN6yKRVhW7S/HDOjDSFkVJb31vaq0dVLn2AVp7lAxoxK5yJnmQ1bqcukCK3gnZ105ghBFISfZ4E FrAglHXq/RPMOYSS6BhaRO+jCFoJvdUlKUWtplIT6R+nQz1ozqXDFHT6NuwAdMa7s//t0yAVAfwA fQzFWycA4ga98y+cGqQOMV9ISoWkWmBEKS8WC1DGiWOQLaAGmPSBmPFLyly04j3CIfg21itvoxNG phf+VrKcLZmJrU/qL57YtX+qVhjZi5481Bn83tOtw+FTmzcW9xSkytS7vS8d+mEPvfrkjjwimz/r TQzvC7FfGQkRwKgEGN0AjOqhqwFGl3meUVOxzNuAJwkOHY5Q+M/nGZCwjY27dzsuZAQXNmAbK0/I mM9zPD9Qht8JmSzd30w6Jvn1n5SKhfwZ4Lfud3S6zvrgf/5Tvo91b6+Lt/1t5VNfxV+Xv6GEQeM+ uCB4AzQLfbPfyygZtcIP4LKkp6qyruhqm2/hdqole0pb/TI3zu/Eu+Rdyrh6lPs59yr/C/W1/OLA r5g3uNf5M8oZ9Y3829wlfhkvy5eVN9XV/NrADflT/Kn8uVpf5BG9ytKO55p+HHwiiJodxD17gmia QaxUgihJfux2lUIzOXCCmUbToWPRE/r3oz+QFgb4NtfETbmV/31srfyBys7jk/KcEh5J7ZVDaTmj pZm8rjEpLGnAgle6NV5VdFlRhnic4XmcV9Uqz0GPY2PRSIQDS5ZOgW1iYqoiyCsI0tMRjERcxYt4 Gf8BR/EMn6cgFrsx9zR3hXsP2DvDK8fVVZRndIaH+02mmjy9b6Xoxws7PBouxz2GX4NyaQW9sywO oN5A8DbgLBqXk+lmmQqrIg5CoftgkuqFuil/pADm5QfqBo3T8kZQmvhYp+o6F9ipuagj+51B8FUb SFx7vIWMAq596pEj8KE/iKbB31zCeravA+L1t8sQ+Sr4ZSgWwKVgCF2cbnE62BQ4UJCRqJk4dChd 7g+MRDoNrsEEW+GV+2NQAaEKMgzTMCX0m4Jp99+4meOEgSYabGYqha1Ve+tK1ipJO8KniKFXhrZi ob7RYoJPCoREJG33w0/C0WFX5DlgS9+/7kQvAltq4fVtthhlTUqEaitUeRnekLmIRUqxZIzCvNNx 3VxL3LwOn7XHOHOFMSB77qS6Jxf8ksJvoU4CgnBBKxt8hLH8xV+uoRpznCAiHLeQJQSr12r1ctmp U+qAVtJrdSY7k+LtSf9ikl91+G81fz7lUJAWOl7WhAJTIqbuHHGO8secj8nH1mfkMytOT7iQ9vzz ruVLzbLj2N8eLipKKV8RnQg2ikbNaBnP5s7mzspnDU4gI9UR8wCzD+1nx7k91d3mfmu/Pc/2xJ70 IzJvzds95zXxFD2ZrIpXyBXrHecauWZ9SD60rjslJhphY/2RHE9Yk7ditpd7SnxKmog+wx6Un7FP CgvivHxSOVmZJ/NGz8nN8a/k5oxwH38IvSS+JEWAE7CbhGDEAivEnKSJeqWs6Yxd05gkTmjJkqJp JSDVEmeZkExnul2ZVHWO5Xi2alsZ27YADcQc4vgMx/HgTpT+KiYZjEmlWh2SlYwsK7ZRUeQcBv5h 2IdVdBdIpKG7SyWUlOhIZBLgTSALimKppOtMiE4ipganAEnlVfRdhjAc+mU3aXXhZqtVS9AfJp/H UFOdv7jGPG9XVhDX7e/m3QkFnVbQW8r7yh9B9X5SdYHe+ct6kiARNp1SUYg3ySoSGYPpB4bHu9g9 YqCu0TNCBhiki/yM6XJvAs05sFNYZyzUs+5ZIYvmfvipdZqlwpCfsFHPRowt2rrdtc/Za/Z1m7Wf q3/hmjYeDE5OKerG5h0oeqa2uQ1TKkzA1/IdFawUPSjZKdVV6qc6Y9RijW3/Bf2NoM4C9gcqkAAV 4B7JAff4zOD/E4b/bVmRG+PGfMGYQpOgFNO0hJgcpFphiJl4hxYmSxDTVCeKrdxjIUPDvQu5FqGh 3x+d7w+kg34C5YgFwmFSnQhk45GQbI9RJRzoSB/qQRr+7e+aspkdQxf3ahnu+tWM2ULlr9lb79l/ 2fon2bpVHB0DPYlohVJt8x/o13NjuUSYkHBOrGT6N++jz4f1tBYipO/ow7+Hxjcvh0PjjT7qGfMM E/4rKMxo+P62Z4wbWG4akToDS7mgMxfraTE0Cp1lpq5JgdC4LlWZNb/xC1wqNt251C6MFvoWEgvS nDHXvCnczN0ybzX4pGNgIlTj0/i48NEOttB2koeHI04n2hE70qjRsVrNofa4cEA8IO3Wxo191tPN bvugcpBMtI+zs8KsOCvNZmdzP2UXxUXprLxqaIloUkxKyVpJLEmlmo3tnNvGYvtZ/vDwRDuy7RSq cN8vj6JR+iAvush1jKaMI4xDn0FzisWW47RbjwTNdTsd+iS+oq0FLX2mMwZwM5fNms2mh4V4vAH2 g2UVo+k1Gx5JLWRdCUke2NJsvDijTGhIc8kLldlKqLJQQRWFOE6rUb9v22ZjAt72jIe8aJQlCstW PZLxPBLPmuZQI55pNOKw8zIfzzVMogijriHjcLzJeskCKpRgJ1yHbgMkcEmiWdmJ1FG9rmlFHAeL eemFLMo6ZAUllnQFKVRX46LXVc4pf1LuKRE6QbOxshoaZhoMi75zwXNM0IMlpoEaq6GrTItph/Yv ldeBmoP/prvqY5u6rvi978Pxe/b7sGP7+SOJvz+fHTt2bOclTvwSAkXQQLrBRko96EpKKGgkiK3Q LRrdBKzdNKZ9VvsnnSptQqhjQBqC2kmdFlXaH2ho6ib+WIUmZR1ieENThvaBnZ377ECZWtv33nPP e8/v3HPv+Z3fuV+rr9XlhlpT5+pQz7Rir7aRbYFqGp1cqREiZRQ2JPTEXvWsON8KNCJgt12bz7rv yqs14uNVw9F2rZatgUY2pvJX7oLUYZYrYuWsKFfmV1bIsGJe6YDBDNopiMBjtRpJ1XNoDoLvGrJA TPGaBUqTq5ymBHrsVZBvX4HRSYpUrstWFXSfXHUTLUzIqHcqYpXV7ZZqhxu6EpEGCRWBMZmQyL/d W5K0aEAiCf/mZUnrIIEsaXkYlgS4IBgaXbJrsQBpNtDZyHNAGQ2ScNneGmwtyuATNBkcYIOm6HZN liXNBi2tO7XOFiq4WoOdpEKn5oWZ3unUSmanlsg5tCQ0m9mlccafubSkboPm1PKkwZsV8nZo5PFL tkfY8vgH/d8cP3bBgCGDv7gUpUyAZ4O/dHS6XIozWMwTbTxOoMmYk7K0THiOD19MBsMW1+j2raEY LvVF+nbPr+7aqjUnM55O/cz3xjOZ5u8jvtjT7/5821PDAExdijsvh2ZmnvM6uwGW3KFjP2sun+yj IxGHqCi1lZW9NnecikRYR/eL6w+OlCFWrM0t9BogU54KtZEJ2KmaotGJOI53Q8XgJoWogwCTzRBt RKQMkSJi3hDzyxvFhFpX78K3mr1e24CsNlL0cCrqdtiol/I4j+wAD+GXyDskh6OAUH/hIen5oLYC daGBDaS+6sv9Qt6+a88vkW/9X8izfg95Aeh5eQA+Uz79AifD8RLVHySpzv5e14HS19nTJorjWLvZ Y/ZyqsMb4yL2iDemDuCSveh7wj7DzfCHPM97n/PNpE+YT/InPS96j/tOpF/hX/G8hl7jfuT9ofo2 utH/Z1MYOImqplMpHhtM3UPofTrfpvcxc8Dj9eZSvANuSKuqQezVFDyS8nIMb07D6AGmYQ63KX6c AIYI1sazYa1b6lcUr4ewBd85Ht/i7/HUfn6W/ztP8/NVbie3j6O5eShsRb1b/YMUwFJgIUAFzu1L 42y6mqbSnkL/+eBPoUpVdwBTn1itza021mprkEkbOzZPj3+IqhONVbUFJ2QjDPgwfyRzw0ig5RMT 9aPkjOcINKifRMUNLm6Us8X+UiGvGJVsGceMpGvFF5yZTPDWdVuHOaTiVDTh5jzNb5YuPjX0ZDkX 1BJ8zxOR0eZVKeiRlQKc4Xh3fHMzj/+TTNg5iwBk3R0Uqw++cPob4+lUwSWNTC1QV/y9YatshdOb hLx6BE6vE5/Xs3Yz42YWmAVhQTzPLDMdCwoWlC8KfaVJtEeadNI+RhE7pc8xn5JuMTekjvapTGBa cdESJbLW7Sz+Mosn2f0sxeaspnEJH5fwPumoREk5ikfVBoCk0RFEblW4GpS26L4sjzp7kGUZR/Q8 yy7yPRZGlKQIzThomqEtFCNhq6gI5C3MJIvZnGA1yfskLOUwxUtvUyNIRAw1oqdp3LsAy+qdFHBO 0IVZgRa8WaWq7FRoxdprKSIKUx6X8pNWCtmxNjextrpDrt2HA7BWW5XhC3mkcaxidBs2EjOhQe12 dn7FjeU60Nx/tgcD+tExFYo0A/fF9Rs6ByhP56BjyIEVQJB0Mou4NGl5/Y9LLo1JOIh4c8mhMbN2 In5nya4xbicRby85QZQM8ZL0OGgCIk5hOljEwRA5NeFy0ImDeQJ49DOWBzep/c33n610+piEiUaN H+Mdh7YrsgV7mn+J0ClPOL+tGX3wfjgdOIgQhTbRB+lPs4eRC2XQ12Abkci4lajPnwiZbZaEHlpS bLplCSk0orMQalLUHz0VpSF7p3TJN/g6wPSvJdEvnhJpkeg4ZvCiAzs8vdllfPxKcNfTrciaqDfA vdC1g6o6AUQZfh85Ai2Qwi2uSQ5/Ie9yOtrxEP14Nd6y50meE4S0PTm8rbzpyGlq77RusVgtaVdy eGJg7IUz7OFk74GhsCBKw+nc5uO7D7wZiw0+M9IlivKQ2rf12O5Db6L19Q0vYBqtIMS8gWDNs32n +iiEqRSdRMCmCf+8Rk/jO+ArL/qsHkRQyFAY8WaMGJk1O3RhCdFdxEWyXz4l0zK44y12UPH4ut7B KRREv8PDyPDGxCM/TKzVW5iC5N8YGNHm1rDQcmulHa2llkv4neejPqtF4u0+W2LEr2rjL+wZYg+r I8V4MSBJHVwlU+iKHdv1pWd1YuuvwNZ/GLbu1Ls5DyAnK3MOtCToDsNKdlBS/MopiAiw84r8MVY2 avVHENjeJGJjJ0mtBLfCoYfGtU3928Go12IVLXYvMTE1uOnw1BA9nR0uxor+lon5rticYSJGHvD0 MPttpOOLLRC5hmLYdzlpckGJpwvINNSfQXyA90sKBEFzUZZNu0FY04HAgsR2EQW7vP6hHpEkkFxE zbJjo0gx7lBMRK1Q5DYlCfXN7UWiBuFPi+QKCH+9Si5Go2OjJG1CZL37Aenak+uqStaMspXq9evV erVOOPbu2exsP7Utq5dezb5aOp89X3p97K3Se6XVEj9T3j82O3andKf879J/yx2TYzhglpI9fDwU XewJnAmxyR4uHlYWe/xnwsloaUCh+6TSwNDOfty/TI/rwlA0g5yTkMxzCZpZprfomUQygUwBP8/x fVlWliLMAnsRUNU7O/bbMWpMVyKxo9FzUSr63bhndGwZ770SvPBGa/PWapVGxcC0ykSjYgBaBfCs Iq8BIQZkq9fnbJqxpyT0NIIqfblNJ3VXpZpKj1SHq5RJjVXSegBVU0MBTNhY6uWXgd/OodoUgE25 YHM8pF02I4mFbYScuQoF0EKcFm3hYqG/RI5GO2BJJgsTxHLio/irs8F0sdYc+HyXgzdnXrpl5brS gVTTGtkycunS9Hvzn/nWpow/lNOC0a5UYbrTS3/f1Bg8WgXa9T/uyz04quqO47/73AWy2bwT8oI8 lkwSQkJoQpeQsEoCSwIiBoJQUloFOzZUUQKMrSMwysMHrdhRMYMZZNTSxIEiCBRn2lCkqG2gnTZQ ldbKoy2tYIcBOoQkt9/f2T3p5SYxQOk/3dnP/M77nnvO73Xz07+lnK2P9UZ3v7VkZFJ0anb2jKfU 2TX72lf45+VkjsmaVRjvvackuEd4t573tFp6nxKpkJ4NlG9J2TLmx4X7C98vPFdofjdyeeIzkWsT 9aThqTmk6N4Md15E0t68QPYw2hsTiBg2dlLqhLsLFG/BiILVBVqBcHlbcT2H9Ane+BHxq+O1eLYd 7/CisXZnx4Zzpb67/tHzOPXzZ/BnLbL7uEfYhq43obBbMwZoX7Z40tBhnqEJCQl5E2eMv7NhvXL/ 3BlDh0Z4EhKj4fpKK5es7Xkvz19fDsfmdk/MLwo+OvfBHdl5BYvLsiI9bndFftGU5XB+7BmIjIj2 l18MRi/0TryM9I74t+102i9YHt515flrjd3PRZE7EtUhGM8zgCujp4rmRtG1xs5Po0Lr2H6eWtOv pHJJlbTQGa2S1upEPrDEbKGg6acafBzNQt9sMAbtm/QnyYfxD6FeC7lJ9ZOG9mrwTzAa1IKR4D5w L5gOHgezMPYn4Pu8hkTbSAtcX6dvGkcoyqijTFCNcpZ+mvL0ZZSBcpDreN44LY3yUM5EX64rDWOP WGe5H+Myxbg6zFtGq9FfgfowEOPaSCmQXhCL9mSss533DFmjHeR3tb5AeQX2MQ3la5BTsNdKyOlo n4lyOfBgzkTVb92PcjTK5TibaJQjQBXmXeU5GO/BHhehPw51lcfiuR7IFB6LNXO1E0qK0kSvaSdo lz6b4sR7H6FIfm9+Z/lOvH/e0wBM4f3ZCe1PwHtV/7O3PqgOFmvjxF2tCb/rFrWdlmpbrYsoZ5lx VMW4TlA63u9z4NcX0XBXmvU37HGasYdKUHeDJAGvuYXWaZcogL588yXozSKqUMeio8TqVL9HaaaP puJ9cd6Ug73PY92DLmRjXK2Yv4jS9bOUjHKAgc7/RZxRiCDuvgZyMs79gpus81hjMoN1fgoOYn4i nl/IZ8D3rtT1tGLsOfStBMugI8NBIvqfFTqMOTwfz7mDnxG6B4oSOghY90CxJHw/kmEScf4tggSQ CMYDfu5L4F1wF0jjMVg3AePTsY8nWGdYN1k/WDeE/kOfhM7yPS7D2bCOhWzmDfUB2gDiwGiTaF2Y PIwV9sL3yHtmW+C1WbdYZ6RE/6iw3n/O78k6ZZNZxmjxbGGDrFs2mcu6z1ILiHfIVduonHU2dNZS ij1UsT2yTUgp98P2KWwEUmugWD47vncp5Vn0yq3kQ9904yOaqo+ludph6P8ClO+GHI/zaRY2+IX+ Ip1R15LqaqPRuEu23VcccjPj6lC+jfXacJaj9HZ6RcgONVPvUAyj1TpntKpPhJBlu3SitIX6WDL2 vpttvxXU40YrPYDy340Oy9I76AWOEa5/KEVgpJRofxusBnnufGWzu0HZ75pDUdCbS+BhPUATjACN 19tokh4v7M6H9jlYu1BvoDLM05Q2elqbQ9vMVvqK1oF7xLPU4/Qkw+tDLu3VI6fO9dUlIaW+9iPZ BjxSCpvyW38SduW3PhU26bd6QpImcmxg/yziAwnfHC31tVcvX6VR2mWbfjr01KafZZgX5dRLpwzH Fo+0U8xJ4FjD7y/8Y52wJ+Hn0Pe2HO+UvfNbaL/aYn0i/HA7zZd2DcYCH/oPhf0I/DDum2PHRmuB udJaoFVbC/Cee831kBet3WqOtas3pvqoOOzLkmUs5XMy2im1N476aGbYn/k4nurbEcNDcTRWxM+/ UpJxUfi2YrFftkO2wUL4vRzE8StWpx5DD2lPE2mwS26HjsziPt1N8dpn8LnV1Kg1W7/TNgkfVKX1 0DwtHzaMuTizJEOlVKOSajCHxHo8BpLbeP+mDv1kXxBEHXcl/TLfvdlJHpBjXKBSvLPPaBHv6hN+ fDNl8zmIucsRV7CWK59idJXyw2N8Ys53kC+I84APtJ1FODZX8JrmPUJnvWLOOKvTHUN+xniTSvF8 n3hWkCa4/TTKqLMuiLwihu7SjlCRFqQRKCcLvV+PGJWLeBlEfATaadAD3YwK1UWsFtK6KuL9KhHP I4xCmivyCe4zKd3MpTGMnoW+b1CB9ibWeRh61YnyDssS+cEfKZqfjfYp4fyE8wRV2MtvMe8DKmAb 4z2IeMP7aYK+HaMRHBNd23CGQ8mDNJLzSM4bi0EM6pw6/sDG8+G21JBUMtSPqI771Nn0Z5jMTiKr gfNA7WNaqL2O+9tJGdp8xO/DiI1liOHVOKvf0L3aUZQz0d4MViD3aySv7qVF2imMK0bfUsxrxxrb 0M+sw5yTkDuoXPuQHtTakB+c4hyBMvTlkPWgkiYrb1GDepUazFLE5DLrVbE+02h9TbANcfNUeG4Y sVdJf3t+DLldP/sVe7Xvk/fYz/54DV5XzMMYXScvzukk8IVkzyx1I7WCrerHGDuDHlO2WwdwrlMc BO11vUR5HIzRS2gfWIPyaMifgZ2hOjWBT8BarH0QcreJTwVGvRP6DIm2ZrAZ/Er22eHn9Ndux0ix DlxXfwexBiiXrAOMc7y+hkrxvFK93DrAaOcQQ4C5iuJcKyhOy0F7OuY56kYK/Nw7lK2R9a/B9vRl 4FdkO8fAjbzjjcK2y/H5dq13o+B+V4F6sYcL8MdChyhSOW6dhKxTjiNuL4cvBagXoB4rz1PeE9p/ KNod9wddIT5zZ7uz7rzXwerqblpoR+pBrz68QBWMPgnjgbPu/oAqGPMw+g73res/GoT5yFGaeE/Q wZy+dXMm5TBqNvaazHNgc6C3fgx+FfBYMd+DeAnYdhl1D2Ix6O0vgc8HtnMt5XPVmkL98n7kvTjv B/sL6EfBfOSzR6kIshbyDintNuvUaWeb9CX9jXHYRtFAa/4/Adv5EBwBv/xfP0sh6CqIAiJHLaMq swQ5Zx0hpnb/mqgrDjIWcQGW14W42v17lO8D+SjvQ9tmyA2QcDVdPWi3EEc0yGY9Gfk70QaANXqW huZ2XwErQ2t0v0t07Q9hGkPzu54DuN9uZGZde8B2sANUYo5cZxPqj0AeQn1qaK0ulLs/A+tBDXg5 JLueAdw/BM84wflIP9+ht1UO9P1xo1J+Z0jZ5xviZmTZDcnrvjXk/Q8m5bdEP1KcQ3j/pm0/X/qN IyX0Z4gd5NJZnFNyHs25rIH8mfPHXsnfbUEhY8PrSOnlGMi5M+evxjjkzKHvvHzb92CVjBt236pc omYQBVLCsgFjruJb5yh8jxc+9TLe73UG9UiOa5DAOoayF7Hu5zwGsh31NMjLMqZJ39rHxw4S0253 /WZj5C3E1OIwCx0M1C75aphpjDMW3yyDxe5bjuUDxGh7nP5v6zLOS4ZUUDHjClgHGGde2icPGKT+ b9bLBUjLqozjz/fevt11t4Xlpqu7Ky7rsiDLCmnDZUFugoAsKihCCBUyFQOaNDTjBVJHxZIsclDJ CXAmolWJQtRISzBripE0nMrLNJoi2aCMl0Bu3+n3nPe8u9++extGvpnfPO853znved5zeZ7/6U7n nmo5rTtOuZzSJUk5Tbv/03sv0TPlUt5C6tydKnq3CHa0av/Eh/Q5bjlvrswcTcqHODCQnFUHjxIv 0P+mArjjmrXUrSw4IcMKntB7r9kBT1H3AXaR/ofdkFlDcDtsTlK+g3KP4CXbdo5jUXf7Ob1vVZ9b fcic2Tj4Q/VfhsIoKINfwdJkrfXuydgHvGdF9J4bzDX/C/ZCSgN2ay+Sb8ETlEspE6vN8YgMHzwk A4jL65wV4vxUhZh9qcb66C7bZiL/TfRf5Fy8I0MDT2YHy81SjelQFtVJiZc1OeJzNeXzaNuTXDTE f1vOilZrnbnZ5aop2cW8fzV5YDjvFXM0WM64y2WZX0F+2CLnes9LQN/ejCPOjgk/tnn5jGis9aOY unL8qwtmymAYq77CTP67AAb598kX/YX05f2Z9bLJGyubMjkpwr93i/CxcJZUZ9fIRERUXfYc3nOT NBa8a/ajzfZHI6TY5SubVzUnJs/ZCvMf5uYyl8vE2cbkm9OaQP2jX39vhPla/rhJv+zD5NJb5Dzm Z39+Lu9M23jNZh/v2hTnepNrp0GuZl81k3MTm8r1zPN3medFOqd2bm+XaX6dzLI5XXO15uxXne9u jtO+JGOxJw92oYWsNqF9EAxlzYaaI7rHKE/QtdK9ZPfTGnJkINP9L8tkuCR4Ui7xvy+T+M6GljYb 8YW5pa2oj6oxFN1fXq3UYC+GgdCoBBukkTUsdPRkDzRYX46xb9S3Ipgo04KldpxPWpFinTPop2X/ ADFNYb7UH8W/zTyAfUfnzs6fzukiWezvxsbrX2LH+kgCnTv/CLD+MBrmu306352tKf6fpEG/134j moo1XYW/n/o3Ei/i+bFtoyUyMdoN+5iTu4j/W6V3eKH0ji6XpuAevvlmqKD+NXTsWqmE8zNjzN8y z0klhIp3rVT6SzlbCyXIPC/3egehWX4Du+AZOKJkTtAHgjulFmrgKsVrzvTn/4Owwj1XxM/UjZCn LO4dsDkP2plD/hdYrzmMPYv3b8fHmTwzjt+DfZGCPl91qC7vp/smuIYY1ZYJaeirdmga6tXWpHH1 5WmoVzs+DfXjO/Cjs3ad+dFZ/flpqD//NPjR2Xur01Bf3YV/09JQP+0U/OhsngekoX5AF37MSEP9 jLQfxKf34PfcSz/EvkUcfyCuM3q3Jbvk9vPM/cIsduW3XLvVrejPzIP5cT+zgDbcec1B4C5irmgl twu+F/dJxjF3w/VOK+yN++Z+G49t/XNj2r6Jr7tS5b6wIx7Pjq3+78RWw3rX5mk37u7Y79xD2Dvi 9iffjb/R9tvdivHhSv6vwtLf7IGrIAt94Du0Owp/5fks7L/gVRhE+aJ4XnKvwZutcUFeD8rkCv+w zY29slWxDS62MVfIdUV5uWoZMb+CnNTf/7H0C35C/HqEuPa6FAXLRCLuoTZ+f0C+GEz7qcSKNbS/ mjKElxAzN9P+Id5Xxh54if/7EpMZw5aJm5p3bZxtJO42ykDNYZRrbE4l3hZ+Bf3SE31yHf3mSGX2 d1IbLpEhtJHgGZGCCfjwuAzJDpay8B7pV/gY+fsWNL0nheRNCQ9Q78k5yTdFd8jI4CkZkdiCF9A7 5JuoXAYRpycVPilTInxnzr7UMrbTWt7jUkn9ZnjW7Rs4MRg059aov6rR/Bewy1VvmKNhCfVVUoU/ g/HnTN5V478jVdFl5I91Uhzt5TyfkPqC8VITzZR6/p9mc48bU3WAv4p2C2m/D/0x3BwLIuYhyxwu kKLEqt5I5kDHYMz6cKmU+TmrWarVtxabvKMCXdMDX6fIm2ldk+ioPE2hOml6MkbyPdaSP5Pvz7Nt 9cYUGeXfIGeHzcQT1VFp63yKjklNuJD1c3o2WgaDYIksDn8ms4IHyeUbZFZ2HJo2kGLVZ+RYO57m 6PBH6PyXpZi1UU3+5/iMmG0wGa6Gb1P/D3jcxY4r43p7Nqk7ud7VfxNuhW/E/+t/ZlX8fPJQ/H77 361x+5Nbeb5PJOOpHo3J/TvG3A/983Uqc6v743gHtkXX6/d3Z9P6s1PLGWaPNOXp4VhPdmPpg44z /431rNWpiY5uYxmnzmo7a837zh5w9aW61zRWpG2rru7MdqpfYw3szlnLeUvr65Rt0dcd24Xt9Hcb y53OldO6vQtb5ubJWu4WZ6sGTSyUqlbOs73a3J/SVtdkhDEtOpa9hD99gwvlmq7QfadEs4jbHeD0 fTvCE8RQyI5uC3eGM7oiImMqBed2jL0XWMwvHcaxTyGGihL6HWPXvgOS78l+5miI8Q+bY11hfR3U it4/uiIiEijZ444b2pLMezKPybwk3534m4yfvPfzruPnXZfT9d1d+Z4PZ/IN+KezfZWO/NY9GPWC t+GI1Sx6nmsdfdkzH8Er8InjZYvGLf73/8AeeJ19l9en3T7IybWWZE04i1YjEcmzwxnzPu2vsdDG wxUdzs9L+DcUUHTRMPp8bO9Hqr3eCA7FeV1JYl/By+iVOBacp7GlQOwZbwh2yWKn9/Y47fc053yI 6iX+L43jnUy0MZc44N1LjDLcCT/g3tYsax2vOB502m+Gow/9tmF/kY9fjz6rt/1HMt4tsNHp7WpX htyv4/oW3/bgywAbg0MJwzpAN/jPyBB/H3t8GLkc/B8AeoFxR3sL5KzgCsr3o61i/VFvz8I+2s6m z+Uw22qKMf7K1rPtb5Z6f6sxFjRRMJ32RWjBRmwhxHG2ROOkjsW3TAqapNSfgv7SHMU4+o5gJHXo In8h+3UG++JMvlu5kW8/HOOvgLulMvMwHOW5mfrPmN8red4O9wB61NsGP+d5MvY97EbaoI29BsrK ndRVYW+G26AkJnMoxvs6tgnLWP772HEwA4qdnRH3y6zGboCbXLu5EnprYDzPVdjB2CdgvIT6vszf Xfu5eW2ua20TotmLFsulnKlLs/PYl+PMzsz7MjqYKz1Z05L4/pDbG99brI7SO0YT/JTyX7ztskDB l6mW9WanXwvOhpEsCO6WCcFH3PseleHBRikNR5FXD8qE8ALpH9wpNbxnGkxX2D8fsm4T/NmSzWzB lzyiOdKn8EViKCqL8yGJ9R4DbGZ2XGefVb09FisyPWeJxo36ihddiI6st9qph/5Hn9tVn1iNTc63 +XWSzHcabjx+6f1Rz8Ie9ksRfSa78zuZ76nRfeV04BLY6t0oeocc4ZWbnd5MvSvYvvPiO6lZGd9v zVTe+0i4Q0YqmU/NOiWvvFM53eXgdu4PF0Ejz43ty6zlMEebdY3WyhglGEs7ZS56cr32jde5u3LU JLWKN4Axyjsor5Le2RXcK7VvZfdl70niPti9Vtu+zDdNUlq+u7tyCWsJyV5r2c+dfb+YLTbuNktv jeFWq+naN5tnFfZRJTH6OafVGr11nNcXZVzUX3oT+y6Icz+xUmPXIuIgmt+9ryn4o43lPTWm5737 qOpWuz+vNw02jqET/89++cdGcVxx/O3O3pnjsneHy28cdg/bcOaH73IkhYCruzOQRpbhjG1iBVWc D3yAAXsd3wGNateo+aGmaWUHnEASgd0UkwAmdu8Chf7Cf1RUVCHxH/2rUsGp0qoVaeskbaRUFPc7 c2tCmyKUSukf7dzp896b92Zmd2dnZ96INQ65H/ZGcU7iOb6da0S5zddZ8T09ifMhPg1+RsNa5BDr Cme9vQad5kycUP3wHRRr0QxlL/RGwVzlWXwNcXuNWoxned5ef/omjov15ZC9Rj2HOlgXlQsTB+21 ysCeNF99CdTZ69B90JxWYIIA/0ZuHsozkYb+sdiXQvY6yfutRTvYPN/n3y32mgr+DWJM6u6WK2H/ v2LnBJNcsfMEoe+WE97W7v1/Vx9zvU57C/OkHHkCzm8853dcoaLJMxfe2WK+XzuOibVm7a2ziJ3j i/eDsx7XYh/vxzzGmvKvZwJNpU3YzyodLVTI9y2M0yXwy9t0Ig9fs/N7dIEHaTL2Ut63fQZbBj2V 5w38Puxzg+e2897kOU6cM9glijkeQsyF/fIYrUO/q8FGgKX35sf5tfHmcT7PHEdpIc9luLbzhUeh r0N7oX/Hz73QfwR/he3J239/0z7Drb11FjpLyDNuHnRchv8Szko3aJ7zMD/vYE58SAuVx2gjB21e 5GAs3xX/ivx6T/vujPp6Hu03eRzIrhy/R143kmfKFnCeyOUD3yCa+gaR+wgGZieSrYeIfFjZpyGn +wLqTUeePRP+WX8imo1VfU71pykqJ5p/jsiPnLMY9Uvwphaiv8DDRIuxsyztIFqGnbT8A6Iw+lqO fh5A3ZXTiR7EeWU1ziAVyLQitUSV6G/NK0iAThE9vJTwcRPF/0ZUi/yl7tSdacAbehTP+BXcf2I2 0Vach1K47i5co2UtkYU+2jF2+04QfRXP3InrHMBzP4FzwFPvEX0T7b6FsevGLvZcD1Hv/USHtxK9 jFy6H+PwvSKigdmSz4MTWBlP4B2dGCd69eDdOfnRpzk9VSKRSCQSiUQikUgkEolEIpFIJBKJRCKR SCQSiUQikUgkEolEIpFIJBKJRPJ/gEKkP0IfUAUdpQJSyUdBeoTIWapdJwfKRB56HZIR/+0SktsF 9BZKCuV/DygrbZvRbKXFtjXYT9m2E/ZR2y6gHcpZ1FQ0F+9TLbJthULq07atkkc9Z9sM/p/Ztgb7 L7btpBArsW3cD6unk2RSmEL4r4RVTzspBb2eLGoFGXqc2oRnDUrtsLlMwt8sapQjEqM9+JtUC98O tM9QWpRS0CnU3gfZhJr1iLcIr0kboPeLWhZ8SfRkIsojSZAR12hCHR5rp93wWbT9P7g/3mur6DHf bhNKzSjxOzKpDlZSlPJXboU3KHowRd87xf2btA2lvYjy+2oWtctPmuFQaKVZvzNlrrdarczjbSlz jdXeZrUnM81Wa7kZ27PHrG3esTOTNmtT6VT7vlRT+ZrqmsrKyiX1zS2p9IbU/lqrJdlaU7e+/rP6 hcOExxQuszltJs1Me7Ip1ZJs321a2+94X2Zzq5lBbFNrcybVZNZlkhn0lGxtClrtpoVIu7nN2tua aW9Opcv/i3NjDVVTDVWK/5LbZkp+nnwyS2rwztYjznvYgXeyR8yPz9r6867/PzXTL1A9ey/HFhuR 2Az2LjWyP1Af+y1dAxr54PHBioA22BPAMTHC3smtWxeOnodeUi50NlAWvsAD2blF4Z+wd9RBWkQG HNeyM+eJyNVsZaVtfHFl3sgtXha+FpvKrtKfgcqusmsUyLfKBcrD4zEdDoV9nbyKQgb1s1/TMFAp yn6VK1kY7rvI3kT8F+wyHpc3u5zVp4XR4c/ZD6iQDHaOnbUjZ3OeaWGKpdl3sKaOQI6CMTAONLLY q9QFusEQ0MgLaYAgiHMPO81O4z4H0N4LGQQW6AYahvAU/Lu5ZK+xXbQAbb/NemkG9LPskNDHoedC vwL/fOjvosx1n11+GZrHX7L9L6I8E/qIrQ/DPw/6BZS5ft4u72N7RbuMrftZOjvf8MXmI26CEGCw emH1Yuh6+W4FqbAn2B5xpe9Dh6Fb8hrD1Zn1F4t31JmbNSfcjyHtxNB3YuQ6MXKdpCHUMVmnI19n GetAnQ7U6UCdDr4vsTSul+Z7JqQPmIBh3NMYd+4fhhwBo8L/JGQP6Oclth/jWIa7eobtygYMTLId uQej4ciP2HYMdZRtz825N9z9Sck1lU9EaI+tvbxuSkRTOdc93JvKzb03r1Frd8zDttHXgErTIUvA /WAt0Ni2bEnQ+CHbQC1TKOoxutQu1qV1ObTQWqXwIgtTzRTClCxky6gCFcqMRIWyotHV5jrgYj6X 6Qq5oq4al8NiXaybMYMFWYTFWYI5zk+MZAtWLYeKftm5anmPu9897B5xj7odw84R56hzzDnudJjO kDPqrHE2OtucB5w9zn6nq8fZU6A2utvcB9zM5zbdIXfUXeN2GAVKf+wptpXnEZA+0AZ6gIYxTsBv si0ggbeRwFBsgZ8gCSUfGIU9Bu1AyYt6XtTzwuuF1wsvQfJIDWgEbXbUeSsy2YbXH+cRsAhRD7we jO0Y5Di3QBVKOko6Sjpqjao3cIc+SBPUACZ8YwCzBnIyFrLjjcAp4uOizmQsytuqN6LJRSNlynCZ 0l+m9JQp0YpILBxdAFFYWJgoTpQmAokBzSq2Sq2ANaDFi+Ol8UB8QIsUR0ojgciAFiwOlgYDwQHN KDZKjYAxoHVXD1VfrH67WktUW9Vd1WwFXl0uuyQUFnpBKddns3Pmhld4Y6vVITxOArIPXAOMDMgg iAALaOoQpKGegfcMvGcoDhLAgRZn+PICadgx7u8TMW7xuPpPcYYHH8yuWh6PVWHJTYA+wND3IOKD onbeGhL+Ycgx4Y/b9fuF34CcbMOwwG0Wy9xmfH6bsfhvpgRoAw56mzVgc2jgPUMaoA0MAY1txr+B Nahn8B9UB9nSqH7fDINmzkRSWzhtii/mU+/BHNCV14Q8IuQzQkaELIl6qvSPqvSfVulPV+mLYKgB JBm60iukP+qO6W/E9HhML4vp6G0W+UlXZwjp5FK5LuQGIZdGp/v1j/36h379fb9+1K8/5te/5Oft ivDt6up0Id1cKi8IWSXkwqjb0C8ZeoOhrzD0mK4cU3B1+gfrVRcbRRWF75ltO2MpbClINlnKbGd2 UJnZCCWkIBPYn5liM8S0XWx2KondLrVgMIC7QyIxVGJIJAZJJNEISqNoY2wMs7PYTEsTCMYXHyTG N8ODEZ58UUExkmg95+7KT9IXE2/2nG/uOd89370z9+7OZrlfw32cPNy6GLWi7JFLcItZWAkC8wk5 FBgHWAjMDMLfgbkD4a/APIdwNzBPy/PwJ/CfNLgTJG/KmUfhN+hrov7tBv4KfWwa8RfEccQpZoKG +HFgHiP+eRx/BvsfMUUi/oesn4+bhD4e/6Ax7v3AGEXVs4HxCqqeYQZXfTcwbmL0dGCcQHg7MPYj nAo0muCLgblOziyHcZYUiFtimkAz2dlQfBor70fcUR9sBwaNskgghFygbkB4jGY5Dyrr53JyoPJF djKVl1jNVD7pONM4LoMon/xSpnCUAvUYVmm5qN2U/zAv0cLZ7xANzsk35nF9Q9j9EfqCafnbWbpd gXzNCEGbkb9RL8lfJUMYCuQrRihh4rIRCvCFXMWb7CNXgBn5gjEuf67y7CcqZvFRT5op+aw6LL+n YT+QjxnzNA32Eq54CNOusU3eaU7LvVoImE6bKJZulZ9SX5a3YHhzCH21aXlDMqSprMca0zPyOlRc q/KpPNszJ2xiInhpQ6yIo+KQOCBuFTeKKTEhdoqrxZVSh9QuLZPapFZJklqkJkmQmLQyXPghrTM8 hStb2glamsg38et2gTz9E8VvfQEkAc+OvyLiCE4+C36Hw5xdWb9Hd0JxYdDfrDu+1P9coQrwlos9 X3gjBLargBuUQsfjfkeuMMsAnjx+Mk746vGTrguOf6XEnNGEfyeP62gdGPab1WyMrTq8Pba9Y9vy Lb3WIm6k4fX7LaY/2GKd/jtOvuB/1un63XSx0Ok6/o58YndhVjgkHLCtWeEggVuYhSPCIXuQ4nDE cu/RmCIcRBozCYhWYwrRmAI1TtvJabhNFduqKkqddBX6iITb5yonjddrJVECa/UTIE1Yw5K8VlJY QzTcD/Vi0QeLtTGI8mLRNsaLrSZSVdOQYmhEqfZoSKhqPTw9fT+tavXpuEzjOhq4XAfgPufxOgd3 QYMjSMjR/882lv0PZKgVr+8p2WOqPaLaY2gj/puH98b810YTieqe65RI+JG1I6OlvYTFMf+6Omb5 e1QrUS2WFkmXKF1UrSor2bsK1VJ6zAqK6aKtFi23NjWRcx7SOnFPKzexSLEJKpYjrSlnkbRD6SnS ckjLIa2p9BTXcgaz4PQXqhLLurnddawJS1rxPIzEu9zsqvaD2/jh2NoVOxqfa2L4s7VEd/02Nesv RaNUKpPKUApPJ6WWYTjaSMWObu2Kz8GnjVQ7hper9AczZu+z7n3K5XKFzPN09BUvxmMVPLRdecfv HRgu+KZv2n56xHKBHofXaLlCuv2yec0UDpgT5ilz0rxgNnuei+GOy8o1RXheOaBMKKeUSeWC0kKJ 3YWZtDmp/KxEPNxNUMFmW1zTQ8QPdStemRpDgTJaXU739Fwho7ASvu0Cvpmn2Ao0FW0jWh6tmX2J /ju0G2i30ZrY6+hPo51Hq1Ekkoqk7Ng+ixRdnb50YpHu2vpN3ZtDxOILdcwP19F+po5mpjuGGGzf 2JqJ4os3sDn0X6N9j/YT2l205kh3pJsX9+q71i2zsg44fYadCrmyXgEdL4Bud6Ws64yMNjg+AaTq 8PC+Z1D2GN4KfCAISOLRMg3zCP9tlPhHgAEA06vbEA0KZW5kc3RyZWFtDWVuZG9iag0yNDEzIDAg b2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAyNDE1IDAgUi9MYXN0Q2hhciAx MjEvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAgMzMzIDI3OCAwIDU1NiA1 NTYgNTU2IDAgMCA1NTYgMCA1NTYgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgNjY3IDYx MSAwIDAgMjc4IDAgMCAwIDgzMyAwIDAgMCAwIDAgNjY3IDAgNzIyIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA1NTYgNjExIDU1NiA2MTEgNTU2IDAgNjExIDYxMSAyNzggMCAwIDI3OCA4ODkgNjExIDYx MSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgMCAwIDU1NiA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRN VC9GaXJzdENoYXIgMzIvVG9Vbmljb2RlIDI0MTQgMCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjQxNCAwIG9iajw8L0xlbmd0aCAzOTYvRmlsdGVyL0ZsYXRl RGVjb2RlPj5zdHJlYW0NCkiJXJLdaoNAEIXvfYq9bC+KiZrZBiQQ8gO56A9N+wBGJ6nQrLIxF3n7 zvGUFirofrJz9GN20tVuvQvt4NLX2NV7HdyxDU3US3eNtbqDntqQTDPXtPXw8zY+63PVJ6mF97fL oOddOHZJWbr0zTYvQ7y5u2XTHfQ+SV9io7ENJ3f3sdrfu3R/7fsvPWsY3MQtFq7Ro33oqeqfq7O6 dIw97Brbb4fbg2X+Kt5vvbpsfJ9Spu4avfRVrbEKJ03KiV0LV27tWiQamn/7uWfscKw/q5iUGYon E1uMH8mP4Dl5Dl6T1+ANeWOcM5sjm0/JU3BGzsAz8gzsyR68JC+Ni2JkW4xZX6C+ELKA6VPAp6BP AZ9ZPrItxszOkBX6CHyEPgIfYb2gXvhfwX+FWRmz9BR4Cnsi6InQQeAgK/IKTB+Bj7A/gv7IlmwH UXr2yqNXnj4ePp4+Hj6ePh4+nj4ePp4OHg6eDrbgcH9OEcds0+h+Z6i+xmjjM47sODeYmDbo71T3 Xe8shTv5FmAAVdbDzw0KZW5kc3RyZWFtDWVuZG9iag0yNDE1IDAgb2JqPDwvU3RlbVYgMTM2L0Zv bnROYW1lL0FyaWFsLUJvbGRNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDAvRmxh Z3MgMzIvRGVzY2VudCAtMzc2L0ZvbnRCQm94Wy02MjggLTM3NiAyMDAwIDEwMTBdL0FzY2VudCAx MDEwL0ZvbnRGYW1pbHkoQXJpYWwpL1hIZWlnaHQgNTE5L0NhcEhlaWdodCA3MTYvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTI0MTcgMCBvYmo8PC9TdWJ0eXBlL1Ry dWVUeXBlL0ZvbnREZXNjcmlwdG9yIDI0MTkgMCBSL0xhc3RDaGFyIDEyMi9XaWR0aHNbMjUwIDAg MCAwIDAgMCA4MzMgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDAgMjc4IDUwMCA1MDAgNTAwIDUwMCAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCA3MjIgNjY3IDcyMiA3MjIgNjY3IDYx MSA3NzggNzc4IDM4OSA1MDAgNzc4IDY2NyA5NDQgNzIyIDc3OCA2MTEgMCA3MjIgNTU2IDY2NyA3 MjIgNzIyIDEwMDAgNzIyIDcyMiAwIDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMz IDUwMCA1NTYgMjc4IDMzMyA1NTYgMjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1 NiA1MDAgNzIyIDUwMCA1MDAgNDQ0XS9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0Zp cnN0Q2hhciAzMi9Ub1VuaWNvZGUgMjQxOCAwIFIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5 cGUvRm9udD4+DWVuZG9iag0yNDE4IDAgb2JqPDwvTGVuZ3RoIDUxMy9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSIlclN1q4lAUhe/zFOeyvShRs39aCILVFryYH8aZB4jJ0QmMSYjxwrefs7JK B0bQfCE5e30s2Obb/W7ftVPIv499fYhTOLVdM8ZrfxvrGI7x3HbZchWatp4+7ubf+lINWZ4OH+7X KV723anPyjLkP9LD6zTew8Om6Y/xMcu/jU0c2+4cHn5tD48hP9yG4U+8xG4Ki7Behyae0qAv1fC1 usSQz8ee9k163k73p3Tm3xs/70MMq/l+SZm6b+J1qOo4Vt05ZuUifdahfE+fdRa75r/npjx2PNW/ qzErV3h5sUiXxEY28DP5GfxCfgFvyVvwjrwDv5NTaFlwZoGZxZK8BK/IK3BBLsBKVjAdCjgUTnYw fQr4FPQp4COcL5gvnC+YL5wvmC9CFjCzBFnCLEGWMEuQJcwSZAmzZM7akDfgV/IrmJ0IOhF2IuhE 3shvYPYj6EfZj6IfpbPCWemscFY6K5yVzgpnpbPCWemscFY6K5yVzgpnYz+GfoxZhixjliHLmGXI MmYZsoxZhixjliHLmGXIMmbZnMV+DP0Y+zH0Y+zH0I+xH0M/xn4M/Rj7MfTj7MfRj9PZ4ex0djg7 nR3OTmeHs9PZ4ex0djg7nR3OTmeHs9M5XbAsH1uBtUnbHT53sr6NY1rH+S9g3kNsYNvFz3+JoR9C OoVv9leAAQCflAWtDQplbmRzdHJlYW0NZW5kb2JqDTI0MTkgMCBvYmo8PC9TdGVtViAxMzYvRm9u dE5hbWUvVGltZXNOZXdSb21hblBTLUJvbGRNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdo dCA3MDAvRmxhZ3MgMzQvRGVzY2VudCAtMzA3L0ZvbnRCQm94Wy01NTggLTMwNyAyMDAwIDEwMjZd L0FzY2VudCAxMDI2L0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9YSGVpZ2h0IDQ1Ny9DYXBI ZWlnaHQgNjYyL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0yNDIx IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAyNDIzIDAgUi9MYXN0Q2hh ciAxNDYvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjUwIDMzMyAwIDI3OCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDAgNTAwIDI3OCAwIDAgMCA1NjQgMCAwIDAgMCAw IDAgNjExIDU1NiAwIDAgMzMzIDAgNzIyIDYxMSA4ODkgNzIyIDAgMCA3MjIgMCA1NTYgNjExIDcy MiA3MjIgOTQ0IDcyMiA3MjIgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1 MDAgNTAwIDI3OCAwIDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDAgMzMzIDM4OSAyNzggNTAwIDUw MCA3MjIgNTAwIDUwMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDMzM10vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL1RvVW5p Y29kZSAyNDIyIDAgUi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2Jq DTI0MjIgMCBvYmo8PC9MZW5ndGggNDc5L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyT zWrjQBCE73qKOSaHoL+Z7hiEwbET8GF/WO8+gCyNHUE8EmP54LffKVXIwgpsfULTXVWa6Xy73+3D MJv8Zxy7g5/NaQh99NfxFjtvjv48hKysTD908+fT8t9d2inLU/Hhfp39ZR9OY9Y0Jv+VXl7neDcP m348+scs/xF7H4dwNg9/todHkx9u0/ThLz7MpjDrten9KTX61k7f24s3+VL2tO/T+2G+P6Wafyt+ 3ydvquW5pJlu7P11ajsf23D2WVOka22at3StMx/6/947x7LjqXtvY9ZUWFwU6ZZ4S96Cd+Qd+I2c GjY119dYX5fkElyRK3BNrsGWbMGO7MBCFrCSFbwir8Ab8gb8Sn5NbNnHoo9lH4s+lrUWtfaF/AJm Lotclrkscln2tOjpmMUhi6N/B/+O/h38O+o66DrqOug6+nfw757Jz2D6cfAj7C/oL/xWgm8l1BJo CbUEWkItgZZQS6Al1BJoCbUEWkItWbSYXZBdmF2QXZhdkF2YXZBduL+C/VXur2J/lT4VPpU+FT6V PhU+lT4VPpU+FT6VPhU+lT4VPpU+FT6V+6vY3xW0qqJcLYf283Ti+KYpM1+z0d1iTGOxjOIyD5iE IfivaZ3GyaQq/LK/AgwA41ruZA0KZW5kc3RyZWFtDWVuZG9iag0yNDIzIDAgb2JqPDwvU3RlbVYg ODAvRm9udE5hbWUvVGltZXNOZXdSb21hblBTTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWln aHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTMwNy9Gb250QkJveFstNTY4IC0zMDcgMjAwMCAxMDA3 XS9Bc2NlbnQgMTAwNy9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvWEhlaWdodCA0NDgvQ2Fw SGVpZ2h0IDY2Mi9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjQy NSAwIG9iajw8L1N1YnR5cGUvRm9ybS9MZW5ndGggMTY2L1N0cnVjdFBhcmVudHMgMC9GaWx0ZXIv RmxhdGVEZWNvZGUvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9G b250PDwvVFQwIDI0MjYgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAy NDA0IDAgUj4+Pj4vQkJveFswLjAgNzkyLjAgNjEyLjAgMC4wXS9Gb3JtVHlwZSAxPj5zdHJlYW0N CkiJFI69CoNAEIT7fYottcjdntEcAbFQDzHEyu1CCok/SMgZouEgT5+zmWG+YWBk++4spqm8dnbC YLCHKg9lU9QlEmZZXhYIOQOJ6IgkKPKUhNb4BFm1hNMKkplQIY9AyA/fs/OCvKKi3X87+viwT3eL EyV0rBVGZ0HJ6YT8glvgnAt1HIihn9fFjsvX9t02L1bYYZO1MeGdL2AYTOMf/QUYAE/ILK8NCmVu ZHN0cmVhbQ1lbmRvYmoNMjQyNiAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0 b3IgMjQyOCAwIFIvTGFzdENoYXIgMTE5L1dpZHRoc1syNTAgMjc4IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgNTAwIDQ0NCAyNzggMCAwIDI3OCAw IDAgMCAwIDUwMCA1MDAgMCAwIDAgMzg5IDI3OCA1MDAgMCA2NjddL0Jhc2VGb250L1RpbWVzTmV3 Um9tYW5QUy1JdGFsaWNNVC9GaXJzdENoYXIgNDYvVG9Vbmljb2RlIDI0MjcgMCBSL0VuY29kaW5n L1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjQyNyAwIG9iajw8L0xlbmd0aCAz MDcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJXJHNasMwDMfvfgod10NxknUOhRAY3Qo5 7INle4DUVjrD4hjHPeTtJ1ulgxkS/Yz0lyxJHrqnztkI8j3MuscIo3Um4DJfgkY44dk6UVZgrI7X W/7rafBCkrhfl4hT58ZZNA3ID3IuMaxw92jmE26EfAsGg3VnuPs69BuQ/cX7H5zQRSigbcHgSIle Bv86TAgyy7adIb+N65Y0fxGfq0eo8r3kx+jZ4OIHjWFwZxRNQaeF5kinFejMP3+pWHYa9fcQRFM9 U3BRkCE+MpOw2T1kJkO8Z94TqzIzGeId8y4xx6sUrxSzSsxalbVcS6VaimupVKu+z0yGmHPWKWfN OeuUs66Z6za1WBX80iK3eO0lNUs7gdsk9SUEGmJeXJ5empt1eNutnz2QKn3iV4ABAOnbkywNCmVu ZHN0cmVhbQ1lbmRvYmoNMjQyOCAwIG9iajw8L1N0ZW1WIDcyL0ZvbnROYW1lL1RpbWVzTmV3Um9t YW5QUy1JdGFsaWNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgOTgv RGVzY2VudCAtMzA3L0ZvbnRCQm94Wy00OTggLTMwNyAxMzMzIDEwMjNdL0FzY2VudCAxMDIzL0Zv bnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9YSGVpZ2h0IDQ0Mi9DYXBIZWlnaHQgNjYyL1R5cGUv Rm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgLTE3Pj4NZW5kb2JqDTI0MzAgMCBvYmo8PC9TdWJ0 eXBlL0ltYWdlL0ludGVudC9SZWxhdGl2ZUNvbG9yaW1ldHJpYy9MZW5ndGggMjczNzIvRmlsdGVy L0RDVERlY29kZS9OYW1lL1gvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UvRGV2aWNlUkdC L1dpZHRoIDY2NS9IZWlnaHQgNDA4L1R5cGUvWE9iamVjdD4+c3RyZWFtDQr/2P/gABBKRklGAAEC AAKZAZgAAP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgICAwICAwQCwsLEBQODQ0OFBgSExMTEhgU EhQUFBQSFBQbHh4eGxQkJycnJyQyNTU1Mjs7Ozs7Ozs7OzsBDQsLDgsOEg8PEhQREREUFxQUFBQX HhcYGBgXHiUeHh4eHh4lIygoKCgoIywwMDAwLDc7Ozs3Ozs7Ozs7Ozs7O//AABEIAZgCmQMBIgAC EQEDEQH/xAFCAAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEA AgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFi MzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF 1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGAjsBAAIRAyExEgRBUWFx IhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPT dePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8fX5/f/2gAMAwEAAhEDEQA/ APUwZJ8ipKI5Px/gpJKUkkkkpSSiSQCQJIHA7rF/5ytrtvqzsDLwjjY5y3m047hsnaB+r5NvucZ2 gxMHwSU7iSzen9UOdddi3Yt+FkUNY91OR6RJZZu2PBpttbEscOZ0WkkpSSSSSlJJJJKUkkkkpSSS SSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+CkkpSSSSSlLCt6LlZeH 1Rl9zG5fUXO2WMktrrr9uOz813tiXeZdHit1JJTkdNw+oftDI6n1NtNV11VWOyrHsda0V1GyzcX2 VUmXOtOm3SOdVo3Y2PktDMiplrQZAsaHAH+0jJJKcvp3TenPw63PxKHOMyXVsJ5d/JVn9ldL/wC4 eP8A9tM/8il0v+g1/wBr/qnK2kpqfsrpf/cPH/7aZ/5FL9ldL/7h4/8A20z/AMiraSSmp+yul/8A cPH/AO2mf+RS/ZXS/wDuHj/9tM/8iraSSmp+yul/9w8f/tpn/kUv2V0v/uHj/wDbTP8AyKtpJKan 7K6X/wBw8f8A7aZ/5FL9ldL/AO4eP/20z/yKtpJKan7K6X/3Dx/+2mf+RS/ZXS/+4eP/ANtM/wDI q2kkpqfsrpf/AHDx/wDtpn/kUv2V0v8A7h4//bTP/Iq2kkpqfsrpf/cPH/7aZ/5FL9ldL/7h4/8A 20z/AMiraSSmp+yul/8AcPH/AO2mf+RS/ZXS/wDuHj/9tM/8iraSSmp+yul/9w8f/tpn/kUv2V0v /uHj/wDbTP8AyKtpJKan7K6X/wBw8f8A7aZ/5FL9ldL/AO4eP/20z/yKtpJKcDoXRMGhmZ6vRqsH fmXPYHPbk+s122MgH3emH/udlqfsrpf/AHDx/wDtpn/kVS+r+EMIdQaOn/s4XZ99w/T+v9o3bf1n +Rvj6HaFsJKan7K6X/3Dx/8Atpn/AJFL9ldL/wC4eP8A9tM/8iraSSmp+yul/wDcPH/7aZ/5FL9l dL/7h4//AG0z/wAiraSSmp+yul/9w8f/ALaZ/wCRS/ZXS/8AuHj/APbTP/Iq2kkpqfsrpf8A3Dx/ +2mf+RS/ZXS/+4eP/wBtM/8AIq2kkpqfsrpf/cPH/wC2mf8AkUv2V0v/ALh4/wD20z/yKtpJKan7 K6X/ANw8f/tpn/kUv2V0v/uHj/8AbTP/ACKtpJKan7K6X/3Dx/8Atpn/AJFL9ldL/wC4eP8A9tM/ 8iraSSmp+yul/wDcPH/7aZ/5FL9ldL/7h4//AG0z/wAiraSSmp+yul/9w6P+2mf+RUXdN6Uxpc7E xwAJJ9Jn/kVcUXsa9pY4SHAgjyQN1ooeLyWH1rpWb0/N6nTh9LtqxcZ+Uyqi9l18NBc0X1Nx4qLm t/edB01Wl0T9m9Wx35BxemPa12wHBtbls4Doc/7PTB141TdP6Dn4PpOdmVWvwsR2Hgn7OW7WuNet /wCsfpD+ib9HZ38dLfTOm5GLkZWfnXsyMnM9MPNFRprDag5rNrHW3On3GSXeHEI6KbTemdOY4Prx aWPaZa5tbQQfH6KtJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+CkkpSSSSSlJJJJKUkkkkpqdL/AKDX/a/6 pytqp0v+g1/2v+qcraSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJK cjoGH9jPUf8AJ/7O9fPvv/nvX+0ept/Wf+D3x9DtC11kdBw/sZ6kP2f+zxfn3Xz63r/aDZtnJ/4P fH0Oy10lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSWb1DqzsPJpw6cO/NuyGWWNZjmkbW1Gtr i45F1I5tHEoGf9YasLIsqdiZNrcauu7LtqFRbjssLo37rmOP0CTsDtElOykmTpKUkkkkpxMj64fV 3FvsxcjL2W1OLHt9O0wWmCJbWjdO+sfRur5Bxen5Hq2hpeW7Ht9rS1sy5rf3gvMPrD/y91H/AMNW /wDVuWz/AIuf+Xbf/Cz/APq604xFWtEjdPpaSSSauUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+CkkpSSSSSlKj V1fpWRbdRRm49luMC6+tlrHOqDdHGwNd7Y81atD3VubWYcQQ0+BXD4VHWX9Es6VT9tvazpxbfTl4 4xwzIaa9tWO9tOP6gePU3Hc7ga66obqexwupdP6nW6zp2VTlsYdrnUWNsDT4F1bnQVbWH0qx+b1n N6nVVbTivx8fHb69NmO59lbr7HHZc1j4aLWiYg6+C17qnWtDW2vqgzNcSf8AOa5JSHpf9Br/ALX/ AFTlbWX07Esdh1kZV4mdAWRy7/g1a+xWf9y7/vr/APSaSm0kqv2Kz/uXf99f/pNL7FZ/3Lv++v8A 9JpKbSSq/YrP+5d/31/+k0vsVn/cu/76/wD0mkptJKr9is/7l3/fX/6TS+xWf9y7/vr/APSaSm0k qv2Kz/uXf99f/pNL7FZ/3Lv++v8A9JpKbSSq/YrP+5d/31/+k0vsVn/cu/76/wD0mkptJKr9is/7 l3/fX/6TS+xWf9y7/vr/APSaSm0kqv2Kz/uXf99f/pNL7FZ/3Lv++v8A9JpKbSSq/YrP+5d/31/+ k0vsVn/cu/76/wD0mkptJKr9is/7l3/fX/6TS+xWf9y7/vr/APSaSm0kqv2Kz/uXf99f/pNL7FZ/ 3Lv++v8A9JpKaXQsWvGf1Iswm4Xr51tri2/1/XLtv6Z3+jLv3Oy11z/Qul249vUpa/CFubbaHV2s sN+7b+mePT9pd4LW+xWf9y7/AL6//SaSm0kqv2Kz/uXf99f/AKTS+xWf9y7/AL6//SaSm0kqv2Kz /uXf99f/AKTS+xWf9y7/AL6//SaSm0kqv2Kz/uXf99f/AKTS+xWf9y7/AL6//SaSm0kqv2Kz/uXf 99f/AKTS+xWf9y7/AL6//SaSm0kqv2Kz/uXf99f/AKTS+xWf9y7/AL6//SaSm0kqv2Kz/uXf99f/ AKTS+xWf9y7/AL6//SaSnN+sPSn9UpZQ3puBnQ17Q/OeWmkuAbuqAxrv+qbwPlT6l9Wb8+unFLWP DsarFyuoHKvqttDNHb8atvp28mPUfoXHTx08y/D6eWtzupvxzZJaLH1tnbzH6NV/2v0X/wAux/27 V/6TSGiiXcAAEDgJ1Rrx/VY22rNvex7Q5rgayCHcH+bRPsVn/cu/76//AEmkptJKr9is/wC5d/31 /wDpNL7FZ/3Lv++v/wBJpKfJfrD/AMvdQ/8ADVv/AFbls/4uf+Xbf/Cz/wDq61ideaWdaz2kl5GT aNzuT73fSWv/AIv6zb1uxrbH1n7M47q4n6df7zXqQ7MY3fT0lVbiWNcHfar3QZ2uLIP/AIGrSjZF JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpSSSSSmI5Px/gpKI5Px/gpJKUkkkkpSSSSSlJJJJKanS/6DX/a/wCqcraqdL/oNf8Aa/6pytpK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpyOh432fI6m77HXh+tmO fvrt9Q3yG/pnj8wu8FrrI6JjfZ8jqZ+x14frZjrN1dvqG/cG/pnj8wu8FrpKUkkkkpSSSSSlJJJJ KUkhXW1Y9Trr3trrrBc97yGtaBqS5zuAq2P1jpOXj2ZeJm499FEm66q1j664Ene9rto011SU3kkG m+nJpZfj2NuqsaHMsrIc1wdwWuboQjJKUkkkkp4H/Gb/AEjp/wDUt/LWuJXbf4zf6R0/+pb+WtcS pI7MUt32bov/ACNgf+Fqf/PbVdVLov8AyNgf+Fqf/PbVdUbKF0kkklPjf1h/5e6h/wCGrf8Aq3LZ /wAXP/Ltv/hZ/wD1daxvrD/y91D/AMNW/wDVuWz/AIuf+Xbf/Cz/APq61IdmMbvpaSSSjZFJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSmI5Px/gpKI5Px/gpJKUkkkkpSSSSSlJJJJKanS/6DX/a/6pytqp0v+g1/2v8AqnK2kpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnI6Ljehl9Uf9jrxPWyi/1K7fUN +jf0r2/mHyWusjouN6GX1R/2OvE9bKL/AFK7fUN+jf0r2/mHyWukpSSSSSlJJJJKUkkkkpo9Upoy Om5WNk+oKLqbKrDS02WbXNc12xjWvcTB0AafgsvpmVea812ccvN6fQ6p2Pbl4jm5Dn/Se1uPXj1P cGODS0+lMzqYXQEgCToAoevR/pGf5wQIsEK7OT9UXu/5vYNNld1NuPSymyu+qylwc1rQ723NYSPM aLaUWPY8SxwdHgZU0SbNqUkkkkp4H/Gb/SOn/wBS38ta4ldt/jN/pHT/AOpb+WtcSpI7MUt32bov /I2B/wCFqf8Az21XVS6L/wAjYH/han/z21XVGyhdJJJJT439Yf8Al7qH/hq3/q3LZ/xc/wDLtv8A 4Wf/ANXWsb6w/wDL3UP/AA1b/wBW5bP+Ln/l23/ws/8A6utSHZjG76Wkkko2RSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpiOT8f4 KSiOT8f4KSSlJJJJKYOIDSXEAAak9lwGDXi4fTOodO6O7A6gxnT91mb0qkVWH0ztLMh9VuRvfYzc W8HQ6ar0FJJXSnnPq6Ok/tXOf9XhjjpvoY4Jw9nonIm/1Nvpe3dsczd34W/ccgNH2drHOnXeSBH9 lrkVJJTl9Od1H7HXsZQW6xL3A8u/4NWt3VP9HR/24/8A9Jpul/0Gv+1/1TlbSU1d3VP9HR/24/8A 9Jpbuqf6Oj/tx/8A6TVpJJTV3dU/0dH/AG4//wBJpbuqf6Oj/tx//pNWkklNXd1T/R0f9uP/APSa W7qn+jo/7cf/AOk1aSSU1d3VP9HR/wBuP/8ASaW7qn+jo/7cf/6TVpJJTV3dU/0dH/bj/wD0mlu6 p/o6P+3H/wDpNWkklNXd1T/R0f8Abj//AEmlu6p/o6P+3H/+k1aSSU1d3VP9HR/24/8A9Jpbuqf6 Oj/tx/8A6TVpJJTV3dU/0dH/AG4//wBJpbuqf6Oj/tx//pNWkklNXd1T/R0f9uP/APSaW7qn+jo/ 7cf/AOk1aSSU1d3VP9HR/wBuP/8ASaW7qn+jo/7cf/6TVpJJTgdJxs/GzepWV4GLjG/I3usbe55u MfTc3a7afLRau7qn+jo/7cf/AOk1S6NT6ed1R/2fHo9TIB30P3Pt9v07m/mu8lrpKau7qn+jo/7c f/6TS3dU/wBHR/24/wD9Jq0kkpq7uqf6Oj/tx/8A6TS3dU/0dH/bj/8A0mrSSSmru6p/o6P+3H/+ k0t3VP8AR0f9uP8A/SatJJKczqTuo/YMrcygN9GyYsdMbXf8GvHl7V1P/k3L/wCIs/6ly8VT4LJv d/4uzljCzPsza3D1Wz6jiO38lr11+7qn+jo/7cf/AOk1y3+LT+g5n/Gt/wCpXZpst0x2au7qn+jo /wC3H/8ApNLd1T/R0f8Abj//AEmrSSC588/xjHJN2D9paxp2Wx6bie9f7zWrjl23+M3+kdP/AKlv 5a1xKkjsxS3fXeju6h+ycLYygt+zUwS9wMbG/wDBq5u6n/o6P+3H/wDpNQ6L/wAjYH/han/z21XV Gyhrbuqf6Oj/ALcf/wCk0t3VP9HR/wBuP/8ASatJJKfGevb/ANtZ/qAB32m3cGmRO930Vr/4vzeO tWfZwxz/ALM7R7iBG+v91r1lfWH/AJe6h/4at/6ty2f8XP8Ay7b/AOFn/wDV1qQ7MY3fQWu6juHq MpDZ9xa9xMf9tq0kko2RSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpiOT8f4KSiOT8f4KSSlJJJJKUkkkkpSSSSSmp0v+g1/2v+qc raqdL/oNf9r/AKpytpKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp yOk0+l1Hqjhj49Asva71KX7n2+z6VzfzXLXWR0in0+pdUf8AZ8en1LmH1KX7rLfb9K5v5p8lrpKW XI9Rfnn6y9OyMnAyHV15voYlofQa/TdjZG94b9o3y52rpb9FojXQ9ckkN7V0IeRxh0tn1yY7BdgZ F9jclt32BjGZFR9jnnNLHv8AUlzYk7YceDOnXJJIdAFdbXSSSRU1ep/8m5f/ABFn/UuXiq9q6n/y bl/8RZ/1Ll4qnwWTfQf8Wn9BzP8AjW/9SuzXGf4tP6Dmf8a3/qV2abLdMdlJJJILngf8Zv8ASOn/ ANS38ta4ldt/jN/pHT/6lv5a1xKkjsxS3fZui/8AI2B/4Wp/89tV1Uui/wDI2B/4Wp/89tV1RsoX SSSSU+N/WH/l7qH/AIat/wCrctn/ABc/8u2/+Fn/APV1rG+sP/L3UP8Aw1b/ANW5bP8Ai5/5dt/8 LP8A+rrUh2Yxu+lpJJKNkUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+CkkpSSSo5fVum4IL8zKqqAsFLi5w9tjg HNa7w9p3eQ1OmqSm6kh2WV01uuscGsY0vc48AN1JXHY/1vdkt6rfjZ+PdGHVk4eOx9T3U7nXVu3b dziWtbW54MwTHxSulvbJLG6a/Mo6tl9Lycu3OZXj0ZLLbm1Ne03Pvrcz9XrqbH6IEe2dTqtS+70W h2x75MQwSUlIel/0Gv8Atf8AVOVtZfTs3bh1t9C8xOoZpy7+UrP2/wD7r5H+Z/5kkptpKp9v/wC6 +R/mf+ZJfb/+6+R/mf8AmSSm2kqn2/8A7r5H+Z/5kl9v/wC6+R/mf+ZJKbaSqfb/APuvkf5n/mSX 2/8A7r5H+Z/5kkptpKp9v/7r5H+Z/wCZJfb/APuvkf5n/mSSm2kqn2//ALr5H+Z/5kl9v/7r5H+Z /wCZJKbaSqfb/wDuvkf5n/mSX2//ALr5H+Z/5kkptpKp9v8A+6+R/mf+ZJfb/wDuvkf5n/mSSm2k qn2//uvkf5n/AJkl9v8A+6+R/mf+ZJKbaSxR9YQM9vT8jp+bQ6xtj6rbG1GuwVbdxb6dz3D6QOrQ pYHXznj1GdOza6HN3VZFja9tg/NLGtuc/Ua6tCSnYSVT7f8A918j/M/8yS+3/wDdfI/zP/MklNLp VJr6p1V32bHpFl1bvUpfutt9n0r2/mnwWwuf6ZeK+q9UtOAKvVsqPq0+6y3azm9u72lvDfJav2// ALr5H+Z/5kkptrzf62/WDrWF9YMvFxcuyqqv0trGkQN1dbj+JK737f8A918j/M/8yXmH1zs9T6y5 j9rmT6XteII/RVox3Wy2S9J+svXr+qYdNuba+uzIqa9pIghz2tc1eqLxfoztnVsJ0F0ZNJgDU+9q 9d+3n/uPf/mf+ZIyVBuJKp9v/wC6+R/mf+ZJfb/+6+R/mf8AmSauX6n/AMm5f/EWf9S5eKr2HqOb uwMpv2e8TTYJLNPou/lLx5Pgsm+g/wCLT+g5n/Gt/wCpXZrhv8XeR6OFlj07LJtbqxsxouu+3/8A dfI/zP8AzJNlumOzbSVT7f8A918j/M/8yS+3/wDdfI/zP/MkFzxn+M3+kdP/AKlv5a1xK7H/ABjX +vdgn031wy3+cbE61rjlJHZilu+zdF/5GwP/AAtT/wCe2q6snpGbs6ThN9C90Y1IkM0Psarf28/9 x8j/ADP/ADJRsobiSqfb/wDuvkf5n/mSX2//ALr5H+Z/5kkp8m+sP/L3UP8Aw1b/ANW5bP8Ai5/5 dt/8LP8A+rrWJ1527ree+C3dk2mHCCPe76S1/wDF/b6PW7H7Hv8A1Zwhgk/TrUh2Yxu+npKqzN3u a30L27jEuZAHx9ytKNkUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+CkkpS5jKxH5nVc44XT6riG/Zsh+RnX48+r XXvdVTXTc0bmbR6ggmCO2vTrh/rDZ0kdRzrsqvogycbbsxs/GbZl5e2quxuyx17He4u9NsMdqO/A Q3UHtWtDW7QIA0AHZV7unYeQ+999QecqkY1wcSQ+pvqQxzeP8K771YYZaDG3Tjw8lJIqG2jRwOlY nTPUOKLC64gvfdbZe920Q0epfY90DsJga+KvpJJKanS/6DX/AGv+qcraqdL/AKDX/a/6pytpKUkk kkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnnh0bMf1s5/wBnxcGpwtbfZjWuddlhw21i 9n2epo28zucRwNCUL6u/Vu7pGRU9+Nh4rKMY4znYRO7KdNe269vo1Q5orOm530jr46r+udKrcWOy AHNMEbXaH/NUqOr9OyrPSovFjzJDQD/coxmx3QnHi/vfy7rziy1ZhPh/ut9JJJSLHI6XTs6t1Wz0 MerfZUfVqfutt9nN7fzS3hvktdY3S6W19b6u9teIz1H0EvoeXXu/Rn+kt/NP7viFspKUvJ/rv/4q M3/rX/nqtesLyf67/wDiozf+tf8AnqtGO62ezQ6L/wAs4H/hqn/z41ezLxnov/LOB/4ap/8APjV7 MjNUF0kkk1c1ep/8m5f/ABFn/UuXiq9q6n/ybl/8RZ/1Ll4qnwWTfQf8Wn9BzP8AjW/9SuzXGf4t P6Dmf8a3/qV2abLdMdlJJJILngf8Zv8ASOn/ANS38ta4ldt/jN/pHT/6lv5a1xKkjsxS3fZui/8A I2B/4Wp/89tV1Uui/wDI2B/4Wp/89tV1RsoXSSSSU+N/WH/l7qH/AIat/wCrctn/ABc/8u2/+Fn/ APV1rG+sP/L3UP8Aw1b/ANW5bP8Ai5/5dt/8LP8A+rrUh2Yxu+lpJJKNkUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckoj k/H+CkkpDeXil5YHOcGnaGbdxMfm+p7Z+Oi5y2zr1rg5lfXKgA0bWfsc6tAaXe9zzLuT28IGi6PI YyyixljWuY5pDg9u5pEfnN7jyXBV19AzmNyem4nTrMd7Rtsb9W8u5ri32vLX1uY2NwPw4kxKQ3T0 fQRx/enTN4/1CdJaNl0kkkktTpf9Br/tf9U5W1U6X/Qa/wC1/wBU5W0lKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJT51mf0u7/jHflcr/wBWf+V6vg7/AKlyoZn9Lu/4x35XK/8AVn/l er4O/wCpcsDD/uiH9/8A7p6TP/uaf9z/ALl7ZJJJb7zbkdOZHWerO9PEbudR78czkO/R/wDaodiP zPJa6yOnM29c6sRXhsDjjnfQZyXfo3f0odv5HktdJSl5P9d//FRm/wDWv/PVa9YXk/13/wDFRm/9 a/8APVaMd1s9mh0X/lnA/wDDVP8A58avZl4z0X/lnA/8NU/+fGr2ZGaoLpJJJq5q9T/5Ny/+Is/6 ly8VXtXU/wDk3L/4iz/qXLxVPgsm+g/4tP6Dmf8AGt/6ldmuM/xaf0HM/wCNb/1K7NNlumOykkkk FzwP+M3+kdP/AKlv5a1xK7b/ABm/0jp/9S38ta4lSR2Ypbvs3Rf+RsD/AMLU/wDntquql0X/AJGw P/C1P/ntquqNlC6SSSSnxv6w/wDL3UP/AA1b/wBW5bP+Ln/l23/ws/8A6utY31h/5e6h/wCGrf8A q3LZ/wAXP/Ltv/hZ/wD1dakOzGN30tJJJRsikkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTEcn4/wUlEcn4/wUklMHGGkwTGsDlcQ/ LHUs4dQZh5XQ3OcH2XUYOc/MuA27W3ejjso9obw/1269u/cpJDe1dKW7ePxXPU/Wm1zc999GPYzB q9Tfg5JymOslzfQe77PVsskDTXldEZjTlc/Z9W8nOty7+q5ddj8nE+xtOLQaA1u71A9/qXZG5zT9 HgDXTVLqro3endQzL8zIwM/Hqxsiiuq4ejcb2OruNjQZdTQ4HdUZG3w1V+26mkA3WNqBMAuIE/5y odP6dlY+Vf1DqORXk5WQ2undVUaGNqq3ua1rHXXGZscSd3hpotJzWvEOAI8wkpz+nZ2E3Dra7Iqa ROheB3d/KVr9oYP/AHJp/wC3G/8AkkLpldZwqyWjv283K16VX7jfuCSkX7Qwf+5NP/bjf/JJftDB /wC5NP8A243/AMki+lV+437gl6VX7jfuCSkX7Qwf+5NP/bjf/JJftDB/7k0/9uN/8ki+lV+437gl 6VX7jfuCSkX7Qwf+5NP/AG43/wAkl+0MH/uTT/243/ySL6VX7jfuCXpVfuN+4JKRftDB/wC5NP8A 243/AMkl+0MH/uTT/wBuN/8AJIvpVfuN+4JelV+437gkpF+0MH/uTT/243/ySX7Qwf8AuTT/ANuN /wDJIvpVfuN+4JelV+437gkpxevdWtxMGzN6dnYbPQY97q72G82GP0bK/TyKYJOnBmR86/VesdUp xacjBzMBj7vSqGLdU6x/rWODXfpW5dQDWzLvYYAPKv8AVehV9TuxrxlX4jsRxsYKG0lpc4bd7m5F NwJaJ2+CM7pND8jEyrnPufhse1m4NAc6wNa6x4a1o3QCNIGp0SCinHUMHvk0/wCe3/ySf9oYP/cm n/txv/kkX0qv3G/cEvSq/cb9wSUi/aGD/wByaf8Atxv/AJJL9oYP/cmn/txv/kkX0qv3G/cEvSq/ cb9wSU+e5RDsq5zSCC9xBHfVXfq9bXV1St9rgxoa6XOMDhypZemXeB/pHflV76ttDur1B0EbXaH+ q5YGH/dEP7//AHT0mf8A3NP+5/3L1/7Qwf8AuTT/ANuN/wDJJftDB/7k0/8Abjf/ACSL6VX7jfuC XpVfuN+4LfebcXp+Ths631W0v6ewWfZtttFgOQ/bW4frQ3abeGeS1f2hg/8Acmn/ALcb/wCSWd0+ lo671UmnCa132ch9JnJdDP8AtU3tH5nktb0qv3G/cElIv2hg/wDcmn/txv8A5JeW/XSyu36y5llb g5p9KHNMg/oq16v6VX7jfuC8q+uwDfrPmBoAH6LQf8VWjHdbPZz+jOazq+C5xDWjJpJJMADe1ev/ ALQwf+5NP/bjf/JLyDooB6zgA6j7VT/58avZPSq/cb9wRmqCP9oYP/cmn/txv/kkv2hg/wDcmn/t xv8A5JF9Kr9xv3BL0qv3G/cE1c0eo52C7p+S1uRUSabAAHt19rv5S8cXs/Uq6h07KIY3+Ys7D91y 8YT4LJvef4ucjHpwcsXWsqJtbAe4Cfb/ACl2H7Qwf+5NP/bjf/JLkv8AFqxj8HM3AO/St5Hkuy9K r9xv3BNlumOyL9oYP/cmn/txv/kkv2hg/wDcmn/txv8A5JF9Kr9xv3BL0qv3G/cEFzwH+Mi+i67B NFjLdrLZ2OBjWv8AdXGrtP8AGW1rb8DaA2WW8CO9a4tSR2Ypbvr/AEfNwm9IwWvyKmkY1IILwDOx v8pXP2hg/wDcmn/txv8A5JA6NXWej4JLAT9mp7D/AEbVc9Kr9xv3BRsoR/tDB/7k0/8Abjf/ACSX 7Qwf+5NP/bjf/JIvpVfuN+4JelV+437gkp8d6+9rut9QewhzXZNpBBkEb3LX/wAXttVPW7H3PbW3 7M4S5wAnfX+8sn6wADrvUABAGVb/ANW5bH+LprXddsDgCPsz+R/LrUh2Yxu+iNzsNxDWZFTi4wAH gkn71YUBXWDIaAR5KajZGJTphpos7q/Vh0tjHGs2eoSNDEQmTnGETKXyrscJZJCMR6pOkm0hZXSe uM6q97G1Gv0xukumf+ig1fWnpgopty3PpfbRXkvYyu25tddhc1r3vrrLWtlh1dAHdLHkjljxQPEF ZMU8UjGY4ZRd1JY+d9Y8LCZm7RffZgVufaKse5zJaxtmz1m1urmHD87TvwU9f1i6eWYz7Bk1DL27 HWYuQ1rTY702te91O1nu/eI7HghPGq11k65/H6/YbwMw1U0AdSdbZqNrcHIZTWfpfuOJd58Qrbfr B0w49uUX3MZQ5jXssoursm07a9tNlbbHbzo2GmTwl0tRFGnUShZXSOr/ALTGbaxp9PGyDTW11b6r CG11WHey7Y4Ol55A7Kt076ytyOnO6t1BtGPjMLGD0Ln5NjLLC1vo31tx2FljXPaC3XVCv5f3lO+k sjG+snScy9mNS+71LLDTFmPfW1tjQ53pPc+lrWP2tna6CRHiE/8Azk6S2q617rqRj7PUbdjX0u/T P9Nhay2ljnBz9JaCip1klj3fWHFqz8HC9HJJ6gxz2P8As942bS1o3t9GW/S90xt7xKl1brR6XmYW Oad9eW8i63dHpDdXW123a6Rvtbu1EDVJTrJLFt+sNNPWbenWsFeNj49l9uY58Br6vRc9mzb2Ze0z u7xCjl/Wnp+NgWZrGZFvo2VVvpdj31Wj1nNa13pWU7452nbBIiZS6Wp3Ellt6/0x+QzE32ix5a2X UXNax9ga5lVr3VbK3uDh7XkHUaahRd9YulNbfZ6lpbjW+hY5mPe4G31PR9Nm2v3v36QyT34SU6yS DRc3JpZfWHtbYNwFjHVvH9ZljWuB8iEZJSkkkklKSSSSUpJJJJSkkkklKSSSSUxHJ+P8FJRHJ+P8 FJJSkkkklKSSSSUpJJJJTU6X/Qa/7X/VOVtVOl/0Gv8Atf8AVOVtJSkkkklKSSSSUpJJJJSkkkkl KSSSSU5XVuqjpQqc6s2+qSAAYjbH96zx9b6+Pszv88f+RS+t4/R40fvP/wC+rmdZWVzfN5sWYxif S6/Jclgy4IzmPV6v0j+8+g4V4ysWrJA2+o0OjmFYHCpdF/5Lxv8Aiwrq0oEyhEn91ysgEZzA/eZJ JJJ6186zP6Xd/wAY78rlf+rP/K9Xwd/1LlQzP6Xd/wAY78rlf+rP/K9Xwd/1LlgYf90Q/v8A/dPS Z/8Ac0/7n/cvbJJJLfebcjAZt691R3p4jdzcf9JSZyX+139JHYN/M8lrrIwRWOv9UIGCHubjz6Dp yyNrv6U3sP3PJa6SlLyf67/+KjN/61/56rXrC8n+u/8A4qM3/rX/AJ6rRjutns0Oi/8ALOB/4ap/ 8+NXsy8Z6L/yzgf+Gqf/AD41ezIzVBdJJJNXNXqf/JuX/wARZ/1Ll4qvaup/8m5f/EWf9S5eKp8F k30H/Fp/Qcz/AI1v/Urs1xn+LT+g5n/Gt/6ldmmy3THZSSSSC54H/Gb/AEjp/wDUt/LWuJXbf4zf 6R0/+pb+WtcSpI7MUt32bov/ACNgf+Fqf/PbVdVLov8AyNgf+Fqf/PbVdUbKF0kkklPjf1h/5e6h /wCGrf8Aq3LZ/wAXP/Ltv/hZ/wD1daxvrD/y91D/AMNW/wDVuWz/AIuf+Xbf/Cz/APq61IdmMbvp aSSSjZFlj/WDpeR1KqpuOWg1kk7jHK2EkzJjjlgYS+WS/FklimJx+aLhfV/pGV06y19+2HtAG0z3 +Cav6tbMLIw/tM/aOn19P37Po+mb/wBJG7Xd6/Hlzqt5LRDFijhjwx+VOXNLNMzl80nCyegXZWbl ZFl9VNWVRZjvZj0uZY/extbTe/13tt2N+j7AR2MTNTK+qednOx3Zubj3CgUgB2K47DRZ6gfj7sp4 qLxAeYcT4gaDqCUgn3R/l/LqxuBd9V2ZFNlF15LLWdQqcAwf9r725H5znj2bY8/LhQo+rFmPh249 JwMS42031W4OF9nbvod6g9VgyHeoNI+k3uuinVJK/wCX4qOu7n9M6flYQyXZN7L78u313PZX6bGn 0664az1Huj2fvLP/AObuVk5FuZnZNLsi12NLsbHNLS3FubkDeHZNznOO2Ad2g7LoEkuoPZTjXdAN r3O+0FhfnNzZa3UbWNr2D3fyZn8Fn4X1Otoe6y7KqfY44u+2vHdW+z7Lc3I33PsyLXWWPiC4n5aQ uokTCUiYSBrUfy6K/l/zuL83Pzen35GdhZ+Ne2p+IbGuFlZsD67du9o22VbT7BB1HkU3U+kVdTsB yHfovs9+M+uPpC/09ZnTbsWmklSrecH1TFmG3Eyst17ji5WPkXOY0OtszHU2PtiYEOq+jqI07J6v qua+m5WAz7Bi2ZDqnttwcH7M0Gl7bG+qz7Q/1NW/vBdEkip52v6rlnVP2taOn322WV33WW4O68Pa yut3oXfaJrHsloIcQSdSrT+jPPTL+n1vx7fXyLsg/a6DfVF17sjaam3VTt3aHdyJWwkl0pTU6bi3 YOFTi33OybKm7XXPmXnx9znu+9xPmVbSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklMRyfj/BSURyfj /BSSUpJJJJSkklij6yU1uyq87EycF2Lj/anNu9F2+uXN9no32iZbEGOQkp2klm9P6oc667Fuxb8L Ioax7qcj0iSyzdseDTba2JY4czotJJTU6X/Qa/7X/VOVtVOl/wBBr/tf9U5W0lKSSSSUpJJJJSkk kklKSSSSUpJJJJTzf1w/m8X+s/8A76uZXTfXD+bxf6z/APvq5lYXP/7on/g/9F6D4d/uaH+F/wBJ 7vo3/JWL/wAWFd7ql0b/AJKxf+LCu91s4f5uH9yLhZv52f8AfkySSSUix86zP6Xd/wAY78rlf+rP /K9Xwd/1LlQzP6Xd/wAY78rlf+rP/K9Xwd/1LlgYf90Q/v8A/dPSZ/8Ac0/7n/cvbJJJLfebcjC/ 8UHUf6B/N0fzH9N4P9K/k/ueS11kYRH/ADg6iP8AJ8+nR/R/6dx/2q/k/ueS10lKXk/13/8AFRm/ 9a/89Vr1heT/AF3/APFRm/8AWv8Az1WjHdbPZodF/wCWcD/w1T/58avZl4z0X/lnA/8ADVP/AJ8a vZkZqgukkkmrmr1P/k3L/wCIs/6ly8VXtXU/+Tcv/iLP+pcvFU+Cyb6D/i0/oOZ/xrf+pXZrjP8A Fp/Qcz/jW/8AUrs02W6Y7KSSSQXPA/4zf6R0/wDqW/lrXErtv8Zv9I6f/Ut/LWuJUkdmKW77N0X/ AJGwP/C1P/ntquql0X/kbA/8LU/+e2q6o2ULpJJJKfG/rD/y91D/AMNW/wDVuWz/AIuf+Xbf/Cz/ APq61jfWH/l7qH/hq3/q3LZ/xc/8u2/+Fn/9XWpDsxjd9LSSSUbIssT6y/WP/m5VRb9n+0+u4tjf sjaJ/dettc79b/q/mfWCnGqwn1VmlznO9UkTuA42tekN0G60X+rP1s/5xX3U/Zfs3otD59TfO47f 9GxNifWex+y7qeNVi49uHb1BllVz7y2qk17/AFWfZ6tph+kbpghV/qh9V+odAyMi7Mspe25ga30i 4kFp3e7dWxX6PqxhYvQ7+kYraqbMvHdj35VdTWusc5jm+q9rfpH3Tqfmid0x8Utn1g6bXVXaTkH1 9xrYzGyH2ObXG5/pNpdZs9w922NRrqEj17p7HOsNzDQMenJY9gse94yHurq2sbXruc2GgEkkxA0l 8/p2bZlU5vTsqvGvqqsod61JvY6uw1u+i26lwc0sGu6PJY3/ADXfk234D2bcWnEwcei7JZVcy+zF ttucX0ts1Y7eA4HbMmPFD+X8vwUNtf5bO2frD00Y4yd1u11hpFXoXeuXgbiz7P6fqzGv0ONeNUB3 1mwWZ7sO5l1LGYwy3X203MY1jg553udXDIDe5GunOiFV9XcnGx6Bh2YWHkY17r2HGwjVju31upcH 0NyZJh3IeOyl1DoGR1Cx77cpgZlYZwstopnf9Mh9W67az3P4cHSNPNDr/Lt/FQ/l9v8ABst+sHTD RblF9zG0FjXssoursm07a9tNlbbHbzo2GmTwq+P9YDdg9V6hVS+1mA97aqfTsptcK6q7Nr2WN3h2 5xH0eO3iGn6sWUYduPScDEuNtN9VuDhfZ276HeoPVYMh3qDSPpN7q9hdPzcOnLJyarMvLs9YW+iR Ux/p11/zXrbi39HMb58+6Xf+Xb+1Q6Wix/rDU3ApzuoGhrMm01Yx6fZZnttIa50NNWOxxPsdoGnj mdEXB6/0vqVracKyxzntc9hfTdW13plrbA19tbGl7XGHNmQZkaFVsT6vXU5Tc7Ivrfecz7Zb6FJp refs9mLAY660h3vlzi4yjU9BNLsR/wBo1xHZTpayC77U5zvb7tNu7zlE+ClO+snSm13WvddUKPT9 Rt2PfS79M/02FrLaWOcC/SWgpY/1gxsjqrelsqyGudS29tj8e5jfdu9r99Tduje8a6c6LNwvqdZj ufZdlVPtf9l32147q32HFubkb7n2ZFrrLHxBcT8tIWs7pt46u3qdN7WsNIx7qX1lxcGudYwseLG7 TL9ZaZ8kO3+F+X8VHY1/Lb+1hR1v1OuZPR7afTFLA6u/dIsIbXZY3bt9u0Wt7mdfBVsH61Y2TTdk ZdT6GNyfQxm1B+RZc11VeRW9tVNW+XV2TABgDUqXVPqy3qQyD9pdRZkXsubZW33Mb6TcW1g92u+r cJ7TPZQ6h9Vas42PmhxdlNyq68rHGRQ3bj14ux9XqM3e1kghwgx4akbJ0Tv+suAMvBxq23WM6g2x zLWU3EN2FrYf+j9urju3RtjWESn6ydIvquvbc9tdFJyXPspura6lv0rKjZW31G+bJ7eIQP2HYwYH oWY2McJttdldGMa6X137fUFVTb/0Z9uhl2s6FVcL6nsw8DL6e04TG5GI/DbkY+EKciHDbvutbe4W Hufa2Trol1KB0t1Leq0/szI6njtfYyit9oba2ylz9gceLGtMGNDtjuJUP+cPTBkjDfY4XbmVu/RW mtj7WssrY+709gLg8bZImY5VrOwxmYGRh79nr1Oq3xMbmlsx81SPQpbePX/n8vHy/o/R+zDHbs+l +d9n57T3jUDfw9P9qunj6v7GGb9aen4mLdlVsyb20Wtpftxr9pLrPRdsf6O120z9GfDuFZb1vCdl V4p+0Msu2+n6uNfUxxcz1Nvq2UtZu29pnkRKz3/VrKu+3b8qmn7WWPYzHx3V1ttZb63rWsdkvbY9 20BxG0kc9oifqxlXdWq6rmZVN76bm3tJx3eq1za/TdXVY7JeK6nGXbQ3nkk6pa0o9WfS/rDdk1C7 Nr9n7Pw8xwxqrbH+pkm1r2tZX6ryPYOBI1lFP1owXZuJi0Mvtbmiza/7PeNjqntrc17fRlvunduj bydCFX/5r3MwhjY+b6bm4uHibvTO1wxHvc7e1tzHFlofDmh407mYUsH6r3dO+yOxsiit2Nbe97K8 cspLMlzXPZVU2/8ARxt9p3GPAonc0k1en8vT/Fst+tHTa8ei/KeWm6hmS70K772V12fRfY9tP6Nv tOtjW8HwKM/r/TK837A+x/rNsbU4+laa22WNa5jHXNr9MFweNsu145WePqvmVYgwsXOZXXZhU4GU bKC9z20tfXvqPrs2OIeeQ4caczcPQ2xkNZdtbfmY+WBs+gMYY7dn0td32fntPGiWnF4f2/wQfBtY nVMTPstrxfVd6Dixz3U2srJa4sdstsrax8EH6Lirqyum9Jvwc7KzLLqduTr6ONS6hm8uc51r2uvt a6x0gOcACe86RqpdFdV0kkklMRyfj/BSURyfj/BSSUpJJJJTEzHtEmNBwuar6N1zKxeoVdVbi15e cwgZlFz7C0tO6ittbserbWz+uSTJ5K6dJJTkdNw+oftDI6n1NtNV11VWOyrHsda0V1GyzcX2VUmX OtOm3SOdVo3UMyGhry8Aa/o3urP31uajJJKcvp+BQ7DrcXXgmfo33Acu7NtVr9nY/wC/f/7EXf8A pRN0v+g1/wBr/qnK2kpq/s7H/fv/APYi7/0ol+zsf9+//wBiLv8A0orSSSmr+zsf9+//ANiLv/Si X7Ox/wB+/wD9iLv/AEorSSSmr+zsf9+//wBiLv8A0ol+zsf9+/8A9iLv/SiLbYK63WO3ENaXENBe dPBrdSfIKji9Y+2dPfnY+JkPey2yk4n6IW7qrHUvbLrvS5aT9PhJTZ/Z2P8Av3/+xF3/AKUS/Z2P +/f/AOxF3/pRD6Z1FvU8Y5DabKHMsspsqu2bmvrO1wPp2Wt7diVeSU1f2dj/AL9//sRd/wClEv2d j/v3/wDsRd/6UVpJJTy31qxa8evH9N1h3OdPqWWWfu/6Rz4XPLpvrh/N4v8AWf8A99XMrC5//dE/ 8H/ovQfDv9zQ/wAL/pPZdKwaLOnY9jnXAuYCdt9zR/mtsgK7+zsefp3/APsRd/6VQ+jf8lYv/FhX e62cP83D+5Fws387P+/Jr/s7H/fv/wDYi7/0ol+zsf8Afv8A/Yi7/wBKK0kpFj51lNAybmiYD3DU yef3lc+r1Tbup11vLgC12rHOYeHfnNcxyp5n9Lu/4x35XK/9Wf8Aler4O/6lywMP+6If3/8AunpM /wDuaf8Ac/7l6z9nY/79/wD7EXf+lEv2dj/v3/8AsRd/6UVpJb7zbz2J03GH1iz4fja00z6ORd9u /wDQj9J9D9xa/wCzsf8Afv8A/Yi7/wBKKli/+KLO/wCT/wCZp/mf6d/6EfyP3FrpKav7Ox/37/8A 2Iu/9KLy/wCuVbafrJl1sLi0elBe4vP81X+c5z3L1peT/Xf/AMVGb/1r/wA9Vox3Wz2c7ozQ/q2E wyA7JpBgkH6bfzm8L179nY/79/8A7EXf+lV5H0X/AJZwP/DVP/nxq9mRmqDW/Z2P+/f/AOxF3/pR L9nY/wC/f/7EXf8ApRWkk1c5nUen0NwMpwffIpsOt9xH0XdvVXjy9q6n/wAm5f8AxFn/AFLl4qnw WTe7/wAXeLVkYWYbDYItaB6dr2dv+Dcxdf8As7H/AH7/AP2Iu/8ASi5b/Fp/Qcz/AI1v/Urs02W6 Y7NX9nY/79//ALEXf+lEv2dj/v3/APsRd/6UVpJBc+ef4xsavHuwRW6w7mWz6lllvev/AEjnwuOX bf4zf6R0/wDqW/lrXEqSOzFLd9d6RgUP6ThPLr5djUkxfc0fQb2Fuiufs7H/AH7/AP2Iu/8ASqh0 X/kbA/8AC1P/AJ7arqjZQ1v2dj/v3/8AsRd/6US/Z2P+/f8A+xF3/pRWkklPjPXmhnWs9gJIbkWg biXH6TvpF3uK1/8AF/Sy/rVjHl4AxnH9G9zD9Ov86tzHLK+sP/L3UP8Aw1b/ANW5bP8Ai5/5dt/8 LP8A+rrUh2Yxu+gNwKGPD2uvJaZG6+4j/NdZBVtJJRsikkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTEcn4/wUlEcn4/wUklKSSSSU pJJJJSkkkklNTpf9Br/tf9U5W1U6X/Qa/wC1/wBU5W0lKSSSSUpJJJJSG02CtxpAdYAdrXHaCewL troHnBWHgdP6vT0zMxM3Dwch2RkXXNpde99L25FrrHstLsPTbuj6BnyXQeapO6z0sc5VX+eE0yjH 5ikAy2HEg+r/AE/K6bhOoyPTZuussqxqXF9WPW4+2lj3tY4gc/RAEwBAC1VXxszGyi77Pa23bG7Y ZiePyKwiJCQsIIMTRXSSSRU839cP5vF/rP8A++rmV031w/m8X+s//vq5lYXP/wC6J/4P/Reg+Hf7 mh/hf9J7vo3/ACVi/wDFhXe6pdG/5Kxf+LCu91s4f5uH9yLhZv52f9+TJJJJSLHzrM/pd3/GO/K5 X/qz/wAr1fB3/UuVDM/pd3/GO/K5X/qz/wAr1fB3/UuWBh/3RD+//wB09Jn/ANzT/uf9y9skkkt9 5tyMbT6xZkfs/XHqJ9H+nn/j/wDg/wBxa6xsd4/5y5jP1CRj1H9ED9u5/wAOf9H+6tlJSl5P9d// ABUZv/Wv/PVa9YXk/wBd/wDxUZv/AFr/AM9Vox3Wz2aHRf8AlnA/8NU/+fGr2ZeM9F/5ZwP/AA1T /wCfGr2ZGaoLpJJJq5q9T/5Ny/8AiLP+pcvFV7V1P/k3L/4iz/qXLxVPgsm+g/4tP6Dmf8a3/qV2 a4z/ABaf0HM/41v/AFK7NNlumOykkkkFzwP+M3+kdP8A6lv5a1xK7b/Gb/SOn/1Lfy1riVJHZilu +zdF/wCRsD/wtT/57arqpdF/5GwP/C1P/ntquqNlC6SSSSnxv6w/8vdQ/wDDVv8A1bls/wCLn/l2 3/ws/wD6utY31h/5e6h/4at/6ty2f8XP/Ltv/hZ//V1qQ7MY3fS0kklGyKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklMRyfj/AAUl Ecn4/wAFJJSkkkklLKrVn4VwudTkVPbiuLLyx7SK3t+k2za72lvcFWlxwa7Kx/rFh9PxMhnrlr8a uzHux2Prrx6KXMYbK6m/SYRE6/DVJT0+F1Lp/U63WdOyqctjDtc6ixtgafAurc6Craw+lWPzes5v U6qracV+Pj47fXpsx3PsrdfY47LmsfDRa0TEHXwWvc29zQKLG1unUubukf5zUlIel/0Gv+1/1TkW +5tFT77A8trBcRWx9jiP5LK2ucT5ASqPTqs84VZZkMaNYBqnu7/hFZNXUQCRksPl6P8A6kSUiwOs YPU7LqcX1hZjhhtZfj3Y7gLN23TIrqmdp4WgsTo2B1anGfkZltdeZm2HIyGemHbHODWNZubZB2Ma 0fJaPo9R/wC5LP8Atn/1IkptJKr6PUf+5LP+2f8A1Il6PUf+5LP+2f8A1IkpsrzZd/6PUP8AuSz/ ALZ/9SLgFl/Ff8n/AIX7HW+Ef5X/AAf+6ek+p3/az/rX/oxdKuV+qjch32r7PY2uPT3bmbp/nP5T F0Ho9Q/7ks/7Z/8AUitch/ueH+F/0i1PiP8Aumf+D/0Q20lV9HqP/cln/bP/AKkS9HqP/cln/bP/ AKkVpqOL9cP5vF/rP/76uZXQ/WpmS2vH9extgLnRtZtj6P8AKcueWFz/APuif+D/ANF6D4d/uaH+ F/0nu+jf8lYv/FhXe6yulVZrum45ryGMYWCGmqSPn6iuej1D/uSz/tr/ANSLZw/zcP7kXCzfzs/7 8m2kqvo9R/7ks/7Z/wDUiXo9R/7ks/7Z/wDUikWPCZn9Lu/4x35XK/8AVn/ler4O/wCpcqGUCMq4 OMne6TETqrn1eba7qlYpeK37XQ5w3Dh35u5iwMP+6If3/wDunpM/+5p/3P8AuXuUlV9HqP8A3JZ/ 2z/6kS9HqP8A3JZ/2z/6kW+820cd5/5yZVfqYZH2dh9JjYzBr9K13ev91bCwKRmH6w31DLwTYMZh LG0/rQG7l/u/m/3deVq+j1H/ALks/wC2f/UiSm0vJ/rv/wCKjN/61/56rXp3o9R/7ks/7Z/9SLy/ 65Nsb9ZMsWuD3j0pcBtB/RV/m7nox3Wz2aXRf+WcD/w1T/58avZl4v0cOPV8IMIa45NMEiYO9q9e 9HqH/cln/bP/AKkRmqDbSVX0eo/9yWf9s/8AqRL0eo/9yWf9s/8AqRNXK6n/AMm5f/EWf9S5eKr2 HqNWeOn5JdkMI9GyR6UT7Xf8IvHk+Cyb6D/i0/oOZ/xrf+pXZrhv8XbMl+Flmi1tY9VshzN06f1m Lr/R6j/3JZ/2z/6kTZbpjs2klV9HqP8A3JZ/2z/6kS9HqP8A3JZ/2z/6kQXPF/4zf6R0/wDqW/lr XErsf8Yzcht2D69rbCWWxtZtjWv+U9ccpI7MUt32bov/ACNgf+Fqf/PbVdWT0erOPScIsyGNBxqY BqmBsb/wiuej1D/uSz/tn/1Io2UNtJVfR6j/ANyWf9s/+pEvR6j/ANyWf9s/+pElPkv1h/5e6h/4 at/6ty2f8XP/AC7b/wCFn/8AV1rE68HDreeHkOcMm2SBEne781a/+L9tz+t2Ch4rd9mdq5u7TfX+ buYpDsxjd9PSVVtWeHAvyGOaDqBVEj4+orSjZFJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmI5Px/gpKI5Px/gpJKUkkkkpSSSSSl JJJJKanS/wCg1/2v+qcjutYww5wB81X6Z/Qa/wC1/wBU5cx9aZ/an/W2/wDflBzOf7vDjriZ+W5f 7zk4L4XrvXp/fH3hEXnFX843+sF6K3gfBM5XmvvPF6eHhX85yh5Tg9XFxs0kklaaqy82XpK82WX8 V/yf+F+x1vhH+V/wf+6ek+p3/az/AK1/6MXSrmvqd/2s/wCtf+jF0qs8h/ueH+F/0i1PiP8Aumf+ D/0QukkkrbUeb+uH83i/1n/99XMrpvrh/N4v9Z//AH1cysLn/wDdE/8AB/6L0Hw7/c0P8L/pPd9G /wCSsX/iwrvdUujf8lYv/FhXe62cP83D+5Fws387P+/JkkkkpFj51mf0u7/jHflcr/1Z/wCV6vg7 /qXKhmf0u7/jHflcr/1Z/wCV6vg7/qXLAw/7oh/f/wC6ekz/AO5p/wBz/uXtkkklvvNuRU8H6y5F fqYZP2Vh9Jo/XB7vpPd/o/DzWusit0/Wa5nqYf8ARGn02t/XR7+Xu/0fh5rXSUpeT/Xf/wAVGb/1 r/z1WvWF5P8AXf8A8VGb/wBa/wDPVaMd1s9mh0X/AJZwP/DVP/nxq9mXjPRf+WcD/wANU/8Anxq9 mRmqC6SSSauavU/+Tcv/AIiz/qXLxVe1dT/5Ny/+Is/6ly8VT4LJvoP+LT+g5n/Gt/6ldmuM/wAW n9BzP+Nb/wBSuzTZbpjspJJJBc8D/jN/pHT/AOpb+WtcSu2/xm/0jp/9S38ta4lSR2Ypbvs3Rf8A kbA/8LU/+e2q6qXRf+RsD/wtT/57arqjZQukkkkp8b+sP/L3UP8Aw1b/ANW5bP8Ai5/5dt/8LP8A +rrWN9Yf+Xuof+Grf+rctn/Fz/y7b/4Wf/1dakOzGN30tJJJRsikkkklKSSSSUpJJJJSkkkklKSS SSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTEcn4/wAFJRHJ+P8A BSSUpJJJJSkkkklKSSSSU0+mf0Gv+1/1RXMfWn/lU/8AFt/78un6Z/Qa/wC1/wBUVzH1p/5VP/Ft /wC/Kl8S/mf8NvfC/wCf/wAByqv5xv8AWC9HXnFX843+sF6OofhX+U/wf2s/xffF/hfsXSSSWm5S y82XpK82WX8V/wAn/hfsdb4R/lf8H/unpPqd/wBrP+tf+jF0q5r6nf8Aaz/rX/oxdKrPIf7nh/hf 9ItT4j/umf8Ag/8ARC6SSSttR5v64fzeL/Wf/wB9XMrpvrh/N4v9Z/8A31cysLn/APdE/wDB/wCi 9B8O/wBzQ/wv+k930b/krF/4sK73VLo3/JWL/wAWFd7rZw/zcP7kXCzfzs/78mSSSSkWPnWZ/S7v +Md+Vyv/AFZ/5Xq+Dv8AqXKhmf0u7/jHflcr/wBWf+V6vg7/AKlywMP+6If3/wDunpM/+5p/3P8A uXtkkklvvNuRW/8A7JbmephmMNp9Jo/XB+k+k93+j8B4rXWQ1/8A2TvrFmHrhBxqA/XP5z6bnf6L t8VrpKUvJ/rv/wCKjN/61/56rXrC8n+u/wD4qM3/AK1/56rRjutns0Oi/wDLOB/4ap/8+NXsy8Z6 L/yzgf8Ahqn/AM+NXsyM1QXSSSTVzV6n/wAm5f8AxFn/AFLl4qvaup/8m5f/ABFn/UuXiqfBZN9B /wAWn9BzP+Nb/wBSuzXGf4tP6Dmf8a3/AKldmmy3THZSSSSC54H/ABm/0jp/9S38ta4ldt/jN/pH T/6lv5a1xKkjsxS3fZui/wDI2B/4Wp/89tV1Uui/8jYH/han/wA9tV1RsoXSSSSU+N/WH/l7qH/h q3/q3LZ/xc/8u2/+Fn/9XWsb6w/8vdQ/8NW/9W5bP+Ln/l23/wALP/6utSHZjG76Wkkko2RSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpiOT8f4KSiOT8f4KSSlJJJJKUsn6wvezEoqFj6mX5WPRa+txrcK7LGtcA9rmObu4kGdVrIN+P RlUvx8qtl1Vg2vrsaHNcPBzXaFJTmdB313dSw22W3UYmWKqH3WOucA6mix7PUsc952ve7knw7LUu surANNXqknUbg2P85QxMPEwaGY2HTXjUsnbXUwMY3cdxhrdBqrCSnK6dfmjDrDcXcNdfUaO7lndW 6J1DqWV9obWKxtDdpcDwujrYytoYwBrRwApaJmXFDNHhmPSvxZp4JcUDwyePZ9WOpNc18AwZ5H/k l0ovzR/2k4/4RqtpJuLBjwXwDh4l2bmMnMcPuHi4Wr9ozv8AuJ/4I1Qtzsuloc/FMOe1gixvLy1o /FyvIb62PEOAIBDgD4tO4H71KxNc35pEfZOf+EauYP1W6lyQ37x/5JdkkocvL48/Dxji4WXDzOTl +L2zw8Tg9F6bn9J9bdSLPW28PAjbu/vWn9ozf+4n/gjVa4Tp+PHHFERj8q3JklmkZz+aTV+0Z3/c T/wRqgzOyn2WVtxDuqIDv0jfzg138VeUBWxrnOaAC8y4+OkJ6xw+s9P6h1VtbW1Cv0iTq8GZj+5Z f/Nfqfg37x/5Jdjt8Eo8Sq+TlMOWXFKPqbGLnc+CPBCXp/uxc7C+3YeLVjnG3mtobu9RomFY+0Zv /cT/AMEarSSnAERQa5JkSS0rs7LoqdbZiHa3mLGqf2jO/wC4n/gjVZexljSywBzTyCpIqePu+rXU bLX2QBvcXRI03H+sj9N6H1Hp+Y3Kcxrw0EbQ4DkQumiOE8BVo8ngjLiEfV9WxLnc84HGZ+n+7Frf aM7/ALif+CNS+0Z3/cT/AMEaraSstdw/8pt+sH2k4tPpPxCxrQG+vubY1zibv3PcPb46rR+0Z3/c T/wRqsGthsFpA3tBaHdwHRI/6IU0lNT7Rnf9xP8AwRq5Drv1O6l1jql3UmltQu2+wkGNrG187v5K 7pMiDSCLfP8AB+ofU8PNx8sva8UW12logT6Za6PpfyV232jN/wC4n/gjVaSSJtQADSpzsu+pt1eI drxImxqn9ozv+4n/AII1WK62VsFdYDWtEADspoJc/KdnZGNdQMXabWOZPqN03DauH/8AG66r/pWf cP8AyS9HTogkIIBeZ+q/Reo/V7HupdW2/wBZ4dIcGxtG3+Uti3OyqQ0vxT73hgixvLuFdUX1sfG8 A7SHCexHBQTs1/tGd/3E/wDBGpfaM7/uJ/4I1W0klPJ/Wn6vdR+sL8d7Gij7OHgguDp3bf5TP3Vh /wDjddV/0rPuH/kl6OkjZQYgubgjOxMHHxDjbzRUysuFjROwNbP4ItWbl2Osa3EM1P2O/SN5hrvy OCvKDWMYXuaAC87nEdzAbP3AIJa/2jO/7if+CNS+0Z3/AHE/8EaraSSnz/qP1F6nn9Qyc0PawZFr rQ0wdu47oncrv1b+q3Uug57814beHVGraCG/SLXTO7+SuySSso4Q0n5mTS0Ptxi1m5rSQ8GNxa3j 5q8oPrZYNrwCJBg/yTuCmklSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpiOT8f4KSiOT8f4KSSlJJJJKUkkkkpSSSSSlJINt1NO31 rG1+o4Vs3OA3Odw1u7knwWF1/wCsWPjY729OymOfj2hmcaDXbbj1w/3uZY7aP0jWtLn6Nkk8FJTY ysrNvzL3dDyRdbhBrb8K1o9B5dudsbc1u5tkeZA0kK/03Pp6nh15tLXMD5Dq3iH1vadr63js5rgQ Vk9Cp+1Wt6tTktfdtFOfdjtH2bMc1ntezxcwuA9QcwRHZu1TjUY7rnUtDTfZ6tkfnP2tbPlowJKb CSSSSlKp1HLx8DDvy8q30Kqq3OfZpLfh5+A7lNkdSwMSu67JyKqmY5DbnPeBsLtu0O8C7cIHdcvn 9dGR1S3Cyrq7unPZLcTZXa3OosrGwYvu322OtcRodrQNeZSU69Odn9Mvx6OpudkYeYWsx8x7Ay2u 1+rKcljRtl3DXADXQiSCd1ZuP0plfTz0zLtfm0zDTd9MVzuY0vbqXMj2u5476rSSUpJJCuvqx6n3 3vbVXWC59jyGtaG8lxdwElJVk9Susty6enYGacbqHpvyGsDW2Vmtpa39Ox3uDHOdAgg8wdCm6v1q jFpuxMO+l/UhUbKcUOa612m6W1btzjtkgd1kdEsHXDXltzHX5mOS+rMrbXvqpca/1TM9HYwvfqXV ge2B3AJSnb6P1R2c27Hy6/s+diPDMmgHcBu9zLGO71vbq0/EHUFaaAMWj7Uc1rAL3sFLrO5Y0uc1 vyLj96OkpSSSpdV6pi9Hw3Z2Zv8ASa5jD6bS902ObW32t15ckpurn6OtZGK9js2xuXg3XnGZnVsN bqrmvNXpZNTuPe2N4gToQOTT+sHWctzWuxgH4D2HIacW1zMi3HqbXZbk03Nsa0BjrWtFZB3k9grH T+jZXqZ2JnPdm9M6vT6rrLKxRayyG1ubaxuz32MIMhjYLTIBOqU9IkoMbsYGAk7QBLjJPxU0lKSS Wff1npdApdZl47ftWmOXWsAsP8g7tdYCSmHVchlYoxG5T8XJy7AzGNQa57nN9zvZY14LANXeXcaK HTuoZJy7Ok9WYxuZWz1a7atwryagdptY130XNLgHskxI1IIXO9OzrPrDb9j6le77WHB1VdbGNysD Ira51tkN91dTTFbfUkv8wdetOGx78a/JAtyMYHbaAW+5zdrzG7h3hr28ElNtJJJJSkkF91NTq2WP ax1rtlYcQC50OdDfEw0lc9176yU1Uj9l5jCGXejl3UursNDiHNrFvqb21tc8Q55aQIPdJTZvzM6z Iysnot/2xuG8VZGC8NDHOaxrnNx7mt3CyHDRxInT26kamBm4/UcSrNxiTVc3e3doR+81w7FpkEdi svodDLbT1XFvn127Ms1sjGyrmtb+s0Ddp7pE/necArXx8ajFa9lDQxtlj7nAcF1h3PP9oklJSdJJ JJSlS6pl0YWBdkZNzsdgaQLK4L5PHptc18v8BBSyOq9Nw6n5GVlU0VVP9K19ljWhj/pbHHdo6DML mMnq46h1O/pnU7G24lksGBtrLshth/VX4jmu3vMN9R1k7W8cgkJTtY+bn4GbV0/qrhfVlSMTNDfT LngbvRvY32h+0EtcIBiIB52ln09OH2GrDzrXZvova9ttoh5Nb/Uqc4t5c3aNe8ea0ElKSSQb76cd htve2tjYl7yGgbjtGrvNJSZZGdfkX5v2TpOYK8zGr9SzHewPocHFu1txa3exzvzSDxJgofXOuU4d GTRhZDHdQpax76GRZcyoub6trad25xZW4uj4eOtDou3q1tXUq8wW5mPHq5dAY6u2h7nObiXuqd6d ljRrLR7SdOTuSnb6V1EdRocX1nHyMd5pycd5k12t2uie4IcC09wQVfVZmJQzJty2Mi28MbY4E+4V 7tmnE+46/wBwVlJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklMRyfj/AAUlEcn4/wAFJJSkkkklKSSSSUpJJc/1zrmRiWY2 N0r0rbsp1rWF7XXNfbTs/Vx6djNr3byZLoaGuMGElIut9Urz8h31ew6Kcyx7LDdXkmyljjT6bvSq t9PabffMtJ2xJhV+gdNzrnYVj2+ni9Me99F9rS3MeLBbXbjXt+jLXmXOEh0NI11FrpnR8O5hbSa7 elusN9dDC6cfLrs95xrW7Henv3fA8aGB0aSmIAAAGgHACkkkkpSrZeXRgY7snKdtqZEkAuJLjtaG tbuJLnOAAGpKnbdVS0G57aw5waC4gSXaNHu7lcpbnP8ArBdbj5pZRjY+UKsa1jHNyMfPrs20Bu5z 22mPe72BoHJcJISkV12V1jJx+uYdFbLGXOrxbmGw++t1lIo6hVta5u4OO10TW4/f0PQunW4GNb9o DGPyb3ZPoVD9HSbA3cxnzBJPiSi4GCccuzMhtYzshrG5VlO5tdjq5a1+xzuY+caSYC0ElKSSSSUp YvW+tV4JZ09mw5WSWMBvY847Ba51bXXva3aN20hrS4bjoELqv1mxMTGyLMO+p78extWQ8tda3H3P dXNrK9rjqwhokE6dtVV6dgvz8iy+9uOL8lgq65hBpdTYHB/pH6T2ttDI3N3EQ7Un2lJTSweidQsb k9HZQ3Ex33MuuD97ji21+nsfhW/4StzKhs4LCII7DtkGilmPSyircGVNDGhzi4w0ACXO3OPxOqMk pSSSDZZtDm1w63YXMrJgu2/wmNUlIupZzOmYb821rn11Fhs2/m1uc1r7PgxpLneQXL5uR9YLLsvo 2f6GXVnix2CW/q731/Sb9mt97DbVodr443BxExpUZvUOnZbsf6w5NNtGRivyi8VittJpdVXbV9J2 5n6du2dfij4vRLMG2umixl3TGP314uQze7He36H2ezs1p4BBjsQNElIOjdCqfj05fUsVtdrwzIdh WtrezGy/8LZR9PZvdrAdE68kroUkklKSSVDqfUW9PxL7wBZdTS+9tE+5wrGvtaHuj4ApKRdc63jd Ewn5NwLrAyx1VQDzvNY3e41tfsZxucdBOq55nTc/7fktx8TGc7qNUZFLi5+DdS8/0ih232va5/6W v86dwM82MJ2X1XKq6iy6hvUQxxxbK63sqy8Ca93rVOfa5gc93sO6e8RIXRYODi4GP9lxGelS1znN YC4tbuO6G7uBroBoOySl+nYrsLBxsN9hvdj0spda76TzW1rd7vMxKtJJJKUkkuc6z13LqycXB6UK LrMprjX6odYy4sdtfU19bmtZsEl7jMD80kwkpF1jqjOqX2dFwKGZbqWutsbY+zHe59Nm0jDt27TY xwPuBhrtCRrDfV7pubZZg5VwY3GwKHY2PZsLL76XNa1tWQx30Nhb7hrLhIgaKx0npGG6pn2dzb+l 1WjJ6d9Jr6LA928VWe2ajrHiCRq0hdCkpSSSSSlKrm52N0/HORluLWNIb7Wusc4uO1rWsra5znE9 gCivuqqLRa9rDY4MZuIG5x7N8SuSqzbvrI5j8p1eKW2j9m3MrcL6M1oc6zHcxzn+qGNb+lMNHI7S EpF6ud1LJw/rDg41QvvBdjljnOqt9tjTjZg2/o7WsLg2zgGWnsD0vROnO6ZhDGftn1LbQysQysWv dZ6de781u7/dwiYOE3G33mtlWXlBr8v0S70nWtG1z2tdxPjEnSZhXklKSSSSUpYPW+r1Mur6JQym /JzHei9mUHjHDXssdsssbW5u5+2AyZMzEKf1g627ptDPsr6zZZeMdz3NNwqe5jrGB1VbmOJeWhrR uGrhr2NPp/Sm5xyBc2kVZZjrGC2XsZl7WO9Smzs/6O+O4BBBBJSmn0rpObc2rCZUMbGxMsZRfkbn ZWNdW9lj6GP+jax7HQ23d9AkELsgAOBCixoY0NEw0QJJJ+93KmkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/ H+Ckojk/H+CkkpSSSSSlKLnNYC55DQOSTAUlyGbazqNjep9SxW5mJgl+N1Hprx6v2W1p/pLatsWj ZB1bO0gt7gpTp9S62cfqDOk00Oufb6bbDW9rbGi7c3dUzvsDC5xMAAck6Kv0npeTdg43TM+nByel Y9Qa2xgFzcsQPSf6Tq9rfbqSHGTxoq/RuidJ6j9ovqa9+Ax5q6dbXbZVuxnMrdbS11bmF+P6u7aH SPDSF1FdbKmNrraGsYA1rWiAA3gAJKWqqrprbVU0MYwBrWNEABvAA7IqSSSlIF+RVjVWW2HSlhsc BqdrRzHyVXq3UD02mrJeIxzaK8m2Y9Gt4c0W/Br9u6eBJ7Lk8nFowarcPKoH/OMTZ03qVTZtzrPz Dv8ApeVtRO0N1HsiEp0jmZnW78bOxqKq7en3H0K7rmupyfVrd6jGPY10W1NbOgcBqJOsbOD08Cwd Rz8fG/aTtwdfWwF7K3E7ahbta4hrYE6THCbp/QemdMs9XEqLCAQxpsseyoOO5zaa7HubWCezAFpp KUkkoPeGMc8yQ0EmBJ+5JTNZPXOpW4GE+3Fg2MfWy6wAPGNVYffkWM3SWsbJ/wBklVH9fuObXdTT k5GBbj1W4oxcd1ovN25zi636NexsaEjnvwM76vYOZbmO6pTVXstttYMt49O0VeuXX03Vbdz797DW 4l20ASO4KUv03BPU8zOfhZtLbWkV5Gbh11vpzKrQ50X1O31+uzx10I0gwuqxcXFwqW4+HTXj1N+j XU0MaPg1uiB0/puN02uynD3MpdY6xtMyyvdG5tQ7M3SY7EmI4V5JSkkkklNDqucOm4ZythscX1VV tLtoNl1jaa9zuw3PEnw8VjWUDqefYctlnTOuYlIfi2Mcb6zU0ul1R2s9VhNm21paD9HQe0qHVaK+ l2Y93Ws1+Ri9Stvxc6m9xNBY6q/Iq9Kr81zfRDW7dTPcwtHpXSX1vx8/IycnIFVJbi1ZbWttpZdt c4Wua3c5/sA1+cnVJTHAxbesNw+rddw20ZeMHHHpDnkMFnp7nPa7ZrurBALZbp3W4kkkpSSSwuvX ZWQ53RKLfsduZTvw8glwFllbt1uOSza5u5kagzBcR9FJTc6p1Svp2N9oMWOc8VNG8MYHn997tGgf nH8DwsfGd1jKybeq9OpoZbn0VtsqynxZjbTY2q5m2t7n1P1cGu2nTtJilRg9F6jmY+DidObg3y6n rXT2N2MFLa3OY6z09jSfV9M1WDU6xwY6rB6di9PY5mOHy87rH2PfbY8xt99ljnOOnnokpfD6bhYA f9jx6aHWndc6mtte9377tjdSraSSSlKLnNaJcQ0cSTCTtwaS0AujQHQSuRvtx+oOr651nFZmdPaz 7Nl4tzRb+zr6y5tr/S+i4btHO27gII9pMJTodV6uL8u7oFdTttwdjXX12BtlXqVeo65rP3K2vaS8 uGpAEnRPhdNyc2inD6zi4F/T6KtrGVtF1dzpbsuayyvbWGtB0Bd9LnTWp0ToPTc+mzItZZZjeo6r BsNlrDbg+1zK7drm+rXv37N8+2Ox16kCBA4SUs1rWNDWgBoEADQAKSSSSlKrnZ1OBiZGZaS5uJU6 6xrYLtrQXfwVbrGc7DZS1zvSpyXnHdlCD9nssH6F7g5u2N8DXuQuXOJi4rWdOsxG0/WRljPTyK2l xzmOe31bH2O3OsrcyfVa9x2/5pKU6bcnqHU82jqmPj0tyMI347aLrgar2Wei59lFra3u31OYGuOy NXCe61+ndObSft2XRj/tK0EX5FVYDiN25rPU2tcQ3Qa8xKXTui9P6UZw63CG+kzfY+30653enV6j nbGce1sDQeAWikpSSSSSmJIaCToBqSVjdZ+sH7LsroooOVdc31W1teGkt3NY1tejt73F2g45JICo dWsyOp2vY6gZI6Ve52Z0kncMmiz3U3sB2h5a0SGulpcHDkAoXSemdG6pl3XdOa4dLqFdmM6l1mP6 OQ/e3JZjurcx7A5mwPaNN0jmYSm50/p2cKz01zcTJ6W6+6y25x32WNc6xz6batrmF7bDDnb+3Erc xsbHw6GY+JUyimsQyqpoY1o/ktboE+NjUYlDMbGYK6qhtYxvACMkpSSSSSlJJJJKUkkkkpSSSSSl JJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkk kkpiOT8f4KSiOT8f4KSSlKrmZuLgY7sjLs9KsECSCSXO9rQ0N9xJ8BqrS4zO6n1TqGDi9Vc2mnH+ 0CzGtaXOdiXNLqQzLZ3a7ca3lsFpPBiUlNnMybXsb9bKM718XDuH6Ghx9JuJ/N5Hqt72N3eoZ42g CNSdTO6K3Jym9Twch+DnABpurAcy1v5rL6ne2wDsdCOxCr9Nwsu7qGXlZmE3Cqy6W1ZOPvbay+0b mushvbZ7ZMFwiQIC3GtDQGtEACAB2SUtW0tY1piQADtED5DsppJJKUsbrXW6MWu/CxMisdUdWRi1 v49ZzXekwud7A535oLhKN1jPvwhi1YwrFuZeMZll8+kwuY+zc/bqZ2bWiRJIWDX+0Lc3qWFldOZl DL2vz8DeACSxtNeTj22bGvre2kAgw5rgkpP03LzhnsxMpuTkdL6jux2DqTA29tza7rnjZsbNTmVk Se/GhWr0zpLulPNOPkvfghv6HFuG80nwqt3btkToZ8iAIUumdPdj42JZnkXZ9GO2l9/0j/Ka1x8+ TpMCVppKUkkoWPZWw2WENY0FznHQADukpmsgdbNPVX4Gbjvx6n2CrEy3n9Hc/Y2xzP5J1hvZ2sai FRyc6vr7sfCxcrK6TeXfasZ7q9hyWtY7aWbnbXsaXBzqzrA1A5Uqciz6y4eZ0PqFBqtoP2fMyKg1 9Be0td+gc7f7nDX6MsPOoEpSR3TeodOddT00G/puS5znY1dno3Yz3H3nGe727XOk7CRBOhjRa2Hi UYOPXjYzSypgho1J19xJJ1JJkknUlLExaMLHZi4rBXVWA1rR/rqe5PdWUlKSSSSUpJJJJSC7Gx8g 1nIqbaaXi2reA7Y9ocA9s8HU6o6SSSlJJLFz+pdUHUndO6XXQ62nHZlObkOe31g5769lTm8Fuz3E g8t0SUmyt/WKmM6Zm+lQLnNyL8ZzTZ+j3N9Nhc17Qd8T5fFUMOzF65gDpHVnnIy6X3h1lYLHtONk WY9eRvr/AJp7tkt47xoCq2LiWhmN1H6psOI65xxc7GyBNbDSHVufe31N3q1lkSCd2gJiHDo8TCxM EW/ZamVnItdfcWCN9r9XPd5lJTDAx8vFqdVlZJzCD7LXsDLNn5rXmv2uPmGj4K4kkkpSBkZWNjBj sm1lQscK2F7g3c930WN3ck+CJY702OftL9oJ2tEk+QXLfbz1bGwL+v4lF/TM8tOPZS5zhRbe11LK shrud3qlu8cO7DQpKbWbX9YcXqFedjPdl1ufd6mIX11YrMZrXbP0jq/UFpftM6j6Q0ABRK8BvVG4 /wBYelW2dPyM2mqyxrmh7LWOa1zRkVdy1ukhwPaYT4HTM21t/TusbcvptL9mMMgbrrWt2lrrXbtp DdRq2Xcnz3AABA0ASUoCBCdJJJSlUdfRlHJw8fIaMiluywMINlRsbuYS3toZEqt1bPyse3Ew8MVN uzbHMZbkT6TTW11m2G6lzo0EjgntBxn0W5JyOo9Oxjh/WPCsHrVNduZf6m1rRY5zmb6HhstOhbBg SCClIvq/1bJz6q+g9VrPUabqdlmW9pcG2bNz8TJ9u02Ng6yJETB56DpvTbumuNQy7MjFDYprvHqW VfyRd9Jzf68nzVjCrtpxmMv9P1TLrfRbsYXuJc7aPieTzyrSSlJJJJKQ5GRRi0PycmxtVNTS6yx5 DWNDeS5x4WNn3dbHWKbcOk5eI+mMYV2iqltrvpvyne5xZs+hDTrOkwRXzOrZORXmXZOLXkdJxsh2 PlVMLvtNYx3jdc5v0XM9u7YNdpB1mEbB6dm4ua7CwHNPQbq/U2vM+n6m4ejiubZuDHaHXRvDefal L047frDTX1Fwf07qWHZbjG/HeHwa3OreyXN221Oc2Yc37iFtY7bq6WMve2ywD3vY3YHHudm50fel j49GJSzHxq21VVjaxjBAaPIIySlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKYjk/H+Ckojk/H+Ckkp wPrH0oZONl9S9ext2LjOfh7XloptrFlnqN2u2kuO0GQdBHcoWD0/p/Wy/qNLb6MbJc19rGP2Y+YW hrvV9P6UTpIjcBrIieiIDgQdQdCCkAGgAaAaABJTJJJJJSlB4c5jmsdtcQQHRMHxU0klPHZ+HgdJ zqulW13Z1fVsO4WYznue7IyaLMbY9u93teRc4ufIgCZ9um/07pNOBY+03X5Nr2tr9TJfvc1jS4tY 121ukuOvJ7k6K+WNLg8jUAgHuJ5/IppKUkkkkpSwus3dYxjdmh1Ten4xYHYzq95vqdt9dzn7vbtD jtG3sZkHTdVbOw6eoYduDk7vSyGGt+wlrod4ObwUlOFR0nKu9LAx8ujJ6f03LY+q0knJoOOWu+zT 9E6ewuLp2kggnVdIGhohoAEzog4uLj4OOzFxKxVTU3axjeAP9e6sJKUkkkkpSSSSSlJJJJKUkkkk pp9Qwxn45xXWPrY9zTZ6bi0vY07izc3UB3BjsubxcbBt6jkfV5rcg29Oyy/EvpeQ/Cpux6rv5135 rrHua1hmR2hunYKAY1pLgAC7VxA5SU1un4VPT8cUVF7pc5732O3Pe95LnPcfEn5eCuJJJKUkkkkp 536x9PbXjZnXTdYMnCYL8Y73MrpFI3uG1rtpD9d88jTspYHS+n9Qe7qFDMjHxbbxkNxy7bRe9pbY 3J9Lkbnie08kardc1r2ljwHNcIIOoIU0lKSSSSUpAya7Lsa2qqw0vsY5jLGiSxzhtD2jy5R0klPI ZeH03A6i/oPpXZNOfTVdVih73O9euxzXZDbXO3VkDaXO3DUDudeg6f0qvp5ss9a3Jvu2iy+9wc8t rnYz2tYIbuPbuVc2N3B8DcBAPeFNJSkkkklKWZ1To9HVnsbmWW+jW1wFNb3Vj1Hbdtm6tzTLNp2+ EytNJJTyHRKMb6x4tWa52TXc7Fpoz8uh3pV5dmyLa3D84s43gAiYB0IHWMrZUxtdbQ1rAGtaOAG8 BJrWsAawBrRwAIAU0lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUp JJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTHufj/BSSSSUpJJJJSkkk klKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklP/9kN CmVuZHN0cmVhbQ1lbmRvYmoNMjQzNyAwIG9iajw8L0xlbmd0aCAyMTA4L0ZpbHRlci9GbGF0ZURl Y29kZT4+c3RyZWFtDQpIiaxXaW/jOBL97l/BTwsb6CgkRepYGAYcxx5kkUwfdu9MY3qx0CbqxDu+ xlIm0/Prh0cVRcpK7GwWgWKJLBaLdbx6/K13/sOckvuqdz5bU3K57X3snc93xYYMh6PRxeWE9CjR f4z82mNkSbQ80/IXi975YqEnFt+UzOJWCS2e1D+yqAij+vdPPbQnjFsNnMQJ4WmUpHlKFutenw0W /+1NF73pjdqmtSuaZbdhdptGk8yUmpSTNI4jDvp+6U9/nk4+L67+OSXzzzc340+DWPS/DP61+Mdz uxzTTnlEnXal+fpq8WWQs/7ZS0pDDx0oZ4xHXMq4pX0+GV8ru8HqxYBlfXIzXUw/kcvph+v3X26m Py7m78iH6/GPc/I38uHT+w/v5+Pr+RFL6GGsIiq5DtXheRP1kjXeXJW39X55Swa8/1gvV8t6OWD9 siLqf7Ev9c+6+HW5uddvVV0Wd9/1226/vd+XVUWWG/35uLvfF3cgVT+Uy71+uX2s6u263FdfOeeD VPaN0k2x2hq50tt6XdZKTo8+LesHciycE/7vJik7DylEJPCQQ0pFqp6Jesb2V+pvoZ4ZpTQe8VjJ XEg1nqiH2jkprdxFMkrF0MrxIcxnoCMDObWOal2XjT6jP7GP5FYO7ZDM2oKyWpeW8b/FhdXv9M3A Ltw3se9ujYTxuNnPnxc5jHF7hpf24mAj7oE+k965A72wH/qIZ2BvBudPwb6J/dZyAuXU+osZ+GoC Z2CwbtLsQy+sXXqNfqh6Z8ybj0dppnUKiEc8OjmNOjIopk3hDu0JtaVKq94sxiSZuCGmzsfUOBP2 nc7cVGC2HXJew9OmbsoFRLgAunya2diZlUkwbYaYdZ/2CqaZfkeNmCLCs+PCsyOBaRgzEUydN03y MxAfuyFnah4qFo1pHVWFUwfFNJKJdiY7FjyHdUmU54kJn31TFkeSi0yFUKgQyuN9KFB3puJOW9gp UqWJ8yzMCoNn6sn7i4elAS/7/3FHvu236/8DijHpGukvmAHSi5f145k8Ev4g12Sz5hWxt/KgE7/j xEMcDCC1NgpvLxFUxyhOh1Alni785dIVlT0XnEXbYs6SNqhi/IFoNGv2apWb1RM36CcuW8iUNGs7 is+OY9VJl+VWry/PQt9ixQJuhPLZmxGKsoYWvSqafiTbFnn9CpAJsdtGxZa+icgM+2cXBiAAPFf9 3aWfva70da0K0V08MuUNBbAVui93231Nqsf1utgv/7Qs5/Zxvy83teE3ati8GDpiCnpT1cVqVdTL rfraVO9IUZGncrUyVKYiu1Wx2ZR3+uuu3K2239dKlSVPmzuiWNJuWxUrtezNWCDVi9+PhFcnjHvF iSHA9mCTdsTpEHoBoDeCBTQeq8T1d4zvxPsGpVhpjPmkRI6YDp4hWJmvMbZaDSbMAgbgCYBNPmic YM+IDVsm8WFTieHBMKlp2z7Z4KLHCEHVcRoDbkD13B5IeBodf/ICA8j3v1Q/VfRd5PIgIThuh6Uf HJ87dHoD4kgRB/3IOBViizhtXJQGJiTpYVSSBMfiEJvRSyDHOANKpxkXn3iLMXBJk/su75NGzoRj 1hjg5Yudl966uHEV+jHQ1dB0+500yePC69koBTjIq0djq7dH4IyWg4ycB89QG+5czxSW1Yc+8ei5 g+GWHeCPt6QGz4Nm1G7BNo6a5uMZZeLPdLTdU5sAjZSKEDRZzCMa6yLxzdKAvf1GborvhFPG35E4 IevlarXcbhr0h5voQ/F7Sf5TlhsCLcCCvEb1Y1DuDPP4YxJHjCaBOf2r6ZSUVb1cF7XqRPVDoVrP yxz1eJNgIspA/3P1dQGh91MBYA47PFMpwzKvS3vdPkibV3V36thHJ4NwvIo6Toela/ab+Ljg97/W zSszDOJURx76kGUhyPEcjB17jcLvIEy0ujAeS3pVHzSDBlUAnUNOCJowUEEf72ignf3uAHHa4UZh hhApGjuCtoHktWmjhzc5mOwI+SE9QaNE46guSHIOYq2Lx/MeizN7JTEDsSflcj8DguKf8TB5vMlX wZCC++6yZImPQkhF92VlyGKxUzzxDwMDq+8aZJJUvlNbkwCQAhjaKXa63m7qBwVR9ZNGqc32iWhw qh9KUqpfhXNvppxMBmjS7Sjjo5Orjdo9qHeJCUgMvdTNfiThRsh4/HzSwWR30jEuhk39OGl7J8EP JJJjj1g2FBBUvEgBDQM9zZaODgcTsArJmw8yB8Z7hQ57Ss82hIi0tdLxJEF9hu65QTTHbyb8C6XE FjFKTHBmvnrunRUd4YwJ9sq9s/nkCO6ZuEXS3qLz7D6GuGtN0t7uwLgUJDlciMagfnJyrXt5LOMo 5jzzE7l/eh8/LAgRsnpbYF54KTzgNOwGxhVIvwMIbVorHlx4TjftOABT+uylC9ttGIvD9QKT2O9c WBpyJPOhadEvOPv8hzkj9xU4nbd9pXwdp2lORJpHsWDMOH22vH/cl4RFZG5w80bjJrmysFnUiuRp EDUA+Xn+d8UAaXqmaKAkX/tAAquvg5MDlxtbcmUNjzKZpYSzNIqTmGPgYgwYFg9cJ9hlE1Te7ono aA9DjEODNLak+uVrKcjklnILuCJh0M0aVWWZqzKgOUAM/Nsr8jOOa20QmQ6ioUSQFDHiENAkv6+7 6wfI8lYyO5qDVzmTwCdXo4y4SE087Jsi/pGMhSCcq0RJqIlJnwexhWxxCn/r2UiqpJJplGbqlyYR zzg54/oykXDVsns/kY2SVNlJdXaCRMpEZnY3guoaKFVSQV4kMs2UGTJKea6ckZDbde/8ak3J5bb3 0ZrysfeXAAMAT6Fjlg0KZW5kc3RyZWFtDWVuZG9iag0yNDM5IDAgb2JqPDwvTGVuZ3RoIDM3L1Bh aW50VHlwZSAxL01hdHJpeFswLjgyMDg5MiAwLjAgMC4wIDAuNzYxODU2IDU4LjI5OTIgNTEyLjE5 Nl0vUGF0dGVyblR5cGUgMS9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW0wIDI0NDMgMCBSPj4vQ29s b3JTcGFjZTw8L0NTMCAyNDQxIDAgUj4+L1Byb2NTZXRbL1BERi9JbWFnZUMvSW1hZ2VJXS9FeHRH U3RhdGU8PC9HUzAgMjQ0MCAwIFI+Pj4+L1hTdGVwIDMyLjAvVHlwZS9QYXR0ZXJuL1RpbGluZ1R5 cGUgMi9ZU3RlcCAzMi4wL0JCb3hbMC4wIDAuMCAzMi4wIDMyLjBdPj5zdHJlYW0NCnEKL0dTMCBn cwozMiAwIDAgMzIgMCAwIGNtCi9JbTAgRG8KUQoNCmVuZHN0cmVhbQ1lbmRvYmoNMjQ0MCAwIG9i ajw8L09QTSAwL0JNL05vcm1hbC9DQSAxLjAvT1AgZmFsc2UvU01hc2svTm9uZS9jYSAxLjAvQUlT IGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIHRydWU+Pg1lbmRvYmoNMjQ0MSAwIG9i alsvSW5kZXhlZC9EZXZpY2VSR0IgMSAyNDQyIDAgUl0NZW5kb2JqDTI0NDIgMCBvYmo8PC9MZW5n dGggNj4+c3RyZWFtDQr///8AIGANCmVuZHN0cmVhbQ1lbmRvYmoNMjQ0MyAwIG9iajw8L1N1YnR5 cGUvSW1hZ2UvSW50ZW50L1JlbGF0aXZlQ29sb3JpbWV0cmljL0xlbmd0aCAzNS9GaWx0ZXIvRmxh dGVEZWNvZGUvTmFtZS9YL0JpdHNQZXJDb21wb25lbnQgMS9Db2xvclNwYWNlIDI0NDEgMCBSL1dp ZHRoIDMyL0hlaWdodCAzMi9UeXBlL1hPYmplY3QvRGVjb2RlWzAuMCAxLjBdPj5zdHJlYW0NCkiJ am5ubmYHAj4gkAECCyAoAIIHQHAQCJppLA8QYAAm7S/RDQplbmRzdHJlYW0NZW5kb2JqDTI0NDQg MCBvYmo8PC9MZW5ndGggMzUvUGFpbnRUeXBlIDEvTWF0cml4WzAuNjE1NjYyIDAuMCAwLjAgMC41 NzEzOTYgNDM3LjI0NSAzOTkuMzQzXS9QYXR0ZXJuVHlwZSAxL1Jlc291cmNlczw8L1hPYmplY3Q8 PC9JbTAgMjQ0NSAwIFI+Pi9Qcm9jU2V0Wy9QREYvSW1hZ2VDXS9FeHRHU3RhdGU8PC9HUzAgMjQ0 MCAwIFI+Pj4+L1hTdGVwIDMuMC9UeXBlL1BhdHRlcm4vVGlsaW5nVHlwZSAyL1lTdGVwIDMuMC9C Qm94WzAuMCAwLjAgMy4wIDMuMF0+PnN0cmVhbQ0KcQovR1MwIGdzCjMgMCAwIDMgMCAwIGNtCi9J bTAgRG8KUQoNCmVuZHN0cmVhbQ1lbmRvYmoNMjQ0NSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvSW50 ZW50L1JlbGF0aXZlQ29sb3JpbWV0cmljL0xlbmd0aCAyNy9OYW1lL1gvU01hc2sgMjQ0NiAwIFIv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1dpZHRoIDMvSGVpZ2h0IDMv VHlwZS9YT2JqZWN0Pj5zdHJlYW0NCgAAAAAfVQAgSgAAAAIjUQQlVAAAAAAfTQMkUg0KZW5kc3Ry ZWFtDWVuZG9iag0yNDQ2IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9JbnRlbnQvUmVsYXRpdmVDb2xv cmltZXRyaWMvTGVuZ3RoIDkvTmFtZS9YL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlL0Rl dmljZUdyYXkvV2lkdGggMy9IZWlnaHQgMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KABgfAKz0ADhN DQplbmRzdHJlYW0NZW5kb2JqDTI0NDggMCBvYmo8PC9TdWJ0eXBlL1hNTC9MZW5ndGggMzE3L1R5 cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhp SHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iQWRvYmUgWE1QIENvcmUgNS4yLWMwMDMgNjEuMTQxOTg3LCAyMDExLzAyLzIyLTEyOjAz OjUxICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIi8+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+Cjw/eHBhY2tldCBlbmQ9InIiPz4NCmVu ZHN0cmVhbQ1lbmRvYmoNMjQ0OSAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0 b3IgMjQ1MSAwIFIvTGFzdENoYXIgMTIxL1dpZHRoc1syNzggMCAwIDAgMCA4ODkgMCAwIDAgMCAw IDAgMCAzMzMgMCAwIDU1NiAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgNTU2IDAgMCA1NTYgNTU2IDI3OCAwIDU1NiAwIDAgMCAyMjIgODMzIDU1NiA1NTYgNTU2IDAg MzMzIDUwMCAyNzggNTU2IDAgMCAwIDUwMF0vQmFzZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIv VG9Vbmljb2RlIDI0NTAgMCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1l bmRvYmoNMjQ1MCAwIG9iajw8L0xlbmd0aCAzMjcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJXJLPboMwDMbveQof10MFhRZaCSFNtJU47I/G9gA0MR3SCFGgB95+dlx10iKBf0k+kw87UVUf a9vPEL37UTc4Q9db43Eab14jXPDaW7VJwPR6vs/CWw+tUxElN8s041DbblRFAdEHbU6zX+Dp2YwX XKnozRv0vb3C01fVrCBqbs794IB2hhjKEgx29KGX1r22A0IU0ta1of1+XtaU86f4XBxCEuYbMaNH g5NrNfrWXlEVMY0SijONUqE1//aTe9ql09+tV0XC4jimQLwT3jEfhY/EqWhS1qSiSVmz3QamoIps E5gCsaxnYV30GeuzTDhj3gvvmSvhilnOzfjc7CR8Yj4L008VufjJ2U+eCCfMqXDKLB5y9pCLh5w9 5AfhQyjOvQpcJuomPHqgb95T+UPLQ9254r3Fx61wowPK4kf9CjAAjy+eXA0KZW5kc3RyZWFtDWVu ZG9iag0yNDUxIDAgb2JqPDwvU3RlbVYgODgvRm9udE5hbWUvQXJpYWxNVC9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzIvRGVzY2VudCAtMzI1L0ZvbnRCQm94Wy02NjUg LTMyNSAyMDAwIDEwMDZdL0FzY2VudCAxMDA2L0ZvbnRGYW1pbHkoQXJpYWwpL1hIZWlnaHQgNTE5 L0NhcEhlaWdodCA3MTYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2Jq DTI0NTMgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDI0NTUgMCBSL0xh c3RDaGFyIDE2OS9XaWR0aHNbMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA1 NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgMCAyNzgg MCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAw IDU1NiAyNzggMCA1NTYgMjIyIDAgMCAyMjIgMCA1NTYgNTU2IDAgMCAzMzMgNTAwIDI3OCA1NTYg MCAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MzddL0Jhc2VG b250L0FyaWFsLUl0YWxpY01UL0ZpcnN0Q2hhciAzMi9Ub1VuaWNvZGUgMjQ1NCAwIFIvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yNDU0IDAgb2JqPDwvTGVuZ3Ro IDMyNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckslqwzAQhu96Ch2bQ/CSxEpAGIKb gA9dqNsHcKRxaqhlITsHv31nNCGFCuz5xKz+x0lVP9eun2XyHkbTwCy73tkA03gLBuQFrr0TWS5t b+b7Lb7N0HqRYHKzTDMMtetGobVMPtA5zWGRT0c7XmAlkrdgIfTuKp++qmYlk+bm/Q8M4GaZyrKU Fjos9NL613YAmcS0dW3R38/LGnP+Ij4XDzKP94yHMaOFybcGQuuuIHSKp5T6jKcU4Ow/f35Pu3Tm uw1C5xScpmiE3jBvImfMGXHOnCNvd5HRIB+YD8i7bWQ0QhebyGiQOb6g+KJgLoj3zHtirlNQnaJi rohPzCfiMzN+lFY8j6J5FPdS1EvxDIpmUNxXUV/F9RXVPzKjIXHuKpBMuE352IG5hYDyx5VH3Unx 3sHjr/Cjl5hFj/gVYABszp5SDQplbmRzdHJlYW0NZW5kb2JqDTI0NTUgMCBvYmo8PC9TdGVtViA5 Mi9Gb250TmFtZS9BcmlhbC1JdGFsaWNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0 MDAvRmxhZ3MgOTYvRGVzY2VudCAtMzI1L0ZvbnRCQm94Wy01MTcgLTMyNSAxMzc5IDk5OF0vQXNj ZW50IDk5OC9Gb250RmFtaWx5KEFyaWFsKS9YSGVpZ2h0IDUxOS9DYXBIZWlnaHQgNzE2L1R5cGUv Rm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgLTEyPj4NZW5kb2JqDTI0NTcgMCBvYmpbL1BhdHRl cm5dDWVuZG9iag0yNDU4IDAgb2JqWy9EZXZpY2VOWy9CbGFja10vRGV2aWNlQ01ZSyAyNDYxIDAg UiAyNDU5IDAgUl0NZW5kb2JqDTI0NTkgMCBvYmo8PC9TdWJ0eXBlL05DaGFubmVsL1Byb2Nlc3Mg MjQ2MCAwIFI+Pg1lbmRvYmoNMjQ2MCAwIG9iajw8L0NvbXBvbmVudHNbL0N5YW4vTWFnZW50YS9Z ZWxsb3cvQmxhY2tdL0NvbG9yU3BhY2UvRGV2aWNlQ01ZSz4+DWVuZG9iag0yNDYxIDAgb2JqPDwv TGVuZ3RoIDkxL0Z1bmN0aW9uVHlwZSA0L0ZpbHRlci9GbGF0ZURlY29kZS9Eb21haW5bMC4wIDEu MF0vUmFuZ2VbMC4wIDEuMCAwLjAgMS4wIDAuMCAxLjAgMC4wIDEuMF0+PnN0cmVhbQ0KSImqNtQz AAMFIwVDhaL8nBwFYkQMFDLzUlIrEDJcyWVFCqkVyRkKxaVJCHWmCrroZqAoNAUq5ALLmxBQaQIz 0hhTIarlxjCVRgSMNIJbXpBfoFALEGAALqdHsQ0KZW5kc3RyZWFtDWVuZG9iag0yNDYyIDAgb2Jq PDwvU3VidHlwZS9Gb3JtL0xlbmd0aCAxNjUvU3RydWN0UGFyZW50cyAyL0ZpbHRlci9GbGF0ZURl Y29kZS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0ZvbnQ8PC9U VDAgMjQ2MyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBS Pj4+Pi9CQm94WzAuMCA3OTIuMCA2MTIuMCAwLjBdL0Zvcm1UeXBlIDE+PnN0cmVhbQ0KSIkUjjsL g0AQhPv9FVtqkbv1fBEQCx+IIVZuF1JIfCAhZ4iGg/z63DXzMTMMjOzfg8Ysk9dBL+hN+tQUvuzK tsKQMM+LqkQoGEioEEmQQrJIU3yCbHrCZQfJTBggz0DID9uzsYK8Y0COPxd9rHFThyhWIlAxqrOg OEmQX3DzjDF+GnliGtd90/P21eNwrJsWejpkW9f+nS9QM9SdPfQXYABNQSyoDQplbmRzdHJlYW0N ZW5kb2JqDTI0NjMgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDI0Mjgg MCBSL0xhc3RDaGFyIDExOS9XaWR0aHNbMjUwIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDUwMCA0NDQgMjc4IDAgMCAyNzggMCAwIDAgMCA1 MDAgNTAwIDAgMCAwIDM4OSAyNzggNTAwIDAgNjY3XS9CYXNlRm9udC9EVFpIUForVGltZXNOZXdS b21hblBTLUl0YWxpY01UL0ZpcnN0Q2hhciA0Ni9Ub1VuaWNvZGUgMjQ2NCAwIFIvRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yNDY0IDAgb2JqPDwvTGVuZ3RoIDMw Ny9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlckc1qwzAMx+9+Ch3XQ3GSdQ6FEBjdCjns g2V7gNRWOsPiGMc95O0nW6WDGRL9jPSXLEkeuqfO2QjyPcy6xwijdSbgMl+CRjjh2TpRVmCsjtdb /utp8EKSuF+XiFPnxlk0DcgPci4xrHD3aOYTboR8CwaDdWe4+zr0G5D9xfsfnNBFKKBtweBIiV4G /zpMCDLLtp0hv43rljR/EZ+rR6jyveTH6Nng4geNYXBnFE1Bp4XmSKcV6Mw/f6lYdhr19xBEUz1T cFGQIT4yk7DZPWQmQ7xn3hOrMjMZ4h3zLjHHqxSvFLNKzFqVtVxLpVqKa6lUq77PTIaYc9YpZ805 65SzrpnrNrVYFfzSIrd47SU1SzuB2yT1JQQaYl5cnl6am3V4262fPZAqfeJXgAEA6duTLA0KZW5k c3RyZWFtDWVuZG9iag0yNDY1IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9JbnRlbnQvUmVsYXRpdmVD b2xvcmltZXRyaWMvTGVuZ3RoIDE1NjA0L0ZpbHRlci9EQ1REZWNvZGUvTmFtZS9YL1NNYXNrIDI0 NjYgMCBSL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlL0RldmljZVJHQi9XaWR0aCAyMjcv SGVpZ2h0IDExNi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAC AgICAgICAgICAwICAgMEAwMDAwQFBAQEBAQFBQUFBQUFBQUFBwgICAcFCQoKCgoJDAwMDAwMDAwM DAwMDAwMAQMCAgMDAwcFBQcNCgkKDQ8NDQ0NDw8MDAwMDA8PDAwMDAwMDwwODg4ODgwRERERERER ERERERERERERERERERH/wAARCAB0AOMDAREAAhEBAxEB/8QBogAAAAcBAQEBAQAAAAAAAAAABAUD AgYBAAcICQoLAQACAgMBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAIBAwMCBAIGBwMEAgYCcwEC AxEEAAUhEjFBUQYTYSJxgRQykaEHFbFCI8FS0eEzFmLwJHKC8SVDNFOSorJjc8I1RCeTo7M2F1Rk dMPS4ggmgwkKGBmElEVGpLRW01UoGvLj88TU5PRldYWVpbXF1eX1ZnaGlqa2xtbm9jdHV2d3h5en t8fX5/c4SFhoeIiYqLjI2Oj4KTlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+hEAAgIBAgMFBQQF BgQIAwNtAQACEQMEIRIxQQVRE2EiBnGBkTKhsfAUwdHhI0IVUmJy8TMkNEOCFpJTJaJjssIHc9I1 4kSDF1STCAkKGBkmNkUaJ2R0VTfyo7PDKCnT4/OElKS0xNTk9GV1hZWltcXV5fVGVmZ2hpamtsbW 5vZHV2d3h5ent8fX5/c4SFhoeIiYqLjI2Oj4OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oA DAMBAAIRAxEAPwD8/wDirsVdir61/In/AJwh/wCcjP8AnIWG31TyR5IfTPKlzUx+ZPMLtp2luKbG F2R5ZlJ25QxuoOxIxV+onkL/AJ8u6FHbif8AM385L+8uPhd4PLdjFbRRqAOSNNdG5Lb/ALQVflir 2OP/AJ9df84UaWv1XVfOOpS3SijNdeZLS3kqO5QFP1ZXLUYgd5D5hqlqsETvMfMJNq3/AD6G/wCc bPNELS+R/wAx/MunOoJBtLyy1OHptyrE7fcwycJxn9Jv3M4ZIT+kg+58U/m5/wA+g/z08nW9zqf5 Y+ZdH/NSygDv9QP+4nUyOQ4JGk8kkDkKTyJmTpsDWmFk/Lbzb5O81+QtevvK/nXy5qPlXzFprcbn TtUtpLW4jr9kmORVPFhurDZhuCRirG8VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirs VdirsVTny95e1zzbrmleWfLOlXOua/rlzHZ2FhZxmWe4nkNFRFHU/q6nbFX9BH/OMH/PtL8sPyX8 ux/m5/zlfc6T5i1yyt/rTaBqLo3l3R1YA/6YJPhvJwKjiwMQJICOQr5DNmx4oGczQHUtefUY8GMz mQAOZL6I86/85geZ/MDyaJ+RHlmDTNFg/cr5o123IQquwNjp1UFB2aU0/wCKznN6/wBrJysacUP5 x/QP1vA9v/8ABTjCRx6ON/0jy+AfO2taX5288ubj8xPzH8webZHPJraW7kis0J7R2sJigUewjzSZ 9Znzn95My952+Q2eJ7Q9pu1daf3uY+4cksj/ACo8oKtDpCSH+ZwCfpPEZT4cO4OuObIecz8yp/8A Kr9CtJVutJe80O8jNY57Cd7eRD2IaIo1fpwxAibG3u2+5sw67U4pXDJIH3vUPLH5u/8AOQX5bSRn TPOP/Kx9ChI56R5qrcTFB2hvx/pCGnTkzqP5c2Gk7f12nP18Q7pb/bzej7J/4I3a+jIGQ+JHuPP5 vZtVl/5xo/5zo0Fvy8/NXyiNA/MO1tpksYL307fXNOeQLzn0bUlWkq8kVim6vxX1YiNs6Xsvt7T6 w8P0y7j+jvfRfZ32w0Ha8agan1iefw734O/85g/84QfmF/zilrSX08rebvyv1i4MWkeZoIinB2qV tb+MchFMANjXi9KrQ1Vdk718RYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX9 IP8Az78/5xR8r/8AOM/5XXH/ADkz+dcI03z5rWkG/t4tRj4ny3o0i80jWJhzF5cqQZKjkgKwgK3q c69RqMeDGZzNAc2rVarFp8UsmQ1ECyVPzz5380f85Aa+nmPzWs2meRrGYyeXPK5JEccYPwXV4o2e dxua/Z6L034jtTtXLrsly2iOUe7zPm+Ne1vtfn7XzEA1iHId/mU3s9ORESOOMIiiiqooAPYZhE28 zPMBsGQQabWgp1oMnjhxSA72GKfiZIxvmQPm+p7X/nFXV7i2t7gecbFRcRJIFNlKacwGp/f++dH/ AKEB/qn2ftfSR/wHLH+Nf7D/AI88q/Mz8pLv8t59Hgu9Xg1htYSZ0MMDQ+n6PCteUj1rzzX9sdif kYRlxXflX6XnfbP2KPYGHHPxuPiJHKqr4l4/c6fxr8NM1Ly8NQwTzH5VtNXWKRzJZajZuJrO/tmM VzbTJuskcikEEHEFytNqZ45icDUhyIfT35U/mFov59eWPMf/ADjb/wA5C6Xa6/q2paXJCk0/7uLz DpqihmjZCrR3kGzFkIYECVCCDx6z2f7cOo/c5T6xyP8AOH63132G9sh2pj8HNtliP9MO9/O7/wA5 ff8AOMWv/wDOLH5t6j5IvGudT8o6mraj5U1udABf6czU4SMgCevAfgmUAb0fiqSJm8etfLGKvqn8 nP8AnG7V/Puoa5a6z/uPTTLT6vcTyRySW+mahcJKDb3KpLbPLewL6bm2R+MRcfWZFeJrObV9p9tR 04Fd/wAx+rz+X84efe3X/BT0/Y+HHLF6jKVgWBLJCJHqjYlw45GxxkXKv3cSJDLD1I//ADhL+T8b rE/mjzSkjdFa908E/Ifo7NV/oo1n82PyP63gI/8AB+9pSLGDFX9Wf/FvAfzt/wCcR77yDpGoeb/J OsTeYPLWmxme9sr5VF/aQokfKUSRKscy15s3wRlFps+7DP7L9oo6iYhkFSPIjkXsPYH/AINWLtjU w0msxjHlkajKP0SO+1HeJ5Abys93J8YZun1B2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2Kv0A/59vf 849wfnx/zkPpN1r9iLzyN+WKJ5k1mOReUVxPG9NPtHHNTR5l5kEMrLGyMPixV+y3/OU/nmX8wfzG tvym06Y/4O/Lwwah5iEZ+C91iRRJbWjU2KW8ZDEfztvugzk/antE5c/gRPpjufOXd8HzT/goe0Mp 5RosZ2G8vf0DALK1FFAWgFAAPwGaKRfOM+WmX2VkDTbGLg5c7JILMAA0965fpx+8j7wnRZb1WP8A rD736h6V/wAczTv+YWH/AIguehB+no8g+V/+cl4hLqnkwEVpb3x/GHNF7WD9zD3l84/4Nsq0On/r H7g+VbqyFDQZysnyOGamJ31pSu2QtysOd5x5l0vUG+pazoF22lea/LVympaLfx7PBdQHko91enFl OxBIO2ThOUZCUTRG4Pm7Xs7X5dLmjlxmpRNh7J/zlR5D0v8A5zT/AOcMj510fS40/MPydaza7p8C Cs1tqumqU1XTQeafDMiMFDGm8bkEqM73szXDWaaOQdeY7j1fd+xe1MfaOihnj/EN/f1fy+Wc8Vtd 2tzNZw6hDbzJI9rcGRYp1RgTFIYZIpArAUPB1ah2YHfMmQJBF05efHKeOURIxJFWKseYsEWPMEeT 9pvMc7fkd+Rmr3Nlevqep+V9Jkk+v3hlke91e9lJlvJhLNM9Zry5MrKZDTlxBpTOLwD89rgCKBPI dAOnyD8udl4x7V+1mOM48McswOGNDgxwG0I0APTCPCNuj8kYdG/Mv8xrq8802Ona1531Frllu7mx jk1G6hlAV1aaKASSQo3P90zKqNxcRkmNwvWnJptMBAkRHnsH6Nnr+wuxMcdLOcMMa2EiIRI5bGVC R29XMixxfUL9c6Z+cX/OSmmeRNO8oP8Ak55i1jUbS0ls59Z1TSdRuJbiNmf0+cQtY90jYKSzMWpy Y1JzUZOzezZ5zk8UAc6BH63zjV+w/sNn7Xnqx2hihEkSEIThERO10eI8zvyFcglH/OKv5aeWfzHs /Pflb8ytAl1K28j6hbXFjYzy3NjLZXmpLNBqHP6vJbyFmGmQKVkJ4lPhCktWfb+uy6aUJ4pVxDc7 GwOXP+sXJ/4MXtXr+xMul1PZ2UROaJEpARmJRhUsdcQkNvFluOd73QfQvmHy/wD84zflt5e1nyj5 ls/L99qGn6dqF3b6dqcpudSjtpmmmjtLK5uXkmgqZD6axyKebNIPjZmOuw5u09TkE4EgEjccveQO bxfZnaft325rcer00skYylGJlAcMDIVEznGIEZctyQdqjyADG/yR/J3yh5D/ACtXzz+aF5Dd2mu6 bbaneWFxzTSIbECW4tUvbNaR3swNyX5XCSGNuCwhfTDtb2r2lm1Gq8PCORoHrfI0enLp8XO9v/bj tLtf2g/JdmxIMJGEZCvEM9oyMJ88cfTXoMeIWZXxUJTpf5e/848fnDBJ5r/LvQdBl1HQ+VnJbpYv b2EqvHLW2vtOia0+CVJmHrQmK5WgaC4iljR0jHtDtDQZBHNZHOif0uKfaz2y9lNTDB2lKcoSIlUp Ek0R9OQEy/h+mzE/xRIkb84f843/AJP6B5o8/wDnee4t77SW8gaw0H1G5uUuLqxjaWdbeOG9t47Z ZLmtu6vcrHF6ITnboJpY5rLY+0Hafh44+GPTPlfd57Dv+PXbY9n/AMFX241Wg7I0wgYyGeF8QFRl sOIyhIyqHqBELlxXUzwRlDL6MHlz/nE19Y/5Uqnl/Qm131DB6Swzm99cObkw/pf/AHo5ginH1+n7 vp8Gavx+1uD8xxGvs7vp5fY8Qe1f+CKNN/LBy5PDq7scFfTfhfTX+b/S83y35x/JqP8AKP8APz8v 9F02Sa68lfmBqEOmxfWCrSGx1OQabqtgzrRq/V7wqJAFYLIpVua8s2mm7TOr0E5H6oi/iN4n7Hv+ wvbqXtH7IarNkAGfBEyNcuPGPExZK5fVDluLibFGn1T5o/5x/wD+cevIdpH5u1PTn8paDpKXK6lN HquqBruK8t5LP6oSLt5CkgnPJY6M9ApqhdW1WDtjtDOeAHiJ5bDpvfJ8+7I/4JXtn2vkOlxz8XJO uEGGP0mMhPj+mrHDzOw586IHT/lP+Qf54eSG1Lyd5c0rT4phcRWGqaPZDS5obpKpWSOJIPUAYfZk Vh4eOAdoa/Q56ySJ7wTbTj9s/bD2U7V8PV5pyIoyhOXiAx57EmVe8U/Iu9tZbG8u7KdSk9nM8Eis ACHjYqwIBPQjxzroSEogv0fp80c2KM48iAR8UNhbHYq7FXYq/pI/59PeVNP/AC7/AOcXvPX5uajb gTeZNV1HUJJHUKzWGhwFFjDdSpdHI9ychmyDHjMj0F/JhmyjFjlM8gCfkxLyQ95qljdeZtUczax5 xvrnXb+Vq8nlvpWl3r4BgM87nklkkZHmdz8XwDtXWy1WpyZZc5El6zYQAldumVEuj1WTdmdnAABt k4ODkyJ6qqqVNAPE7Zk6b+8HvDLQ5wNTjs/xD7w/SnS/+OZp3/MLD/xBc9AD9Uw+kPl//nI5kGr+ TQ7KpNve0DECu8PSuaP2qrwYe8vmX/B2zQx6DTWQLnL7g+bbiKoO2crN8djl3YrfwCh265US5OHJ uwm+hpU06YYl2mmyWHsf/OH2siw84fmp+W91R9M1iC28z2cLfZDTVtL1FH+VRWOdJ7IampZMXukP uL6n/wACjtEyxZdOTy9Q+L+cT/nIH8utM/Lz/nJb8yvy71S8l0Dy/pPnO5tnvFt/rL2mmXFz6qzp bq8XqcIJQyoGXlQCornSZDIQJiLPQPc67Jnx6ecsMOOYiTGJPDxSraPFRqz1rZ+merW7/nX+Seq6 cbVtH1nzJpU1nc2N5HNA2n61aOUntZ0mjjlUwXluyNVK/DUds4uB/I64HmAfnE9fiH5e0eWPst7V QycXHDHMSEokHjxSFxlEgkerHKxv1fBX5W+dfM//ADjs/mzSD+X2o3vnLzVq1jp8Wj6hNHbyRwxG 7SyezSMST3/rytMjPFCsUZjjo7m4VU3+v0uHtGMZeIOEAmx8Lvu/Hc+v+1/YOg9tY4Mo1cY4cUJS M4gkEnhMxMmo4uEcJqUjI3LYcBJ+jP5fa3508xeT21jz15aj8paveCSSDT0lMjratGrRPMrKrRyM SaxsAy7BgrVUc3rMWDHm4ccuId74l7SaDsvRdpeFosxywFAyqvVe4HePMbHpY3fKX/OGZJ80fnyS ak6pp1a/8ZtXzbe0391h9x/Q+hf8Hb/EOy/6k/uxvkj8/wCDUNb/AD5862Nhaz6lqeoarb2drbW8 bTTzzNDBFFFFGgZmZjRVUAknYZtuxzGGggSaAFvo3/A1yYdL7Iaac5CMYwMiSaAFkkknkH6sfm/f +WNM/L7VdV83eV5/OPlrTmtru70y2RZCyQyo6ysjPGrJGQGYMaUBqCM5Xs6GWWoEYS4ZHq/PnsTp tfn7Zhi0mcYcsrAkduYIqwDueQeOflX+bXlDWLLW9U/KT8gtYt9Pilig1K40iy0fTo5ZY1Z0jLG7 txKyLITxXkUDCoHMVzO0OzssCBnzi+lmR/Q9N7YexfaWmy48XavakDKiYicssyAdifplwg15XXky r/nH3zFbeYP+Vrzfoy78vahN5zkvptE1NBBqVpFc6bpyRPcW5PJBI0DlSRRqGlaHKu2MJx+FvY4a scjueRdd/wAEvsyej/Ix4xkiMAiMkN4SMZzJEZda4hfc8rX8z/ya078zbvyfp35B3+p/mLD5guHS ZdLsJb2W/EzXBvI7m5m9VUJHrLIWVUT46qoqMr8hrJaUZDnAhXearuofJ6A+yXtPn7Bjq8nakY6Y 4xtxzEBCuHgMYir/AISOZO25QH5zedbjX/zJ/IHR9Y/L7XPKGq2XnbTLq3utVFo8M1u93bJNHBPa XFwjMGEZdQ1QOJPUZLszTDHps8ozEhwnlfce8Bv9hOwYaPsPtXNi1ePLCWCYIhxWDwyIMozjE99H 3p5/znG7D8rfLUYJCv5ogJHjSyvqV+/K/ZX/ABqX9X9IcT/lnyI/l/Mf9qP+7grf84N/+So8wf8A gW3f/UBpuPtV/jcf6o+8sf8AloP/AJyLF/wmP+7m/NHzr/ymXm3/ALbN/wD9REmdLpf7mPuH3Puf YH/GZg/qR/3IYzlrnuxV2KuxV/T5+Q//ADr/APz63065tKJLP5M1GZiu1WvNRljc/Pi9MwO3ZmPZ +UjudZ7TZTj7JzyHSJYB5bgWDTNMhQAJFbQoAPAIBnDS2fBMp9L0Sx4qodyFVdyT0AyqRdRrJgWU zGpX0qf7itPubmPp9YSCSRKj+XipBy2GDPIXGJPwdLqz2rmx8Wl085RPKQiSPhs9o/JzzP8Al7f3 EHlb8xfKujXN3LJx07Wrq0i5O7GogumK/ar9l+/Rt926H2f1+lyVizQiJDkaG/7X0L/gQ+3XYHaU 4dm9q6XFHUR2hOUIjjI6SsbT+/3vv2NEjjSOJQkcahVVRQBQKAD6M6d99p5D+cOqflroGiQ635/0 Ox8wXFt6kWk2M8Ec9zcTuBWK3Eg2rQcmNFUbnMXtHJpseLjzAEDvF/J572513s/oezTqe1YQljhu BOIn6u6IkDuX57S6prmsalqGqafosVjDPICul6PaMbKzj3CRKI0qTQfE5oWNTsKKOK1mTLrcpnix 1HlQH30/MfafbnantJ2jPU9n6Pgwx9Ihjh6QP6XCPqKjLqKyyvaXcD2N/Hs0EylGqQCNmAIqDXfM PJjnCVSFFv0+fNjy+Fngccx/DIUftY3qCj4sYO90h2Tb8grh7P8A5yU8pohITU/LGtW8oH7QjNvI lfka5uPZiRHaI8wf0Pf/APAtykdrEd8S/Hn/AJ+b2CWP/OaX5tNHQLfR6JdEDs0mj2IavzZSc7N9 aeFflh/zkX5s/LB5Tp9hZ31tdSWSXNkqR2dnLb2lrFaV+r20SItyUt4yblQHkYyPci4dlaPB7T7K x60gyNECrA/H4+N8h7Z/8DXQe0dHLIxkAQJDeQJPFzJ3jufSfLgMN+L1zY/850eRJLSJ9T8m69a3 5QGWK2NrPCr03CyvPAzCvcoPlmmn7Kai9pivi+a6j/lnntcZCMeoxmPQniifkBL73kP5i/8AOavm jXrS60ryJoieU7W4DRnUblxc3xRgP7tQojiPUft+xBzM0XsxixkSyHi8uj0nsv8A8ATQaPJHLrsn ikb8IHDC/PrL7GHf849fnhoP5M2HnDVNciufMWq+cbu1RbK0LevAtgszvc3Ms6pGRM19SMI7vWOT 1FQemZL+2eyZ6wwESAI39tfqdn/wTP8Agfaz2ny6fHgIxwwiXqPI8dARiI7+ng3sAbxq9+Hh/wCY 3nFPOfn/AMwedNOgm0tdWvFu4I2f99CUVFU80p8QKVqMzdFpjg08cZ3p6v2X7DPZfY+LR5CJcEaJ 6Hn0PvfV35c/85nXHl6ys9B846Bf+YdKs7S2gXUXu47jU2ljgjWdpi0NskqvMGZK0dEKrI8zhpX1 faPs1jyz4sJ4fLo+e+1X/AJx63NLPo8scciSeHhIx0SareRjQ59CdwIioiQeaP8AnNTQbLQJ9K/L DyRNo95cGdkmv0t7eC2kuHaWWZLe2eQO7O7MalasSx5bg04PZjJLJeadjy/WXB7I/wCALq8usGXt LUicRW0bJkIigDKQFChXXbZ8pflf+dPm/wDK7zdeeatPnOrfptydbsryR/S1BWkMjO5U7TAsxSSh Klm2Ksyttdf2Zh1WEQO1ciOj6H7XewXZvb/ZsdLkHBwf3cogXDaqH9HvHWh1AL7RH/ObH5bExaw/ 5far/iaK0e3WUJZngkpjeSBbsyiT02eJCfg34qStQM0v+hfU/Txivj9z5ef+AF24LwjVw8Im69XS wJcFVdE9evN8u6v+eOofmL+cXk7z55xuI9D8v+TtRg1G00+H1p0ht7CUXjW8IRGL3FyYBGrsEQuU 9RoolLJtcXZMdPo54obmQIv37fJ77Q/8D7B2L7NajQ6QGeTNExMjQuUxwcR32hDiuhZq6EpGjMP+ chf+cj9A/OLytpflzRvL2oaUdN1dNR9e8eIh0SCeHjxjZ6EmYHr2yjsfsTJo8pnKQNitnWf8DL/g W6z2Z189RmyxlxQ4ajfOwetdya/kT/zkR5U/JTyANAvbG68zaprmq3OtTR6eDGlgjpDaJbzvcLEG mIs/V/dc4/Tkj/eep6kcZ7Z7DyavNGcZADhrr3lp/wCCN/wL+0PajtgZ4TjjhCAgOLcyIJlxARv0 +ut6Ng7VRPkLXdRXV9b1jVkjMKapfXF2sbGpQTytIFJHhyzaYocEBHuD6P2dpTptLjxE3wxAv3Ck qybkOxV2KuxV/Tx/zirInn//AJ9kpo1iwuLjTvLWvac6LuRLp93Pc8SPGgGYfbGI5NDliP5pcDt7 B4/ZuaHfEvOPJ98l/oOjXiGq3FnC9ffgK/jnBncPgOUelMbnWzdzG1t3/wBFiNGI/bYdfoGQlGnk e3tSZkxHJ+nP/OM4V/yp0tioP+mXVCR/ljO59nP+M7H8fvL9E/8AAcJHsdpB5S/3cn59XVDdXwO4 N1cV/wCRr5x/aMq1mT+sfvflP/gixkPajWkGj40/90X0t+W//ORlz5V0G70bzbaXfmBdOtmOjzwU a4d1FEtJ2YgcT+zIfsjZuxzfdk+08I4jHOdwNj3+XvfXf+Bh/wAtFafB2dLT9syPHjj6JgEnIB/B Kv4+48j1o8+B+avNWv8AnjXbjzH5luRPqEwKQwRk/V7OCtVgt1PRR3Y7sdz4Zpu1e1cmtycUuXQP lH/BD/4Ivaftf2j42b044/RAcoj9Mu8vq/8A5xOobLzx3/f2H/EbnN77G/4vP3/ofc/+WXwR2DqP +G/70PmL/nI2Th+cfnuh4lZ7Ag+H+4yy6Zqvar/jQPuH3PJ/8HKJPtfM/wBCH3PILDW/r6SWs7f6 VCK1/nXx+Y75qxGnW9i6g5I0eYei/wDOOVi+qf8AOR1ldIvOPyv5S1CeenRWvpYYY6/Pgc3HstjM tffdE/bT6d/wKtOZdpzn/Nj978WP+fj+t2+u/wDOZv50XFrMs8Njd6bptVNQHsdMsreVfmHjYH3z sX1V8PYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq/oG/584fmhY6x5K/NL8kNXkEsulX aa9ZW8hUCaw1CP6tdxoteR4vGC5pQc1wEAiiggEUV2qWd5+WOseefyxviy3/AJR1eW0snbYy6dck z2k6+zQOCPfPP9VpDp9RPGf4T9nT7HwL2x7Pn2brsuE9+3uKlpV0Bx3yicXg9fp365/84vPz/KLS H61u7v8A4nnbezo/1ux/H7y/RX/Ajjw+yWlHlL/dyeMTf84sedHubqVPMOkcJp5ZFqs4NHdmFfhP Y5rNV7I5M2eU/EAsk8u/4vnftJ/yzfqu1O08+qGsjEZJylXATXESa+pZ/wBCr+dP+ph0f7p/+aMr Hsbl/wBUHy/a6k/8sq6z/lOj/wAqz/xTj/ziv517eYdH+6f/AJpwH2My/wCqj5ftZQ/5ZX1g/wCR 0f8AlWf+Ke+/kl+V2s/lnb+YodY1C0v31iW2eI2gcBRAJQeXMDr6gzcdh9ky0GKUTK7Nvqf/AALP +B9l9kez8mnnlGTjlxWBw9AO8vgT/nJm4EX50efVr/u3Tz/3LLLOe9qB/rgfcPufLP8Ag14eL2sk f6EPufLs2pvZ3kV1GfihfkR4r3B+YzWxjs892fE4yCH21/zidDZ+W/JP5r/n75jZbHSdUaZLKeYh Quj6Ekhkl5Hbi83IA/5OdL7I6UxxTyn+I0PcP2vuv/Av7KOn7PlnkN8h29wfy5/md51uvzH/ADF8 8+frzkLjzhrl9qzKwAZRdTvIqmhIqFYDOge0fW+g/wDOGGn+aPLmgebbX8yX0LTvNGn2uq21jd6a l1LaxXsK3EdvJdLe2qysivxLiJAxHLgteI0Ob2mliySgcdkEi7q68qL5H2j/AMHfNoNbl0stHxyx SlAyEzESMCYmQjwy4Qa5cRrvPNX1L/nBbUBp9xJ5e/M6w1bVU4ejb3mntaW71dQ/OeK7vGWi1IpE 1SANq1Ah7Vx4vXjIHkb/AEBhpf8AlobD4wGo0Uow6mM+I/CJjC9/MPjLzr5L8wfl/wCZdS8qeZrQ Wmq6Y4DcDziljYco5onoOSOpqDQHsQGBA3Wl1WPUYhOB2L6f2B29o+2dDDVaaVwl8weoI7x+NmKZ a7B2Kvb/AMvvyJ8zfmVoD695d1Gz+rWs8keoTXSXEFnpiQxTSP8AW7h4hzkYJGUS1S4or1mMHwh8 HWdrYtNk4Zg+XefcP115W8p7S/8ABF0PYes8DUQlZAMQKMslkAcEQdgN7MzDcejj3oB+XH5Un81P MvmDy95T1e4mNgkk2mm5tIobie2Mwiju7yM3pighTmnriOaeVC6iGK4Adlnr+0I6SAlIbfjb3/Z3 kN3tV7ZD2f0OLPqsY9RAlUiQJVZjA8NykaPDcYRNeqUNgYh578px+R/MNz5WfWItZ1XSAYdUltY2 Wzjuw71itpZCskqLHw5O0cZ9QugVlRZJLdJqPHxidUDy7683ZezvbJ7W0UdSMZhCe8AT6jGhvIDa Ju9gZbUbBJiIdlzs3Yq7FXYq7FXYq7FXYq7FX0H/AM4u/nxqn/OOH51eUPzRsY5rvTtOmNprlhBx 53uk3NFuoVDMilwAJIwWA9RFqaVxV/Rn/wA5TeQdO/M3yd5W/wCcjvyukTzFFBo8E18bD95+lPL0 49eG5jC7tJbcywHUoWXqoGaD2o7LlkiNRAbx2I74/seK/wCCX7KHtHS+PiFzgN/OP7Hw7pWpRSxw zQyrLDModHU1DKwqCDnNGpCw+G6vSmyC+r/y8/5yV89+QfLlp5X0O20eTTrWSSRHu4JZJSZW5NVl mQdem2bPRe0ebS4BjEQQHqewP+C12h2H2bj0mPBGQhdEkg7kn9L0mL/nLv8ANCQAm30AV/5dJv8A soy4+2Go/mD7W/J/y0J2tH/kLD5n9SLH/OWX5nH/AHToP/SJN/2UYP8ARjqP9TH2tR/5aK7X/wCU WHzKx/8AnLX8zl6QaCf+jSb/ALKMR7Y6j/Ux9qY/8tEdrn/kLD/TH9SWz/8AOYf5oxVpa+X2p/y6 zf8AZRkh7X6j+YHJxf8AB+7Wn/yFh8z+p8s/mF581Xz35n1fzbrYt49T1loWnS0VkhHoQRW68VZn P2YRXfrms1+slrM3iSFPL+0nb2bt/tE6vLARJAFDyDDvJ3knX/za86aZ+X3lpmhudS/fapqAFU0v TFYCa6f/ACiDxiX9pyOwJA0mjyavMMUOvM9w7/1O39i/ZfN2trYwA9I3ke4M8/5+efnz5e/JT8mf Ln/OK35cyCy1XzVpcMGoRQMpbT/LlsRGElPIH1Lx1K/ZPJRKxoeNe6wYIYcYhEUAKD7/AKbT48GK OOAoRFB/OxljY/Tv80/Jnmbz5/zjH+SWg+UtFm1zV3g8tSiGHgvCMaPMhkd5GREUFwCzEDfOY0Gq xaftPNKZoer73wb2Q7e0HZHt32ln1WQQheYWb3/ejYAWSduTxX8of+cafzo0L8w/K+uaxo03lWy0 fULW8kvI76xlV4oZ4muLeT6tevKqy24kUcY3DOVRwsbNImb2j25osmnlGJ4rFVR/SO96n22/4K/s vq+xc+HDkGWU4yiImMxuQeGQ4oCPplR5ihZFkCJb/wA5cec/L0v5yeWrvRrbTtfvvJtpbLqaXK/W bK4mhuXuFsrmMMA6AGkig7hypNRs+zumyDRyEiQJE138qsL/AMBXsLWx9mc0c0pY45ieGvTKIMRH jieh7vdbE/8AnJb8lvJ/5N3HlSz8sXus382uxXM9w+qT28qqsLRqgjENrbkEljWpOXdh9qZtYJGY Aruv9bsf+BT7edp+00M89TGERAgDgEhzu74pST38sPyd8m/mN+SXmXz9rxv9O1X8vItVsoE0dre3 jvktIP0mkt6Zbad5Jed6YuQZf3SRrT4amvX9pZtNrY4o0ROjve17bb+Tie13tx2n2J7VYdDg4ZQ1 BhI8fFIw4j4REKlECNQ4q39Rker6z/5x+0zyFYfktqFloXmGW/h1mxGseZZVMMq6fqF/p1uLy3iE EMSIIhFtGQWXuemantjJqJa0GUao1HzAJovnX/BK1fa+b2ohPPiETCXBiG444QnLgkeIkm758iwv /nG7y7+R+g+fvME/5debtW17W2sm06GK+lgkjmsnSyu5rgRxWkDLxmj9OpanbqRl3bebXZNPEZYg C7279xXN2v8AwU+1PavWdj4o9oaeEIcXETEEETBlARsyldxNvFvzS8m/l/qn5o22hfl9qNz5v89+ dvMUttrmn6lAs2n2qpMs7IRb28d3DGHiHrTwzB0gEtDQkHN0Gp1ENKZZRwxiNiOf6vger1Hsh272 xp+wJZtfAYtPhxA45RNTltw36iYSNH0xlGjPher61+V3/OMH5bzaTon5p62uveYl0uytFj4rpoiS ASA3Bh0aOzasrMSXuZJpCFUGQ0JOLi1/ampBlhFCz5/7q/sp57Qe1/t723HJm7MxcGPjkf8AVLuv TxZjP6e6AjHc+kPMvzi/IDyJ5Z8jW3nLyRdw3nlO5gvb2PXZ725eaO4uBayWUEogtryKe1ZbWS3t 1SGCRLm5WS5upIF4w7Hsbtg58ssOcVMcvh3jd6b2E/4J/aHaOu/k/XYhDPGW4AriiBUhUpDhlH6y dwYiQEeKmf23/ON/5Y6j5X8vfm1rWv3HlHT/ADNpg13zDCg09dLsodYsJHe302CexlEISa6UQEmR kVaIfV4SLr5dt6qOWWCMeIg0Odmj138t3nsv/BT7ewa/N2VhxDLLHLw8Z9fiTOKYqWSUZjiuMTxc gSd/TYJ5pn5Nf845/mVpWuH8m7iDT/MemWl1B63KTU41+vWtxaqJrXVvriUIkZkkQJLG6rJFIjoG AHbHaeiyA5hYPeB8arq4+f2/9t/Z/VYz2sOLHIjYgQ+kgnhlj4d/I2CDRBfmZdW01lc3FncoY7i1 kaGVGBBV0JVlIIBqCKZ0kZCQsPueHNHLjE48iLHuKHws3Yq7FXYq7FX62/8APt7/AJzotPyWvY/y O/NzUfT/ACm8w3bvo2rXLcofL19dMTKk3LZbO4diXPSOQlyOLyMqr9Fvz9/5xe1Dy7cXn5jfk3p5 1zyfqfK+1Ly7YUkms2k+N7rTVFRJC1eTRjdeq1G2ct217PzxSOXALjzMe7zD5r7d/wDA38Yy1Okj 5mP6nyPpmtQ3CF4JefpsUkU1V43XZkdTQqwPUEVGaQVIbPk+r7PnjkYyFFlEGrUAHLImDrsugtMV 1g0+1+ODw2g9neSjLq+x+PHgZQ7PSa51QtWjVyQg5eHRgL/J3lPzj+a2v/4Y/L/Szq98rAXt89V0 /TkPWS7n+yKA7IKs3QDL9Jpc2qycGIWep6D3vUey/sdrO1cwjjj6ep6B9g/mT+Y35Q/8+5/yau7q 4uk83fmv5vDtZ2khCX2u6kiUEjqCTBY2/IVPRV2HKRwG7HsrsrFocXCNyeZ733D2d9ndL2PpRixD fqe8v5h/zB8++avzR86+ZfzB87atLrfmnzZfSX+oXcxJLO9AqICTwjjRVSNB8KIqotFAzNdqw7FX 6jfmT5+83flx/wA4xfk5r3kvVzouqz2Hlyykm+r29zygk0iR2ThcxTKKtGpqBXbrSucvotHh1Pae WOQWLkevf5PgXsr7N9m9t+3naGDWY+OAllkBco7jIBdxIPV8xeWf+cs/z4i1WN59Ui84QQpJcT6f LplsnK3t42muH5WVvDIoSKNmZqkKAWIoDmzz+z2gMNhw+dn9L3na3/AY9kZaciMDhJoCQnL6pHhi PWSNyQK68nqn/OaP5feXdKsvKXnvR9NttD1HVrqWy1O3t4hF9ZkmjNws8ioVX1FKMHbjyfkvI/CM xfZjWZJyljkbA3Dz/wDwB/aXW6jLn0OWZnGIEokm+EA8PCL6GxQ5D4tf854f8dn8uj2+o33/ACdi x9k/oye8L/yzr/iur/rR+4p//wA4/Wd3Y/8AOLf5yw3trNZzOdauFjnRo2MNxoNhNDIAwB4vHIrq ejKQRscr7ZkJdqYqPd/ui4f/AAS8+PL7f9nmEgR+7GxveOaYI94Io9xTT/nE7/1nj8yP+2zq3/dL sMh7Q/8AGhj9w+8tH/Bm/wCc00f9SH/TSbxv/nBz/wAm15g/8BO7/wCo/Tczfav/ABSP9b9Bem/5 aD/5x3F/w6P+4mzT8lYdIn/5y58/HVJY0urQ6vc6Qkk5iL34kjhPpxh1Eji1nuPhIai8mp8NRR2o ZjsiHD5X7v7adX7eZNTD/gcaXwgaPhidC/RRO5rYccY77b0Or5j/ADu1HXrf87vP2o3NxPY6xY+Y ZpLSeJ2imijt3H1GSN1IZWESRlSDUdRm07LhjOhgBuCP7XvP+B/pdJP2V0uOIEoSxgEHcEyHrBH9 Yl9o+Sra1i/5wq1u2umMrR6NrEzcz6kAlmlmuIBBIAY2osicuLNwl5xvxlR0XS6qR/loEd4/V+PL yfLu38uSX/BRxSjt68Y7jQAjLiHMcjV841IXEgki/P27ubb/AJxK/JuCCZoor+HyzDcKOkka6PNK Fb25xK3zAyfZEQe18t9OL73M/wCBvghP/gjdoykLMTmI8j4oH3F5t/zg67t+bGuhmLCPyjdqgJqF B1DTjQeG7E5k+1Q/wQf1h9xd5/y0FED2dxf8Oj/uJvl/z/8A8p552/7b+pf9RUubTR/3EPcPue+9 m/8AjI03/C4f7kMRy52LsVdirsVdirgSNxir9Hf+cR/+fjv5n/8AOOEWneTPNNvL+ZX5TW7RxR6X cTlNR0mEMATpty/IcVWtIJPgNAqtEKnFX7MaE3/OH3/ObdkfNP5d+aodG8+vAsl5+jZI9L8w2p2B GoadKGWZVY8eZR0P7EnfNb2h2BpdWeIjhl3j9Pe6Tt32O7M7VF5YVL+cNi858yf84WfnJobyP5V8 w+XvPliCeCXLS6Lfle1VYXNuT7+ovyzS5/ZbWwPolGQ/0p/SHhO0v+A3nBvBkBHnsfx8XmU//OP3 /ORFnIYZvyj1CZgacrTUdLnjPydbwfqzFl2J2iD/AHR+BH63SZP+BV25E0IA/EfrTjSf+cXf+cjN adVbyRp3lqKQ0+sa3rNqFUeJisjeSn5UyeP2f7Rn/AB7yP0W5Ok/4EXa+Q+vhj7z+q3uXl//AJwq 0HQ7SbzD+eH5mRXGkafG1xd2Olt+h9LjijHJzc388nrvGAKkj0vfNjpPZIc8878o7D58/uer7F/4 Eug0xEtRLjPcNh+Pk+ePz4/5+Zfkl+Q+hTfln/zin5c0vzjrNkrQDVbeMw+WrB/jBkRk4yX0gYA1 QiNg1fWYgrm+0+mxYICGOIAHQPcaXSYdNjEMcREDoH4LfmR+Z3nv83fNupeePzG8y3fmnzNqhAlu 7tq8I1JKQwxqAkca8jxRAFFTtU5Y2sDxV2Kv0pv/AM1/+cdr/wDLzyT+V/5mXc2vy+SbDTLa+h0s 3MtoupadZ/U5RFe2EqxzorM4V4pHicUdGZeLZzsuy+0sOryZMVCyeoO1/F8Owexftrg7b1PaXZ0R DxpTMTLh4uCcuMXCYJiTtsQJDkQGL2vn7/nC/wAsRtdaR5P1PVQkq3B0yVL+8tZ5o45oY5JbTUb0 2rsiXMgRnUlORK0OSlpO2spqUgPPYfaBfRzs3s3/AMFDXnhy6iEdq4xwRkASCQJ44cYsxF1zrd87 /nx+eWo/nRrtlMLE6N5b0MSR6bYs/qSEyEc552AALsEXYbKNgTux2PZPZUdFjO9yPMvaf8Dr/ge4 PZfSSHFx5Z1xSqhtyjHyH2vpzWfzf/Ij85fJvlkfnfBJ5b8zpYzSwT6TI916LSSyW0kkX1M3bwln teYgu4wwHBqSRskj66PZXaGhyk6cgxPfX2vCaL2H9rvZjtPN/IxGTEZCxOo3QEgJcfCJUJVxQPeN jcRd5/zkV+Stp5M/NDyT5Vsb3SbDVtOv/qN1cR3NzdaxquqR3Iubm4mmaaU/F6Y5zycyCBQKoGQj 2LrZZseSZBIIvlsBW39iMH/Aw9qcnami1mqlGcoSjxAGMY4seMx4YxAod+0RXxLBf+cZvzo8meRP Ifm7yp57ia10O/1cSG9hmikldtSszE0X1JZBdlFXTyTNEjohZVkMbNF6mV232PqNRkjmxEWKFfM2 7j/gr+wHava/auDWaEgzjCuE7fRLiB4j6f4+RIO2170j5S/Nj8jvyp/OuTzB5E0zUB5BvfLA0aZ7 cXMky3s13FPJcOl/N6hULCoIWniqk1rHUdn67V6LhykcfFfTlXLZPbXsZ7V+0PssMGunH8xHLxi+ EDgETERBxirs9fiVH8yfzW/J7QfN/lf8xvyWtXuPO0WuS6nrN5cLfRia3kieKa1Ed2WhVZ1mZWZI +S9VYYdD2frMmGWLUH01Q5fPZl7Kex3tLq+zc/Z/bEqwHGIQiOA1IEESuHq9NDmaPUM41P8AMr/n FL80NStfOvnS01Dyp5s4ejqMJs2uUvoTBJbvFL6dveRMCkpCTKI7hOKNHJGyIVox6HtXSxOPGRKP Tfl93y5Oq0nsr/wQuwMEtHo5Ry4ecTxcPAbEgRZgeY3ieKBsiUZAl5z+ev8AzkVonmryyn5aflpp txpvk9ZfVv7+8LfWb9xK0zf3jSSH1JT6sksjGWVyS+5Ytk9k9izxZfGzG5dB3O6/4Hn/AAL9X2fr z2j2jMSzVUYx+mG3D0obR9IiBwxHLpQv88fzQ8l6z+Sf5dfldpOrLqXmvyW+kQ6qLUetZxy6dps9 ncrDeJygmCysArxM8bj4kZlocHZegzw12TNIVGV137m+TD/gfeyPaml9qtZ2nlx8OLNxmF7SInMT jcD6o+npIAjkQCxT/nFjzp5c/LXzR5o88+btSg0/QoNIXRAqyRyXst5f3EVzCsNirm4kjEenymSV UMUR9NZHR5oVe/t7RZdVpxDGLN39hdt/wXfZftHt7sjFp9JESkMokbIFREZi9/Mh8+ebNRttY80+ ZdWsyxs9U1W8u4C44sY553kSo7GjDbM7TwMMUYnoA9Z2NpZ6bs/DinzjCIPvAAKQZY5jsVdirsVd irsVdirNPLnlTz/dalqFx5W0LWn1rydNFNcnT4ZlvbC4SdY46CMCVZllGwX4xxZqURiKZ63Tw4eK YF7jcbjvDr9b7Q9maSOKWXNGIyfSSRUtru+VefLcDmRf0K/Kv/nID/n475K0rSJdG8w6r5g0J0la Gw84Tadd3BAmkQ/WDfzx6ih5IeIeRfg4so4FDmLLt/QRmY8fLyNcgdjVHn093MOs1f8AwRfZzTZO CWpBP9ESkP8ATRBD6+sf+cvf+c+zaW0k4/JuOaaCKR4rqy1czQvIis0UhhnaMuhPFuLMtQeLMtCc Me1ulN+ifMj+HejV/V15jrXMA7Oll/wZ+xBOQGPKQCQDUaNdR67o9LAPeA868+/85b/8/GruN9N0 QeSrUXEIb9KeVreFDExLAoBrVyfiAANfSK0I3rUDIw+0mimNyY+8fqty9D/wWvZ3PAynOWM3VSib 9/o4x9t+T87PzWn/AOctvzW1y7tvzVuPO3nW5tWa+EF08tzpMMkNqWL2kduTYK/pAgCEBmYlADIx ByI9r6Iw4vEFfgcnbw9t+wJYY5BqoUa5mjua3ifUPOxsNzs+YmtblLaG9e3lWzuJZIIpyjCJ5YVj aRFelCyiVCwBqAy16jMviF1e7uBlgZmAIsAEjrRujXnR+ShhZuxV2KuxV2KuxV2KuxV2KuxV2Kux V2KuxV2KuxV2KuxV2KuxV2Ko7TdMvdYvYdP06D17qfkQCyoipGrPJJJI5VEjRFLO7EKigsxCgnI5 MkYRstWq1WLT4jPIaA/TsAANySdgBuTsH3P+Wn/OL+nyWrXnnOsmnX9rZuIeLxX00sVw8sylZoUa 1t5FWNaD/SWUVZ7XlLbZzvaHtDPirHzBPu5eR3P2eUtpPlntR/wVcoycGl+qJlvziAY0ORPHIb/7 WD0yVGb7P06w0zR7OLTtH0210nTrcuYrSxhjt7eP1HZ34RRKiLVmJNB1OaORlI3IknvJs/MvmubU Zc0zPJKU5HnKRMpGhQuRsnYI3mMWPF5O5jFeLydzGK8Xk7mMaW/J5f5+/Kfyl59sdWW5s4tN1zUY WC6pDErsLj0Wt4p7iBqRXDRxuyRmQF41ZvReJyHGTpO0M+nlEg7A8vLnXl37c+tjZ3XYHtdr+ys2 MxkZQifoP82+IxiecATueGhIgcYkNn58/m3+Tk/kjWLuLTll4mGXUEtTGVt5rSM/vZdNmeeaSZYR RpoZP30CMDyuIke6PS9l9rRz443z5HylvsdvkeRO1A0H132O9tY9p6aJyVzEbvcSPIZBUREy5RkP TMj+CRGN4JmyetdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir7q/wCcVPy+0680 5/O2pzyXM9vdTRWVlFbxtaUDW7+pdXMZYySpNaq6W0tDBSO5VazxSZyntN2pI6o4MfQDi53vdUD/ AAmyOKP1G436JB8k/wCDD7Zx0+f8hYgKBMiTxbiQIjAj6TGVeJE1L14/4Jh9wcj/ADP/AMA//NWa Qgnoft/W+Wfyjof9X+/9TuX+U/8AwD/81YOHyP2/rX+UdD/q/wB/6ncv8p/+Af8A5qx4fI/b+tf5 R0P+r/f+p3L/ACn/AOAf/mrHh8j9v61/lHQ/6v8Af+p3L/Kf/gH/AOaseHyP2/rX+UdD/q/3/qdy /wAp/wDgH/5qx4fI/b+tf5R0P+r/AH/qdy/yn/4B/wDmrHh8j9v61/lHQ/6v9/6mP+aNBsfM2i32 mXtlY3sskEws5NS06DUY7W5khkijuUgu454y8fqEglclEziRRkNwdjKN0QaJiQa23HVzuxfajB2b qhlx6g9xAJjxR6x4hRF/tfjl5n0a58veYNW0O9FvHf6Xcvb3cFq0jxW1ym09qHkqWMMnKNmDMpKk o7rR27/SZRkwxkCSCNias+e3fz/QH6T7G7Qx67Q488LMZi4mVAyj/DOhy4h6uh33ETYBFlzmuxV2 KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KvY/Lf8AyvP/AA7pX+BP8U/4a/f+l/hP6x6H r+s/rfXP0Z/x8/Zr6/770fR/3T6OaqP8k/nc3Fw+L6eLi51Xo4eL+DnXD6eLj/i43kO2v9BH8oZP 5R8Dxtr8fh4uGhw+H43+T/qejj4/4+NOf+sov/Mp/wDc7y//AFt/of7Fw/8An2X/AEA/9KXf9ZRf +ZT/AO53j/rb/Q/2K/8APsv+gH/pS7/rKL/zKf8A3O8f9bf6H+xX/n2X/QD/ANKXf9ZRf+ZT/wC5 3j/rb/Q/2K/8+y/6Af8ApS7/AKyi/wDMp/8Ac7x/1t/of7Ff+fZf9AP/AEpd/wBZRf8AmU/+53j/ AK2/0P8AYr/z7L/oB/6Uu/6yi/8AMp/9zvH/AFt/of7Ff+fZf9AP/Sl3/WUX/mU/+53j/rb/AEP9 iv8Az7L/AKAf+lLyTzV+n/0/f/4p/wCUh/dfX+fpet63pJy+tel/x8f7/wCf731efrfveeZGk8Lw h4f09P2eXd0rls9X2D+Q/IQ/J/3W/Bz4eGz9F/wfzK9HBXB6OFj2XOwdirsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdir//2Q0KZW5kc3RyZWFtDWVuZG9iag0yNDY2IDAgb2JqPDwvU3VidHlw ZS9JbWFnZS9JbnRlbnQvUmVsYXRpdmVDb2xvcmltZXRyaWMvTGVuZ3RoIDQ2OTEvRmlsdGVyL0Zs YXRlRGVjb2RlL05hbWUvWC9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZS9EZXZpY2VHcmF5 L1dpZHRoIDIyNy9EZWNvZGVQYXJtczw8L0NvbHVtbnMgMjI3L0JpdHNQZXJDb21wb25lbnQgOC9D b2xvcnMgMT4+L0hlaWdodCAxMTYvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ5JcJUFNnHsDzcr+E kHCEEBJycQXkEomCoFRQQRBQCzO70uI6dmsdLB1Fq61bu1arFfFC19muVQfd7e6qVJal1cUTVFRU vLag6HhXBEFAuUne2/e993KAUhBeiMz+JzN57/+dv/f//sdHo/3fCwQxmFy+vaNY4iaTu7vL3Vxd nEQCmMOAIFtvjRKBICaH7yCRa7TB46Imx8VPT4iPjZkwNtBL4eYs5LEYI54SYnLtxTL1qAmzPvg0 Z0/R6SuV1dU/V5QW7s7OmpsU7qNwdeSz6Lbe5FCEzuI7y9RBiZmb/nWtEe0lDRX52Qtifd0lQi7D 1hsdrEAsgUTpPSlr74VnBBSCGPGMT0/P7lo4Xu3mCI9ISIhpJ9H4Jm4tq8OZetvQpKwpzZ7s6e7I HXnHlQ47e/gl7L7d1iegqaGl6k+TPOVC1sgKPBBLqPQL2/Ko89f4zJTt974O8nDljaTTSoddfII/ /G93/4BGyM5Ls7WqEWRIpkAeEHWwa2CAJCTSuifMS8wdIYxMkTrk/coB85nkwrt+Ut5IiDoQy9Fz /Ff1b0yIdX+0NETGHwEOyXbyjsnrssiBA2ZE0NbccHe7t56RI/ZJKEQHQYiPMeyLUgjecka2WJtY /OZuaIRE0fx3lG83I8tJG3di0IT4wMJwBf8tjjkMB58JR4dAiA8tCJLDb23uoAs8dflDIgSDDXla KcfWKH0IBCsDc5GhEQLGzjUaZ+brFhCmbT989tyxvy7RDTeaUdiuoz7uGCohYGyao7J/1R0l+9q7 9QYEMRi6O6tm24APd8S4mqETAshbkTJu7+nTO0ypCNR7BY42QOQpQ44OJh2+Soh27/dxZvWc/SvS xw16hIA8LB12QqaL75dtFADiAPWfKOx6RNVFBoDV9ay6rOT6E7x2MmzlDzMhXaBOqKaGEMBcmOjC tpg9/BlQNhQtTojUBSftaQSMt6cPc4nAlgbkdVLiiThj20aN0ILgEPDD57nTg11gNotttwjcRNFt Fu4Ie3rC5CND5u3h0mt3Mi8vyat75nv6yAdOSLdXp9+jihAwXktyMSfH6PvAbHsSPUgHZeSjdbcu bdBiHyF1Y87mhdwJO0+dzJsLorAwfUdR6YlD38w0px3O7NyiklMFG1PI0dJPNufkhtEkmftOnv5x +7u9nL5PYUtHf2+gEtGw2ducONYaMN39Of4mu2qXrsxImSjH3vdiLZULKsGgy94sWkDRC2KGmjwt 2de7oIFQ1R70whXBN7CXVbNOduHaZ9tFAyKEBKo5d6gjBIwV003eyP0BqPLjBOYFBUqJiAcMtRNr eX4bzyd/i+b63DQXVyVEgeB51ay6Fgg0geWg9TGxDtb0hYA2AGGKA3cMua7piYis9DAGVc8zYOp1 YyzLAeMzQEQM+JCs0fzTYGTjhfOtYMCPbuDjnwZt7RfPN4H/S2IjYieK3iurQgBjTchra6leRoQV M8qp4yOkOMqJPJih18D7Io/XLb0Tt9HjvdmFJe9LfwP6XVyRFp90HhRJn2LHYH4r1uHuZ+kJSaew D6FfAROICKr/80epseteghHzhP0j0h28P6OgdLMUBG39nZxLmHHiTXwjMvDMLUYNhKDlOiNiTU7y GN/xofyL2PPDtTFSmKsERvtJQ6Ndwv5bVk2Tc5nemCchV9UQiXjwvSB7lut+YMY1/cdViCWJ+J5K PkK2+JMBJ7IKvM7HyxnuMVP77Tn2xEFFL6QoGTQWWwiez6Tg/b7FKCqTaD4PMYa7M5RAtRdLNS2x HOKgohk6EErX4At59Y8Iq1JuUmtE8J0vRzkTJzXkClAsdsMRjxub0QcLnQjE7h/CeKAtBmhLZvmp 1Rr1akxfk8lMrce6XknzU2k0ki1Yldue5UAg1r/nCoYsB3Nt0/aJZjqn9tpFemoBgXT+1p1IjfKT YO9bFOCZc+BFU3NzM/ieDzJIxNZdfnjAmG0q1Ilv0LyaP7+p52fr3CgjEB+k4A6YBSLV9v4RGWLd DqqNCPazypsoQyHcC07gx4ketXx99vrNPRBf5HrgTvt7S0RMureIFr/oNet3GgLxTjI+dxYyMES2 bEqJNRCLQkSEMy5rx96bphDH1kmhVPqhlohNG3BfA1ZEkQenz5JSVvKFeAFmReSXM0bV2dK1WgLx ViL8JoiwemYt1YBAHkaICargW8A8B8wpmt4D8flad1wbhmfD5MnRmIwLi4iKHi9IrsPuX2WzYjBN TFhYxMRJkeRBvTn9jRAF2g+tQYjqk2VkgbNbjzG2rTMuyFjZA7FhNRH1BUB7LloAwzxW5kcxKjaL pniEDXwcJeDCMLRwwRQPBodJWvHNEEXBf7QKIpqh4hIr+D4EBmo5MBa8uGVebCEiqqMREU+ZNOgw uKMsA59F2VJ//85fMPVRLJ50bAKuGnyz4UHVSR5tUIjOY3dZB3GDF49cIr0LQOkbqo8fuV7TAsIK luTNViQQsayBSf0XIlrkdfB0KBimzQRu3JjjTAs7B1THQ3mDQnQdf4T6aAPizQEfO+Mai8kS2GAA fyBw1m2Ld+iFyM8DxW13W2sH6HR3cTAbXDVJFbgINWWGswaF6DbhMvWAQEr9TNUjI63WIiEgSPvx rGRwfeyBSJOXmgfXrp0Kim778+ZhLauTXQZ3UOUx1dZBvBooMi1C99nxpK1Lb0AM+s62p4VLZoW7 gHC7vb29s2aVzLSVXU2deoNB39VasSxBgWdL4bfNHbiq4/qymSpM5V/S3d51g0D8+GVHu35r/4iK uMfWQbwzxtG8CiQIyNj1n3OXy4vzVqROHSMlgm3Awm+yv04zIdL4MTk/lZWX/P3zGRNcyQsXHLG+ 6Fx56f7PU6PcgIo/ZcX67JUxeCRTzVuzfsN8z34RlfF11kF8pHOyXIfOl3oH6caNHe3rLmAYlSKN xkPBN3diiDSBurFjRsm4ZpVQHagbF+ovh8l3V2yMGzEDX6nRqO37RVQlNFgH8Redc6+lICaLzWK8 dhcWlCw2E3pFxYBe33tAoop/Zh3EXla0oSjinlgH8Z6lL9pU3Kfctw5iVZCDrdlIkb3zs3UQy0eJ bM1GimvkGesgHtEK+l99WEQ87qB1EL8z1ai2FofRm6yDuELD7X/1YRGB3xLrIKbL2bZmIwX2mN1h DcKWSS79ZfnhEo58WpU1ECtCRXRbs5HCdInMp/7CiKA7/eyGUnRRKXRRwBqqAYFkKDm2RjMKxFPP baSesHaaC9PWaEaB2K5TT1F9UhG0IFRIuqJsahIpCRNVtmFkOPpbITMuVcGkK6ZWNzUS8ry+tjrn 1wvXWOMF1zGWwiIe4ik/eEStGRH0dqLYeE7T6iyb9E8j+t6K57+fpOA3X8a0+8dGsahjZEkiClEq GbGpdvqb4mlaLYpcu3Kl4mpl9dMuBEGbg/uKtO7FaPNyKTjf3ljSSaKwxKXbq//wglrEhnkStiXi /PhJ0dHYL+WfrSha7NTHRhRH0ZdfugFELYreSKEQEeJIJ1N82yjQCU15H0NE58rYHA6HC/P5/9Cj bZP7OILuOCJkBUQsNar+x36ZBzd1XXH4vad9sfZdXmRkWzayjG0kL3IcoCRQmHEwix07DSENlH1J KZiYAnEWJlM3MVPcMiQZILETYsoSltIJJC0ltGmmTJoOw2IKNnGhlCUG27LrRZJP73tPwrKRsCxp xlaH3z967+rc++53z7n3nLvVETk3IieuVnEfRCOJ+KLC+2bvgt7KACeJ/iQ4tqjJp2SAc7MHLioi rfahLjyNTj6C8omjnfTXiO1GNMyxbPFAfUohKr1vsQ7ofT0OPfxg9csTPFOMnb96AQfjLN/cCD3H N64VZ656HeDf71c8IyT/ZdhX7Th0aE/FTDFtrZq/Zjomm1d94Ehd5dSgywuGJGFDW+QQby5S+tyj BiM+2QU9ywzooQGgRku7+offQ+cEjhw8qzx9K4CbfLqQj+4q2l800+O21dkp67w78IepDU6q7VZ1 oH39kNiazN+7I0XorEsS+YQQifjCgzjb74JvZqvQw26A+kza7Klr0DpPFPPl5S5wtjR+t2zF2SYA x5Wrn88VYrLP0JhNf/7TefRzroi0tjXBxYuo7e+XulHbW+IgEXFhfPHNiLgRjXFxisL3pkgirjTJ FQq5KqX8SA/crSzk0IifTHyAeK9MQqQvuQCdOxctmGZ8Al1hG7f8uDyXhx0EaP94ffnM2etuoCPI RiP2wrXt618o++k5gK78YNMnU57yqisyiI41Or5v5iMRb1+7itT0XSuaZtUsDUYj7vVFRN4wnQJH lVEsZDCzkcue1cTwsSkIYk+ZRcbnigrbwPWxkEKEu68UJUsF/NktAD8POlQ5uoyjEXGju36chOE7 MpkXB/7uO12iIQIg+smLh8H9j7LxdFCsAGiezqAQfzuHMsNOA+xKwoIULkx84lL4jP1w1qJiDxqZ 9KKvRUcpFjxiO3S/W+jJHvweuL9ZTCFustGreABF+4Sgr6UMScqs78PMHKjz9ck67uBvkl5cUTYX qfSljcc6+qG3JGjEZCd0rkvxDEScgd4PYinEhQa6qb4f9mUHnx1ZirTFqAAIgxF1bS2JFQ75JIm4 KEkml8sVSo1+3n/QYWjEg0S0O6H9ea1nIPwjcB1KwaxN4HxeRTfVuaHBGrQXUeZQmSs7wmBEPVuX JogYQ4YdnBexZQCdFfzBiM2BEKc5oa3Ym3Dw98B93Ex6sec5eWiIOEdtqbofMiPqdntNomQo4VBE MUDvh3oM2zOA+PQjvVgq8c6vAVxHMyjEclloiBjO1WS8ejvE/Yg6/WtNopj50KhDEAmEuN+EY7sA GjyIRdcDIca7wLFc6u16Fnr2poeHiBhV5oqWkBjJlL/YH+FQRCtA924zju0E+NRGIy5pC3ii3oWe Wm8JL3NBW01qmIgoVhWpC7+FEQcraf9lSXyMH8KhiEfQXlxvwrBt/fB1Lh3VaFtSiHEnvIjJXsR6 6P92vKdnJarNFxvCRURnjixp5oEQXNi3e7Je+NA+9CKWecvyxF290H92DjokV7VDXzk1ux/d9SDq j4G7ijpIDKiAKyXXKwP5fDudZyffB9fJGfLwETGWJCGnyjGiYEWmd9ZZ1Hz/CYpE/Mv++vr6ur2H v7mJbgjtFQWoSM24gjbvAh6W9PY9t5tGVH4EcH7DUgnypwv6ji+fycOwauT0D8dhmKDiFsCNlRNZ EUDEGAKdufjUCBiR4e+mGWWcAJ8iEd0uStQVqfW1YqpIrXFCf4+jo8sJJzwnKmMDsuyFF0WY/CsA l/tyHgsT70dPnS3X2vvQOm6aocAigYgRHLkx82c3yKkPi0nZNC8x6f1uQ0rP3UJb1Su4vm/pLAPl bmZtN9XS/enyi3DvWfJSlPQ5uav3puL40x3k0EulGK6o7qL7u06vLIpFOLar4SOi5RRqUwrfu+Py QDyCD8B5syYrXsYJXEXFvVTzG1o7fvXaktIZWTLPnNhPvf/1pXNHNs6xFr+5bZaIsq089sXRN1BJ htt2njh5cKEWmfLt206db/zbvrWlBUqyp6Tsl7VzPIkk55Vfb8gMvoDzFc4W643Tdjd3DQfZ+c9a e5yS7/ec8UpgTPPIlGRQCwYWnakYn/9kYZaOhevTEukzRTAuyzZRh0wIWZrVZomhFlyabCucVJCh 9ZT37MTUJI5nCIUpTRmSFzEyWqXa+ClvnbneDX4w6df/tvxxS65WIWSF+hEMZ3HZQ5yAM7wNBPFg XCaHE3AjhCEGR6TSps+v/aLxvj8Htl747O2SFKVMwAwZcAyIYAlkKr1lbsWOw19dud3potlcjluX zxzcvrYoVS0TcRnRDEgKZ7D5EoU6IXNq6U/Wbt5a/c471W9uennh3EnpeoU0hscMbaePNeEEkyuI kciUmtj4hERDQpxOLZeKhTw2k4h2Bw4STjB8Rfx/0Q2IweUJBHxuVB8vgcSUapMyrbbcPHtBgT0/ z2bNNumVnOH7RYdwtiJxYp49LzfH5itEm5+TquZHvUMJjjLVmmPLzvIva06ORRfgehEdYsbEZ2Rb 0s3m9AAym82WrGyjlB2lvmSJEyzm1OFlGm8xyqNxXxKiWFOKMUglmwxS1mjPeKTiqgyJCSOQYZxG ONpzHpliNHF6nX5EitVJHnmhGlsixGqNOgTJoiZYCbEiREULIxEjk4aq6IhVnCcWhSyxMBrqAJYw DAmEvNGe//Ai+LywJGCONsGwYnPD1Vgv5ggOO1yNdTcyWeFrtBmGESMCGuuR+liP9Vijpv8JMABW gfxRDQplbmRzdHJlYW0NZW5kb2JqDTI0NzEgMCBvYmo8PC9PUE0gMC9CTS9Ob3JtYWwvQ0EgMS4w L09QIGZhbHNlL1NNYXNrL05vbmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdT dGF0ZS9TQSB0cnVlPj4NZW5kb2JqDTI0ODggMCBvYmo8PC9PUE0gMC9CTS9Ob3JtYWwvQ0EgMC41 Mjk0MDQvT1AgZmFsc2UvU01hc2svTm9uZS9jYSAwLjUyOTQwNC9BSVMgZmFsc2Uvb3AgZmFsc2Uv VHlwZS9FeHRHU3RhdGUvU0EgdHJ1ZT4+DWVuZG9iag0yNDg5IDAgb2JqPDwvTGVuZ3RoIDEzOTA1 L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIibRXWW8byRF+J5D/0I8SEI36PgJBgERZi2zg YB0RyIOzCBhpJNPLQ0uO7FV+faqrzxmaFGU5Nkacnu6urvOrr38fnf50Q8nDZnR6vaDkajX6MDq9 eZwuydnZ+fnl1ZiMKPH/GfltxMiM+PXMr7+cjE4nEz8xuYc1k1tYNPkKf8hkQxj1v//1n9aE8SCB E6EJN402zpDJYnTEjyefR+8mo3fv4ZjBqUktf8yY/zueU0QpC3IMJ0aIhkeBH88oFYZSeQmPpTA4 P2Gcn4WRvI6/mlIFq5SC93EYh5UMVioBD4fnIqz2q4ocpQcy+HCFl6h0b48Ia3Cti2eauBIcJS96 +1U8l4Xfy+t4Ul9mPLva5zWyYV3WjBYbtvd7L2W9bNDDfxvY4vVwxVKUKaOEcfzOersuqhWXRQP0 mxnaqsZD/+YTVJABs79Oft6VJy/mB7ONrfIj+8T0fcOCDZye4S9z8MuLfjhW/dzCbzlWplrHg8/S mIEcBlnAZHin14M5Ve21xbeYseNqbHMcUc8UnyzLy6/OTbmQo1H2h/mL6pxKJ7RRxmy1A3nb0Qlz O/yadXUxy+JZtV9l2iPiHA/zVcagjCrrt+KBvlDVeTEuOU9VtuUt2URlI6tseqnqfGYrlspaFgCJ KRAmk24JKVKctmyo0AI3YvKMa0m0H9FhhSp6IFQwVknNL/wFcAqmJk11jKYtEWZXr9CjSJRRmi6+ 6R1Zw2HYUSmp1DmzEZdUz1nJzTKC1pvTQzva0Do9XgOgmBF7vOLXXtVFUckQySF1uLfcEAoju6HS hfW9kKMQky/rluRdVvv0QCdegVjPs/3krtvnXn+kc2r5g9aC6/bkJmMvRbUwmYY67YnMMLqMaM0K 1Th6P5vPZ6vlhqzuyVM3m8+6Z3L7tOlWi/aYHa035PiEHU3n63Z690w+Tb+0pPvUztakXbbrY2aP Hp7J02b60JK7aTcl6/Z2tb5r78h/nslmMV13ZNF2LUiZLu/8RnJ8uAGMmr4BzKjGSq6Ilro0w6PZ 8g70XT+T2YZ8Xa1/my0fSLci3Xq63MynHSpM7tpuOpuDYmBUpVjQeraE9dHo9TFnRycvqVmqh+7S UfA+xDpaqFrVbKsmItgray2im4jghr+Cl9zJMv15KddpaVBpDe83e8HqplSIYNFPf2NddR6/KDWS bM1zqtRVrp16PtlfE4ba9tTMryvdL4quWMeXhyBgTrUTKBaldsURiBctuQaZTL6s5k/LbgoZB8mU sw/e23tfEfcryC5IKPhwC2UDCQhvU7LpoAama8xAWLKYdvGtLqVbqMSnxWMHFfliqRyQg1TkW8rH RFCSL2UkrFIeSnbDyprsli8VmpWZHUQrze6mWklyDzPPTyyyWYk4SUW6r0i1Jew80ZGaAzgad5dD VD/x47Eiqdwzcwf7jVJwVr4q7TzC2R2RU9ZVGB1wedZuMJMASdt5e9utZ7cerD2gPT0+zmceZmdL Mp0vVpsOoHp+j8i3gQzECT+4XUHmriOQf3eCpU6ijOxdSrDnxz6fe70pEU4keMB1Qj9XBR8TQRyQ xUyeK7zBbzvwJsztxpshGccx0yHMeX4/FeWvZKLpYmZUTEbE/6S7DD5S43Pt52OKhTPSWhrl61xP QW/5/9H7LUwSMkTTfhfcupLRPbS4jk4/8uWa9DI7zFnJomxbuuAWWxPfQklaXVGHGbgr+/Zl3u7u HrOk5/Hr2cPTui0+/32E3rVEOdYo5QhjpmHag0ZjmQEONvonWcKy+F1IGeKC89Y6IVN8rGJRirbC kdvF6PSvC0quVqMP3wz3h9HpTzeMPGwikrEYdxrijkdw5yD+3DZMWO7jfhQN4A0h7/54BOQCGnaD HOw9crCr9nG+el60y27jeeNN53smvHBA1ePJ5+wJsCicQ4Rz0LK1AD/CqRqO4twJ4w2IqpC/Ab4q q8lXr9Z7+PQZnp/Jx18puSO4ajEC0G4o1fA+H92AceUADuzNcc2c4AT8Y7x8Z18t34oGRGT5+7pB r3bQh8y4Rgrr0Id/X3XtX0jyJNl8Wn3dIKK3f3TgOM/ee7S279JNdum//gROhY3APqYgqZ2BjDWp vXx4hQcttWpo1HKrB1Q8s9cD4p1I1Tw4YU5iIoCB+qxay0vFZ7mRH6Tql6WCmKcKYovDVtUmSrUj BbDVGlYYTV39iFDXQe+kc77bpUrndIuvy/rsAeOp75MJ//t9D57LAe0ZvwGXQ9Qg83UdtXGFj+nG e115eYCTVUfre9rSnRiacVMOPKv7XlD1e+oJbMgidmDyLnkJa+PenGV60CNS1qbOWZ3HY89KTEXF iKnMiMEnFH2ibKKaSY8oD9cMiCSLNohhFvyILhyiLXTDY7TPitI5WKkMkxMS+ZeRhlVO6DVkV5RE A11xxLBJbtOWKu0HQc4JZMsZWHY8OpT21+cgVoHoNf2U0Cm5B+W1past6zJ1MpVtNRQlGy5iQlQF E9adA7aC/5XxvWVy5wPA2PkbAJea3BZ86XJXa3R+YnhdzxGZEl9CkzLSxcVbuytOHD9ES3Gli2Iy AKYzU6gSOqridvmuXJgMO+u3hlSIfWl7AojXLp0IdIIaWu3maXdMmYK2SXwGoe8prMQ/esE4q5T8 xtFcVK6JMJUMzHSwbojfgF1WNTtlvieJJCiuOR8qHrF8v8A9XMWJTAKOrldrcv+0RmIxW96v1otp N1st/0we5+1005Ivs82s+x7KEUlZ77R0qcgk2wPrFTw8PB7owxOuVIz96CiEczjMcxsexr8npyQD Hsucqq3bxorhZeD0l/n0tr375eqanL4fUxJvCLSxnFrHBUo/oY3RQPY1IxZYq9aCSUOEMI0VXCgW iHPjlCFwXYM7AW0Yd2T94Ok+93Q/8FmQo4Auww+Q2rkfCirICfBjBUPYZAw54Q2VOHLaD5SFAYcV yo+M3ycbfNca3qExMedHwrEwlNJLVAwXWi8fqIqDkWi4xcOZn2MNWASKcgODT6N7pO/7zDbgXLgk gNmuERauRUoHs4W319sFayQj//gJvhk4PzJ71mf2fY/ASosaKolmKriWJX1lA87FEUfLKFzDvMtU GGnvbBX8obkmLMzAjYHCpSZ4mDUSNOJeRXS3d3D0r5cLR7PgDRhJ6+3g/mSKN45P8U6z2ykQA6AG DLQV0KGYUtYKe2AuwCSIgEihNl5f40fMMjQCEhdNNyyEn3lBlONSDvdC73Z3UOTgemG0ZpAWXkkN /yRUy5sjd4K+iqHyKYzZ5HAk/HefVz5/JQbNhFVU4xCz81AvS/AU1Qw8IQSkvmDgcX6wlxVc11Ba 8J0xwemoXnEzpg6gI5PeszSMaJAu+IF+ht1GOq+maoSU1oHP3+xnCDf6OagBCSJ90goEAooVDcUe QwC2edNsGHJUPxhzqK9tA9+1oMHXgKLauMPBTaqALzJp4MEOgIbHXDBgg/9BTDvxzQi8D8dQF8ZS Kz/mOo590sJYKxdK1FKct7gejgO5MHQ4Dathmx+6AHZQjChcBCyREnQREJcwVAZRk7kw5F4zcK6Q Za/HxuBzKxEppT4wEbSDmDGBHUIbLrQQPwIqJfQAmrqD8b0ioiHYwdDzAQCFDCDqR8oHNEMq0GiK I+rTxzRCe1WcxoEi/2O/alrjyo7oXr/ibQLdgde+t+73NsksklUggiwmWYQeCSfMyMHOMPjf55xT 97VksNrPjgayEDb0K92v+jhVdcq8GDaUMnA0VMtyOZNxpMlVDfiC/8rMGDTeGUDGL0NCfnqqIZlQ Ibt5b4NLgdSvAONgOwARpSMtIcxwnO1GI3LE5KHcZnqMKjRmiUh9VgIkeZuyoYDhR15jd0VrAXzm acj0N/JapYtA4m1ot/M0ULbCn5vYYfXaT2niHu0JUt80aQO4HqdiUw7KEyBs+wNNWr0xIX3AadbI cuRZ0NQ3cKs3AxZYSKXEGXwiGdZKygw+VgWTrCKtzUJGbybJbWyCO492qdEZLIoOg4EKVJ5oOU6j VVphWsbfE4ABK+NFjvJJ9N0dkIK/Lqtgi/Rn1GLqSuw4FRm0MJ0mYnumUCYYQ5YYzG3ILAlxuhbh 6arnzc2NRfzBowKHhbwlCWJg6qh5VxMduDniwzpymo9H1Lj2EjkdPVezK5Wa0rg6F0qyxQ2HN/RQ mIZaYFNoNp0y2BTqdFFNSjxzZwakQbrsHI3ZuyU2IFYuSy30pZ76xcttrqAAI5LdGSS6T3/iUEru e1NvZ2DnIpxN8Diz7XgJktuihtsp54lw0+rYcim7SAmPV9/quYFAhMZnPI3riWRmTMhCRAfqp23r wI1tOwmjYEb1ErTS3Abj6yYlFrKpH1IBGEiKA89Bgw1xhGxipUy+Navabr5XwWCYhm8NyRviXIvO xmf3C/2xTO8sia0w+0ovZJzw/IiA4u7pA4XGPAPM/Z7HUEVMU9RYkcskxJWrwF0QWZNv1sfq7hnL UF141CaaIMH+PlwcTUla5+pw0pWc+LL60EW7ErGxD+EDZDYzzVob7QXIrCrG1htMoRal9YqqAjNZ RHkiMA220SULZgS6L12aKVskhem2zO9cJn8p26DClkxBDH8nGCoqONgt8xx+Z7IKGLvBwDGCvaZu cFQ/zG3rUaq6W+8s4lbWJxNTN8zb3JrIsQsQ4kDBLxPT+1NHrCCJfrPpJkrF6wqLGHfmzblxUZp6 0Zl0bk68POgtgTlWBa+5ZJp4JSFnvSGE7oxkKOOyQy2JQMW0B2mV9Ncsww/g8siREEgSX2JuElHl USkVowBm0jcGJU5wKcGHosmPltGFsrpXOoTFWltUtS2LX4unVv6QBXlBTzVd6CI2ivcpJlXRiy6g uoIMThAw3KyC0dMg4j4o0b17wiuTzMERnfVwIgNgm97fCeMySL3KaMxp0jx4EnV773xnnrnBe2YU FIqTn2rmHN8B5Z6dQo4ih8Pb2vC6aNUTXhUp+40hbVn9RcjAkpxTa6pOJMol1peoTkii6vQ+LRd+ Hx3HCJIpzsEljofB/Q8HZJIE/46Bw2HxgaYVjo29zZDB9dODn8asoJWiCRgMq4AWkglGGWTSzbS8 v7v56/Jw8+b3fwnL+QNsWD6cHy66/+725s3treHPt/c3pAVjuT1r9uDXL2jTgXjli+jRbJtpsBsi 9laVq9j2083hbwY3HW//pRoZdcn8+IWNdgAhy+0PNwcLYALbPn+ClXb48veH2+Max+HtcU2HuwXf JR3+eFxzOzx8OK6lHP4j4Z/H1er8/tl/7pZ7/b57f2wHnGz18B3+YIcftffu/OQ4t/gV/tfFd/oF 909e8GX/vntw6ePx77d/otOSO00G22aw0SIQlQESSqchcQOCnavyB4kaKue2Tqd9f/gDLMyHu38f 1z6oaI2Hd/r+eEzl8NOx4FWoXGEQH+VT6Oh4oYg4Tp9ph59beMY/3x/zgFe0+FZ/+cfD4zUoF1Pj ODVuM1VQd3p5orGNDhaGFJfGJfwGsQlTITLdDTAcCxTNiFFgavbu/tjzYbk7jnB4+MGP6F3fOWKa sFgv0PlUL84rl9t+dgjcvUeE4uGDrvvu9lqu5wjdGwoWdMuB5ZPtt3qyi5tbrHpkq1rpSdViHUcz MZbTtS6cJJcz5yA2wAWh9vXI9Djf4CdxSetV/843OosXfClo4/1vrxeoq0p/XYX6dQ35YtPIVRWt WvqMJUb355FpSUr7LFmzDPjxax5OHSqnjtRs/+PDse94uWD8KuhfaLtpoLT1gHRyk73yXmLCERCJ nNDiopzPH7i/s8vz2/LcZFn+xo8omu+I2//zjS5R9LS+E2ZXNP1WmP3KJu0AHCePlslFXibuZDSi ZJoC00YJnaR5ez97dxa7NRUT5VNfPt746aS5RbMDR7OxnSbZ0eEqYRL9LD6tOSeSr5s2cS4TexeN 4AF9kGJXvqUtHFVFOlC/13Hy8U5RiGRNZw4QmdyLDIt6kW5G3wKK4kLTe1CBG9NJMwM/wfU1Mcju Qv6PbUNPxeo0ByJViKSu+GF1lVQkcDiRQF3dHok7cqqju1Srg0jF06A1pT8/Q3no4Dm5UvwJ2sOP mZaKTANbgbqKo7dlbB/V6RkroKamtzvS6Ipy35JGL6L3TlafE7IrJJTlhrYDdFkFNxatB1+M5Itv /hyelC12dwHMxxBBsqZJUBnQ4N/MAeguVPgZ40qUS9bYfAViFnzwPXwSMtcf5SA6NJOkPAQhjUlD 7w53A5HdH9emWD6R7BMpuMIEJAcIuXkw+aJ7GQuB0xXVgJ4FfdB8HoOul2+YVF1Vub1ubs9uf+N1 exH0fBCuIagDQOFzAHqN0dfGaGe2GCafHCxFcKWEaWvkmC1eyRbvG8b5h6+wkZm5BSq3jwLohfVT oWYJKSxJLoeEombkTpQQSRA27KfaCfGAtTn5dzBOa7wiqzEktisI+vUGAslOXVLXWlGl1ouQmhpC P4noZPkLMXQpqDN1zam4JER1lTj8uWLC0qDKq2ZW9Y6+KwGu+PWbEuDV7fsxTZZkuRgKQ2pwfbJi Gwl8trUGZhjegzb0Ity8ykNMxiZTxlY62mUJFK9HGhYoIQZFZhZJWRJqCd1tuAVXWmFmw8eR/MMS rYXU9XhqvFtuJjVP2a3O2elXPY3mzsQvxcQoFAQIKuDCoaAMem7Fc4M3l6BVq6CQFFHmJDU6u2RO SKuRmqG2RJEhGhF9keTNzMNbRQRJbqRiac7aGrGH1eqcKfJCiJ0oWGGOpKb6NzXC1sERzSWYbBvn hDuNxTh6hV1lZ+bFexLuWtCv59vnif8rHP6P4bC7uaEcDSsdEcPYBDe2knHbs80NKMGAhofkD810 0MH4vkiooWFXIWJJ9CFdrBKVWNuySAcOscKN2dNNi4mH4mBZZkVVaXV8bIuIWB3gTZxiIBldx5rq i4XeZxn1Cg30LMBBlzNwIWKMxRqb46M9OQrRIMqVggfZ2XYUIrzGYi16UaqYOU/MVYyFUKk4luhA 2hYEdoCHaQdup3emCP1j9AYwOp3UZnNo9riXD3JrEfhdNywGa95+TBfVHL1bBFwEKLXkSvTy5JnC 2Q3wNrU4iFhFHgWlCnEuUfqjD8J7bC1j5hzJF0Le1R0DcxfBMGXr0FAZOJ3sa/fPIu2b2v0rEF+B +Bkg7qx7EZ7LNYcOhTPjaTmX0IRGH6cqNcneQUylHaXcmVtiiQVCxPHYVhZUbOrJeo4DILOq419O CuRE6j3S1WC/sKCMisJ+0YKkExEsxLLDJ8BpiInaJ8mmCU6Cmv6MizrRqU5mjGs7KVbV1DiA5LaR 28Du1d1vjGRSC5VVX1Y9GnGfa0RicJaNoyC37VH3rJbGRBIliHzMh9OgJtp89iPQqNfwoQxRRVat Sd0NW9mb82xwILmhQ0nmRPfuZ+DhKxywyYUj5rZdV659jnt4kPSiBx8UjXqgrXbp91/2yyQ7jiMJ olepCyRezMOJtOmV7r/ob+ZRIHsoIAWpn9QiNyS8MjMGH2yg3OLy0eJQxWx7jeenQ1JfYXxqaXP1 +JT5T971YQOhvzWWPcLOZVqKZarZ/goK94e6DZWIp0NjeHn/Gkdn33xgYzRroVFjClMoDa9D3VkG 4+Nbd15y5EXpHMuFHQuhUciuBun9kj3Mzo2C0257zT00MgtZ1vg3fzcyTizQ4klIOmoN7Vbke/rR V8i4bLlGS74BG0Vt6gCVw/yv8GjDUGHUHjJn5NwjkE0WHL3vZ0cgbENAhieqR1zSPXz+RFMNbzFe Kg/F9pALrWc9He0VZcEBAU/jVJSeqsYYi7rsN63ptveLP4cSa9RUtPXxU6R1y9JLOOHVmyWvgc01 u/IxcqpxCyd6oxz06kp9iuQasnr2Meoc38qxRCaX8LvFvLMtJ3d5RnSlt0JfzmGhajpjWST2PNkG SxY1Xfc4PjNcKY8tFlPCxyqjre8gwaXsIa2Hyc9zR0ApaIwVDU6aKVrvblPYCmYgifMwMfnjN9fx slIW2/V7IoT0jzI3vQs7stSqrVOJb7DvBXPUnkM52M6LjUh9m0e+V8otQrNcn7pVOWq9l/egC3tn uBKQhjHIOS48k5BG+r1ERKs8R18GbcVsX0XwXL3dnQs2KlzmTEsXxHNk/prtX4aUNGoINWTMUJY+ odBZaE3NcgSMJA1ZR6CquiXGN2t5e7Qap5PvWpGuz08HaqxUys770ZX9xFutvDYbfLp0rCZs+Ic1 YX2PeJjJET2TY3yqL+DEK23qpx0jLaDc1hp2ln4Gp3tymQhyS+Q7MLjD6sfPWK5mh9nLsAfgU89I sd5US8xoA0q2IP/nUwRaYrjBH2tSQlTv42lCaa2R5dzc1BRht7CDJmfdCfXBnQLlhol9SPUY14bu lgNcAcStlcpZKkm46t8ZiMi6M0CVICPxekAArwz+6CG4qKvg+km7GWI6m0tXDQFWLpF0VeTS5X5n yb+k+n92xF+8I27q7y3P0/OAf3uS48AYRlNgC9UP7Bt///rLE5rffH/fqXqXIqiFHe6BT24ycbkq N01Cre1ca32NPsWitZ2GMfyT93EsAKQgbXuUGxl49wCSO12avd8VVi8P9qUZ+WPOfbOQQ9xbexfl d80fFLuDb5A4k2O3ritkGOW9lLTVzpYcnoQpHXiVI5f4dXep/hWChN+li9EOpl4EQE6SMkegMXNV Ykv28tjBKgNhye47JiZXcX5aqJltdFKPjMCTjp0TRP1gXN6fT/BLy+M5q5maTOZu3+TTzRVKvRtz JlJJu3EHC8GxNUCXZ8kKYBXpvRRzC+sv2B3+rOexcgVSuXIAQhe4WSVzEVV1ao7TPTH2UWU+7qr8 37rqZ81+d83ujhQCuSeYDDlXVbja9yifjNQlRVy0VQ6bxdqySaFQwX6Q8mRbbgfeKb79efEwVhMX kUbbIlxVt50y8wHSSZpSOt3ssOAy7uubZTlSwmOTqPegWaa5xkaTRnzMJ+zIRNXHysGhz7CFP5JD 3ZINUWq5w/3Yh+FPmFOOeIjIoLpUI+FjhL9NAjaHG17ZpxwTW8E0rH1ENwyPzVjzhPAlpodzrHi3 83DCwzUOubcMTqSQjmzqKE1Ddd4mab/K4fIq0r5QEE/pMUidCPMeU33UAF+Y3J+t8f/SGnfFE/4M gZDGfrAV96gpgQUfAwT5ybmJ3us5JWQAQI8SiDrlHimhZQKSAHgDzX0s2AMNL6VqD6jKCs0pZTfK cQQEruA1BHM/4OyCf97uH13nC+3+Z130ZvFyUQd2BpvryhrsURcX/KR6zJbkL/1phmM0m9tonUlF 8V0a1RhHSPmCVJdPmcXb1pUPS3kl9yIvNiWM59a3jY6vEWd1KAlbZ3wZgas/fQl2qLAzE2rPoC2x XBcD7KkrzQ7oghdNvbR964pp+DPuot7Bcn69n9dpAccAC+teMHpYMbbR+yqMhgtkkkXRaYvjikJQ nOI2vJ+0HXm1SuH93hT3mHoqO1o8lxAAwKqVwAi8aerEUAbtNM84DWAsU1J0W5VQiUZAtO9CDq+3 yZFxFkPHWeSq4uYzyVyNm27lozb5ylT8bKC/UwPdBRtZywoA0jFtsULfe+7y2vMm6fkShlA99TBJ 68euyJ3CkdDG0+KBoCT/RXWR9QGy+q/EC3CfaqLKQ9DNuuO0BWxdV2iS3FQeomiZLurk6MXf2UQI uN0vwONS5J1YGs3xjChWMbZ7TUorxaIyDVLoj/xgu/aUQuttlA+Kp8deG2eAjckR9Ubr01t6w6sz i1C1z5FEIFc+Wbnc3VcLN3Rjul/X5bPpTv9tun+W7Q8o220CR5USTO3PlmvMMj9TX2enEjdmNTJ2 zbdkWREYQTKTVUcYTPKXoipbcJpX4KX04zbA9Oa6pi0NstQ1gvVK8i5gKQkzMmgGKF+glmGeLcoW 2q2Ao0HLGMtTvN/B6r4l+YfzI95RrM1m1K2h0oqooIQC4mxksyt/l0Qt7fC29k2Ke53Ir9icHy7F dxsWHVtmmgVV3BjE2tZObP6SBJbMiW6QTaFw2TZjOpUjLjOOp9LdZXV8V3wa/uwtae6yPCKYdLMX Xp/xS4D4h1/hbq4xh2MgtZADFQGVOi6zj48IV20qHdBiR4FVAaWMoVNYyNO6D7BJqwBo0VpJZ75G cXOHdlHcrUH4WpAtIbX99bUEyEyJgOlWTV7f5Ysk9Sdd9W7tllRbW5Jk+FFIqbTBoT5GdgaYH8Ws FoDF50Zuzq1bTlvHq5E935qUhjycVsPT7XYx7TVen29Ss99i5DqfCyj9+WLyLRcj3PTmcPOeGCuq eIIPznGiUMO4V1f8wEQ0/zCiCmgC7fC+hHzHyl6j5/hhxqJsHWsYovihkDn/AMXmf4up6XB7KFzC LyNWBiZzFrqVWU7MAWmulmweapOGkOo22CredF8l9vu8KXVA3c9ZeN4fVucRs9H33yuT5cEqLSaa mEJKv4xybtusWfLwWVOT2KB8Za8QFvyPTB9zHwmSHwNSGUd25MfklZ7jIUd7D+dQJ1D/VaLQc+rL saMrkCFD7bYi5H+p/65DDOupTqa8ad9KN0dOVmBMxvKNerVXo34kJNsq2JCoG+nXmJOidOtHb5S3 bw/09WPlKA1QOVbQ3nhIitpt0KZQkItiQckP5sobsPHRGH2B138O2M8B+4EG7CZZFRK9U144nrak SXPVHL3UGbotNi6cGkFHVD6j7Uc5bBYRE1PzsYoaDN0vXNx8K0pUmKeqzqrhxz6HhdcH/pKY+B/f 53YVaISa8pZ/3dyv0WH1dRXoDPoDv6vuQGsa2CIocrcggU/Z9STz8o5IXpfpX/EVItYDGBHelfHs Jd6UO2AIvlt/q+2ez5ouh9bmkKjhHhuzXisOunDzgTZ2NwOqbNlSLNCGgKyqmyNbSGrhxLxZ/leZ +lL5/66JvNt3Us99JqFmq/KKO8O1rxuPE2xaPfAM+eq8eDgcmIiGTeY8RshEuU+wdJsdeRPDMmxk uHyLwD1dZopXxT55ByZrEEHbFs/IZj214BmERfZdJ0Cd1DzHkhwu59sjC4i6FMv8MURfQULkzg0A Rd1TJh9k7UtN+AMk9W4/ivJgxM1WCA3Ge2WR3st+BHm5U347U9ShyQBv8jU1y34AWRbNdY90ZSW1 xANu/wz8BaNa4q3xyDmuPO04oYVyIg3aiq+UiOoh7HFnBlla6Saavb7vlzrpL52O386FFZmdepmJ SzklG7Bmv67MIDEfv/5yLu52TNqNucl8JB2kAy2jaVFaHICjK5TeagLOUt7eBTvQGhmanjPu4tkY jOejZfW2MRwByhDYFiAYmFyivd83rpaBBmvG7vkdoC35N2P4SAkyVxrbgq5aCzOQ+g6Jkaykt0CA AUXJ1hy3QVUTgT5GfGee5P5W4vyPtH7BTf3oCb/bzGRgpbQaj9o/2a+WXEdyI3gVXaA0/GQyybUv YMBH8N6buT/giEiW1GP76ZVloOGZ0aafsvmp/DEisuD3sL5e6evGd1Qzrz1/J/XrleWz0p/9W/t9 QzOzsphWZJTgW7duGMRnBJ8PlivIoB42BqiROfPMJ3hFkgTJbChP5NOFDEFF9CtIG9qyf543za1U 9PnUzuqBUUQmWx1DOFNGe+6hcErV47HldWzZgyEGTFLVX42+kEmenrWdI0NtTLPRXkMR615AKwOz 5A+01YinhRFqoaqZZWAc7stPsU/G7egbzQa57tiICE+5tpEOe5DUI/LDF97f153wHtR/GuX32CgX caMToqatINpRCNZa1/iOBQszvDPTKCL3YKOhYKW2Q6lxJKEMFhqRhjyFfitxO2pCLRJnP1gQj347 AJmJnyghAgulwplLBN8UvD58CDdxDIhbmYpFACUFDa5JOqJT+8NAWnHjSMU5deGklKDzQGKkTzeI Qg6UR43F9JvMRR/hHZrhqP0B18HNgxXFx/Vz/rAwE/9xDAmBZq7cxttQ5oNPQjIWEredbh6IoBv9 7Hbp1b+s4xu0+6nwz63w1ecKeGzmfQAbDAqiLEyHyPjr54oLXEmYGSkzXhPlDgmog3p+JsBjJwVL V+G5E9Ik8YuD4YFB4kdrQ+C4O8+NBDBchvrW3LgojGhlL2XCOMnN7AyV3/IgWgNIevQcLGCBCo6m kW9xx9E2L3DUrMp0nstrUBRFAWCOpc1pBot6cCBVkxX1ZjsBFnqMRVI3VvYaanJuxGCDDKXnU7fU H62aZITWXB2c59mL6O7YzwB3B4ScZ2/g6cz7NRZ/Weg33vOnBf7PWuDqgy8cGlpt1D5QQ7P2YZg3 vtT1OIv0jFNmIfG1ZMImQ1FU8AkVQKpiuwtYfKTVWdW2VQRBqt0AxKlSBsGynwLQCY5nSinMOr81 nlY8RVxjEmUUwThujNwX5JZUi8656rzPiJ2ZUCg6+BT5vxjETtGk/SflcHJbRHedkMQ7Zv5syRS7 a2bCd1YnRGE1HsGvHxb9btlRsSmtC+rHZjhnR5XHMeYq1PpsGRJEqAQjrzwFcc+eFcFREIpV0qL/ dd9yKMuHXZX9LxrlLdn/6aM/Yh9dRR2KuZjdKgco3FtbVEifL1Gn0/FJF0/KoJIawn6zlETqmKIw qN5Yw8TowS1C3tnFQ0szZUvoVaUkDauyNnkS5NEHIVaMpWkSLkvxdU1eSOWouYa/aEoXnKMZbo8b O2Vs29oQS4HuXfw3Zan6VaKXFCdrrc0Qt5P1elErz7wf8yH0N5yrm7xicgDVkli2L244OfDciKhQ K161BSwCJ6ForfLl4Cr3fHFgJw6XI9cwQu7UBlviabC9MRKo6GzzkBesseOdlHoNVL7ug7dA5dMm v8M2uYoZRqTB/GkIbaLSZVlBwl+PJoXodqTYSwW5QZkBUSUmRxA0XcOS1FzhT+XOGDbntNSSngPX PoUyaYrzvTopv9hkp37jOMhe2WepUsErp4AkwHuVY6jGoSm3q9ts47xEtc2HVG7SlMl47IVDc2Ce OX2s0ppTiT2Sl5BF6c/LXP8q1W8MB58i/FsRrjY9n3LxiRffB9NY5sSjeaXO/XZsIaUkQ8Gk7JC6 yIQqc6cC0dCzfviNomxFwBOIKHXE0twEEXaadaResMSYLREkCkbjkye+6tuz6YPImjbHJIKxYgKy 6MRG3qzPRpXwqnvwGZVwdBBnkIDFSS73+SRunqNTWswp1RbgKPUdh7h+20VB7uG7XyanL3P/ruD9 lOZSaS4TQsNNPiYC6R5g7+bd7RtCOHCQkljExTjc8LIZu/FneM4jXGAthlgMcTzWXJ4CqsTetezF IfomFTpPYjpKE845iW6vYhF9IMRYXDPCVX1Y0CCpFvzGEWIrArQMJUNsAYLvA9aWatDVQ40MTHRj CdRgB+t0EexfpPENsP+TJfhqsw6+yrEqnkLn1BetDlDR62btfGCgIYXT+PigypZyeUdKSUPSiYPi EXAFss6A8KYp+4anSbGFsHrL2JG6duYX4eLlIz4rW6ji5QMd2hQ0FcpnrJamGXUrvVg9LapAMJ8e NPoIZ6h/redjx1/kVkan4O53lTu/AcCT7wiipBZXNaiYLfU2/cHHqB1aNoaEeQIlMLKE9glALvT5 qwq80eef2lytzdUngodrkJ6Omzo+2a3Xsuo3T6QRSajDpOcQRlSxHh8x1V2qMRhIrVaQBPyljtM+ JwsBN0pdGb6Rh7oWmTWcG8qMF6XQ7pZmZ7of1qBEBaVNJsZRN85RTUZQGWJaM5tpIj6IVhuRxInB 7WHmKrrC1DrojnpjKZn94bQwuvWQOXg/QSyEqJP9iMKWQTPgrREKZzI3oNZ/MLF5EmN7Z72mZDjM KPE0SQUSAYvfd8hspznVKSD1Xhn5HGwCbG5FekIzpIHbhZJzES1hzhW5ausZwgwNnAgk5BWat6uh bYfQ2iP9iJ6awu87MXhiMDKnSCLeGJq2LmUcrk6uFl0LM9hntkaqES4iE2fCQ0olu2GlVsJrlrwP mZaFLBpbPK6hzatmfgNtPm3+afOf3uYXgdsqqxuzgP0aWNa8DW/Z6hP0hp3wO38/cLsw+QdLoG69 ByeYeyhh/Y4A4e0cSafOJcWMpuYYtN9BZf/81ipbGH7/QvE2UduwSRLFZFNAwTG/c3sorT0nG9w2 Mufu174JJBijGmk80P2rjv7tJyWAeUlklKRWZqnwLbLCc6UvoPSDLdIv6iEms84JAWMg+m5e8LS+ E6TsZGSchcFcx9/q2yohA8HS92ynaSI7Cq1Ogd05eMIaWoPO8GxFWmp0WSGY6Ay1C9AAMNJCgjoc NkkhvDwqIU0ZpgxxUFi5hJc672OLInw6KHCwMnnFgZfhj9vR9Ro6mh5LnFhJY7T0HVfnvAtIVSeO i4PViwS/pTc/qc/UX9WTgPAxS1tBLAamWC9uem2//OVvoOJfb7/8tdx+/fs/doZxPQjgniB9R9uv BB2EB7ehpSX1qxho3fUaqfIdRtIyEHQQyTeousC6RUaMw4hYiIZsUFbjJuGGqbQH1TX3muZRripZ SLERu3GDMimepSSfeyagiar352cgzFUC+CBY7Rs8B2PjXo0I2LW9sC3uG1F3ZVVwCMgEcb9NE4EM 0rgWjS6O9HgoVKRJkfsO3DXRaGKIXOmcG4Dr4yJCfV3A715Q+U8v6FPfn1nfq+KhOPk72oKQLYCk CZ4DP77moYoySMQZQallfRZFZcmvVwlDsWPGE6kbRiYGvkNRMGe4GPzPkFRgICPgkbtaZ0FqzZ+Q NsCglRiF9ZTXKgGg9WHNO1zH1/ysVn9ajdnZl3S5iWhrGinuEw0JcjXvyzNHugoD7qPHEkMVOZXI yk8Fn4Lrvs6m9I288B0oXITq0IoGI2peN7nie9cQjitd6ME6H66iT8czisW8Pyx0DyzndvX5I0D8 ZiZK0pWRCERIeQIxPkMY94sz1ctWeYNRP030h2uiq6AD55p1x/jTFyRGDy/rX5RB/Y0yIGK3DKwx t4T6HFUozmsKparZbbFgmqP6Vab72p/3Gvt/cveqvAoyyPK5JiQlsDrC4fwLeaX+Pmp+G591ujV3 V7o9yVTMePpvg0zIjt1DLx6O3zW4DifDYYVMFO1uk3eIigKstyg4ef3cw+YeIkNymFkQx+NgFYkW dlkMvqej7hdyms7hEiY0hHhRDBuoWhfhlpF719TqzI/Sg9OShiatq08JK5wF5V2nDj+oLp7HzkV8 Yi3RtFR6LAplsfbKW3V0bDPjBMWveOaAapt5nLzxAPJMSziidoDAmT0hzOSsoka4yCmTsOgT1XdV /jQBNKp8JFppb9I2PetYWLUYl3r+Rf+8p+4+7fXnaa//agScXkBWfYAHzSqw9muMAsd1fk7ZaKnM LamOtFmZAHFOMFZ2BCJXDpEjpaGRolBtTaqwDLQ3/sl+1bRKchzB+/6KvhhmDt2ur6yPq2xdDD4Y 5mZ8MKsnGyGtjGQj/O8dEVk97x125jUDa3alx8LbrunqqsqozIhI99hZDgEI1SnYcOs0At1HyLnd jdMQjAV/tfHQxOE35q+o6epCKtmbV9A863FwdhI6CtO9OcSrZD+7KTnaeX0Ut4dq8zcB62HvAd9T RhlwiUB1i2HkAXheaXhU33HGuNn1OVHROVnPic817b9PKI2/m9s34+/NfW/js3eWw/tc+dwAw7ol VTzXitPYRu2CUfGBycElQcIXk2yPuJ07CDxkd74UbI7S1kA2ppIacrgE5Fpovaf2SooMJjn1T9ti e6NASToKFK3R6jUvLEjRPhjsGMi9ctaW+Dn1SBUJcWRFRpWKhiiIlZ1Mev4WJdTdn2tLdhGEpIDO sY1XNmWNfY06J2nMPg08QF1lUR7LnrvgPJA9vwrYjnJPQAWA1AOcUgE3hlSs1jt6SK+ESMTfzsLp qsFFHLvOds+K959uo1DY3ola5c+RNKlBlQ6oL2XUADDvj9NWGBZE2HlWlqn7W/N+Jc3bGSBMLNGM ZqyIa3PX0Sd4UC8fBi5VvL+FBUKLuSLurKE6TuKr2gTnczIQVReEt0gmDnP3t1Zlb5xBqrudQvuG YaJjW13ZcFWNFLHG/eaMxnDFr/JCYAYNuwtg89TpTkGJh6FRSs+D7BKVCftKmyt5ZBDXkbn3DZs3 eV19XfKvsi5QYCLN6a0Oe/Q7+fKQD3hLp19xOh3lIKCLvEoB+lrAiTlbqcVuc5CklZKu4LldUhPh Qq8e60Am3971oUw+cKjDeIDDLdYOEAvSNPeaA/LtvtivyuPi2RTVp+oWcYroGWcqLloRPsNqhelT eM/uiTBifusxSt2i5yNGXU48N88w9qFJS7Fpcy//4hXrrnlC4MCQTy1/5FbuxP6Aln8JqBxNC4Mx qdl6JvWCcmrOwe5Jtdcsu5Pv5wCuU6zGRgpnGyJdUgzTdWjQ0nVgW48vpvGNOeP4apXQEVZG2h2S QJJdhwdJCjt+9bfje0xaPqfwD5c+Nq2pdxBRgSTB2oKW4u07ZppVpZnLQjVGKQcIxncx7FQBqB9V L6ofQedaREvSSYiLEVhXKXZiqI2QXNBqkQJPPUuUqK1EVyhYUrxTaWXRHZHTKFKzcRAT9kH2tm1F q4ytJI56exbURiurEeuiTdEbtMeAeXRfpcRrcElyRqVvz+e0rdRrCNcdEts33IM9D/ZXklMKWXNQ mko0TFBql/7ZnNqL/Lx6xIk0ylqtYXVsg0cfuNtRP3X7wh9K+rd8+Jzz4TALRDa0YcBYF4N9bDUY KOm+AQg0rsZQyVb4FBcezVUK38TqeseAGJd7VMRDTKeBjcKPQfK0VLKusx9M5TunfkC6P208h0UX z72n3E0CNarBLNY7hLxJWrwktliVQdMJ0lEU/saAhil9avMYoBXIJQVky6BA6SkmrzWfgflSJrqV 3dAfEdabMTzGMf/vEA/flcHgtZHp8hqqN4VRWn6lbJJ+8FBEj2UagcpUyUVyb1FBDgbZVeogI301 GPI+8IpfQYVqWckOyRvA5kPzL7UFGFgtXr92fLloFzVxnOX0Y2I7U3th5FiMinrW2RySdvfHQuJc ozNwZLBj0iN8SXKyIqsCIdUEdoVeoF/LTpsJv49Jk/15oIrL/gWWhCAENZC4ISQQDukK07aAW9sV RuFeR5FNKXmy+ggFmoL3RVgM78jFO6IuLSRS8Pg+7Uim38mAByjoLTe+lNw4SBGp4b5aCSkUtZc1 tASBucPmQDY5foG9G1DQifn7cArMFPtY986Ag7EFDozQ0TiYjos7A7zqGUyQD0+axt9okbga/CC+ zQISIziTJWdqGj6KXAnhy2GB1E2ri2ytMUMJst51zomz+TTEnJbmi5QudD1XtDzSWmkUlTeJfQ60 UomP0Tgm/reBfVBi3nA/ntU584QpFiCeG1bqNUcb99K6GReQaLtTL25z4xzIRmdGA3Ocs9CihTfH x1sJFvq0YBrGSV5RbBnTNAVJX+KmyqQFTQYPLu7NMQBuk+dIgmH69u49BKydLc8tReSFktm0DtmL Z+BJ2TwI66iD8zL5YQne+CRadg15Ht4uT8B2A9SoHKj6WbvZ3G14etjcbXj8uGgiCNyFTc37WYRb Nf923nbzDWlfCU/tDg/40z/lWXcoMeTLMdO1alSmharz2lxAkpBzLqTDzct8s6piopZ/vXLvJM+D pfuWW7+N3DrKTmDHVOMIOGHGLbRqFSHcJKcsr1O2EuQ7CBlSo1bXgjHUU2TdYtj80nrXnW7dUQ3m /sCq4A/dh5FtC2xXq8oy2Iq1kG71re5iLYxZehJI13yf7MV7nM3lRvQPmLNLUWTTwtZFKuXGKXJn GaygyRAC73MAAZueJEeDn3EuNDrGL0H8CJ5pl44V701sH6rdN+h36A/7yYCdLCUAVhpoLPSIf7eT G7UUl76TIz0LDDfpgb+zN2gOfKUxiW5Z8Fz8C6NJt7pNEgGrouGp06PkxeYnRYDDZMiGlMyuoRSf mBvXKEwFH8EqYfk8aS/LA8XJdLjpVPwRHRXw0kcFzUmnsTffGATS/OBOONGngceiKEUDcHERpji3 sQ2Za2Xy6BqdXXJXyonxdJdV6aiZiZy2zu6J99rYg+kVfB9JL09NgBh8ZBiu7OXPRzztzct9qLre 7v5zufuD1R0b/XwG4dWlSGIT2CHerm6AD8yMgAGQQk9AxtEzvqM9IboV8LXFZnAAJRaOhDyEvRXe pqkdaOQv3GY7ZubunPihlP3EAR28h5KZQaMMpEsOIPPYQ4M2KKqBnWHqjMFFSMFP/3g11PixUAMz sRrNDUUQlcE/76k3FD75wMJGkK/qPhlPgZNQzKqwyu5PLzQXReDf4wGz+B99MDbAU9jnBn78Hjh8 xev96vLu95cL5i6Xb5m1oKDl8gtxbxMaXEpHD1oqrFxEfdPChw6zefnh3V9PfzxDpU9P/zqvI5y+ P681nn7U83/PuZx+OJfT04d/4+fTor/+bvGJTz+fV7PTz5zpr/+p138/48+H5fy3y590JJz38p5H GqnPI+VQXh4psZDBLzqShd+d4WBPCzbr4/Stdtdic61fFlRsJSSXbzD/6YPmfeNTuFXgHDBFrD7n tJ4v3704ynUd3D3dqq/zHw/n6acz7AWi4nJfXw6nWqbZKX0A2Y+V/CMFNbPMZpYxN4yZ5g/XbPPh NePmtLp//Amy7us//2HxP395978BAC6Q/ZENCmVuZHN0cmVhbQ1lbmRvYmoNMjQ5NCAwIG9iajw8 L09QTSAxL0JNL05vcm1hbC9DQSAxLjAvT1AgZmFsc2UvU01hc2svTm9uZS9jYSAxLjAvQUlTIGZh bHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlPj4NZW5kb2JqDTI2MDUgMCBvYmo8 PC9MZW5ndGggNDUwNS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm8V2tvGzcW/a5fwY9j IBnzzRlAEGArcuF27W1r7XYXabFQHTlVqkcqKxtkf/2SHHJIjvWgZ6hB4FjWcO695z7OPfxrcPnd AwQfnweXNysI3m0GPw0ur7a7xdPscQeGw8u/g8u/zb5tvuzAaHT9bgwGEKh/CPw5QGAB1OtIvX49 HVxOp+rB9EmemT7KQ9Ov8j8wfQYIqt//U19tAcKVBQwIB1jkXJQCTFeDjFxMPw0m08HkrnKT80Ka g9KTjZHwnAFeihzTAhTyD0zBW1LkQmCwnQ8QJjmUX9kT8glkLDjBUQ5FWZ9gImeU+CcwKnKOsTvB 8xLy4IRg0nFRn8CQ5wIJ/wgtsHzkAilJjllg5Gnw1wCZTGpUtJDBUgyhoOBxNYA5K6hKgYxO/i8Q +Pk7+cJXmUpwJ9/6JH++B+9/g+CDrgFW6VHm5KsA8TIvCQXLwYMsp3NU5YdwyEg//nS2CwFlCvrw V9UOlSXtx51uBMEhQb34M10Fy57SyRS+XjxJIqCFGsUUbqQhRQJwjxcFB7McwYKURXc4sr1Pj1kq WIbMXsIK3PWALhjqVOgMEe9B57s7P7qAQpKBq3bIS3C+tx6wBXyVCpxdf3vQ+f7ODy+kx1Tw5OoW bF/tAnfnR2fI+PyOFBdjmvMkXo5zMZGchgQtIBWd0RTsNBcngxXFxX2gC8gxFbooLu4BXcCOycBF cHEf2AJuTAUujot7gBeSYyp4UVzcA7qKi3twpFkSSxJF8toIIensh0r9XRZHaasPdx6P9ODOm+w+ vHmT1oM7v/V7cFe1fg+OpAwhREhjKQbsoAwJ93Uqd4flQbBAU7k7uK+DlZbM28EFGqyYVO4Or7SQ 9FP5O7hjZEPigktjKdr+uC7GtJDIZFdy3nm8ZGJO6eJ0sKJ0cR/oggWTCl2ULu4BXbDPkoGL0MV9 YAu2Zypwcbq4B3jhtk4FL0oX94DOiIPzO1JcTEUukng5zsVIkJzAsixFdzTS1EkuTgYriov7QBeQ Yyp0UVzcA7qAHZOBi+DiPrAF3JgKXBwX9wAvJMdU8KK4uAd0FRf34EhyMRI4L5J4OcHFmOWUFkVZ JLh28rzg6AQ5poIVx8U9oAvIMRW6OC4+P7qAHZOBi+HiHrAF3JgKXCQXnx9eSI6p4MVx8fnRGS4+ vyPFxZjmZRIvB7k4JK1U7g5zZMAiqdwdJK1grpN5O8giwZylcnd4rsPOT+Xv4KDJhuSlkB4LCBHS XvQTaZ+AH5KIAs6KvJTeIcIt7etrphD4aKN3hxElAs6Jxpuj7miilv4Z0XhjmgBMxJI/JxaPBLqD iVvqZ4Tjc0x3OFFL/IxoquV9RgeKI6V12sl61LLu7iZqSXd3E7OcE3iJWcrd3cQt4+5+GoNy+fB5 tgbD4Wh0/W4MjEEE/lRvIfXW9XRwOZ3K0oHp0wCZ51JaQtXuBdfRgOlqkP1jt1gudt8upp8Gk+lg cietNYwfMIWw0L0XmnvYzXbzFsY40x0WGrub7+bbZ9DFnKDO3O36eTdbLucfXm8QYyxbEwfhvc+m FyXOZtuP8x24+G36fVubXozvs/svq9/n2wtUZGDz1MksxwkyiUWppyUszP1mN39+vTEqbciRQI00 /jx/3nzRkB+l1dcjrpqaSgJWM63iu5r8eDI6eLihqWIobGssYLaRfXMqsDH+zxGTkqiNySGUXA4h YaMOESJkzWW396fLaiy9hTkkAkwfgfmgmadpnJWlg//DxVsisn+fbESHHmr7h2wXws/DjcpFhzzo 9W3ycHd7Kg9HK8S4XyGCZWTXUH44Ed1xmww1bU4ibB5FTOriZNP7Dk0uh9oZ+ld86mQPIVxWPaQ/ 7K8zqgvzXkEvdaHfCjrU+E/OeFQvwbpi2S//bJEKuaCRIko37hln4o2M8PXGMEGKJ1lgjb2RJY+w t6+JHPF6bGS4A0vJTciICJ1NKNUfhFTOklQbkCH5w833Qv7g6jOVn5VUt2fV92xszsnzDJr3WfWe /h6ad+y7bL9tpK8A8ofpPyMqfBwxYd7YUBVcYYI0TuvA/IC4911ZfaYGCGUeWAXm2jwfV+f199gk x9jQyRDmjARHr4wt7mLQ503S1Tlq4lTJ0JloQx8uD25p6CESIwGHlXNlX1eUuurAG+2Q8aBLILzm I8aGLlHYAjLgagC0eq7i1t9zk6hxBd6e02dswq5cwrpWHflkCa+rQGFpWspv1cJUlJvgfCBepXXw 1AE/NAJ+p6BxlUgk30Wk+okfhS7V9tfuK9retqeuim1NG+i1qTgz75mqV51SJZiouZ3U7droHscx anvZbqg5JUhwp+qHwiCqUtIx4tVvXbFxWDE/Mf7Ma+AmUdp2YRLLXMItYGwSaDtL+6dBwrpUXLDj zD5ChTf3OiHNlm7T4oWXqBuTxMhWr7lCdK84D9hNM8nY7LGb0ztLl1tGhkw/WwRRKDyS0Db8dqpL +wItE0eZtVs2QqlIHMvphBg6tkMe7DlL1Y3ebu6nev+pvi+9oZ448aDaqSYasw4UExPjV523TNwY /i5zQELmix3+okXlfba0+8uAYCZxlh2tXveWuZ1HoqqubcGmQIjWtvsS4Wnyp80W7P6Yg+18NVus F+uP4MP883LzbTVf757B18Vyqb6Yrz+0ufU4j8iXWjrTljK5k0PULNrrG9eGtQzylEQtl8z3+7Ju KdSqi2ZLNqk6TpZ1aj9ImnLz2PhECJBQCraIjRY8x5SiGPFfzzurArafA2nYipxcFIEgJw1loqtp q0ENaVkmN11hs0esEvECrW4bJ7K0Z2xceE4nZ9JmGXt7Y3lBtDH9gcHaHM8LYcyRFtPFEM6hCANT 1atWS7Uy/DXSlFayZV5PIi4bTkdnj5tV22SQXE5CKa3ROhm0TS5kVolgpR/W4VyMEELDinHdHEYn owGBFjmX0jeAwNpAUKsZCda4oRgE7dvWE/zZ7WQCHlaz7Q7czXfz7SlOP2rWKens4cv2v/Nv4CcE MET4pFH0wijMGaCC54KXTFu8Wi5lgODX7MPl75ez03EeMMmpM3m3WK/nz5vdDPy4+Trf/nrxevBI Lk6IidCxclhQ3WbZ9ELATBpegovXD5SzyXBtM7u7bxFdiXOEMQqiy/gbyX1tdjctZVxyb/nWhtWN NZRDXZZiw7gaUavMfW2lNyJxAtLf+vbW6isALVi93aF1laiUt/r4UnWfuAW8AN1VDajWrDvIaHsr h922ileZGrW36ay2qVWnsUc8JanR2yxht2UrJTrCUKvQhk6ysezdvJ3uJv4ADM2Ov/H0sl9fmw1T v329wGy0zKlAmw2LRv9duPfqCjQUplWUzJzXz/zqoEh9cTwBkrQaCQga1IgaetWQutQ1MPMEkr00 WCmtA2buu1DauudaJl956g56lxNhLkWouhjZYXLSulMCcOEn4IVG9wN85+4MtrfrXe5/N/bmxT63 7GAT6iXYTjwW5mZmfCs1imVS8Lj6rc+Xpnu8Luymwxt0GDOsNjj1t60S8Vqb3rSsigvKoyrF0czp 8rqFbGAm0/idCdIyltXsN7FCpiGyGMlFFYvIS2JXWyuVJTPMyheo0KRTikLqInvIHNuJMhc5ZCav asiWaaEsL5V8poy5tIh2akmGBCgi0q6U0UaDLWbrHZis59uP37qoJWmVC1o01NIpsbQv47VNUpS1 zaEZS/p6lezsCVHby365bYG2sOrLQ5tRTt7Ak/prjzlMrPx6vbnjHOsXw2TObhLEjLyhRuJU3IEK 1dNXI6oEgSXUmkxRSAWWf/SzK0e0msxKQw9GOOhNdm3I+ibcZppOCkPK3M2N/m3nKoHogChIh7fI 6ktjrUit63rbV/uhZkA2QuXQjPV4xNX7Fla9a6inRvzdUzq6pjYVBxTpS9URxN0lHY2xQoqoyqox Xurfw+rULiLbXM3ndnn5+r5V0wQq+PXj73D743+7+ToDf8yewQwgNW5gJe+iW/B5sdzswGL1eTlf zde72W6xWZ+6mR5PNmd+sgPxarqfWdnjSXsrdP9Pe9n2NI4Dcfyr+GWQ2MqPcSohpLQUqSeelnal 5SXXy91G2m1XoYC4T3+J47EnIaRpzL1AbWk6tscz//9vMBoJeB4lF3dkhTOumzDIJs2LApx3pQ4g bJGJDUl0/6FVS3+kLXTdXB20BcaAYxuicfraHZQ+6x79TDUjmoZmhcay5RXUWJLhuzYFzG276wHY 2FG8nj6wRSwXC7L69VjsybWp2uOtx8dF2hitnouX7I18ZYRTxscjhuDxZFpabg0D6a+sOGFJlG3J ssSN7S5/OoQFvS5eBteS8SNJozck5S5ktLwa0+9g5Xh3lbiWQsZm3mm9uAb1F05Bw9+9oTUmwcsO 71fO+/1voMeU7zXoLWyQpgd5a/AC02RoLGDWCJEJQl+75+PwvmMS5xxrrNst1kxkvx/fD9LoFuX3 maJTEzR+dmm5wwlkci5WsNHhcn7LHounU7LZvWRFvv2HVK8kpuR3VmxKhyO7v8n+R5YXrjeD7I5P Kb4K2bIskxpKOzkibIB91xIK2QesCmWNGG5c6fllm6XHlT8vlJ6E88eee8zf8Gm0PRHyUl2lKBdP JlR7rZkdrJkPFZtrVcXU9VD4/LTPt+EzYRVUSxF/olJzxVzIaP19RKm6GQ7vDjBY1mpglGAeotRg B//rIq7pcJ5ByjEoYkxqzTKJm2UoncW1FTghO0L8QNrNc9zGVPa31H6f2s/hks9jgfMqwfDQDkCC ZQcsOiMU/i4+ZUJD1vPxXYfiNW6CgSL7Pv2tMXVunx+atPkAnu1VzlZnuHpJmlk1n2GT8MwcgNoe 3hx4qGG2xDSmk6lgscku1VZZpiOERZUlmcj4fc8vxtm5zxSq9c9E/4aWfhb6c1Giv2bMov+JltFL /rR/JN/2+c98n2dB7F9FT9iRftLpAi4i4zai5Wiuj2rPL3TCqtNuiH3zSrpWodSvIlIzqQ68OGpi t+Im2nqYy0fExGnZz8eXQ1kK1qqOjNUvUf6ijCGda3lm1WXepHGjMrOWMvVQO1YnI6+xlVcdTu5e 7cLMiUt0eCGanuI2xdwAZmhUpOdlAdXZMjbspirQb9FxGl6bVteMIbDGV/Z+Wb8338GUpvzvAE4h 66FZwJ0lPrgN3pJ08z+4GWr3iCrBIQVgDff+JDB+XHjrMGtd+nyayim/q36GKwwqItCccavLkUdR fUcRvhHwmGmuOkVzR+rTKXhNfiZNcZ326v88DT0uSxJU68BPZn1N2/OdKWuOSxqVb7Uv4CyF8uan thaGyHOhz2oRcNeLrxLEZYqYkNb7iA+KUlDpMx37GhgjRMreY4NDlW9tN2NiVJv6lnbPoxjtulAQ R9n33Mf09xaEeEeYwKF894KM09vIU8Y4GmTJRMYqKUMmEyZrMxxjhKrcEp+aQNKXQo2CdgizJQFX FIaITmujza4osqffu+1fj9tNRl7z/Y9DkNh/iU7PDl1iNT7GaHzs0vz3ej+m0dzmvPqA0faIJgeh Vc3v6qY5mP1O5CUs5hMqtDK5T4v83932kdw9//kz3xxm8w9CKupDrrLiJd9kx3OdY08Ws0miY/mZ 1MyEdjGtpIuL4+uXJbzmWLzHSGt2qkehrGBWf3E4dloK2SkN49lGEqsTx0g8waBgZK0gb34eG4a7 bBqfsH3RRb2mDpGhG7NL7Z81OSBcR7kDaLafosOMTk5xHQDWOkuqdjSz5Io7Dk5cfcYqkoBFIwt0 VIZwyiKQydgcZYHRTjI2cwKrXwUNRp5m8Q8bKDC32GEl2F9xUTbqa2gnfjFCUw+v5s0rafkhlROV JEm5lJpwCh3FBrdS1/RaJqSMxVV7/84d57VDYmB9D1ABbomrNrrO9llBVs/FS/ZGvrLDot0TFxVG xCnjgw2A17E4ETHRorwMJpNar1fX6f2JUKVusyQi14v14p4sb1aljMsovbpKq9f18vZmRU6UitKb C3J3f/vHYr5eXJCLxd3V7cP14ma9IrOHExFH5Nt6ebVcPzTE/78BAK7Zy+QNCmVuZHN0cmVhbQ1l bmRvYmoNMjYwNyAwIG9iajw8L1N1YnR5cGUvRm9ybS9MZW5ndGggMTYxL0ZpbHRlci9GbGF0ZURl Y29kZS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0ZvbnQ8PC9U VDAgMjYwOCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MwIDI0MDQgMCBS Pj4+Pi9CQm94WzAuMCA3OTIuMCA2MTIuMCAwLjBdL0Zvcm1UeXBlIDE+PnN0cmVhbQ0KSIkUjksL wjAQhO/7K/bYXpJt7AOhFKwGURQP7k08lD6kiAm0KUF/vellPmaGgZG7yY1D0zosS3lDeWm+dnFY VfVhj1AzkFAbJEEKKaAo8A3yeCd8zSCZCRPkAQi5DT37IMgzJrTyt0ZTMOt0RZopkagM1VZQlufI H3hE3vu4SCPRd+NszWAX0zVutEaY3smT1vGTz6AZ9DUc+gswAMmQLBUNCmVuZHN0cmVhbQ1lbmRv YmoNMjYwOCAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjQyOCAwIFIv TGFzdENoYXIgMTE5L1dpZHRoc1syNTAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDYxMSAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgNTAwIDQ0NCAyNzggMCAwIDI3OCAwIDAgMCAwIDUwMCA1 MDAgMCAwIDAgMzg5IDI3OCA1MDAgMCA2NjddL0Jhc2VGb250L0RUWkhQWitUaW1lc05ld1JvbWFu UFMtSXRhbGljTVQvRmlyc3RDaGFyIDQ2L1RvVW5pY29kZSAyNjA5IDAgUi9FbmNvZGluZy9XaW5B bnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTI2MDkgMCBvYmo8PC9MZW5ndGggMzA3L0Zp bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVyRzWrDMAzH734KHddDcZJ1DoUQGN0KOeyDZXuA 1FY6w+IYxz3k7SdbpYMZEv2M9JcsSR66p87ZCPI9zLrHCKN1JuAyX4JGOOHZOlFWYKyO11v+62nw QpK4X5eIU+fGWTQNyA9yLjGscPdo5hNuhHwLBoN1Z7j7OvQbkP3F+x+c0EUooG3B4EiJXgb/OkwI Msu2nSG/jeuWNH8Rn6tHqPK95Mfo2eDiB41hcGcUTUGnheZIpxXozD9/qVh2GvX3EERTPVNwUZAh PjKTsNk9ZCZDvGfeE6syMxniHfMuMcerFK8Us0rMWpW1XEulWoprqVSrvs9Mhphz1ilnzTnrlLOu mes2tVgV/NIit3jtJTVLO4HbJPUlBBpiXlyeXpqbdXjbrZ89kCp94leAAQDp25MsDQplbmRzdHJl YW0NZW5kb2JqDTI2MTIgMCBvYmo8PC9PUE0gMS9CTS9Ob3JtYWwvQ0EgMS4wL09QIGZhbHNlL1NN YXNrL05vbmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxz ZT4+DWVuZG9iag0yNzQ5IDAgb2JqPDwvTGVuZ3RoIDQ2MTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJvJdtb9s4Esff+1Pw1cEBsgofRQoIAsRu2n247u1ufDgcisXBdZTWrR+6tnNF79Pf kCIlSvUDLdFC4MQxrRn+hzO/Gf41uHnziNGH7eDm9RKjV+vB74Ob+81u/jyd7dDt7c0/0M3fp9/W Lzt0dzd6NUYDjPQPQZ8HBM2Rfpzox0eTwc1kohcmz/CdyQy+NPkKv9BkiwjWf/+nP9ogQgsLFLEU UZmkMpNoshwM+dXk0+BhMnh4W7hJUgXmMHhye2RpIpAUAn4reEs5+oGpREqKNvmAUJZg+KhYh8+x ELX1lCRYZnZdyERw5q9TopKUUreeJhlOa+sSPqfKrlOcJpJI/wtc0YRyt4GMJVTUDDwP/hoQGz2j JKVpwijFOKVothzgRCiuZcO+4Lck6I838MBXCB96C099gtfP6N2fGD2ZuFMdEm0OHkUqM/tdDB7h BCs/RVBYigXrxZ2JsZKYqz7cFUdGsoz34s0kgEwxI324s+mEs35iKbS6PhxB1adUJCqKFyVNzeM9 XkyRi4QpxTLZXQ0HNYyfKLBYsiy9vpflu+tDXa2eY6mz7N2jznPXg7oaPqKJKxrH9+I8b31oq8Eq ljjX9fao8/z1IK8Ox1jyoGdLse/sfHc9qCtY3IMjYLGQPFFRvJxgMaEJF1xhJjqrAUycYnE8WWEs 7kFdDY6x1IWx+PLqanSMJi6ExT1oq7ExlrhAFl9eXh2OseSFsfjy6iyLL+9Is5jAUhQvx1nMoR0I SkjG+2FxNFlBLO5DXQ2OsdQFsbgHdTU6RhMXwOI+tNXYGEtcGIt7kFeHYyx5QSzuQV3B4h4cAYu1 FxzFy3EWs5SCaUgQLDurUeIki+PJCmJxH+oacIyjLojFPahr0DGSuAAW96GtwcY44sJY3IO8Jhzj yAticQ/qChb34AhYrL3gKF6Os5jCcioghKp7Z5HsJIvjyQpicR/qGnCMoy6IxT2oa9AxkrgAFveh rcHGOOLCWNyDvCYc48gLYnEP6goW9+AIWKy9kCheTrCYq0RSLHRtd1XD5EkWx5MVxuIe1DXgGEdd GIsvr65Bx0jiQljcg7YGG+OIC2Tx5eU14RhHXhiLL6/OsvjyjjSLwQuN4uU4iwmM5lKlKhPd1QAm TrI4mqwgFvehrgHHOOqCWNyDugYdI4kLYHEf2hpsjCMujMU9yGvCMY68IBb3oK5gcQ+OgMXaC43i 5QSLGU+UYAzTzmJ4dhLF8VSFofjy4hpojCMujMQXF9dAYyRtISC+vLQGF+NoC+TwxdU1uRhHXRiG Ly7OUvjifjSEwQmL4eQgg5u0iuLtMBsb+Iji7SCsGgUdx9lBejQKLIq3w/XcTPko7g4WGKSiFDrr tX3zGVhm6JcoEwAIhDlN8oyxlvbNnVJKejS7uwgIavaX1OHVTRcdQX39gjq8iuwkI6CFX1KFV+pd ZIR16wsK8SHSRUhQY76gjqIjX9CB5h+Bw+pkPagHd3cT1Hy7uwnpuhG8hLTb7m7C+mx3P41CuXn8 Ml2h29u7u9GrMbIGCfqsnyL6qdFkcDOZwNGhyfOA2HUYGLFOd871bgSaLAfDf+7mi/nu29Xk0+Bh Mnh4C9Yaxg+YIlSa3Kube9xNd3kLY6kwGVY39jbf5Zst6mKO0crcT6vtbrpY5E/nG6SUQmrS2vbe DSdXGR1ONx/yHbr6c/JzW5veHt8Nf31Zvs83V0QN0fq5k1mKI0SSysxUS/1gfl3v8u35xrhKdUmQ Rhj/yLfrFyN5BlbPV1wkNRZJJgQpTI6mi918uQaj2TBHb6Zb9Lc2sTSWU6g9Z3n4sMhnu818dlI8 PlwvsFOZsczlkMTDNeTlqe2N6X8O20wVKW3eYswwxlTenb/HjCZE5463xSG7Bmvn66WM6MwRdWPk GrpVgMF9aqtc9CyCWirgdQ82M/irsJEv4MXH8HoN7ym8JLyHNS6LdZLCX1gjrHqZ5+BzMIcB3NAL i+fM57h43tkxa2mxpv0IYu0Kz+bIrvNivfB94lSOCtep6AkX99Z46jm6rzbPG6KxrG9Qf9QUAMdj gknHNqh6HQIrVCXC+dPB0MEtA6eKwJsXrQdQ76mjeC/H391Wu9JHrF/Gizse5h392Ds+UuyIWLWw I5LpgtHPjYrvGDXuqG0KmQjJwpZZv/fWnG9ho31fj+ihPbnvcBPlu5N0OhKZNKsqbLucbnZoWQB/ vkIUE4q+zncf0fPLYoGe8i+L9bdlvtqd6gbHDwOmOD8TaXEepgR4EV9dYiSrsuxoCYkqtmWGajve WVEbL5NpssgoF3+T8fa8THxd7FP7f+oy8XwoVpq5B7JNPl++f9lscxPKr3MI7Wq9Q+vZ7GWDXlYw VenI82v0JV89zVcfukWb1eq+VIVtVMdWYbonAtyrSWHXsip6RXRb1GXVzPfT2JH4/GM7/4jKvfiA HD7OPuZPL4vT46i1JxLFjEXzRsAcpfRdJM0kNEVetC/a4hgFVTDtGEu1YyQPNkLf9a8uEfAoOfyy ybdbtMkX+XTbNgxwsYXSVmBYVGFgbcLAIaDSWCLfh6FLBvr8sxnosqzMLly1JAd55loWCY13IzQw xdJMZCiVrAoNbxMagcGAtlRXUmbIuMiM7tnhYXv4aDqFuRqgx5fNf/Nvpy8IR0z7dPydmL7T4opg Jm4idM6lbpZffVgXN6Ifvz2ZN+sfWg/zmJWmuw/zErbKE6UUP3OYP2YS6FyaHL59aLE5RROeMdrY HLliEir3GiqgxfYoyxKWqabiM4we73CeVa+E3XzkStcUw8jOT7LqaOZzNwsq2yHtupnT3JwxakzM jRnSzSAHZ7Zymu40yWJahVCXOb9j8tZOPO5iouJeTMoJNq3sld/PqiiVE7BvT3jPu7l+fJeaPZMW k2sFDe/Yhz/tNusVitGzhEoyBW9SohJKrHki2pA5hQ1CQTUTlDy07BmpTESWpvWttRkOqxg2sknf TYrXXcpviwnP3E3s/cb8X06QwafX7H0syYjmaepFOG0HfNiTCTQhBZdHi+nsM/oRZurt6Y502KKg pcWHVb758K0D50UKegVXZ3J+38FVNgGpzqZmHpwJo+c3d6L0fEpJbY/DjF1DFZ+vGFIKdgeQOt/a UebVAugIb68AhjsPFd0NixyR04ruphsYJt2R7NZ2hvEBsh+7dpQUhzwZe8xNQ5h7qmKOh0EQ/8xD 6V3khnejI5UCd/szOya2ru8bFHdRGFc9texz42osdn0Te33PRC6k5+3LplK3l+vvhrP1Cli/QNPV E/qSTz+j3XyZA/PfT3c5Wj9fUTx8zjdb9HW++4h2H/P5BnWaLuBXLfmcXNMEx167J1WYXMKYULib ghsrqHd09shIcXc1iclkhVtzDMqz+9prpjZ5/fCbv2PblL1ExfCXZIUfPSjoj7omI8zZXjL6Cafv RvpOam4eLlkyd1+yw5dNOjyyu9Pji7A7FG6HXsRkPaqCVQMcf/V9ApoIuHucstEcm5GjQ7u8HIja ttKUJpLAxUnPBlTx4gZFZIfOh0kCMwv/rpn+tv6ab7p0QTCMKaExuyCXsrR5axNPtuiCpb1UlPaG //p3m+uT66ee2mGaXeNu/fRsa8dr1zPXIosZqxqFo1inNpoVrdS0URbURjuI5yqr8vCMNlok1742 arkN0WDjO0Kz2wroqg3Q7xth5N5nomo4vPtE0agfA+KxhXBWQfgU3MsDkjaBRnumhQMNwAH+VMK0 ToZjk0Wt3pf5DuaGa/Ty5cNm+pSj+ep5vVlOd3O4WM7Wy+XLaj4r/utSe1wwP+Qu61zY3BBWDlD+ mOpCmtlE4N5UIWyfc/+rajLAr/dlrddXR4061u+5tTe2vdZViZ1yiE2HVrVY9dM6iPadrwmAqEYt 4sYs+92yncqA5r4nF8q9+FyAIXMZfMiNjoxZAnvLEM9owkSpzQw4o5P7O9iXOVOwT1Vcqcb5CnL1 t//TXm6rjRxBGH6VuQoTcAb1cXpAGCytFgJryOJAEnIl7Nm1QIdFkr3o7dOn6q4ZySOpW7kQux5b NdXVVf//1Wax3mc4sgk5UrW80pEHQxIeQpZ//p2QXM0raQwUJ1fSOy1Hd3WShzLiB68bUPd+ro3i iMZGkWbb0W28YqKOhjG3tiddV8B4WvxlEYXhOZW9BcOPKthwUE0wpwneuy614RwVpfLEVRW71Xy7 L5yqum3s29tyWby0P5abw0p3cJ6Ook4bdwt+co8YcHlsQTaORFsbaKJABt0zdI5srX/5/Uv1YJBz 8BHtdN2V3XHJumi7tbdk4YWqzwThkOYzudbXMzqPNaPYefqL85f3+fq5fXFdt1h/L3aH3b5dFfPn 7Wa3Kxb7XbFrt++L5zar+ViNlHPc6yqBkI76Z9N7KccDTnwV8nlQMx2lXNEvBbXTEJaFkExK3I6j ic+u8QI3RTMIFam7rYTbjH+K7RlaFrWeZRIzd9NbMUjHBcducJhyg8Vqh/Bh6/kwy3M1HCQPrJ+6 nk1zqc310IMQCNhUnPiA5Hy0D6FD80vFiKABOrbzZfE4X6zPjs9QUNaEoP+Wf2x+tttfiSqL6Wal wxxy8MPkS4SuwO2Ihun/QMjycZZANIpWxBANTq6Uo/oC/DjJMwZTzeB1wolsmsHxTvgKLBwwtEA1 YSlRaEyoly9koCaefT5yAw8SGJabSU8Cb0EtwwfWlUQHtoplDOzB6XQwNDa0fJ4mC/scLSamGOAF fBaVi3o9xksuaL0tkt8CTZH6G1jm4VFbG9Wz5ZbxpACqUOqQJcaEJp5qgHVIY1S1x0wCKjb1ccEx gbGucsQ8ByMC94F1r6nrhzxfRW7IfUxMpElumHXnejVFB/3YVnPstC8jgI8SnZi43uBBEi5FwJ7f MV7pYin9Tl5xxd3+kSKCQnuT7ty6nz2ZZZWiKzBpipqVABrycao0X4/n8f1ossof21YT+LZdtvNd mwg4TJsyb/SFExUvnCRdOK1UbSOJ7oX7kpjhVu6TVwI0c+XTar7dF49mNyme3rbv7eE8Rn0cmjYI AL7qn0eEJmKZ1ghZMUUcMU5f20O71oz3ZfH9dX+XHFPyGPPzW7ssfikc7V3PUEBjJk9KR+KGgEcF DSHLv/5JaCaiakd4OLux338mniYU0ESKgnPumO9/ewFYRO8FFFGAUYMgXwj4qHdv/uD+1vrU5x7f qChzo2YYFHlfjT53+SrQB8/1Q9OgoZk+LGca/Q3iK4/sA37Yp4zIUvfM8JMlCM9T6oinsvgHD8D4 1mTm+Uels1Sww4dcNLlpc2clghpvfO2UJLKSNjwmqFHlutLX5L2Tpmm7vgm9iNYV58o5xrJ93uSL u45IlWyuFPeTkhxiEhZijt19Un69n1ONck6BUY4lres7fU0JlhGHD8WDnoQ1ywvhoFiCzNSxf/EC Asht/1b4uA/dIRyUKjR8QZYe3MfKJMMymVDXUAcqYl13lpNWhpN2xWrx8ptFm5+L/Wvx7W25LF7a H8vNYdWu9+fYZLj23d64dO09VdNLjCvYxdTFMuWPMu/thyDR9L87Fs4s0xsRfOikbfbBJ0fcVpu3 0X68iB67Tc7BiWqiuozP+xa+ZtFx2yGPvJf12PrU9UQa7QFrzJfN22K3mK/nKa0eQ6Lxgk1Q+fYF i5PRk0Fi7M343+Wvo30txvPi58JqkMRolGh3TFaKaIelRFaSgF6zdLsjNa8E4c43p5vVarP+2c6X WpIyYkoaY85eFrvNOsM+TYZMMHbD3UhPeQhZ/v4lITlF3WqEkyu1ql3gmydtmPhhxuG4CZZrxDhi rzkpVgXhFQPMk3tjBAFnp4zx+v1BsKguoKl9eu6qUpY2SooPb9xeAC3w4+QCOYM0cP8dGouCvx+e kVjICRDG0UoXDQgoxD6DHBgqyhQVkECRsgqBGt6YBOXO3ug0clhY4eAagKf8dZwyDGuv0n16Xi6k fw/YJFx7dw2MljtyrCWE/Z77N3MFJEx17h+sEJS4o8joBHAaU/+Jvxtk7vhu6ScEFWrodDkWc+kU e4w2/hcOZxNO3a6aSvHaaHBdSeV1ifIEQRJCVLI+FiQyy65Nd8jPDTEV/sJkbFeuwKIT6yR0edio 0bkIVCeRUifJKp226h/rojoN0VfX82az4sluI49mGznv9QNx0YyVT2/b9/ZQfCWGxymO+t8A3Vze MA0KZW5kc3RyZWFtDWVuZG9iag0yNzUzIDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDEuMC9P UCBmYWxzZS9TTWFzay9Ob25lL2NhIDEuMC9BSVMgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3Rh dGUvU0EgZmFsc2U+Pg1lbmRvYmoNMjg3NyAwIG9iajw8L0xlbmd0aCA0NjYxL0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtDQpIibxXbW/jNhL+7l/BTwcH2Cp8FUXACBB7k6K97l7b+A53WBQHX6Ld 9TaxW9u5Re7X35AiJVIr24xFC4ETRy8z8wxnnnnmz9Hl93cYfdqOLm+fMHq7Hv0yurze7JYfF/c7 NJlc/g1d/rR4WT/v0NXV9O0MjTDSPwT9PiJoifTrRL8+nY8u53N9Y/4Rnpnfw0Pzr/ALzbeIYP33 f/rSBhFaWaCI5YjKLJdKovnTaCwu5l9GN/PRzbvKTZYXYA6DJxcjyzOBpBDwu4CvlKPvWJFJSdGm HBHKMgyXqvtwHQsR3M9JhqWy94XMBGf+fUqKLKfU3c8zhfPgvoTrtLD3Kc4zSaT/AC9oRrkLQLGM isDAx9GfI2KzZ5DkYIMqVigl0P3TCGei4Bo2xAW/JUG/fg8vfIX0oXfw1hf4/Ig+/IbRg8k71SnR 5uBVeEZlinH0OLqDI2wcVVlhORZsGH8my4XEvBjEX3VqRCk+jDtTBDLHjAziz9YUVgOlU2h8g3iC 5oeizGQSN4U0rY87vOhehoaEDmBKst5weEybpYJlSexbWL67IdAFTZ0KnaXgDnSeuwHQBRSSDFw1 P74F53kbAlvAV6nAueHXgc7zNwC8kB5TwYPRLUXX2fnuBkBXkfEAjoCLheBZkcTLYS7mimac5gUG n33RAE0c4+J0sKK4eAh0ATmmQhfFxQOgC9gxGbgILh4CW8CNqcDFcfEA8EJyTAUviosHQFdx8QCO wDJXcCuJlyNcLFjGFSOK90fD5FEuTgcrjosHQBeQYyp0cVx8fnQBOyYDF8PFA2ALuDEVuEguPj+8 kBxTwYvj4vOjs1x8fkeaiwXNVBIvh7mY5fBbqBzjojeaQhzn4mSworh4CHQBOaZCF8XFA6AL2DEZ uAguHgJbwI2pwMVx8QDwQnJMBS+KiwdAV3HxAI6Ai7UXnMTLYS6mMDFzCm7AZF80kh3l4nSworh4 CHQtckyDLoqLB0DXYsdE4CK4eAhsLW5MAy6OiweA1ybHNPCiuHgAdBUXD+AIuFh7IUm8HOZiwmiW K8pU0R8NEd0yv82OaXBFkfEg8Fr0mAZeFBsPAa9FkInQRdDxIOBa/JgGXRwfD4GvzZBp8EUR8hDw KkYewhNQsnZDkrg5TMkFgewWBQa7fdFwdZSQ06GKIuQBwLX4MQ24KDo+P7gWPSbCFkHGA0BrUWMa bHFUfH50bWZMgy6KiM8PrqLh8/sBEgYnNImTvRzcYqs03vZzY0gfabztJauwoRM528seYYOl8ba/ n1sln8bd3gaDUpRCV722b66BZYb+mkQBAMCMUskVYyfax4jJTEp6sLr7AIga9ufE4fVNHxxRc/2M OLyO7AUjYoSfE4XX6n1gxE3rMwLxSaQPkKjBfEYc1UQ+owPNfwQOq5f1qBnc303U8O3vJmbqJvAS M277u4mbs/39tBrl8u6PxQpNJldX07czZA0S9Lt+i+i3pvPR5XwOR4fmH0fE3gfBiHW5c66jEWj+ NBr/fbd8XO5eLuZfRjfz0c07sNYyvscUodLUXmjubrfYlScYy4WpsNDYu3JXbraojzlYIWpzP6y2 u8XjY/nweoOUUihNGoT3YTy/UHS82Hwqd+jit/mPp9r0Yvwwfv/89J9yc0GKMVp/7GWW4gSZpFKZ bgkP5v16V25fb4wXuW4J0krjr+V2/Wwg34PV1yOuihqLTAlBTHyz9WpV3u+W98879NPy0+fdCciN 1Rz6rrb6F/Tz+iuczTFTeH+rQJBSMeXKR+LxGkryGOYZ/fd+m7neJ63NCcY0x5jJq9fHqGhGdNl4 IY7JG4Hx6/FSRnTRiLYxivEbfNRgF9qmDP0MWrj0FowqgM2umIRrmGGYYxgD+WJBqv/1d/2X6L/w PCngw6qPeR7swCvVO/BFSHtdXyuq/81fYa9rmzP4gC1Bm+f1NeeTaZtFZaO2Y96/OuHA6xTomvQO nIgGCZk1aHUU3EY1va0i1RG4awbBbfOszoC5LitExo5DzTyks9dn7FvbRwr0cALCitcBcAvQHTEh VWL06Rog7ijyJgj/SFyAXDTBi2ubsKI50jrZvPrelezgGVXFgm2Z0bo8eiUgV0ETmKKTXpptAxiU zP7NW8cP17i6IoV+XzWZcAXMr609m9V2oxWTV2Y29xuyXwOAgvTh19BchedeP0rbpwBVtaHag/Wf FQ4+tzBmlT0/re6an6q6I6SF7cUhfH9wjbw1KaB4YqjaHAGDtLGif2p4SI/t2jTTge2hStmEaNKh 7Gl6de73WdTJ33b3iIkBvjPR5atfChgLU+B46zpkaBO+F/JritlcJ9b27CrPJ602V7YC/HTt4dLa vl+JM+erXyooCVPhh1A0J9J27+A5yubTVopsWuoR4uh+1nqXVicLMISuNsqrDFF/hMiwOtw44TJN CrBqzwq/DoU9cC4aGhHcXmtnRYVZ83tjHwX5GSHkBM5vJHOs8HFTyyGauc4+lsdayImsYMa/+SKA UoCaIAAFApEbKUfzEzQc5Cor8iJAovvm5sRxWKemJYioPRtD0TdNdRreIdU916xmTmspiO281v/j XsGE4sQYzCuio05z8qPyvHsbEQqOghLhdpzt+nH5sNiVD6euN6JgjcGbh+V2vTp5u5EQHocDxvyV 281BkxLXJsfv/3XCKsIVWAIi8IOL2msO0opvzTajT3y0aJSHaN1ruB13bhFtVeE2FywrOekk7T79 bYSbUyme1neCsL5vFU4/KSoK6ifCX38EaTjSTRHHTo75TU96fFtzbu716L6V7dCicd0kth7Awk2x o+13AK9fkA/lH4/rF2i/xeoBgQd0/7zdrZ/KzRZ9XT4+ol253aHl6rvPcO1Yix7Osiiazpq0asvf 4/zacoOb42A3q7WLWxp8iefGm0lnpVBNvbiBbY/OSMFrTxSI5hnjz98vZ97YtWMSRuEJQ73m2Mju CzS7K7r8tAJofHsFP96Uj+ViW8bSUmuwEpYpVYDFPIPGtpNVnkblkFOY1DzDhVT1eHg2pdjDIKON wZtVufn00mc8cMBLQQAkHA9E1SbH7344IThFQdRQEgQ3zk8dD4zYfvWsTTwGm3oMdtt8J/0oOHRG PQp2cqeWrrihQdfzRHiBTJs10XWUk8ide5AVmIYjLG+4znM933O+QErropk0zON6mvuR+WL92pO+ DhX8T4U3QS37mWinjYAXrOGOmlmJt8x2bnJXuZHgnQtvrxXGL3KdgnreeTPUS7bIOzat9t4zvW3g +lTZFiNujrs5q9PqBobW1m5GU28A1AWl9fSsSXWzRfZLB5Z+uQtv93TjxkTaQl4/43Yid8/LZrDf Eq9tBO6WZs5X3igVnRHdRq7IurbCWp7FDKODyeCwEQTt4ZrVeaJ7Gtcr/X1C0mXGZGza6DlXH5Uw uMp1vfUd6CGFdUXUlrV1VV47tdhnqHssM75fP0Vzf2uiY5ZBthTYExkVDf/rjpiecM4Cq4wqY5AE A+XGY7Si+hi+7zzKPokJBmy5Kzfo7nnz3/IF/UKOC4sDdr0mHlNM6OkihRckI1BAler5+Q71FipQ ViDMGE0oVLjIa5Pj+T9PCK6QlVDxgxtz/AYfVSpd6wxTEJfmD98aFEuEucN85KfOSnNmC9NJc2/B IEVrwXAMW7OynVldvFU/a7nOSANv3yPX+9TWId7rNZt4XtTwJ/jghsr3TUwVwWUHyfT0MziGfd8i o9mOMQ6eecaorSaqTigkwUmGc2MK+5msCK8HkfknMy4Nk51GOYhzmlGKpbH0dv20XC3Xqz5sA/ZA aeSvZJsme99hYAbY0e6R/fIVdbkhRe0GEsqUFomxCcXGestyYVcnH8CYRHFIJyXZ3SkwR9/wBKTk WdT94Osip+hmjeqr1wHudesBrvGXHtPBr+acQ0zRSx0y7AN3IIxSwI2U8gW/AT77duehuZcUEb4T LCTKk+I2Od07kbedChwsCOb/mM2xq4xq7F69fxj/4yLH4+XmghTjT9CwC4R2a/RQPq1X291msSvR 7jN8yvvPq/Xj+tMLWvyf9rLbbdwGovCr6FIBAkH8k0TACGA7DpC2WaBIbhZFL9xYzRqN7cB2tsjb l6Q45FCWJUdML4x41/ZoZjg8853tKrn8BnY9Pi+C1g9wOWwEjrRZezTsLgxzy3FzBD7NHOXg/MfM HJP8ZOYKdP5Te3nm3ZbKFG1nBH/mYkhblC2gbS7Nb6Ch0ITcF+cOQCD793XFV0jLJzYjaVesDKfd HSvzxgY+b6PODG5T24DK8Dfm32A471pdYOjWztGoEDQ+aMQMlGgzW4KZjUIjVgZadH5Qo9CHh/1n YBjBwqJJaFTohkj9vfKGCZhWyKwYW7NPJ9RfCrNW2NOA+TPZXap1LfaiJCulfhTLWGW3JhuzLtUp ZQU9SbrbasaQGBLm9HGz3B+TwFhGuEosuqkyqNpYDsfrxjwmFNRWJWkw72kRQXg6FKGfBbzeiAqW bMT04X6Mm7TshlJLC1FGohuORq8vQ8F+0fAB7f1RMmJHsAPSzihdAGjaXlWNOewEtB7LhhVZwEIH BUfK7oDRqXzUTuEM9WBmjVx7+VPIR9htgpRd5zDj4bYxSj9FezD3kNDuM8QzOgU7VoZ9zdVfMgu2 RUzNfr7b3KpyoFMrR3gLAjihzZrPbF7cnvsMckMQhmD+pD+3vm63IaX/vtm0ukfzLr6NYFdGpLtH 6+2x3q4Omld/LH/WyWa317SqwpGHZKOF85CsFcUuX1/rVfLXoH729z0vcd+rPOD1EzoAwwP3Y4q4 bvY/EglH59gJwjGzRyXWnD49gP0N73Nbj9vrGO7L8P/jOKdfF8fow6ie+Xy8RmnsovKm5PqvPigj 0EMYdY5ucpkxWXH1gCLjwtINGUM3RK1zaiJhOXV0U/pjdtd/fuE49SEJ3tTf6n8Pl27X0z4oaVVU wrjvAx3VB55V3EQiXX0IKK97lOL6gaQtwD6FaxHkh4Qr1dQ3EvpU2RkTTDTQ9/5PnSy29f7lIwL+ dEgiKf9C+qOicCHT+28xyXHuI/36fcQ8+VCMulDaURGtOSM0xQekeRBQ3Ug6ZJL6A+ZVELAYmyHA Mz7aSbMGDQJJi5Yc0HIECgBS42ek5FrEM3Ura618ZkEvLMx0gbUFMFGEwGReGK4L+2K2A9MWXHeq ycCSdfAXtdSLqj1Mpsi5J3pTlAy39lnytUnxqf+tcwJ2fWBSdCQEnyEKNXlUqEEtUogiyUAqnneb zfpwWO+2ihiTh+WHuhLqy4osV/Xb6+4jKZvpikJILCk9/ARewyydRYtHoOOLhgu7RhIumxmz6jIP B0tOaxP2aw2rRo1XKH4attyMU3tPYGT4mYJ4Y57aBUHSobmwm5laqEPAPfzsqEJDUe4VBphhe8fg e84pVP5+te8anA44BY4oG0RDuwHTrBI1C08Vco3wntt8XDN5EyOyKeFigROGxEySrDWiVtmc/YEC 56hJLLRgbdHpslttQdGFM/WeiWYy8ruuaYopnshicJ2gotzp2mkwTUD3tEtZz/lI8/sCTR0872J/ GVV4FQhdPrPbn/Wc+rk9N89PxvvzhhKNfschmGlxehNVeEnb4+6Cd9zZvGzuKjSC5e3Fbllsau3H NDxxGFM3QdLrQ9CoqZ+gLxjrIm+vMaOm+OSILeK2W+zgDjslvkUCB+QD9xWfPCg4xChsIyAeWl2n dz6qaB4K2cX3yBYo0SojzRqD045DvwEF/1pBY0UfKhIyIrjzqRfAN4yM6UaB1gHsR4Bue5l5dSkf iqxiJiPzRhQkMyaGqbotITI2Av1EoQwWk/LEDy3GwatvFoL29H6xSB43y/0xeaiP9X6IUXvjYih+ fN//rD+S34mGYToYlZxEzTOhPCbJOFEt0BEXW5Xfy8dwhmdi5dLH+m33vj6sl9vl58t1vlcnR0VV 6YB/pE9XZZ7ujsvXqz+ffvnsUbuYsnQh9RirkaT88ydNqjIjVA0hTjEl9JoPWtwu06OcR25u8JdE c3oQtM8c7hWRqTpgdzjJ+pA877ar9+fjevuSLJO39evumOz+Tg5mYse02j9fzYN7fo+jglUAftZ9 3rVuqvA7ZuXMrKJTr/Zmp85vinJihG9EGe7SBW3UM1PZdc9vhJgYpRgI33FIIudZJagIj/xut9+M 8bA+V9TyicU6TTBqv+l1pF+UWyqRaPcUmHwihA/drtSonZ6qCMGrhI/3+Lavl6vDj7o+HnDI/wYA OEvDMg0KZW5kc3RyZWFtDWVuZG9iag0yODgxIDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDEu MC9PUCBmYWxzZS9TTWFzay9Ob25lL2NhIDEuMC9BSVMgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRH U3RhdGUvU0EgZmFsc2U+Pg1lbmRvYmoNMjk5MiAwIG9iajw8L0xlbmd0aCA1MTg3L0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIibxXa2/byBX9rl8xnwoZ8NLzfgCGAIuxF91usu1GbT8Ei0Jr y46ylpWVlBrpr++d4QxnSFMSLdJEoIgWyXvvuY9zz/w5uvjxI0YP29HFzQqjd+vRP0YXV5vd8n5+ u0OXlxe/oIuf59/X33ZoMpm+y9EII/uPoD9GBC2RfZ3Y16ez0cVsZm/M7uGZ2S08NHuG/9Bsiwi2 3/+zP20QoYUFiphEVGVSGYVmq9FYns2+jK5no+v3hZtMajCHwVOIkclMICUE/K/hknL0A9OZUhRt FiNCWYbhp+I+/I6FqNyXJMPK+PtCZYKz9D4lOpOUhvsyM1hW7iv4nWp/n2KZKaLSB7imGeUhAMMy KioG7kd/jojPnkMiBc+oYdoYgW5XI5wJzS1siAv+VwT9+iO88AzpQ+/hrS/w+Ql9+g2jO5d3alNi zcGrCMAZxtHj6CNUMPopksIkFmwQdy7HWmGuh3BXlIwYwwfx5hpASczIEO58O2EzTC6FRTeEI5h6 KVimevGilZt53OAF0HDGM2mAYKjsjMb2mgCmOjxhfeHy9PUSV+puEHiVie4LnmffBniJuyHgVRik N3TF7niJLvE2CLgKYfWFLmy+BniJvyHwVRmyL3ywuJVoql7qbgh4BSMP4cmRJaM409RYX50dcXNU jQzhLiGTAdwl0z2Et2TYBnCXNv8A7oreH8ARqBHrhfXi5bAaoYxl2kiCqemMRotWA9YPrFZiZAh0 tXnuB10rLTIAuhp99ASuhRQZAluNrPoB106JDACvTo79wGslRAZAV3DxAI6Ai60X1ouXw1xMhM6M pNyw7mgUO8rF/cFqxcVDoKuRYz/oWnHxAOhq7NgTuBZcPAS2Gjf2A64dFw8Ar06O/cBrxcUDoCu4 eABHwMXWC+/Fy2Eu1hzuaoMxGYKK+0PViooHAFejxn7AtWLitwdXo8aesLUg4gGg1XixH2ztePjt 0dV5sR90rWj47cEVLPz2foCENYOi9eFkLwdX2Kovb/u5MaWPvrztJat0oHtztpc90gHry9v+ea60 fF/u9g4YtCJnPCNwrDVUvqkeYIpkSjJidHd1A912TBD0B6uVIBgCXTJj/aFrpQgGQJfMdI/gWkiC IbAlFNIfuHaaYAB4KWX1B6+VKBgAXaEKBnAEXGy90F68tNIF/blrJQz6c9dGGfTorY006M9dO23Q n79D4kAJ2/zWvvsNLDP0t17kACDMKFVwemAn2seQg0wperDFuwBotfjfEkcyO11wtFrxb4gjGcpO MFos87dEkQx7Fxjt1vYbAklZpAuQVgv6DXEUi/kNHVj+I1CsTtZbLeLublot4O5u2izeHry0Wbjd 3bRbtN391Abl4uPX+RO6vJxMpu9y5A0S9Id9i9i3prPRxWwGpUOz+xHx9zHi2LY75zYagWar0fif u+Xjcvf9bPZldD0bXb8HazXje0wRqlzvVc193M13ixOMSeE6rGrs/WK32GxRF3OMRnN/fdru5o+P i7vXG6SUQmvSSnifxrMzQ8fzzcNih85+m/10qs0kxk/jD99Wvy82Z0SP0fq+k1mKe8gkVcZNS7Uw H9a7xfb1xriWdiRILY2/Lrbrbw7yLVh9PeKiqbHIjBDExXf9BHAfvqMPi+cTMDt7EiautPfL5nEx fzqOGO8fEghPGWZC4yg8XkMzHkOb0//styk1KW1eYkxv4MMnr4/R0IzYhklCHPNzg/Hr8VJuIDYl qsbUOT/JWNl7leS54p4RM4YCf55v0TKMNXJBo+1qvtmhVdHxuzX6unxctxnQ/f5tL5Rgdp8Xwfj8 6Q7dfX+ar5a36Otmebt8eoBo0OP6+Yfl0+16tTjWfE3ljV6T8n6C+vIpxoLCR8NHwt86/sah9lwV v2MG1zlck+KakeJZceX/tjaEf8fa4MWz9l3i3pkQDf6YKuzbZ+x7zq8qbLt38+Jvkfv7V96Wi2Fy QmdH6NKkne2sBuuiQOoiV4VnDN9EF5cv0EM0FN6lefHt7huPhnhb/nnu7+Optwn+CIt2HVrqs8CL LADSLjUGMZQAFawA6Er6zoOUhUMXgImOLQBXmrwanLuWHiDzH1/y0k4obR5b5pBvQl5PK5Hs906v o+cT+qQ0nQ7m5eHOTiFyP0G+U0+Hlo7oeLOAJbE9Ln68OZFp5gy6C0Fg3RgNFgWQMXcGGT+BPgQx maa6vhzIddIZOI6S64Qrn5a8GIdO1U5Hd/yw/u+p65fbkw0p5MbNcrPdXT+5lZ6vN19P3sMK7NJM S8z728NgE84tweZlwRZUncAK0SAcKlKD0NZ02trgDzjDhqLZLfIX7nxR9yEMr/hgrxEP2FnfZ1nH FI///a8TilUIElIp1liek5NEBCOealNj9JwLdY6PGjxM3mkvWQFmPKMKP2cwSzSsGfstisXq5s2z NpUJO7NkkYYle5MsXxmXsZ3fdPWRq2J5ExXX1cvV120pM1yB27SVQ2hhs7rQA92oYqGUiyfZuDyk ARdpKJk7jzbc/ZDKPNnkPn0ATyhbBu5nMO8OOZlsB9kuFeOrmLgW+6QXTeDS5vTYyeO+S8KyEr76 Yd+75/PimnjbrntadJypdFy3dCS8ZNMhTAzLZl/67IfGdem6iioyrai7zxMdJuNzZeewOAhBdzWm OXSHmFDs4ZYdFDTblX/+pnMaUuq0aWBgmvmuaKyw9gMikns8hBIWRoOKU4lUCfcb9nc5ZDp5RySp qsTTDXrC7ZeJjgweQyFkFMlp0aywJh55ENeEtUCQJ7ORiO+yyVShg+uzIXTMUhpnN9EO1qqsECJm SavmCSIS6xTbtpjMo72T9IZDwP3YhUNZHrNW7x8uwnPdai50M1xVLXzJ6TrISF+IdFLZxDDPEn4S hQiskbS5aw4wSvKkcURsGDJNDj5B0Xs2CYQYRuc4/CbZUKLnkfPGoPBvd5vlLbpbbuH792+75foJ 3a5XYHK52KLn5e4zWq03C9RFVwjGG4eMxzxWhucmyQtL9mlCHWG31gcrbZdpMlCpxHgN5XQcLPqS XXRcDW6OaJyxVEdVTq8BfGiCpjmszdlBhgnixW/xUIQw78FWZJ9OSSC4s6oUPgPcvxNOdmFZl6e9 ckRqC7VBk7is57hRk3RkGG5qDBOYJLjVkXUCKYbOsxHTsAJuXobvGiisCdn8TAo7aAWfWk4u4zs9 LlKuZU1DTDS+fLnv24UZw3MpC2I66fkXgrsinD202hyJoFxTAa9jJ3RNgarKKCL9EcYk/JInY1gb vzYc90qxXKrH1wxSH6mQFeJjiVwJGzRkQWhc3bYpOSUFLg+WGDeeqNJxpzLOSBAXKbFVZgts0mkL kju0VCGdcakun7a7+ePj4g6Jc7CLVovdYrNF8y36Ot/s0PoezRHn8Van3cqZrqyYhhMGISfQt51n yjlBkldLyWIDhSbmMjkXqBiAK4kqG6pLEAynQVR6IfSOjB1dWWq0IIeOAZBKmm3T8Gl0lm7skvGC JBE10uY+UN224USmmYvIXQgBpYcNgySoC+CWoumYOKGLhBQZU9ZUFR657pwvLCsFq59vriIhpEPc vAm6BFI/274Q3YlgL9WBjnrpNCKM7qvnSxb6I+B08vPEPiAsg8kz4EMmfSBP6QNiMtgmph5u0QdR txzi06Ms08CfMU3JCXQMx48jGPZlBIeMwCaOGVFtrSUJwSEhaWCnEHWEKKoMYmWe10R2/djFTkVc 8OWB6Mr37HWnKeA1dQbHVuq6vuj+8lgblmsodu2k0Xxy6DYhrDqgzI8Fr5zC4FNwuDsaMDVRpbhs Cs0ErdEttOT41hzahONETtN3UaMGqVPhm5OFVQyJVBYhnhZdFE6J/DoeJMLBwpaoHgXBXbopPd6k lJr7a8g+0cUH50dZgbzwgzOBOIVZBm8u9+Obx/VmeTdHf18/LzZnxIzRX9DZkTzutUxIaXn88/Lh 8w7l6xW8/v31PPF/3sttt20jCMOvwquCARyBeyQXMAxIio0aSAIULtCLXKkWawuwJUGSk/jtu6fZ naUkSuKmvXBi6zCcnZn95/sJrUcVZbVNl0pGXbp/fqircqUh8HSOx0MypULI8u7zgOS0CmpGIEly JTPgaX4uD0gZ8dCJA/IrMThgoNikfF/bn7vbzay4XbpmP70Xz5qe5+36ZfWusTocodi+GqIeUOX4 ZD0N8cn7qF7sntvFxqVCK5PKg30mTOSpZ/fCO27xdepVrWkTXtaqfeMnYAV77QmaxBD8T/cVPEVi Hbf2JrVx4YNJrJAhhO9VUV2wKc2yTqyp4ywttkX7c90+7nSX/343tS/a5dz0gWqJuSq2b+v1auPf zbFNrBa48lWdaiRUAptKpk9Kx25PUm9KuUKKX7tqZIFQcrMe3pbFQ7vcLZbty0AiYlpMamXiypFQ Pq6gQxhR+0BNRGmKiBFtWRr3M2QgYgnQjSzdZftirmXx8Lb53p5se1/oRFL/IGaoTpXi2BbR0zDS 3W9sqN9nP2aLRXH7oid3s3g8neKRmLyJMfN3kkmRUVV3dtIgyYpBmQxBrx260tM7fj+evvXE7Cac ZFmTq3rYYlI6O3OtcTQuyBlrqV8mUDw4rZlx6WAwSIT0AgnojMwkSAj3kiE8rvWJ9v8vwnryQt12 z5vV29Pz6m3nl9+23XxfPLaFvoSbxW61eTfq+7qYf5y3j7N5myfEaJ4MY1s1lftlM3RrywMOBUo8 PazE+PvJ7pT+c8LvV2whTAumN1Iiprf+i7u/7e9+Qxxv0RC+j+WgHA/c8Wbrvyf+ycHs6P/9ieBU fUNmP1fj6uR4gkRsrt01AR+kfZK1bZZpfL/M+6ZnkzvvXKYxa9vrs7xSr9jjmf7a/tiePaadHVpp cSG1lmdBRlIoCYvP7PrJgJoJoh0vr0WSId6kB1QG0JD76zH0xsfqoHtXbtqXdrZtBzIGYSOlGh1R hfKUTA1BDKJGDW26Owbqwj2idi9E5uCmN85QnpVoYG//IDO7dkYl0hHqtUNGHheJ9pxs0BEQ0CMn RO045X4+e15555sBAzokU5L8UhigjQhBrz0C1gOaEQPWDAc008/EELqgni7QqUuu5FDfC3hxebh+ tUfxfP2sWnOn7oAJzHs2McZD7xV9ilS9jqpud5dwvs7uLnbO7jqxcYIbGtDjcGh91/Chse0yycI6 yja5iLOsyZ34wx8oBgcokPF7Iea5fNV/aHRTzHrExvJY2227OSp/F4Hu0lZB25PY8J70n60iJMAY hQ7wG6auHe4gKMjBGXyfv/kJh9TiY2NjKk92uOnmyIYU+kq1f0NuPrJaP3Aib4S4jjW0D1OHp8Co DexYiyo0jHtWDSRJW3/WsKFUfOtsW1Wn1fzS23wjTFnIidE7rDh5ZeCJ1p1zuqr2V3fs/rT/TPzr U/cevB4qWccJwuBkp2iM9nrVuVS+GxX4iV+jdSzROgMXdOwXJRibXuOSRTZDt8u5C7fDgfqsleSa Xggd1dRxIB+yHwWno0Zx3j2BbbbKBT68f6wmcReYgjNRNzWH13mcIls3W6OzXUmnQBr3G1qbxlSx QGRIgQTXqF2TvV16m12czp66UCCs1qYFzbFweH2U83b9snp/bZe74nW2HuhVBBuRmiodWcYW0EEt 0EyobVoXWc9qQe+Z0boo729vi4fX2WZXfGl37aa4nF1jXKS/5cPb5nv7XvyhX67IqeMfcymU0pGk zBXxfjlfzJaz9eplsT2d5pGApAoBv5XO8ZCmLH4rPi+ennenrEqf/TG5cklFx/7khCSqCSHL+68D Zogob1Nwdtdut1lAmQCgXD5PuufOs+DYJamueJ5lSQrpL3sgFnaAQDr0ZoSD3t0oegDOgAnM3xyE B2G9fQ3tdrs6aUpUmB/YESqisG7dtqPVtWeDswSrvzx6hFEnGaaPT5F4bCb+FPvd3q8cZmRLRLlO buI/74krj3LwTbCEC2zXRNoHrAHOwpSPe2bfm8SqCQ/jsHxEg/qI5okdmieJTq78/Eg4cacywucI HGlem95IiWg5czaIluLk6sT0rVc56Pk4ek3EK5EgsjdSgMLY/51DnPAsg9aHMTrv2DXHV+JiIL/r mIGJa4gxBeZ3e+ppagJsHGguc6ewMafVwCuTdT1kou5QVrCXfIxaP403IClGFQ9iE4NESWyVm9h0 su20T/znaHwu988Ctc0zGns74dBgd/R9z+WCDnC4t0MpW7MxqRuz8sWoVn7xcTaE8WSlGa+p9/Zz PmZ31sSBeaRwN/wiZLCwxme2rA8GE3Z5XL0OpOmK6SiVMhCJSs2HlFo7Pap0KJxZKLXXr8b9HF/t ORVB4lw62I6QnIHdWP3KS2D7o549ob/2o+hQMuH1SCob7/NqW4yXT+1Lez5zV4dCMgEhP7VrbTes y1r9MxTkCWU+3rfyrw9ClLOdR/nZcl44sM8hb10BQRt1IcwfRPAQU6cMMY2Emb3JL5+ngPQ4x1Jd 0ZPU3cfwSbBaXok8hk/qZw4L28itOstQluv9dsL6DLpNjSSNjc5HjQ+Mh7gdA0aynqent1oAIJIP IXrCcXu5AwcK+xKyCE+L7sLIi2Vw5QDEMjjrMPilzgU5loBccHrE6ftMkAUiaMZN3239Kcpy4gnB VyX00PkkohKfhOgEuL6JPYVTw/vgaMBxhKryCLBQTX7rZsvk43dtVu8Jwb1PvFSnj7YC0+g4wtRC Xwx4VodP0jcDHF4D3rpNpxtw3lTC5tXgvHJ6rhQ+u+0YcjrBEXVmM9iN5r+db46YNUyB6U82k+5p HDqlzRbdbtsBfwKrbb1zP2QWY1odHcJ8X/m+yFhnd3vOXUMdOmNy1JDKbPdm1Ai/PbgYQmecjiSv RDf9fBDuSpJlvKndvXYN2XbgVlX5LejIwcSPnnJX2/yY9WAXl0JXVPpFmEua6EY60Fwsn3IIs0Fs 8LDetLP59rltd1sc8t8BAKlvHQ0NCmVuZHN0cmVhbQ1lbmRvYmoNMjk5NiAwIG9iajw8L09QTSAx L0JNL05vcm1hbC9DQSAxLjAvT1AgZmFsc2UvU01hc2svTm9uZS9jYSAxLjAvQUlTIGZhbHNlL29w IGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlPj4NZW5kb2JqDTMxMjAgMCBvYmo8PC9MZW5n dGggNDU4OS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm8l21v2zgSx9/7U/DVwgFShc8U AcNA4iZFH9K93fjucCgWBzdRUreJ3bWdBrlPf0OKkijFsWmLFgrXjh5m+J8Z/mb4d+/k3RVGd8ve ycUDRm/nvT96J6eL1fR2cr1Cg8HJ7+jk0+R5/rhCw+HZ2xHqYWT+EfSjR9AUmdeJef1s3DsZj82N 8S08M76Gh8ZP8B8aLxHB5vt/5tICEZpboIhJRFUilVZo/NDrq6Px9975uHd+mbtJZArmMHgq1shk IpASAv5P4Sfl6A1LE6UoWmQ9QlmC4VJ+H65jIWr3JUmw0u6+UIngzL9PSZpISov7MtFY1u4ruE5T d59imSii/Ad4ShPKiwVollBRM3Db+7tHXPSsEil4QjVLtRbo+qGHE5FyIxvWBf8rgv58By88QfjQ Jbz1HT4f0Je/MLqxcacmJMYcvIpAnGYc3feuIIOVnzwoTGLBOnFnY5wqzNMu3OUpI1rzTrzZAlAS M9KFO1dOWHcTS2HUdeEIdr0ULFFRvKTK7nm8xovZxLATofaZVqy1Gq0CNlgsWY5eL2X57rpQV9vP sdQ59q5R57nrQF0NH9HE5Y3jpTjPWxfaarCKJa7oemvUef46kFeHYyx50LOVWJc7310H6nIWd+AI WCyA+GkUL1tYTGTCqUwx+Gyrhm1ncTxZYSzuQF0NjrHUhbH48OpqdIwmLoTFHWirsTGWuEAWH15e HY6x5IWx+PDqHIsP78iwmIhER/GymcUcOibXjGjeXk3AwTOerCAWd6GuBsdY6oJY3IG6Gh2jiQtg cRfaamyMJS6MxR3Iq8MxlrwgFnegLmdxB44gYlzQREfxspnFTKWJEFpinLZWo9hWFseTFcTiLtTV 4BhLXRCLO1BXo2M0cQEs7kJbjY2xxIWxuAN5dTjGkhfE4g7U5SzuwBGw2HjBUbxsYTFmUP7gBkx2 wOJ4ssJY3IG6BhzjqAtj8eHVNegYSVwIizvQ1mBjHHGBLD68vCYc48gLY/Hh1TkWH96RYTF4IVG8 bGYxScGcpkyn7dUQun7Mb9Ixjq4gGHcir4HHOPKCaNyFvAYgI6kLwHEn4hp8jKMujMdd6GsSMo6+ ICB3IS8ncheeAMnGDYniZguSiYLwpikGw23lyO1EjicrjMgdqGsQMo66MCAfXl2DkJHEhfC4A20N PMYRF4jjw8tr4jGOvDAaH16dg/HhHRkWgxcaxcurLG5CK4671xnZoEgcd69Cq7GvI3l7lSKNfRbH 3ev7uln5cfy9utGgIJUwxW/s22tgmaGPUcYBZdZPFdeM7WkfIwZ7UtGNJd5GQFDjP6QOb++00RHU 4g+ow9uUrWQENPNDqvA2exsZYW37gEJ8irQREtSgD6gjb8wHdGD4RyBZrawHNeL2boIacHs3IY03 gpeQhtveTVijbe+nsVFOrn5OZmgwGA7P3o6QM0jQD/MWMW+djXsn4zGkDo1ve8Tdx4hjU+6cm9UI NH7o9f+5mt5PV89H4++983Hv/BKsNYy/YopQZWuvbu5qNVllexiTwlZY3dhltsoWS9TGHKOVufez 5Wpyf5/d7G6QUgqlSWvL+9IfH2nanyzushU6+mv8YV+b3hq/9D8/PnzNFkck7aP5bSuzFEeIJFXa 7pZ6Yj7PV9lyd2M8lWZLkEYY/8yW80cr+Rqs7q44L2osEi0Esev7cH66dXX49YIGU0ozXSRZ4f4c Cmf7yl43KVNSmuxffNpjcZomxGTVW1ufHWOMd7cFKYBVKVE3xnGAtRH970tzZYn4cRtgTN/CJ4UP HwoBf2OGMR9hLGT+W8CXoPDR7jqB71P3nHb34CEB1wCk9jdX7t1T9w78zc/cNZnbLJ4VqvLDU/ds 6u7ZNQx3T2mpVhokF8GbzG7Q0/T+Hv1czH9NbzI0QTfPs8nD9BquTK+nszv0c3o/XyHz4B4ZK536 dXQ9ny0fH7IFymZ3k7vsIZut0HJ+u3qaLDJ0O18gWx/b3G1MqZS6llJuQpy6UCuXIlwPKyE2tCSF 55lLj7lvU1GkAVLHL6oUipGXVl6ViP3dSL+xVZQBhm8C94jM/yxLjISkd7N0mFMK6UYJeKCwEjrK v8siTV3hqnoREzLcPe4VIJtbCawzmm8n45kJFwfpbaEiBzaWQyHNe9w9o4JLXSQps+uxP4RkidYw wWAN/OE5KeQe6DeMltyMqyTvIR8ns+VkiUYwfOzRl3J7jJT2vvT/MX9yjfM39Gl6923VCticJqnE fMcesC6plU2Ybwubg7xeGd1SJevWCMcB0wr8JfYJb9kLdre2eff48TOFeA4fs0mNaihWejFkqugJ sgKJYA4MHq9L5jdgUmy3AkYGEvbdCweMYkvSAgj5b7NtzW8LDmMbnies+rQFB8M16bu3JZ9hsCTh lsaHzDDVLLvZIpvhse+762yNf0Mwy9NREd52kr3KLnBlJeEq+mXLEBuyw9wSTZbeeohTL8NiJbnl l63otLpvKs76cb79tmIqsWo9Q2kr8aJ9GOAw6Ich3+FFR9zQFbfJdoUt3EbxQ2Ges/fSqjuWAxar Oq0NT6NH+XbMEs2a/I7ebkASmldEuZkuf95PnpfH6CZ7MEPQIlv+hPklQ6tv2cMcDmYruDdBT9nX NvORSH1s/5wvgNnHduiazn5ly5WZkZbwG8F6Vovp18dVdgPjE/QNSvp3z1vPWxvTD+Gtb3xRpcOG 1W1ym7IiTXnV8YE3QfgbxWRP1OemasPkr/FqAHGXhJvSuKjDcZOFtDHQrXmctB+qhKi3wG2FLyvv mwp9PS5zum8dxNbUUzmH1bri+/NzdPUwWazQZbaCsXv3Oq3sej2if/W4+JU9oz8IopjQPWchYRp5 qvKTwaf543T5C84jGXoHM9Zv+w5YgtHK6Pl9dg175nqPw2sxAQkYADWV6Y5T1UaTRJcm+x//s8fi NLXjlL+2Pt13mtL5NLWzsc27xrNmuuuFO4Lo6kBQgONFl2y2muLvUXWgstdHbvdxb6DwZiXO6wcP ixVW7+7Wpi5bRxvBMNh7ggtMWBpK/LKH1RC4fuKx19dMXK/1yRd9uZiYeG676ukONdXw2Ea4V82m hXBH8rIneN25Ni+euZXpRqpHfjevp7SwW9zDZ2YyGVI8yKcWZq6P6pFYlwEA7B4toUThK8VdnnSZ W427ZgqQvdJQt8Z+E5L9muvPsqflfbYCyodCQCQpszbtD0hmwphKwapIqHBWudqXw1gkBAJlrVxO YHiZz9qRnWtWWYxBdswTrRmNSHbIaGmy/+/3Lcjura3Pj3k7su9qbPN+96y5A4Nf/Ouovva0uwaI dtt6ICyeNdyy215619OXz/vgLOFXHRf3n9E5pKUqlVm2epovfhzDUH59/3gznd2hBzNdwWng/F9H RPfR9bfJ4oik/TtzzxwUpnBuOG43qvu19eXlEC0GWw9G9pHUvWU5lJ/tbKhG1SiOPeM8v20fx9Xr eZSHspjcvTNA8aj5243fxjE2c22aXzLfpm5aTuZcpvWIeEOE4a0ty5EbPFjeRURaRa0oU9NF7PL4 kKlB3hvz5XkdzCvfF312zTHAdjXujf9+ZyoCKkLPrJvDIOTLwjitdkRx8ijnJidp7azlHdrKXaqK 8mi8WzT6Ihy0vgN928XsZtNg/tZDSgYuJd57edG0a86b+VSOBcWI4oqguFawxUbPNung4ajRTyVJ lCIcFpQmjJYLsge8sz0mLiFVIrE1WFNIzvcc4cqQ+XgbrJ9FaQOnxKHbJk+HorURIS4SLbEG/7KM UJ/r/eYDWBPinCaUYmUNfbbYndyjd4vpzd5zgrJGQaPccU6oIv4Gw/sCja+R+/GE1rkhaeXGFu7w jTDkpDwEEaUCbB3VnUCWzSgga1r6RLQ95fnmzJJdxyjHeOp1EQfOZiH5JOHCFV5BnQa5yhmh2L+6 mjdqhPPgXJJJ1tdRkazN4ef/rJdNb9s4EIb/io4K0Bjil0QBhgHbSU+bot0Ae+nJTYWusU4aSHaK /PslKQ45lCVZFnMwEsfOaDgzfOd5OctwAbpySgvrBgCOkNw5QEKbyLgy/d3P3p0RNg46bi0jh+hE bcAl+k0ZdfjuxK5XUjsxOCF4nIAMRDcDVSXrAE37hR0FOKVdPETYanD7O/KybOiU8EyGPkPuEoFM 1P7NcjwDJvLGPhVRwdAK5rB41p2q3CFakROqMOvyxfSflTwYfjgAXIIC3dT1OBMYYKS2Zervm8+d gk2m/Gm3/2MuAJM0vAAqItu2EHn9YHv49G2NIqGPUudeYrreTfm8kGimdXWodk01dT93CIIwBS5S RWQLJm1EMWelCVIuJJVdQW/ZakrtovgLCemyvwls9IJEPTyUrz74gwS6a2ZYfGMS6sgKw04LKqOT y2ZSJ80WuaRavgo0NGQ+dTIF5lQWpKXO6ke9a/7bJV9PPw77pyQirBAu7Pf06+8/VX1DZJrc7Ztj vX86XgLQMabVKRN6LdKORuQMIqZf7mfgttQZUYJTS/lsQgXgRdH0dS6197J8JYGvolZAEN8sAHsp KGat/Jx6uqyI11ZATsBytOVHHMeRlZUh87KfcVi5V3NjVD3U0Pp6wBndOgbO2fj3ohioBzob5Ih5 p7+XEay89kLmMEFAPlE18VdjeaF32OwM0a+rQ5TIIgHoHdyV8566pnR7HY1oy1twa3n1L9iN+iT8 sOgkNC5RvrotuM6Iz3C8HaXPhFLSXKrnyAUXVujZLDogC8ZMJDzejg56xy2qPcHI9AEBhTEqQ5PV Y25i8mAE55GjMeU+J5Cb4FobCZu5orV6Z4UqN+O+cXxO47jCOmYikZ7G6SJS2b6ikJYpfISl9fi8 q4/JQ3Ws6uTxVL9V75chYCRy5tfhN5LQjNB5SJHQki6YYKJd+l8e1drn6frvmKWvQ5KS8is5oq9T PmYuXcylVR9+fWtIWS5yzRM4x5TPpImypQkca9nKslk/m49AiaCYoMnqFrFiJTPQYkvdZlHyc7C4 tFRI0VmUIwtxDFYciIMSBK5gjmv1ZZAZrjEFdAB9oz4rp0E2C7zGIWNAK1MJ7qsEp9LxLlUQVnDY 6zHUiJqD8AJMbZGxqLItQFAoewAK4qz/7x4duOe7UCi3bO7Ac9nCbC2j8ujDijy47ahTuCMuqRx1 tAt3GJDtNGSFhaayfev+98yxdgD8zk5V7j83z+t8D7Yvj++62nmoEJj+upePZb4YwnbBdGODV6/t bOGLRmGCOsU7R4awmLophtyFdxg82ilQ1pE7mPGtf4p7b0/l+X9FSv0/Yx6qr4XYi+mYG1sN9D0s l1ggTFx5Lol93iZWAmkWlCbAfxHaoKEtsclbgj/bEBd40d2wHCm7LZseiKGhdDkya8siS5DJoAQO gaVP18x0bquf2Zf9rG96tKnJbYnwVEBcwW0Xt9kZ2gZH5qEo4DUhhu/K9ZzlqkFKr5Lp6bg/7I/7 qkn2L8nDrml2T/+emup4bJKf1Vt1+P2a7F5+Jvvn10P1XL0cL9HnaB+IDGWJ++k433qIC5BT6dPb eAN7Rkvrdv7NE4QVRDTnnk4sU4BQQpPhu5OaNZ5ah2DuvECYWhEYm5nuiIhFLqkmJaaaZKdCiDn2 iJKFIDSEru/Y2Q4y6Ixx9gVChJO+1lXTJHV1qHZNNdUodSrClHfgpVRjS1BF8nlGSZ0+IXm54MpC WK/0zw2RaXL/UtW/3mP8kg5LhZRX+qXRkFy4kDrR64eASHWTtFPC2ekZWFva5ZZ82USX06dkjFg9 Qc9IyScV7lM2z5M5hcI1BdtUrohc2ssu0QUX7d+NTG0jrdRgecYlcpjnoxYmEQVuXp8NMutbhvuK YyYEgd5eZkKDIuozkiOwvv7EMX1Hg7+chnMYquFwvO9wQ7wFbiJvWw8HD2xY3sIK3bY/ceHheR9w eMbw4bONTS73ibuugL9DszyFlQ0o2u8LS10ZwN+6c2c4+pvwU9XL0QE4RhVBbS9888WAgxDbVa65 D7mHqYJ7mymVVb/9SXrWWKjmf+2a5IakalUQkla/9LtbUqSPp5fJ8p7pB3VWm7KFspA8IQVdqGe1 wimKOcteZIsiUzG7itku+xVf2qmV7Stux2M9Sh+fd/UxeaiOVZ08nuq36v0SlI6Gxivvm8KJjFAc 7v8BAPDgBXcNCmVuZHN0cmVhbQ1lbmRvYmoNMzEyMiAwIG9iajw8L1N1YnR5cGUvVHlwZTAvRGVz Y2VuZGFudEZvbnRzIDMxMjQgMCBSL0Jhc2VGb250L0NMUEJCQitUaW1lc05ld1JvbWFuUFMtQm9s ZE1UL1RvVW5pY29kZSAzMTIzIDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5cGUvRm9udD4+DWVu ZG9iag0zMTIzIDAgb2JqPDwvTGVuZ3RoIDMwNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SIlc0UtqwzAQBuC9TjHLZBHktxMwhiStwYs+qNsD2NI4FdSykJWFb19FE1KowIYP6R9GI35un1qt HPB3O4sOHYxKS4vLfLUCYcCL0ixOQCrh7gp/MfWGcR/u1sXh1OpxZlUF/MNvLs6usDnKecAt429W olX6Apuvc7cF3l2N+cEJtYMI6hokjr7QS29e+wmBh9iulX5fuXXnM38nPleDkATH1IyYJS6mF2h7 fUFWRX7VUDV+1Qy1/LcfFxQbRvHd23A89cejKInqoAOpCEqOQVkZlMakZxLlcsplWVARkwpSStqT ctKJtCedSYegPCE1pDyoTEhUs6SaeUnKSNRnSX2eGqpSUF0/hPttb+PwrwaPWYurtX7M4WnDfG+T VRofr29mAz51+9ivAAMA2jGZbA0KZW5kc3RyZWFtDWVuZG9iag0zMTI0IDAgb2JqWzI5IDAgUl0N ZW5kb2JqDTMxMjUgMCBvYmo8PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciAz MTI3IDAgUi9CYXNlRm9udC9DTFBCQkIrVGltZXNOZXdSb21hblBTLUJvbGRNVC9XWzNbMjUwXTlb ODMzXTQyWzc3OF00OVs3MjJdNTFbNjExXTY4WzUwMF03MFs0NDRdNzJbNDQ0XTc1WzU1NiAyNzhd ODJbNTAwXTg1WzQ0NCAzODkgMzMzXTkwWzcyMl0xOTFbNTU2XV0vQ0lEVG9HSURNYXAvSWRlbnRp dHkvQ0lEU3lzdGVtSW5mbyAzMTI2IDAgUi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag0zMTI2 IDAgb2JqPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSk+ Pg1lbmRvYmoNMzEyNyAwIG9iajw8L1N0ZW1WIDEzNi9Gb250TmFtZS9DTFBCQkIrVGltZXNOZXdS b21hblBTLUJvbGRNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUyIDMxMjkgMCBSL0ZvbnRX ZWlnaHQgNzAwL0NJRFNldCAzMTI4IDAgUi9GbGFncyA2L0Rlc2NlbnQgLTMwNy9Gb250QkJveFst NTU4IC0zMDcgMjAwMCAxMDI2XS9Bc2NlbnQgMTAyNi9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21h bikvWEhlaWdodCA0NTcvQ2FwSGVpZ2h0IDY2Mi9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0Fu Z2xlIDA+Pg1lbmRvYmoNMzEyOCAwIG9iajw8L0xlbmd0aCAxMS9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KSIlqAAgwAACBAIENCmVuZHN0cmVhbQ1lbmRvYmoNMzEyOSAwIG9iajw8L0xlbmd0 aCAxODA2MS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA0NTAxOD4+c3RyZWFtDQpIiVxVCXTN Vxr/fff+73uJJZY0EUt48SRCorEEUUwWScQeHWvEkUgQS4ziEEu1gra2kZbaO0Mt7TQ9k8zYKVJM ddrYh3FwiKWGooxT7Qzy7vwSc6btvO/c8+69/+9++/f7IABq4k1otB3w65j2wdkZy3nzGVdWzozp nimP/zkEkCaAX8TYKePy8zzZzwD/JMA8Hjdp1ti3ez2xQJ1YILRT3pjs3MsDFuQC0RP4vlMeLwKd 4AKeN/HcIi9/esHJs2nFPB8DOr466Tc52fJ65+3A6GCeM/OzC6YEr3DIv2Yq+T2Ts/PHtCyNooVr 3qM+95SpY6ZMnNw1E9i4DghMhNYT1Gcw8DPrTQdaGf7iX2/CWFVfjFJ+2m2M0k4FWtsyFCRSqj8X BvXr4QHJPjcTfanSwR0mBxIg1tIX/ZHpW6UdjvktmnFftZroVWgM2Otct7ju+HpXvYXXN8FW6EDq bvFi/fcXjoVogTtYjcMYia+VRoq8jGFwJAQNoaQL+khdNICRGoiEF32QjiD0xjdSGyVoh28lFfMl HAOwEc3RH8FIxLvYJD3tXczHORmPYr7+WBLQEn0lzV7DQKTbPdQBdMUarJcANOOXGuK1VylhGt7G flyARQbWmk2Uko5XMdnuQSbOSIaMsE3QC5MxD2uxGQdxS96RMsfYLHTEaEwVtwRKpC60HyPOXPTf ZY/Z06hL/s2Uel9FOan2OyTgjiM2j5UUiA6kyfgQu3FFQqSj7oEAxFLXSMxFiY6kjWlYTN/2yxwp 0QF2K73pjBy8gQopkDIVZi6aR3Y26tO/WFq6BFvxOY7iHqWlyiCd74u3/SHwQxRSqGkh3sIfGbkj pGNSR8KkFyV/Llflup6sb1PyR3iAH/AviZTxMk/Fq0LTvnK+3YUIephAGb0wFJPwqURIgozg241q ppqn3tC79RUn0nlo4+xRuBBD3kJ8Qr9O4hz+znylSj+5oObpHeYtO4f2xiCPXizENuzDEzHiL7Xk JfFIB+lMz+ZImVxXocqrhunRusQss7PscoSxVkZiDF9OwAIswh6cwg3cwwNpxJcxfBkv6bJcVsgx dUoP1Zl6tZPgrHaKnSPOc1PPHPGd8VUw6lVy2qIfaSTGYjZjvZd0FJdES2NpSkndpTcljZKxMleK 5H3ZIttltxyX03JXHsq/VYhaplapA+ov6pQ6rUN1a52sf6/LnTDnkvPMnV0Z6jvse2hr2ijbwRbZ jfayfVCdhSas+Hj0YHVNJJYsRBHexweM+U6cwHnW3bVquoVHzMEzcbGaGtKi5uKVlhJN74bKMJkp S2SlbJUv5LrckucKqpZqTmqtOqneKlMVqvvqua6hvTpRF+g1+qx+6swy7UnFZpd55LrlDvcrf76h 8qoPvvG+1b4NtiNr0cXKC2TPxSKJNdebWc7Fa6SpmIGZjNFsRnwjK6cEf8YBfIlyxv4ULuNKtb1V dJeZ+B6V8IliPo34kV7Y3paZ6cFqyZIxzO0LmiOFsljWkjbI72Qz43tGzso5uSY35Ql9gmqjElVP epSuRqiRpFEqR81XS9VO0kl1QV1WN9RTXVfX0810S52ix+l39BJdqnfqv+nzToST6KQ5E53jzhl6 nmZ6mVEmxyw1m80Wc8R8ZW4Z61rp+tC113XHXcPdyZ3uHuRe7P6D+4D7itv6tWQ99aP1rfDTb6WM cGJUkVi1l34fUtP112qVFP+MA2YJLcjFKLVXH1QfzC3SN/SnqhBwkqs/dyeKlXNmlJtzTpC5g+Oq Eb4jHq7S2eqQWqdCpJPu6ixyyok6s2jnFnVNuVUJOe4xG6MwWBrisTMEDxn/U2YJY5qqrkqx+kL1 ZiVfxFZ1AOuwCWOkM63LxS48xbuyT3tkN+vuDZzGfVT8ZK0TU5mk4l0haobrFWZonwy0x1Ure49d f10W4bJ+ytofIv0lBttxk1k/L7HSzPE5jXGGyNcUG1i1/8AO9uBXTgt20BPs07HIcCqY85jKv/qS zXS9QH5QiUxng2rkHlCFxsTgtcSqKhwNQAkrgShS3dH3cEKaM4rnXJewHiuwXwchXG9Tbyqrv3Q8 eA8Vui+1vk58aiKxlJSP8fTDY2/7tlLCBMQhTkZLBpL5JQ1NbT4t304sSrCZdp0ZbqJwUvpKEA4T vUIYxdXG3/eAnDvZh5eRJkuxw5eLMs6VEAmX9qymB2aGKTKfmJ3mkDnhaocCdu0GZvEGvufU8EgO Y/EtfmStJ7F7otk/ibQijTNskhquD6KHNMIUYmAkcTuJMchgJqdRSiGWsZ+2cYacxCOpK5k4hIvs nAbs8xzq96OcPhjMrE/DdqLjAtnBm1w0RWvG6akESJyaTn1VOLuaOFtGm67gNpHDVtsVLV0lmdnL wY9VvUwNnZAuf+JM3o0unJTJuhzfoAWnaxJ7dCvfZbE2AhCKLuamKET7+ts4NV4flGBOwwBW1SBO 9u7yGq2oQz8qESQD0NHXk9KKiWXpZhunbxQnQ5AKcoaawbT7EifZSUy1w2S9OzkhafCghPhfde/W 9ZUucZ07xnZo365tzMttoqNat4psGRHewts8zNOsaWiTxo0ahjQIDnopsH69unUCateqWcPfz+0y jlaC6BRvapanNCKr1InwpqW1qTp7s3mR/bOLrFIPr1J/yVPqyapm8/ySM4GcY/+PM+EFZ8L/OKWu pxu6tYn2pHg9pSeSvZ69kjFwGPfLk73DPaUPqvf9qvdF1fva3IeF8YEnJSQv2VMqWZ7/MF7tsU1d Z/yce+3rt33sOHHiR3Ovb2wT36TOy5DYbnwbP1oIgYRkyKZxcQjpQulGgiYY3aKlVWnYBSqmamWd NBW00VEhbdchDAdVbUaCVm1d/5m2P9A0gTRRTaqlTUrZgxDvu86j5J9p177ne53vPL7vd865JyWn T4xLqXwSmisY9Ak+MaZvbkIFvQFYA3Cyg58oYEc3rjCUIxUpUEhrgkHJTj6Zkuv4pDICmfalRg7L /QOZVNLFcdnmJhknRvlDMuJ7ZItQqYISlW5kJiFrKt2wR5TZoLNsoWlBOlck6FBeMB7mD48MZ2R6 JKv0YRWg36TsePWvtV+J0LgtkZl50uqipVTtEVYRJWmGlS8NZJ60ckqZzUIb4Ev50nkpDV2fgyD2 DrLQG3U6m5HxaeiSVWaizGptfmN8StHkX2ZlHd/Dj0sv5yE1TklG+05xs06nOF++h5wpVhrK8Jwc d/HZkaS7YEfSvlPX60S2bqulualArGuBLZgt64zR9CQztmmrcJXqCte7bzOyWBkRvxMAIbOjLIwk w8OcOpVirBNJo51QDZ4sBi/5MGTkiKxL5CUSUfSKv6z2EZ6VvkSAAL70xVbNyLqG8ZEvkcIqONmE Gtg3eFkQ5GBQgYgmATmFMXZX5HBz04ki9R4/QVggED7UD7EdyUZCEH6OUxJ8tiiiQyDI0wOZNZlF h1yzSAwJWZnKK5aFDUv11xTL9IZl0z3PA5LnkHL/qZa1/s2/hdRUpcYjMq75H+axNXvvIN87cCDD pqT8emx7h7ZIa/bOTds6J1clMrSLWucoF12xAiiHNysrQsYoq3zwZyqgPlzUaAGVFQ1m0zLJP79W ZvUc9386Fct/V7wq5Cu39WHKEWGrHN0ibxmeUaJhwCo/1Tt0QJL0W2xp2IEkKc2zaSkvjRTL04d4 lvDSPHzNBKSJVH4jo8XyrbMuOX0uC5MYxxFAK4V6Cjw+M1AQ8ZnBA5l5AvewM0OZWQpTiXxPttAA tsw8i5BY0VKbWkViFQnuVYD0WUpbMbnmRYSmK1ZVRVGRR4sYVXTaDR1Go0VqTUcqOniUhZ4YyjyZ wsq6yDbD/c0Np7lbDZdFpEE9cxReZDRFWitWIbVqkUZ6jWoRozoto16k6A/xs0gHh+5+VCuQh7HH sT1kOdb3OIbiwJMVKFpbOCtn9UGB3Sq0wtILK6IaPUKsakHpYV/5PjMAd80W9AzahSPid95lfuh6 J3kl8bPkXHKpTbPNeNVN3UjeTt5J0aeqXk9SncyY5YSFjuM4FVHRoVCoJbCT3mYMNYeepkMohEMU LTS2Mq0M02332O12T2ujwKiMUU/3TrtKYBkwqjp19p3dHhWfpm7jltuwCqydV3mcLlIrsw6Dvkg9 FnVWQ8tBdAw+gYo0J9qN1EF8DM75JuNti6neRJk+dvpvUf9GHeUFUWezd8Q79nZQHUX8sWgIRePR vVG6PoqjReo/oomwl1iKnbX01PdQPUXq0Q3n/t5j31eiVcot50o5KIQSeZx7vJyLEXhRvKT8bF2h WImUrDZHl/LiDWbG/LRgniJLM+alpdYWnFt7UC6HuWozpalx1LS37XAwGob3+gOMUoY7tu/wK2V7 GxzQDFTZHu7wB3zbgQT8vJepttfQ4AAEfKGu6i18Kd0//a2XxGZhV6xxX+65F/acH5v688mP7v3p U6fz/i/PX/ng5uTdtyOdq8ePPB8NdIUS7Fw/F/rGj/v8Bzv/QQsBffzBW8MNdSM1l5PtieGh3s/O vvOXgWe/G7n0x/MvTl5O/ObBlRPBKDMayMYn+tp3xVsnVv/g9XemXrz1Esf9Ez6c0WD5HtOgfgW1 41fEGj1RN9A+c+O368/Uv9Hwhu9845mgnoeVd12n7zCuU2adBoGKCWDGNeOGk4aTDfP0R6oic7Ph pv9mUJ/k041icKbxzaD6Xf/F4M+Zn2quGu74fteo2WWuFV0kPlGLn/rEUzvsdRQhtXbQfM+BrZ94 HF6+3YMOUB6Mi9guetGBlg+Ep+oxqTc5amu96rBAm8JeHbISK2Xtxk85w4q/zkg6wrZtdR3hD/Eg XGC/ie/BOhH2LPclMr+y6Op1lK7vbzlXQddXyu4hwsNYXymHNrJv6+rC8CLyxXIJk9JyScA5QXlb W1Dv4KlCSps4JbaxQcZi8EM6Aw0ByKLPyOt8yMyRHszWWwgTBEkfMPmQhTX1IG2j2ocFaEQgMRID Jii89hrK4UloWBDQJLbyfvikY6hqu62CBWuH38/zYa6aUQBiZVSAJ3/AHyaIa3OswUV92pdYXX7v R78dGv79+davb69JtfLU271Ront99fOLvy4v7kjjX+D02EDTHZu7xa4+uupd+vTa6meXF1fvStV2 7OwP+X0+dX1D1a7VB5HokWtHpWu4Db9PtL2NXQoWPOX76ovq3YjDk7M2G1cs/2vW1KUQ8aSxi7jd FuL2eCymiEfr9bpYyJSXing0Xt7Kemp284gjHMV5WA9H3A5s8Xi6EbZDsx6XF1ktZow9Dk6r1WgQ 5ajRWnSY2ma2mPBBEzZN9fOYJ9ZtbuTC/S6MXMdclGvK+8yJWgE2ucnccWWf6yO5h2scisdj8ZgS VyVxVluXDdZrZbnOqKaWEChrCeRxoRLqGRKbWpohS5CM1pZEZh4+8GVRqAojC7HsQMfZCW6aneZ+ gC5YLrAXuDk0x5lUrIoLqgIGb1XQyZBi+YXZqjCQ98UqW1iFEbFjQi7gS26ZyG4tUpACWc3CiXmD aO2uOFS9B1tVbRxpzVVxBGfkumSxxy3F8ufXoQ7Qu7NmR1yBCMBBELIYW2GP0ISVvaXaymOrvaa9 vZoLw95hDQASwniV+gnfMokX9kc578rRoyl2tX4i4xF6utW7V25Sz70qRCifz8DvzT/6L9VVH9y0 ecb1SrYlxV+SvyTHjmRJtuNEjk1smcRxsAUhlK9Auq0tZLiEFbIBHeBc2412DDho13UbHeuxdKN3 0N5gu8EuDLgsQHth18GNu94If42tt5bbcvtg4+uacttdk+x55fS66U7Po/e1/Er6Pc/ze37viG3r J289+7lEAg08Tb0TX6iSCaBXA3aCJyC6jUScuH6BiEF0XcUYju4GZ3FtEo2ID4WHsf+otlYmSiBX DCKroliTQ9XcsSafqkUyPiITjTr8PpJ2MJyClA8GQ/tCx0JU6JVsEiUjXiQDcbe5CRfnIvtdgy7S tSeRfBs2SwpsjOh6PVohrNajadUghBJqEAgYgKA4eze0Mag2SdYCjaIQFkiHFlCySG4EowbjWRQT pCxB4MrSW62SquIBjykV4MphvHApFZSYxcEOisfFAzyskS2R3g0za5/siUSWVsm1KD77k+9v+pvC P3/w4AFyaPblHUU1kdA6d1C78NXkGwffVkXy9Zkx8vDrI98lAMENcx9RH1DvEu1EN7nSDDo4rmiL ccWc2b3U+E7hNfpogSpjMtq0qjBWRN+kT7ad7v5V29W2m8rv224W/trGFuheeqV/pbCisE4YYo4Q Rwsn0BgaY1x5Gu0r/8j247Y32m1Eub/8VGiwPCz8MDiKTnRNoFvlBibUX36mRC1nyKAvSJbwU34j FO+VUC7PwP5PT6f0dEJPt3TnT+Uv5SlbflG+L78n/738sfwv8u/kf5f/U/5O3rkrj/KlAKMwW5hn GRvJlJjVzPPMt5ljzEnmt8wfGNbJRJhdDBXwMZToTso6rNgylC0tJ3MjRDWbJUWzRTe8oixuFHeK x8RRcUKkPxT/JX4iUqJoejhDJGWadHrTcjqbrqRt6aUtPd6EnCATtwkiy1bYvewEa4uBIwmWA1Ie R5dMzizvK5NmebBMln8WRMEI/rpUf6oyF0ERnejgOsiOnN3UEsZO+307ucBu2vvtg3abPbyo8zFx HLW/iGmiWtP77tSma/qvq1y1Nl2FRINe/3AKUqziK+pZ+B0oYxoSjZuZnoJ+LxSrtWEfNnydRorc NYbr9nR3Q02j4V86sGw77xKbRJKorreyMtfZFdUaOMrmTTQllYQzWUx6JF4iXDFWQqrWRXVIBBd1 S6hBBdNpK0k4U60moNeP/XCg4VqVgBPVoBHAXGJeOyQKOHFVrA8EnLv1WSwmYGglONYbltzgHfW7 8jlyxamX+7eNo4Jgpha3NkaTK0qVx4bf2/HiUcHTEHA3RqTc9qX9Aw27S81KuC33ysjWtdtPHXpy W0dLk08MynqqvXd1fvmBZbUlrSOzR0yFS4gre1YdQcVHHl3YkdEiuC+smZuiNkLea8QD86sfO1Cc RevZk9IV8op2E91GfybpBgalydbAE/IQ+2X5Ofa5hmFpxH/afzowTl4MjEkXtSvS9QRPoKCfoDzR SeIWVNMkuoVIGwoAZyj+oBgW7/OI/6eYdNLKcpsTGoZHR5AJ53LhCvZmhOUNL0LH0Rn4R+No4h5k lTcqR8lojp6/D/uxlG5M0oiuqwKPQYfjnYesRqIDVQPlrMHUA7j3TQ1bCuBOjeuGDOAhE4o1S/1x 17DeIyBCw7WEhThZMDrmVR2GP9k8HydLBC6kTHnJlZ2Xbg29cPPwqd7OUh/rEAR5gWp8YUXHqvZ1 D8Rv7EaNVycOj/5goLh0zeZKOJzvO3bwQUnPYFZZC+hWAd0gEUMFc53DtypQDewMfCW4RdwdoBMN PyWvktf4G+QN6qb7ZvAj6t/uhr1BpJr+oPE4NUTtVL9G7VUPUC95brv/HmRbmbkQYlhWJxiOiTEU U7XHQgRaFhpHqfORpJ+2jyPpnMvJhjBATgAtZIZVI7SVwNjB0AsBx3A6PQb2psgXiMasWlE3qvdU mxprqdN8jpvH3PKSr+6TCwzsTRcAP8khLqzMY2/1YiD+KYy+ruNa1fW6Ap+ewb18ujqFuGu1Ovnz UlOiTv5RnywRjYGQhCQ+IiEhCGae/PX9oNBwkGpIqcehXh0gmgwfxIo2Pg1TkKrOzLEDvZu6v9Sp rh7fPbn98ZmfH7pxV0sENUMpoY8vPv35nidCR/cf3z9xGwX/8dabX5d9+fVHNYBiGXTNTuiaafTh BcIxd/+ss5jBX5hdVTDsy0iyPzOZIWm73RFyJB02r5tQibTs5lQu7fCNeiY8JOgZf1z2jJPvm7za HJdVTWXjslvTonFZGSf/aD6lpeJyWtMQ6KQ0IQ7ZaFVRPB53AyOziG0N+E1lccVv9j5i+M1FBb/Z A2exCwYL2sE0p8DobWDUOBhJBsPxxnU/8vpRzH/dT3J+5Mc067ucQXLmTIbMZnZlyIxZLuAPOQdL WR5WszwsaHlYyfLpjOVND+RbhqgXXGuq2ZqCF7vfjLLNl5snmyk8da6jy7B8tr3u4aWsW9kmxWgO t63ZX69EOKAELSXAzTMj8DCQdm1Y/+zonsGbNEvpQaLgIrWmKQ44GlVBcF0gFHiGz1lRrGcEXBUP 7CDrI3/IDSPBAybsBQMbDA/Mn1UClU/XX4+quNCHQUSABkO8xbUW1QpYeXXMSwnVQfPAtf8zB2rs 3b59vev2tKQWzSZzYZ9Pj6RWp73+0myyFOabQZLN/OXRns3fOj772vYCHY/TSuMW9OYzJaWjd9a5 Oawy8bgjFtpOjW0zGKzNWoEINNiFOYko8b4ZkvbxQsXLEz4iKvOcj4s6hLjsG0d3z6vuuMzjC02M y9FL6C6QsgO+ljcWGqMO5DBBuUUdPr6BxRhEYbbeZ02qxeXyumU36W4VBROWx9uus10F7M7FNMPy fsHyZrZtgXFGQK8KiBA4gRReMKV+iZSlQem4dEayZaWK9CpcXJZuSY6mNZdFHTru8MMqZtX5sEGj heLE4q5yx6p9C2od5T5rbP7/xxkwTS4e+KJpDgy8l+mZpctSILPkv2RXbWwT5x1/nnvzy9m+8/ns sy/23dnn15xjh+RCXkjko7ykwAgBLZSoMjCldKyULWnVqrC2iVQ21G5rmDZQJzRV6qSh8WFohILX TVpQK1i7D2NrpXb70KEtqihrPkxQBENJ9n/uCNo0S37+z3P632M/L7+XP/u0+8BxHl9et9Q20cvk 81ROmaBy0CX7thW48xJwZxhqlq86yasqLoWw9Jg/Ugxj5FOKvoCfzziMe1mBqxinCPaFwYxqktVv 63HDsBcabpjrH7JJdPKgI/PmNZNCpmPuN0kXPMibJmUKki5RknONx/wDDnQjTE3iRaA+PpWDOWYu lHr6pojrdW9809OeBzf8DlGgRdihwUXydXlvIwb5pQq6ZmgUJ8fiMYrjim1pNZ1K05wQlkqwyoyG EwFJQ0lfpoSjoUgJa3REw7GgoqE0q5SQu9mWW3G2t4Ph2LDHWVPG/XgL3iIeCbGT3HRoWpxMzXCz oVlxJvV76ooenPZNhieF6eSsbyY8I8wm/aB+zalxqGswAYTs8yRQUnKcazuIE4FjI6dWxMtH/3z4 wNGPP1z4/I/dW5QI/2itQyuF5WJBpd99+cZrV7/7Fi6/+z62hrf/44NDzeGtqdzQPpw9O52JE2+x DSH6m3CCFVxygnyR7+flkOhtKHAHT+qlNt22yHiNTeLMeb3HHWY077EgutEpyQlbtPAp/oRF8akw mIUM0lBFz4iaWOFwPKEoKPeWrrkwUq7oGRdGZl6vQMfJmMEuwdEGG4KT7m0IX2dpxocqnJYJCk0U fAfvQwzed+mE75rvuo/2tfA7Do8qgqIDOtrNnHebci6P2rYb2ww3OrKUsOdzeDKHUU7MUbm/to+M AWBW0QJguX27ubgoLnhogbtgWaQW8kXEQUJzazqBmh4gyy0VcXztf1sRonBE4xRyLsqDitH2Ssb3 m99f37dhfa1nxBcMZ9RK3MC+UL1v2Tdk+YPFTvrMRz/ct6mxYetGhkvkGl977uO+frEtRefzbP9R ih1NpFW2AGe0c2WB+gjOqIs6C7ViZ1xsMGK4IouZCsPJCflK4UrxL+JN8Z7oq4iF9j5xbftx/qR5 Mv8L/mdmi79g8myIDfsr8dAwvy3EObwToqQuHZ2mdIwJX2OHlxpvYoxbeJMTQ6elOjyw67espJ46 3aarKoEVpJxQsdrChxwtdTpxS5LYouWTtKLES54lcaS4jR+XgP2vXwjI3BjpOMGATI2hrJilXFXg ecH2RjmiBs4AoFcHq6kKNq7bO+x99rfsafuczdmS3yCTkJYaE/y6n/I78LLXy6mV8qpfKuPyqtcs p7oJ4AneweEsAPPBuYFOve03QH78JE2BV/yOnG34B+MmNIkCDGFtDxSJEMSdZ4hNXX01a3iKdt0J wBzZvfA+WckcTOFGmMWNMBGJ5x/OZY0vWFMwg5PCTjkJm5yOQiO2QRNRoAknvMRxcGHkhzRNExpa a+XvcyHZi5BB4nlIdxPdvF8jduVtR4JcVoNEVoMsVl5NEb8gxI/FxduLSPyCLMAR6k4w2qg7AQEa WAtJI0leFvnlQgf8NYD6tTkvwlJBsgsdIN4w+tAJQKfQAXpeaK38a07RSVy4lDQaoXQq20AP/cI4 Av9IHGGzCZiJma52E75iCFpcawhoMeluQmBre2zXyIMSdXd59pH6sZAbemV9ZUA2cLE58vruDZMa n01kxVzHTzd3Dg0e/EnHIyd/8JXhtqiUSNKXly+/frA335aqXP3e7pFTo+18Fx49dmxde+fm4af6 dk08fa4gCCbhuOLKLeoUs4RS6A0nMsvPhii34UMo1cIX4XwYWabjr1CYM/hO3uFp/pnAgQhP0S0c cTIsfzGktmGGQQKrsxTbHkvEj8hgC2H3Y+RKiZmcXY/Nx67F6FhKJeziGe7B7eLtQRHEGPzTiHhn +yIMUWNpodkYXBp0PfcgdkudKQR1T3fcfFhjusTSEzWBS3px69NPhaK4fkDbeXH829Hg0Zd/9Qiz tHx2Yul3O+uZicT8xFDuFL5njr93hKw1urLAnqfPoCr12AUJRXG1tXLXOSPJNqIRwyd4RUQiLTK+ ulxP1JWG3Eg0lB3yjsQOZQ+7R9qtHWafDD7BH5QOJQ4pT2hP6s+LR6WXEi8qz2pHjBdKs7U3rE+4 G+izyM3qXfRl8Ev+TuR+tcgFOZ6LMCIbZTSnNlrbXwtgTElSNBZDQZHXg0ktpSeZEi5ZZb3kOSIG 7LUSM+CfxRK6UjQKetFprTw/F6Upo7XyrPMNHVUNq1rdrBuyrhsxFECcTqG9ugZDjaEDNKb3RkU5 GhWBexC1OSpBXxIZmmICVS0mYcRFeQP/07hvUIZV0i1Dh6dRkcHBaqmYVIIBrkpTiK8RTat6Zry3 zzPdRtYz3cmUatccUorBmqhzNVxTFLX0nKG3cMdFZ390MkpFf4M7kIECkB0ndBSYDqwE6M6AExgN 0IFUR61F7Z7LXh5LtnD1O+BFboOWqClw3mpySU0tJUc2Hdj4WdMzJcSOEAmCj6T046jU39+cgl5U 6T++vWb5XxLfY4/XktZU5P97pGNZahKJi1icd1vLC/PN/wlee1z0D/oHyeVrkirOJRZt5foc71aS q/EuUEd/wi/3K/DFHshZTJs0gW5PNu7COxZz1S4b57yRi2x36MP0wgq6b9/rK6W68SedeePVY0Gt o47/1qdljr2gFntxvLbWWv53mvrl0i7q56frRqRQSEvRseUf4cPJbRV/oUCnlMQ2GI4+qpbyTKHA 9by4lCI3fR1UhpvZQ2gA/cnpDlply6rSr5XPln9b/kOZeSr/Qf5GnvbnK/mB/JY8I3AornNinAnl dZ+ZU/N63PUhVF7niP3YZQp5XTZNTVDr9rkKrty0izkcTrcyWgYuErFgwY6uogXXuj3shHDocyGd OaIOCIIuUEJ723+4L/egKu4rjp/d/e3eiyKvRAwo6uUNF0URAhQMV1QUoqBIjBpfjYYmOj6Q0dRa H2ntKK0mUadqWsY4tmktOjFJ2yTjWCVjq20zzDTt4DQv6WiS0RhN0lHrqNzt9/zu7s26oIhN/umd +cz3976//e35nXM2F6Ex4cVSpXRD34KS0oM+/tBCyom3HfrIgiO4OgfXHnl5+CXHdCI5vzgnVr5o O0enhgZlRYPicybnvls+f1IKRuVbX0r3S58KD1qQH05ElGPq4KxAMLEsITp4LSq+PBg/flD08uXf Pr398R1jJ5WXJaRkxiaWBXz+2H7avs7UeWXI6T0Z8XPV1Z2bHhuQ0i81Vcvov0BdvaD56LL8mf68 ygG+9KTCqPi+cQOGjkxfySdPpEe2NV1rrJ4XXXrFm+Al/u07W1DB+qdXr2670dS5JYa8BRgbAXgG 8PiC4+nRGLrRdL0jJrSO49dvmlGsDOKSatNCh0QDvSKIMkEN/udZo4Vq1WLaorK2UALaV4jnKBPj y1HPg85Cv4r2KrAJ5AEfGAXGg0mWTgRl/B9gN9bI4nWkEq31NNBs/STF6NPJD50KBqKcJc7ScKOY sFfya0lybDzKw9GX7tlKWRiXhPoUjMtnRT1dNNIi9FehPILXxHPEQaNAHNp9+P9TvGfoWPEr2iHI vIhyOtaejbl+bStVQ2ugNWgvR/tk1CswJ1ttMU+iPA5lP85mErfLZ2+kDFCNOQ9jn1Pleo1Uhr77 8L+x0FwQi/7+Wga9pBynF6GPiSyKlM+NMfK5p3/1TNAJck/dwHvk/TnhPanF5pfgQ3DW2ltlF3hf TogWaKOoBLoBpPD6ahueuZYU9H9Lv04ljJfMTjzXRyBeLKRo1M9jn1P131EB10GUBLYkmrGny1SN Pr+xk4ajPV8dCRurp+HqL6nISKMIPN8sjB0HGqXtsS0spDq8DxPaT3xMiehLBel4h4esc4rhs0Gd 3y+ez/wc+/gMY6aCaWxb0r4WIuxelmfO7z5WmR6EbZrn0TcHzMNzlYAH0b8UNjxTzsF8rFti2WFW WAHbnoNM3oMNvyebkI1Qf3C/RQY4DjaCbWA5mMFjsG42xrOdLMaa41FPZvtg28Ba/B6qLNuJhX1n SRsL3Zmf4RyrwAMArpYmWvTD2P58X9hm5X3BXWB7ZNtim7GV7Vva/QF6h5+T37lDB+qnaRrvQT47 bMuh6WxnrForZUvNlnc2ie3NVnknQ/tP5ztha3g/uJ98R1iFn9L4rrIthhX3lM8irAPwcVpMk419 2PvT9KjIoCptMY0Rs6hSewX+J8j/Z14U7fSy+mfye1qlzeAZ6QWX8nve7WlXFumt9DrOMk200QvQ FNGuJot2RdcPmOf1A+q6EHbZqW6U1lAfK+Ps6237vaCe0g9QPcqf6u24O+20nWOE54IyAgy1Fe2v gQ0g2+tXdnsXK296HsF9IroMlokA7nqACkUrfEJ/CuCc0tD+iPFT2NxiysDanWqATqB8Ar6vUCPc T/yXegr+AvD60MkOO7rF5rqxJam2vXajfsuWpLI9w6+9Z+n7ll4KKWVzbGD/zPGBfTSYGLZX2y4z KAf6sG2fbju17LPass+udulSK7aw747je4r/8lh3djb7R/Zx7CPZz7GPs8e7NTy/hXbhGf4p/XAb 5obu9RDgBznoX235Efhhc6P0hwvNlZ4Kc6UYZq40is3NxgXok+YqdY25JBxTBY20fJnPjqUyjh6h CDuOIrdrtHwax918vQSxKRRHZfw0RmMfT8r4loN6PN9DeQd/QnHqGpxrBvURhVSvHSVNq0bcRLsY Bp/MfQ2Uql2iQaIJvm6H+Zm2jUbLuDmRntDmUzHP1V7DF98z5NPfRSxbY34h1+N4BeU23r9RT2PY F+hLZOxdZPnjHH73XoMivYIy5Jg2+KYOiuNnkWdQRcnyHHjuM0iosJbnPA0RxfIchjJyzlWK5PPg M7rlLEKxuUqu2SH9WZRcuwP/+ReazhhDqMrzPnwm/9cSmh+hUqZ+0jxnxexKxNNKbR/yoEgiaf9t FKkV0kDEygqLCWItzrwRY5utvIIVfl/G+0vwVbARvYlqZT7BfT9E3vMWTWBEC6UaZfCPJfD9K2mQ kYQzqqMUadeTQv+N9kqZn3Cc4jyB78toijTmYz7uhdwDxxteO0uebSVsdIy3D2LL4xSNNJLzSM4b 80Ac6pw6PufgeattUEgVn3qOZnIfbPYSMoBDROZiGe8LKUc7iPj4OXz8G7CHBBqtLqAi9cdUJCKQ m5Wi/H0q0n4DtuMM1pgdYgB8+Di0/xxswrx/4Dyj0fclxuyHHWzE3MEof0hjtdepSP8B6mmw1RPQ DnAN8/rSFu1l2mLE0I/UBeZ2uT6zJvhvhtfjeSDXVt6rTbd7/jVFdrvfcV/tM7zHbvbHa/C6ch6P KTQ7cE4fgLSQBqeqW+kA2Ku+h7mttE7ZaR7GuVa4mOisi3XKZjAFCLGO9kCHQT8F7aAZHAGXRAHO Yiu9Bf2tgU8FRj1KM1jR/xL4Azht9znh/+mu3Yn4xDzsrOt5VMyoOeZhpsv4PZQvvgsfO8I8zGir 4B+AEYV764W/P4P26ZjnquuZtEsso8FaLWk97elO4DfCcY6Bu3nGu4VzNI7PX9d6dwve73rwHXn+ e2m4tKFzuJEe87hyhOYq/zKva81kMKE6Jcrz3IO4ZL0ntG+W7a73B1t5kM/c3Y5yKWPX3e+1pzrW fcqJbQc2njwKMOI0xgN33buBAozBNpbTtR7+39tRR/k4pwpRh72c6VqHD8ll1OWo70b/J8jRQbhe h/hRF7JPBmebwuCsDzPqGXyPAq0WfbVy/EOM41xn8LlqrTxXzpfvx7Zz9/vBXBJ/RHz5iJJRTnSr 8866bdrdZvuS7sa47saI2635/wTuzl/BSXDiG/0f2LlCsFUQA2SOuhS56lzcizYqI+pcT3TjGNHN VpRvQv8G3YsYkQj9PchF207oWOgD4B30/QdxBCl7sF4k0i4rr0RfsAbjngVvhtYJxqM8DOtfAL8A TWj/GNSDoYDHVVmsQP8HobnBp6GbUb8OXQXeRlstxqxF+SCYjTLi/81rYA/IDa13A+NuvMH5SDff oV+v3ub7427V/s6w1f0N0Std2rO6vzXs99+T2t8S3ag8B+u76Zzj2+eO3zi2wn4inCCXTkFOmcx5 NOeynD9z/mir/G5DHmn9/30OjeL8lXNnzl+h8vtOP09TcM5F4X3ZccThW9UcegLEW8Dv0ViM+Tts 7Qv4nmhlv3kFueXzDDskjmMQYL6NcjR87jHliHkF2oZ6EmJZhB3TbN/axcd2jWnfaL23MfIeYmqN xVMu7PZ6C3d/rkUy447FvaWn2H3Psfw2MdoZp//Xuh3nbSIeojzGE8C+A13zUnce0FO9pzy3t3V3 3uGov8rcoV/W3XmJXXfTpb+r7YXymUTcNxvXvestuKflYpn5rn1f7T247nGf8H2z6sZ6GgfG26rs p0z4kSywxfruSkEZ8cz8HnSm9yblef/LerkHV1VdcXjlPO7NDZR3SG0gkAZCJUAoYwQkVAgQIAHC I2IFCqhogYwtGnzM+GitPJxp0f4hGiilVKdFoBWwIgMWUWjJMNS2OLbWMgNCFEWC0Ie2tJLTb+2z z83l5sF05M58s87Zd++z136t9du/1HtvQI4NXg5jTnCL/of9QcZLaOl/adRpWsl7nFisdb9uueVK +zl936o+N/qQOTO+/5C1+KcUwyjoBjvhruRac/ek76PudDQg91z3veATvvVJW1qwLcs97x697/He mffOxOaiWJaIX8H/tbLe2izi+DKYQcyehi2IPW7qlPFflTdAqsmb87yRMtFrCOqJ6bM0/8TGSrmz XIo0B1E2hLrjyaU57sfSK75KbvXrgwWaCzQHZNbKjNhA8gDqhLIBXgNnpFZm0nayP4rcgdohzhfS T2QrYoul0h+OHp3FODTnzUZbr5FsbzNtN8tEdxvzskly+W+YlyCv95ASbev9VsozDspPnDrZ5JRK D8q2d+gtuYlqyeWuVpWYLYXYQnwoStRL78y7pXe8t5RrvoryqsmJ9hntdobnOTpu3nOtnRqNOV0T qH/4lutsDepT+43axQ9KkT+QXEnfJle2rm1Km7VK0EiOf9zm+o/S+6NdIfXKra1Mz/WwlLYzdE7N /HxLljlNZhxhriZn+0tYW5e1sHOcrrOivtiTjW1poUibwJe9deyXdeEeo/0QmGT2EvA81PewNTIW ij3ykPu8+hYs9pbQTnmFeURfeP2gVkapn4ruL+dBGeRMlYHMxXFocnQcx9jXW6XEMsWrDVaaNkPR L+pjd/x7B/1XL5Ppv08KlYYS9nGJ9MHngYrOl1MTrFSfnD8E650n9NnspUIzpxdkGd8exLe78c1s 4+t46W72Z65k6/rDQt4r9EwZ+1+ZZuZqJj48L5PNGNFU9HEv/p7zOpkxTovaxBqY9/9IVfxu/C6m 30rOxRYpjB3hXF5kzL+Ba6SH+46UOuuJlZBxT3DKSfCcIEbmw2HJc+/FLoIxcsj9txxiDHUpNBpc 2oD3JGcr5DbF2ZqRz//v6bjtc4/wmbKR8qwh+sZWWZcC9YJGt5MMdu6QrIwafNtHHxX4QT9uF3k6 HdrcZsnW9szpLO9meTqNcenQVm1xOpSr7Z+OLf9SOpSrLUuH8rJW/GirXlt+tFVemA7lhVfBj7a+ W5AO5QXt+FeZDuWV/4cfbc1zv3Qo79eOH9PSoXxauh/Ep31wgDvqeSx3ieDb2P3Yr2JfC/8Pfg93 2vc3bb2xMC5EfwF32mAojA9pWm3Ln2ouM+V8u+mv4X9RP6oxgmooDfvStk2vWN/2Nfd5ma/70957 wrthf9re9LU31DHBKltnge13T+h30xDsorD+pRPhGE27Pc0Eblh2qQ92t96lYJYzm7PZjTPKOXUq w1jidIcN4bN73sSUvIwXsZxnc46TcUH2ecNlkXdERmsOiN+OdtBc0CTTibniPSd5KTniXnchObuB 3LmAeHeQ+LWD/13JMjruUxlG/B7OvXO6t4P6Z+V6YmF3X9hzO8lty4lRf+Ee9zviZ1+YiW/4p33w fY3t0zTvan/ufN7nm5ym+qSv5jGNt1kZxJV/SNdYL+LvG9I/s7Nc61fJQHzrwDcSmYepT96In5E+ +NEx6ySa7BJ5YaQk3OEisdHSwX9U8pP5b5UM9t6WUZFN5Mn0+DzKn5F8b7vkJ96TybH7ZDLznx31 HWkt5yVBjTX9HH5t9w133c+KYIr6rP4ajTaKWN+A/kY7+YeIzz8mn44kNw+XXHwsoN6E2E+Zrw7S L76AfD5byjPPMg40qP9nGe1NIOdG+g4dgEbrH7vA+E9IP/J/R+8xuS7egbV6TCSyqjeiOfBPM/79 MtH/lLoPS0ejHTYYbWds8htrmMtamcwaXEzXNZGOijSFf4Y1QnNFfUTjMXab0Sd9bR+RvVxv3CW3 ktt60bfRHa3Y0Kdj6NkbGbfVs7GjUhYbg10oNXxjindAatztMiX+EOMqlY6qz2K3mP5maY729zJP f5P+9owdxt4PO2AioFiD5ZS/Db+wMWJmWG7OJmWX1tvypfAQLAn/1/+C74TPep5N/FkS1tHfpRf0 LiKS4ageDdGYYOLCA5CfqlOZV9VzRS1ss67P1fFf0UbrcwWrZ5izX5aih4us3m/XWh17KrIpOvoy Sz+Fqu1CG3xg7WlrG3WvqdZLtym6ulXbln5N6nd7zpLnrVlXt2ojfd2GHZGuv9u0abq9Havr3T2y maEG7RpZ6ER5cYrtlnp/SrdGV2+VntrW6vd5zHvcu19ubg/t39wDv0lMBP+ixZZbfd+CGDtciX90 Od738bMd4lOoB5lvtCBbMfcCQ/BmCHdJQ3BCQa+L4u9sQbZi1r4V4hniK5kP0xfEPwjxBpCz2iH2 MfXnJsk29492iOfwXciss/RMkq1E8x7NYzQvjO2ijjvps+0/+u7nXcfPuy5Xa9zt+Z4Ke/kkvGqt 3iWyW/Ob3Cixt+j7OXidZ2INdcWSbffOBThnbSOc1bileKgs72fJ+qZNi30wSe4wRGtSb85ot/hd 9EkWIZ/SLlgRQgxobX50XR6lPuo2tgEWS6XVXif9L6JviO9KFPsSu6RQY4HGUY0tmRfwVYgdr8ud Vu8dsdpvN+c8R/WSJ0GjjXdVlOWbmNCAPzeRm4G+HrEctayw2q8juNAJtsOWVNwh6DPg+Qb6Y0aD Z6zeLrDv0PRiWJ707Qi+XGticKH4/iZAN6D1xnF+K7yN6EZw/wToBfwd6BbLNd6HvJ8gzqM/VC+Y szAUW4u18J1yz+X/6KyMkqleNfoJVBMZTVrFN3aF1sbZrhon3W9wF9lFmznS2X1WJrnvi2/60W8c EU91kbuUskPiu0WMW1kGfSx7oB4N/T7z8QTPR2EwunUtdhW8Behttx//f4DVOtnwPeocEN9odOVX lM3B1ll93s3iW+ZbHb/T6vblVtOrnq+w/MhqedX5D5t6fYyuf8r2MwY7F3sMysU330vY+lovqlPZ XMc/h7auI792l/L4XOZwbLA34wy+V0sX1vQLUMJa631ot9VR9VAFG3m/4LwqSxT3PskyvBbsdTeA tf7txLgG7hgT0LOvsjc2Byf8ccS3UzLCnyE9vSflK3ynEohGTaxvcJ71m+HVSK+Md/Hl3WCntXtj f5QhiRWsOyqLsyKRdbYBNuOmsMw8q3rbFioyPWeRxo05cmNsLTpyrdFWGntm0Oa7nLkCo7F7g+bX Mrneargy/FqBvcHs8UmSQ5vV9vyu9nOIK+wrqwNr4AVntZh7pFPHHIyWPNtW63CfCB6x81fBdzf6 w2Sk4gwKXlZ4LlV43quk/H9V3jmD13kPEFeG8jy05TtrWWW5bF3jw2SM4h2nnlIt17ncU7xq2py6 8nusixQrzjLe61p578S9JRNtqW1nX/ndOSX5ijuTOZ7Z8p3+v6Ykx32Fd85wgRLtteR+bmv8tcFp E3e3SmdieE+e45Qdd9cEn7klwYfsow7E6L+bvSTSn3p55JKK2EHi71Ti94OSQ5scYleJd8E8F9nv lXG/m6paWnW05geN6xpXVbeqJnW3BCs1xqlOtN+f560D2qvGt1pD/xth4uz/2C+/2CiOO47/dme9 9vnM3Z5tMI1DboWviYOx77KXYNet7Ds7KTSJzQEOqnjBVnwBg7lzz5ekpDR3oQ+VGhLfSyPRPmAR 8oc8BLPbB1PjcA8obV9qhKJiSItRk/4ntkv/qVWx+53Zo6CoERKVmqqdO33m95vf/ObPzsz+duYl nPl/iXcD51B+R+OxSMSVGsSPx9z4oxQ4y6+rXW68QOyoVr7rxiSh/wRvw95SjNrtxigRf76z/Bb8 16ivuPGKIf4o09wP83gjVl0ScrW6vxSH8E4IDoEOsIO/I0sllkchT2Mezoh4VV2Kg4+iHnR+bxHn m1Ey+TsIP+t2ZyV8/yfALDh7i/zdDXm7M2GpDucS5+Pl7ENai710F/s+Ysx2cXeLlJ0mzz/vXESr +PdaPyzuF7233EXEGZ+vD7/riXXid6c67MWjtPbjdwLtc7QR3842nD+q+HcL8/QueO8WudNlufbG N7r8y/iu8W/uS+Jc0cDPDvwuxs8NfByIt8v8HHTLfe/GPU7cM7DGHWXN1MQuYw8uUQLtfh5sAQi9 SzhxLh3j8H2m30fr+VmGS9j4mWAN5O/BH8DVEr8G2I1LC65+/XviDod5uXEXQlxoQtmo/grsv8Bd aRLnopMUEGeVZfEMhziYk8Mcbhf/Wjfe0/DtUQ9++mgvfzL6sEv52/8+la+7VGkuK47exMCkB2L/ mhr1JrWoX4dVW33+JvWnJf9trNkgkUgkEolEIpFIJBKJRCKRSCQSiUQikUgkEolEIpFIJBKJRCKR SCQSiUQi+T9FIVqxna7RF2iMdFLJoDBtJ6p4UT1LZcgT+ehtpIz4b49IuV5OP0ZOIff3kNJW0hmt UfaVdA36t0q6Dv2Nkl5Ou5Sz8FQ0D29TbSrpCrWr3y7pKvnUmZLOYP9ZSdeondWVdB36lpKO8bAX 6TiZZFEE/zZofbSbkpA9lKYUyNJ+GhGWbuQy0Hk6APuQ8GhBSZyG8TdpK2y7UD9LoyKXhEzC+xmk g/DsQ/k+YTWpF/JZ4ZWGbQAtmSjlJQMgK/oYhA8vy9Be2NL01B2Mj7eaEi269Z5Abgg5PiKTtkEb EDm35xSsYdGCKdreLcZv0pPIPY1SPq4h4d1y3LQikTazb3fS7Emn0tn9I0mzO50ZSWcGskPpVIsZ Hx42tw7t2p0dNbcmR5OZZ5KDLd2PJ7q6upr6hvYlR3uTz25N7xtIJbY1d6WHB3v67rxQWE2YTWE3 h0bNATObGRhM7hvI7DXTT33iMM2hlJlF2ROpoWxy0NyWHciipYHUYDidMdMoyZhPpp9OZTNDydGW /+BW6abHKUFd4t90y8Zxt83NTZPAEjbDJ41WBzGSPtHWLizWsNg4d97Op1Hzf+oFOdlnTmpVTpXP 4tKuqbMmNa/TaAb9cUOrpjxQyY+0E+wETKQKxbRq+6vR2CRExhUpV+xxRV80dhqOj1J0uahVO3Wr LW52KqusPJcVHp4P2DuisbhHCyAyc78AHkVIOxEVxT28lQBtdK3Ow4+4tbpcc0fJuT0ajIeQN0EM jIATYBHoGH2AwqAAloEmctwvB8bAOLjCfUVrFVF/vF4zUGKIZzcoCMKAUb8I5hMi9WsVmJUK2gyO aOWkaZU2DQdPoRHmPCJGypymFiHtxvstUWDfdbc1rTH1MN1HQRgUe1W9KCG7q6ukbGhzFWddszUX r9SIFoCqkaZQo1vLaWyxFs8gr7Al8isKt7K/O0YtemPXHX+NFYsb7K+UACpNsJNUBCql2Z8oB1S4 n7CbH+AdsRNOpc8y4L9AJsgDRuNIFZGPAe6/4NSs4s3/yvYHRL05O/KgqzjGaisRr2U/xXh+xM5T AwXZzyHvgfwB5BrId9kPaYUY5zHHb1h59Pcq3F9l++l+FL/GnkPUCrI32fNUL9wu2j63n4t24zor XsneYAeEyyj7Cj0IOcz22lbQnGLH+H5kVx2Pl4/vqm2stKbZb9heqoXXh/CqC/qnWYrCgD/JpONZ YRXiVWwSjzmJaQlijAodEWmMnbfREPo7zvK0CmUz7AVaCfkWO2ivDBan2F+E2595K+jvKHYMF84K n1WMe9hRvkPYNcz4NdHbH5172yyK38sOUQSomNQPoH3AzyRsHto8lmkeSzOPpZnHKOaxaYl9hJKP 4BNml2mEvU8FcAS6hib325jBU0IJNVqn2NfZAcyEMYW5U2B93vH4+MgO2NU1wu0Af8E7p9kF2gxU DH6Wv5HpKfayeJSCs7qeV3jP9lRh6r7mrgUqPsfXYJrl2UExEy+IGZh4B1nsf/YNUXnZqQpYOax+ H7JppGPgHFgAGtz68Ax9tBMwuCccn9/yT7EdovKXbF80OM024dE3idnaZK9cK8a8saRofrv+Husd rlAzjlmW5tN0OxzcMsUew/7ZzHrtwSDGvsVGu7xir9PWbkWmWK+Yi1472OCa7ZrPCOWLtsfdV91O ZYCP5GHh2GRX+IS5qfRKsnVObZ0VxD5tF08b5Yc81orla8XStOI9iYrFsByjGrt/kFniiSzqB+Ng AmhYY3yMQQJcERY/24DH3UDLgGFtN9AiQKhhD1AnGANnwBVQJqz9QIU9gh76kRaAihbDyBtIY6Af 5ME4KIJFUE4zrBn9NMM7gjQPJsAc0LBW6zGO9SirZiZdryAKUk49HGtXcpRTcmqO5bRcWc7IBSpi D312vRXbw5MWnjQiae33jHjyHhbxxDwJDzM8pkedXC7a5e1RiFi13h691PPbnr/1sOrWgl4oV2fi VUqA5sACYDSjGMgZyBmxb7KZjrmOhQ420zPXs9DDZi7PXV64zGaa55oXmlmsp77dat2ppJWcMqZo QSWsdCqbFW0nS7McG2NakIVZJ/aC1u8d8ea9LOKNeRNeZnhNr1rwjnsnvEXvOW/ZhF7Uz+lX9EW9 LKH36yN6Xi/o47oeLA+Xd5bHdG0x3q2+j0kdRzoBVMojLQjNECVFpOdEviDy/UhHRD6GNCG0BqQR roEGtHUJfnmkBcD9eL4BaYTnQQOi+0XYRpAWgKpejN29NhKKhVQjZIZUCimLIeVc6EpInQgVQ2ox 3q7OilHOYpSzYpSzqDkr+p5Fu9BAA0Z7QfhdgN8F4XfhH8RXbWwcRxmemUtyGzsbO07kHLnYc75z tpfdOqncGLsNXt+d79LCdZ3EDnDXmMRx5Y2dWKndO1tqf0Q1UgRVVH4QRGsXkpZKNGposzuukssH yBIC8aFI/oP4ASRGpAIKQnyoRbSAeWb2GrfCv/jDnOd93p3nmfd9Z7x7Owed9FYbG4KdUF4K9oDy ErAPSI/9XCQ669Jb2UuIeBT2Avod9BDZDduD/qS64lLBXoJNsbn5++7HC5/NCQPfkYB4AM0BbFcw /4lt7UfTdWwOIecQcg5B5BVH75FXywtsVmSldlZ0B/Dwg3fSnXiLylJmyWV0RvbDXlDebtge5V1W mrp71x7skvImYF++N++o8jjsh3NDbA6fWXh17BmMPpOqZaSxEb/rGjZpDRV2XYw18Ap7SyTrAfMB CAnpzSyEvdfpn5R9U9kLyn5N2c8rW5eqTej/SOg/SOivJfR0DfsMacXwn5X9vbInUhtb9d+16j9s 1V9t1b/Vqt+gvyFxEC2pbXH97bj+q7h+Na6/HtfPxfXBuH4wrj8Wl6GSOO3prElaekTZ7amtMf2f Mf3XMf2nMf1HMf2VmF6M6Q/HIKd/xftUp99Q9gVlO67u0fkevWmPfp3hm4keFnVk/Q3G6GGih2qE afNKaL0C1iKcHYDtwkkDosLpB2wTzlOAzcI5x9PrWR31cVjhbCP1NYkbhDkDujYATZhHAGuF+RCv 0H8LMwH4QLhNgPeF2wx4T7h7AO9KuEn/RlyGMPQvwj2P8PQdkpRh6W+JwS4BK8LpgfpqkJ2+RWy6 A8MCpz4p+44wURy9KMwk4DVhtgK+HcCrwuSAV4S7C3BeuOcA3xTuXcCcSI7LeLMkqeK8SAyFJeFE QU8KR0aYEM5uwJPC6QCcFPYtwJiw78qpx6lPcWdTl5iq0mPCNUEfrS7kCySp6EHSoSI/Ihy5Jftk kLROc9WFZGmvPPPRDPVVlJQwH4DMFqYB6A527lPCtQBdIok9pp0ieR4798lqgp3y/3OTtqIMGSgh zEsQceHuBDQLNweIypkoanM1awOxVVGbhClV9cKM8e/RWuKqiDXEoHNX+L8Q9wO7Qj8n+PupikYF /3sScIX/0Rnmf3AqOPHyd/AIX7rC70B624abquW/NO/yX7hx/hMTilSU/9jcxb9vPM0ryRt83mnm Pgrz3GF+2VUR3jQwTfCLyQqjmP2y+xh/0bT4C0ZF1vBViL8kcyDQGfNp/kVjhk/hVig7z/GS2cQn kkf4iaRMtJWPmf18FAs5jjkj7nF+zDzHhzpUxUfMW3ygQ60h76oVfdpWxKNuP9+HCkD0SAIV7MV9 2Y6puzpuyD3CSaV3/hb/bOdNhrcwfRb9qdSu8HfDp8PD4UPhDN4394V3hFvCzeEtWoNWr23UNmg1 mqat09ZoTCMaYVsqy0spi+Dba8u6egnr1ki7Rvn1TFoYeSZhVGP4oeVtDuVZfiDjdVr5Sni53+uy 8p524HDBp/QrRZr3Fp4g+eGY995AokJrDj7urU1kqNeQJ/lDmQjEHvtyhZJDhQpdljPORL2G3sI1 Qun9Z56PStx35vlikTRO90R6GuxND+3LrmKGqjaXtVZaxLI+dtXkfT0/UPBebyp67dJZbirmvZ0D scHCNTbOTuSy19hJCcXCNTrKxnP9cpyOZouQ7VUyYrOTkBFHAmRskNhShvHBj8ioj+Gsb9uBaD/1 pQgPzX4lejwQ9X5UFDpLe5WoN3RWic4HCU3UgYQpCZCtHSemSmiuHVeyiJT5hoFIriElfrsBgW+0 K/rgCp0M6DcC+g1JVyhd4TuMoNokMVQGgyWhsf6PbSTzP0yi893Tpwq5kURuKJEbQR/yzk6PRrxn h2Mx/9S0JGJeyBgafmJU4rERbzoxkvVOJbIxv7uwCl2QdHci65NC7lDBL6RGsqI71Z1LHMsW5/tm uiY/luu5e7m6ZlYJNiODdclcfZOr0JOS7pO5JmWuSZmrL9WncuX7MzR/oOBrJFPsHQxwntXW4GkZ irYUM431E7Z6dPa2RE5Hr68h9CKptYrehkTG09El1ZZuS0sKj7SkNmK4rkpFTu9tiV6nF6tUPYY3 JTKkHMmNZfFXQiuXp9Cwx6VSsNeRgChbOcVDUIZXVg1K+LKX1GiVL5OplWZZgZaUrN6C7zi5yFg2 ikP8vDx3W8USsawgoWUR5MSq1UG/UR30a9c1Pvgz523nXSe0oE74i+hL6oS/gNP9IvoSTvjNoQV7 0V6yQwvOorME7e3F20u3Qwtti21LbaHOagUyVZGiwpXPlFWaksMWVatV65aFoGg4ctUfbkNJEWW1 MWjBuJpqIZB1b7q14pQCckpNCUZLK/cwCBm+PGX9d6uO/keAAQDop9D+DQplbmRzdHJlYW0NZW5k b2JqDTMxMzIgMCBvYmo8PC9PUE0gMS9CTS9Ob3JtYWwvQ0EgMS4wL09QIGZhbHNlL1NNYXNrL05v bmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZT4+DWVu ZG9iag0zMjQzIDAgb2JqPDwvTGVuZ3RoIDQ2ODUvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJvFdrb9s4Fv3uX8FPCwVIFL4lAoYBx0mKnd1Od6de7C6KwcB11NYdPzK2MkH31y/Fh0Q6ftAW LRSuFdK6957Le889/KN3++4jBF83vdvHBQT3q94/e7fDdTn7MpmWoN+//QBu/z75sXopwWBwdz8C PQiqfwj83kNgBqrXUfX63bh3O8K/VTvjL/JH46n81fhV/gfGG4Bg9f2/amkNENYmMCAc4CzlmcjA eNHrQ4juBuPvvYdx7+G9dpXyXFqE0puNk/CUgYwx+X8uHzEFNyRPswyDddFDmKRQLul9uQ4Z8/Y5 SmEmzD7LUkaJu49RnnKM7T5PBeTefibXcW72MeRphjL3BzTHKaY2AEFSzDwDX3p/9JDJoELCqXxB kFwIBqaLHkxZTivYMi75f4bAL+/kC68yg+C9fOu7/PwEPv0KwZPKPa5SUpmTr4KMpIJQMO99lKfY +NFJIRwy0ok7leM8gzTvwp0+MiQE7cSbKoCMQ4K6cGfKCYpucskqdF04ko3PKUqzKF7yTPU83OFF NblIZe0TkZHWaGRlH2+wWLAMe72F5brrAp3Xz7HQGe7dgc5x1wE6jz6igdOD4y04x1sX2DyyigXO Tr0d6Bx/HcDzyTEWPDmzM7br7Fx3HaDTXNyBI8nFLMvTPIqXw1xMBU4p5jmUPtuiydlRLo4HK4iL u0DnkWMsdEFc3AE6jx2jgQvg4i6wedwYC1wYF3cAzyfHWPCCuLgDdJqLO3AkLVMhaTqKl8NcTAhJ qSBI0PZokGSQY2QcD1cQGXcCz6PHWPCC2LgLeB5BRkMXQMedgPP4MRa6MD7uAp/PkLHwBRFyF/A0 I3fhSeaMEJyKKG4OUzKmPCUQYtFe6+c8RdLMYYaMhSqIkDsA5/FjLHBBdHx5cB49RsMWQMYdQPOo MRa2MCq+PDqfGWOhCyLiy4PTNHx5P5KEMWVpHsPJYQ6uKItwzoT8SeuRgtFRWRwNVhAJd4LO48VI 6IJYuAt0HjPGAhdAw51g84gxErgwHu4Cnk+NkeAFEXEX6DQVd+FJkjHCOM2juDnMxjKHhFF5Snlr NBSmEOEj7BgLVRAZdwDOI8dY4IK4+PLgPHKMhi2AijuA5jFjLGxhTHx5dD4zxkIXRMSXB6dp+PJ+ JAnnKM2jONnLwR5bxfK2nxtd+ojlbS9ZuQ0dzdle9nAbLJa3/f3slXwsd3sbTJZixqqqr+yrNWmZ gL9FUQASYIpxRgUhZ9qHgGRplh0e/W0ABA37S+Jw+qYNjqC5fkEcTke2ghEwwi+Jwmn1NjDCpvUF gbgk0gZI0GC+IA49kS/ooOI/JA+rlfWgGdzeTdDwbe8mZOpG8BIybtu7CZuz7f1sNcrtx+fJEvT7 g8Hd/QgYgwj8Xr2Fqrfuxr3b8bhaG3/pIbOvBKMsd0qraBgYL3rJv8rZfFb+uBp/7z2Mew/vpbUt 43tMIZyp2vPNfSwnZXGGMc5UhfnG3hdlsd6ANuYIbsz9dbkpJ/N58XS6QSyvIhxjL7xPyfhK4GSy /lqU4OrX8U/n2nRi/JT8/LL4XKyvUJ6A1ZdWZjGMkEmcCdUt/sH8vCqLzenGaM6rlkBbafyl2Kxe FOSptHo6Yl3UkKWCMaTi+/D7fPJttZiAd5MN+MsZsJVJLpuuNvkwL6blejY9agvtbxQZYiaIsMWT wWQlC/IY4hH+bX/zcSnhrc0+lFMCQsIGh2M8bJAL1yDB0ujDEYO7QEv2Q1UVOpgTTsg1hPBICneF h4mQ4WXMsyfDQ3fyw/UHPspvYj9n5KCpdd+JysFQOhDyO5ff0gGVjiW5Q8bN3yP5jPTfLNN79NF8 5Ds0079D0gaiOkg/YL2v3ofGNtO21DrUdpTt3Oxt+YatQFfVvgWaPhgAVANmuAlOBTU0zjO9r4KR AFnegFdrNmii15SdkQMKOUCxtqGSNTSf/JRknV6sTQ6cbkoWmjMnyyfw9GM5Wcym4FkSwGz5Faye y9lqKff+nMzmk8/z4hjFHM6833KU6eyoDDCDuCoZiQ4hZ/1Nze/IYK57ZOfvDpWULW+h99QaM6Wc Ryk3KQNrMuzvrxG3eZxCZ9ywXRW1qlPaNKBtTJst28C2eZlFws33qEFqfcHMZJ3rjFVLWzGcwdsN fOpTDDcRjgzVOJ1UeauismcD70x03NCJaKKrzlJlzqEgtW5Qq9q4b9DbrlPPuKEvOGqyd9Y5N6Pe 59JdLbuvEBE6vZVrvy6dJdPVIrhBWZoTZU09MEhSmRwh7WVyoFE7d1RfnZEXBkWKhbJHvPpHD7qu WT3FdfaxOVFVqw9Nos6rvyY9vm6wI6k68vp5pP8mhn1tJ6nucY6qXX1s6w2k4VbFp4b7g3HMG3qo 6wQ2pBQUyMF6cfkowRBdkSxBoFhIhg+Q4QcMO50uC3G9LjbPq+XTZDk9456kdSlBUgwhLcU/LKXN FqKUE5jmHNITRelBk5DXJpPxf84ILqPqCuPGluBrRmiAfNw132XCWKUePYPkWhb6uXq05nHHolFN iq8tn7J2clHZEG6Jm9mPNAfVvH+GbHyr3lrNc5S7iYgqA80orwRQDfiQeKn+vjN+nEHnSQlHZNkE aKHTKglO5fcbUHQXKFfZMTttWzGp28lVLRLN3VjCJ9kA5X1DpQe1wLGpcpDqnBpICEcsC+3VraGL kDGI5S1SGINMHG/Ut7FVhMl4nsI8q2cMMQ3HdQPcPepnNW6HfqNCETRXdhM1Y7z2mzzMi2kp7w8t uJrxLBWY5ydy9a6qaWxSUtvs62LB9PQ5ainbDTGh11zwlpTtGWTXmLWmbC+L9hbBtzu0UWKKxoZG izuauengAcmMhrL9pTS8aG4clv+3bzLH+N/e+dDQUl+rWwdjzD3sU6eGvRFUReJmQxE5hAET5pxJ 1YaQ3epWt0x7O0TNvciNpIrW0kK9l9nR4N7+3p7zHR+wrN+gJzuQVqp+26Ydh3VcdlzS9uctu8g9 b2Eq/LG5WdrqY85AVNOAOWc3ajLn3ihVpVJ9L3FvmV4Wke4ee3NV08hkD9oBHJKVM8R9kwckGhIp v01K8Dqbz8G3Yv4MFpPl5GsBNj82ZbEA89XkCTy9rGfLr+DbqgStiAb6RMNs20C/XWptRI0eqltN D23i6RNjwx7LY3NM9fHt0T91W5qWrVNvj5E3bfpWv7UqRCo84jlbCeaGDtmW/D2kBvcqvVMFWhtx 5g6d/u4ZsYsv1PoOcGqxlVrcGgWeKBw6LWkyjG19qu/QVtySdRSnkoMqXSRSzEw78oBhvlvW0Ryl SDJ8gKwjCNb3MVsEajp5M/1MmUe5qONIPi4m6xK8W8+ejnHHXnMsa8zdF4vVclOuJ+VstTzbImW1 xU/JP9ZXKE9W36UcPaYcD4lRmbpUCIJjilEqBbO1WamvUVV4ocV2A1NJCmA8BebhFexyQakT9vur G5mLMQiPGioH+4wT7MZPsJ74J3SqBIEQ0iDUw24/2Ml95WioVPsN4/2T7nCHwcC8dpL8+79n3Fty WcjyTuBWSoLINT3rQiDPDVYXAs8ab30b8MpYKf5BRo1WoiNfoVtltotNyHCQo77PKPUosrrZjhu1 PkCib8h2NODVbaO2T7bsOzrIjio8dMZX3hB2jGHNc68LrQxwpYSj8ly96kZYzTMrLdQ7WWPH3iK2 pQs2cqbKiuJoO5hZIxjqZ75DLHgDvoVidJnoUzJb/llsytX6CsPkZvW6LJ7AZPkE5hNJpSKR6vH5 5fN8NgXPq9diDV7K2XxWzorNCbSyKwSHqfrOldEV8cK/LrrXE0odzQR1iuvjYL5gV/bu/SP20kmd taGjPB/f2rGNYzVeu2NwCDUpX1c3r5MfYLpaLF6Ws6meiZ+L8rUoluBpJsfk7PNLWQRM3gMeHWqV J/t/2qutp3EjCv8VP2Yl5HqutqsIiQRoH3phxb7tUwpeQA0JckwR/77H47mcmTiJM9M+rJIsyfG5 fpdNM1DvRdbPH4zCRfbYvPbDX+12Tbe7UIvQPTdJTgFDrcGQRYA/gZeyIk23+qQ8HSmaQXdZQXyk Hy3kp99WYIhmzebLxDayWp4IObU3rOI+1xnw1ftFro0cHpfK1vUYp3NbeGaTo10fXNGlKKcSgQZi I+FDCLR5LrB0n0zPY90o0UE0a9BwLeCO3f3+IOA8IGQPPy+bh/X7I9zDyyZ5RQHNPWmTLLYPGx4a rLb1H9XwfRWbuFjWq5gzoQYFIwySK5hXYcGnoNKO2/KwK86wnkDrq/5uflcNVhUzpIqv/2ZY7hDc n8V8xwtnnghXXTadx9NaHi78JBgdtaZYkvWHKNxIrdoxJHPrd8wqJ7Nu56nvsWQCMcR1N8xeU7er g5CZCsMir5h6mnojKFg0VlQZhwNn1MhbEnGyQMZ5LftQfurkxvVo/HTPZxDXJqSXZn9s2+75AxRT dv+6arsY3HGBfRXkY0Nkrwuei5KDMYETd72mJ1XDfpZFLjJGaU5pUaoodzfLP7MbUA1Pn6dVyIF4 pHDxlgrMPyPM12DjSpUe3IsclOy3L2Ux23ar9XRpCpa0qOlgSdWbEbdYZrSu7GM0XAKDTkx71IfW tHePxCtgJib4vTH+ZESDGw5GLmDtUw0kjmgKrwZ3w6iP01aWaIlgpYmVHhpcsL7jWEojoJEBR2h4 Nlxh3NkYMYrIa3c1w4raLr5sfrQr0B/vD91722TdNtu9v70BBGSrbKfu/7XpwBZtQKhv279TxDle stnHS/cMygac1moNrztY6vVgCbY/Mj1YnMAuSf9QACQ0ZqwGrc4JJTp2Y8h5Keem2ZPAZ9K/cv2e IGWZsEa81pLiFj8vRRbQkuMGmJ1Uu3qrd8tIggPCThyT5yh51QwojtSDpLd7jgSk2Xkc53DzkgqX 3oFbHyH161LLESTMihJNlqEi0Eb06ld5h+XwiqdmJhtulAcUpiFM/6NBs5EgVHFipZBrhHBX/93c wMiYQ2tq97++JPVcV4myHUZ3yhUdVQlHQThSJRCSV5AbxBY5qzToSBajyEiZSyZ8rvhuJdklJcZR LXxZC2pSivmw2A7oJ/vHoCApclkG5fA4kQIpAacKoP6y0rrnDoTPr9v148vmaZcgVyjjeSVlvFwZ iwl0ZWLOBy9Jp1Dg0aAEuCgMGuu9XFBYaBS0xw1axgattIDCLZ0PqEoWAzAVvVlbGqCKUARGV+Fn gK4qSbKuCrI2J61eMSkuNAAZHjHwbBzOwofmkBjV/x3gMssvBIEbgnCqf6dice06ucshEW4BLFAD VPClw3VFlFKPbqlHWTrOiSViqzKQwjHNMo00RGsVTDW8qhw4ziGpAf7Z9lPpp2cfineY/QeFm02q kdo221QhKTehQf6mpDRhDGbMqo9sRPJ6958X+rta5Zhm2cIEknpIZdjfE/PdpMJ9KNyb/phoxhM3 NMpxQmc2I8AWfu1rUG9Drpx0Syy8RAx46PD5JSvnugOHjh93rD/QqyP3kgoIN4fWL0bWuVZIDwLP mV2frZ1/uMBIgO4v7cRdG+WjpLkLH+6m+gyOKJ0Mn2P9xpgZO8dnJDaAVd7iq+pkse+ijBJGZ4hH FmISxswQDpzC0tUJHevaxz9sL6FK5WMYeg6i/KSFp9JrgRqgGQpxQzHqRpT+YsDjhexpQi8BXZ4u bW9RiC5JLwm99jFBvbfGJMm2eWK/7+jVZVXMHegaP6QmduX2UqAjdJsQ64sEywWkUuWk1gJWivMd jBB1zpgvhH/OIhSw644vAJleMbGH07EGV+Zl3T9GospljL+FRCXdS9iQQhRUjnTYNQYJw9lb2+x2 Wdusm9WumTq2oBMM7BevKwjMUSvKmFZwaEGpQhVjvVDoW020isd6gHXh7P511XbZ703XtNn9e/tP 83lq8Y6GRspr9hXaXRB6Mtz+GhdwVYTQvKg5VaHutm23Xm0es1+aTdOu1qdzPBC0KFzQm3Xz0LUv D+fXSyhMnbISkiR5Dafbg9Ds25eymG27PrsIZLMxq9KEnA8Lz0QENZKK5oTCZaEU55rqNe37ai6G flkNKffc8z8+w/IbavVcI8LVcA0LeSl6SrF0d4aF26O4K83IfPi+dUtYzHOkafTvQn2FLFwKq9c1 bqxAzVwck85nCt6wPqOSCvd73Lf9GgOxyxS9J/CXv1B41oVmBDtbEvC8jNSS9tleyy1zevJ1cviQ NlkOva3hcSyn0o5VSfCIlAWpc1pDPH9LMHeirrHRq0jgEQdUM8Ufu+yj+St7Wz3Fcqnguei5tCam OzNZ41j/DgDzEduhDQplbmRzdHJlYW0NZW5kb2JqDTMyNDcgMCBvYmo8PC9PUE0gMS9CTS9Ob3Jt YWwvQ0EgMS4wL09QIGZhbHNlL1NNYXNrL05vbmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9U eXBlL0V4dEdTdGF0ZS9TQSBmYWxzZT4+DWVuZG9iag0zMzcxIDAgb2JqPDwvTGVuZ3RoIDQ2MTIv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJvJdtb9s4Esff+1Pw1cEFugofRREIDCRuUtze dq+79r4qFgfXUXLuJnbXVlr0Pv0NKdIiFT8wFi0Urh09zPA/nPnN8O/BxfsJRg+bwcXtE0bvVoPf BhdX62pxP5tX6PLy4t/o4pfZj9VzhUaj63djNMBI/yPorwFBC6RfJ/r16+ngYjrVN6b38Mx0Dg9N v8N/aLpBBOvv/+lLa0RobYEiliMqs1wqiaZPg6F6M/0yuJkObj7UbrK8AHMYPLk1sjwjlCIpRCZQ kWeCcvQTKzIpKVqXA7iX5Ty39+E6FiK4n+NMYmLvC5kJzvz7lBQZ5dzdzzOF8+C+FBkR9jbFeSaJ 9O/zgmRF7vwrllERvH8/+HtAbPhqKRCYAgnFM6pYoZRA86cBzkTBtXpYHPwvCfr9Pbz2HaKIPsC7 X+DzM/r0J0Z3JvxUR0YbhVchqiRTjKPHwQR2snFXh0ZInNN+/JlQ4wIL2Ys/u3VY8X7iaVKBK6Fk P/G0qUUwJ734E1pfj/nJRJZv3bFMJnFXyAwDIfBLb17xYZmxHDMlWWdxhYiovVTiLN5eigvc9aAu qPRU6iycd6jz3Z1fXciVZOrq1vJSXeCuB3UBxVKpc51xhzzf3/nlhdBMJU8bErs2L3B3fnUBos/v zic0bHCRxFsMoXleZJzmBYZxsas2Jo8TOpm4KEL3oS5AZip1UYTuQV2IzGTqYgjdh7qAmKnUxRG6 B3khMlPJiyJ0D+p8QvfgziM0z+GRJN6iCE1VxhUjivdC6HTi4gjdg7oAmanUxRH6/OpCZCZTF0Xo HtQFxEylLpLQ55cXIjOVvDhCn19dQOjzu/MJTYtMJfEWQ2jGwIFQuf7dVZuKIHQycVGE7kNdgMxU 6qII3YO6EJnJ1MUQug91ATFTqYsjdA/yQmSmkhdF6B7U+YTuwZ1HaO0NJ/EWQ2gqtGdwBoa7apPs KKHTiYsidB/qWshMoy6K0D2oayMzkboYQvehrkXMNOriCN2DvDYy08iLInQP6nxC9+DOI7T2RpJ4 iyI05lmuKFNFd21cHSV0OnFxhO5BXQuZadTFEfr86trITKQuitA9qGsRM426SEKfX14bmWnkxRH6 /OoCQp/fnU9o8EaSeIshNKEKAl4UGMz3MEOnExdF6D7UtZCZRl0UoXtQ10ZmInUxhO5DXYuYadTF EboHeW1kppEXRege1PmE7sGdR2jtjSbxtpfQbYilcbefmS2qpHG3F2LtMk/kbi9VWmWXxt3+Mm8X Qhp/e+vOy0wJc5gwfsw98MDQvxJOC6A3o1RyxdiJXjBiMpOwEYcyvouMqLngnDq8UuqiI2oCOKMO v0Y76Yjp9efU4RV/Fx1xXf2MQnyqdBES1b/PqMPv22d041ORwNZ18hLVp7u7ierP3d1E9eUEbmL6 cXc3cX24u59W3VxMvs6W6PJyNLp+N0bWIEF/6beIfut6OriYTmHv0PR+QOx9jDjW2Y8k53o9Ak2f BsM/qsXjovrxZvplcDMd3HwAey3ze4wRmpv0C81NqllVnmAs5ybJQmMfyqpcb1AXc4w25v653FSz x8fy7vUGKdQaZCcJ1vdpOH2j6HC2figr9ObP6c8nG/VW+Wn46/PT53L9hhRDtLrvZpfiBMGkUumS ycO9+XVVlZvXG+OFMHXRCuTv5Wb1bDTPwerrJbvMxiJTQhCzwo8ffzm6Prw/q8GUVEy5jZZ4uILs Oba2Mf2PtfkTzrCiaDpH9ocp9LabHDjh3FxizBgG2I8il42N9ZZlye3mewKG5C3H/C3G+PURoYzY 7T/FYBOPXQnlx9iqNxG4HTEJf2P4zccYi9z7TexvuCYofOBPof++re9DCzHP6Pu8qJ8VV/ZdYAK/ rq8xNlLs0kRbCOOr/qbc2pb1cwT+JuCEjK1fZ9/e1/bMNbPGUXR67AhHrjHvhcPJFXY52o2ReVtL q5cwErldNqwG0/GOUFnpLozChkaALKFs2PxwSe++8N6n9tp4lGufxNqHNZBCb58Nr7OjQ0zDEB+t 7APR8SplWD6W82q9mKO7xQa+Pz9Xi9USzVdPYHJRbtBsXaJy+TB7KO/QYolmx7F3wHGuGsfz1ePj 7PNqPasW30r0db0CXm1QtUJ35bfycfUVQYtZ3s3Wd7CG5V0ntzAqbd3er9ZPs2qD4BvV2ldLUA+C n57hx8zIh27xpCF/zOvhJOTCBxK3eefyb2cJ2JJxOWTy1ZWsyRevZIsmn135bnMt322f5DYP7d/C PSPsusaNXy8nuwSBsYDKdAdTvKJ0i3WL4rIlRoTvmcXK1wXFMcwBwAXX2TWbIBo4uELW9joGgwYt 6tBuC48AhhoipFFAFtUQzTyzI9Nc4MxzsrHDrzyf1NoqGn+iRSITvKIOECEnBKMZW1otixY1czsx TmCecclF2GJvoeZPKeXtWv1+onF9bTsZBEtXif5QG1i3GX6W2/byaoI1/n1im/FzsXw4AYmNQZ/E k6/rcna3+W9ZVsfm0F1REvrAK1loVEfppqtqn9ulkY0mFTSM8gGI3Wk/eSv33AjkZoSiribRqpRa 0in9+PByQkhSCxuTPjch5Bip7zk6M5t+Jh2Z/Yz1tS612QLV1vjYy/vCfmxITOkW9ccsLLf09dpL t2zAqlUDaPK8/lb+QL+RLqUglJdlFBN6wlGsPjOJgmWYEnsQ+2gOYasH86VHm5tluX74EXEM3XeU ysEDhUVj/sqj1EGTotiaHN4eO+ftyprGFM+3pi7rVKX5CWnYGGQ8MJhHGNx57irAngrDNyRCdD11 BdthT10m16ltrOJlY9f1YXBimmw97ptn/eOGa8juNGb7iXnPw1E4mdjGXjTvGaSNvdOXrVl868GC dT5twRL8bRI7K9+bxfzRZcdwu6UNrwfWZhCNi/DO+e7AAbDbTOfXz6VFI9sV4hMD450+64KqbW+3 VOzxFWWzk/BWtefh4l4cPa7r3dy1WF8kVV7uCruTdse2TS8mC9zA62awcTPcRs1jh8WHZHJTNpZh J9aXXDOkV7ZJXnkBugqPOi8KmjeiHBi2WWPT3E3o+3a9o1AaIm4fYraeybbV55ftLBjpWcm84Z0q 7Br1rcMnuBEll/Www92Bx4Vly8PajLvkojP2zkNeGtSn3E6TW/oOcMKhp1mNB+IhDPUwdKzLx3K2 KWPnIzDEjFnzQzBoxJIUYJhnQLbasDylZwpOM4GJbDeL3eNjhzExmGcmT7N1hYJhscuk6BFvCENn p2ERiivDhazHzo+Tm3+8f/3KtoMSVyJTNC9eORceHL64JFubbpp7d8LwxZkevkSwxiGRb0WX2Ss0 ZwvPUFbnj2ooe7wNWDbYccsVr3CIce1Mefcc1U1IbP66om/TnNbvdqEwiIWTRUusOaIKO8WMa4Fm UYUHvdsWBAuvP/pt5uB0ZAeNK9u7i5RDTaeghAnqesp2x91BtN1HeRgwPbSYXfW6lxtFt03oqgkQ dIzXL3rLkF1pK5p0MpG6sot1Dd4Iiq28FsE5yQgz5aIyKnJZE5ycji0hMyI4q7H1/FBWaLJ6Xt4d 5+pei1w0Fm+W5frhRxcSijxTitGTSfgTrIrArzmyP76jXW4Y3brR26hnOx67RdhYDy3D3tQDly8A Wm2n86lvq83I9lFTNnjYzkneMdNNuNv5z5W8N+IHw45ln6saV42CNWhyk6C7/mJw4o61XSZYzrkf hF1js2ZbcB45OId6QaO4ObeIBi0mKAKH55erJgjUBt4wdhvETlg5vNOivTvtQ9Kt/eZut07EDSyD Y1gGRDBj1GVxhymJFBmluMbWZDZfz57KZbXqQBucNwY/PC8X88XX2SP6o1o8LqqI6XCfXaZ4Y/fd YlOtF/OqC8dAOAwhecqJTq/R2bysG188tDx7Bckk58EShzAWv8Wn0YoVekAMJeuTgbKDx7UdPJj7 dKJB6EQXiSl6ffRw4+B1UwjHpiN/jDQL1t+yveBTJ6X/E18uu43bUBh+Fa4KDxAIokhKIhAYcJyk qwKdBuimK42t2CocK5DlDPL25VU8lBRfRGO6GIzjKEfn/n8nKFDR6CDQ/q7ugrIvNb+bhIewUuQX BT92atjYYaPP2m1THzfb+tiidltWDTqUzUe1KpE4CpuqrZtPVOzq/Qb9rNrthPPQvTVPwMiuP/fF W7VC72IRVPvNnXg0Rk9/f8N8hlbbovmG89lG/AId2qKt6v3hDhUSo84M+EkHstiFzWI5j2hdvkmz TXl4F+8o0aret029E9/LHBzQj7M772SXEebPLDNVp+azEcexMVNCDMeMgu+YIw3bsXEG7C60bXmM kLh/VBjtW2ih1ZdgyCgR6o8Sd8cCHJn4wTiZmiRYJxfOyY4mwBgN8OfRnazdmIBzlNnjpnekdGOW x+6cTeC4BSWBuJn6B5xbylNzpagyyJ/5HHObKeCBOZ8maJgDneH+VnkxNSCJIa8UrBNuP0+EGsIj ysQJleCI5Ga8MjJhbJg4dZKc8oHUPRkuzHQEGtuCeBBsf1ktwkBPJTAn9tids1QyAQV99+yGabi6 g6rYJxEL/MsLOPirKsU0wlzZzkCZ6JQyYbFHk6GbXZmWukSWrr9I0NVK4tIDlGT2RymECr0cm4/y E33HExTK2YUCkcR4OpcTzEUnZ1hr3Uuxa9Ff1UepVA39qf6r/y0FAV8vZw5XxTvED7ck4IQza9I0 O3mcDsDAwVnGkzt2ln/H1FvjL/OsccKm0rTe1545uCefnaYQM3FwF6jvz2hRn4+Vzi21MCv0y/83 9BNhx1mXxWov2Gq3K9eKrKp9W+7XBySux23xUaLX405i0Puu/pQ3JapfA0iIwdaSC1clJNXJGOXh L4M3AmbEnYDEySJQw9geaaWWtLTski+kWQGLfNcDKEIKfCCXLPZT2U9y4rKvUv3e1B/VukQF6gGx 4N7muGqPTSkf02QelP8Mg36nloNSwFyxn2oIp7eaDQZ0tks/HwHZ3JxNWJ9NQ4idzmoiF4zDXhzS 8GmIvQhSrWRTnVhl08JFDyA0uc9Jfm/6NTMBL4NxEGqEiVSWjpA5ye5PqbOZrN4EhmKNWz73uldU +uRRk0+lGhYRsRBEoHEkFUxpDZsENWI+CGU9Jy3TELPYVW1tXyz1rghD0Z7mMjeYttmpHVTTg8mj 6SM7rBj2YQBXwfVUNG212pWXCnavLKIaOU3lwktdWdJJZRFokqXe6vyVqAnW5i1JE2ygMNBMKI0I I0xZehF/91iVmxr9XhzQb+cd/NIqSZzVp50AVSFK14fruJLK4yOhN2XVJO5sysGRS5xOgNWMRsI9 z8UZviMpvYAwR3kVG5HxDYqGDEVWaNHKVmYki7sZGPAnNTqaak21Wno9d7qV1GGRWTvqH9BwtjDP ZhbJgvRatCMI3GqzfbFyDDCaApVEM2IXDAYBJtqGl5zMT4xlSRtU9z4YpOGAzmYKwIr1WTUoAaDX pY4zQLDqLYBUBhF2JAwIA6DdWAup8oEWUp/td8xl20M2plFNZZPabE7hBRd2nHt17+DvemZTHnKT Cc/DC3luDGY5AOPcVEMzWwgPXDblt1c6MGRG6n6WPw5VO5UBaBJlOefCMItYYgxn2RQIoHmUYmXK WwTjFBCSAzBns5c3wUDIE/0QxQe9PPsufw5QfcxJRGVClJ/1UZyHzX663OMcO3PLYle91s2+KtDT ujrU+wDdl34mLM9vqfs45Z3NG+g+dHFG7vhFMn1K9z2D7I6E6z60KCMGixkuegK2gZUvXwD0Z3t2 qs2SDrnBLvVLtV5xhVypy3NsESKBskdBEk5ByhA+bswMuQMqG7B6/sHYAjoBE3UbFoD9L1mgX15P 2015H9I5Y/cuQ2PiIZ9VGcDu6vTUDqrhwrQZ1XZg1mGGu0vWcoXHLUFsgFnmpeFkQ/RBjc8xNyBJ AaypFDDQPEszSQAKiC2w/O7JfWf/Tj1vJocuHIBI28Q8Gy8BVnXYFpYOyrx0DN2cY0l/JJsTZlkq dpUhzDxvq5q530n3leuZfs66z3rPjqW74+EUcFY8UqLhwRCUDuKtzI6PqYnweVikblrN6lRzkLjN QG1/m2jCKK+30/u7+PoBDaAeuFpn2/qtRO/F5hz1ueh62JfwiDKeC6s0EkZthHghz4MJKWMCH5Nc GfQU4ObwBxfrjeEPLqsx+PtvANO48Z0NCmVuZHN0cmVhbQ1lbmRvYmoNMzM3NSAwIG9iajw8L09Q TSAxL0JNL05vcm1hbC9DQSAxLjAvT1AgZmFsc2UvU01hc2svTm9uZS9jYSAxLjAvQUlTIGZhbHNl L29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlPj4NZW5kb2JqDTM0OTkgMCBvYmo8PC9M ZW5ndGggNDg0My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm8V1tv47YSfvev4KMD7Cq8 UwQCA4k3KdrT9LSNz9O2OPAmyq5bJ97azi5yfv0ZUpREyjfGooVAsWxRM/PN5ZuZfwbnP9xh9Hk1 OL95wujDYvDb4PxyuZ49Tu/X6OLi/N/o/Ofp6+JljUajqw9jNMDI/BH094CgGTKvE/P61WRwPpmY B5NHODO5h0OT7/APTVaIYPP5P/PTEhFaSqCISURVJpVWaPI0GBJ8NvlrcD0ZXN+WejKZgzwMqioj mcwEUlRnhOUohy+Uo/csz5SiaFkMCGUZhp+qE/AECxGckCTDStcnhMoEZ/4JSvJMUtqckJnGMjih BCjO6xMUy0wR5R/hOc0obwzRLKMiEPI4+GdAnCstKqF0phlRmlF0/zTAmci5cQFYB/8VQb//AC98 B1+iW3jrL7h+Qh//xOjBBoEa9xhx8CqcMbI4mg/uIJ6NotI/TGLB+tFnvZ0rzPNe9JWxI1rzftTZ RFASM9KLPpdVWPfkTmHw9aIJmMCo4UnU5MqSAN6iBeBwijOtc0gS0R0O0EdMnaXB5dhsE5evrhd4 rbJOA89R8RZ4nro+4LVYJBG6so1sovO09QKuxVlp0FUtcAs8T18f+NocmQYf9G8ltkXPV9cHvJKS +9AElGzU8CRq9lMyE8BskgN/qc5wgCsOMXI6WFGM3Ae6FkOmQRdFyD2gazFkInARfNwHthY9pgEX R8c9wGvTYxp4UWzcA7qSjHtQBFzMTDUm0XKAi4nZWLHWsjsadng6Tgcrjot7QBeQYyp0cVx8enQB OyYDF8PFPWALuDEVuEguPj28kBxTwYvj4tOjc1x8ekWGi01aJtGyn4spFAbRimPWx1icDlUUFfcA LqDGVOCimPj04AJqTIYtgoh7gBbwYipscTx8enQhL6ZCF0XDpwdXsvDp9QAJUyEymULJAQ4mPNM5 U1rQzmA4zkDcAVZMhCqOg3sAF7BiInBxHHx6cAEtpsIWw8E9QAtIMRG2SA4+PbqQFROhi+Pg04Nz JHx6RYaFQQtPomU/DRPJgc8wxWBGZzT64CycDlYUD/eBrsWMadBFEXEP6FrcmAhcBBP3ga1FjWnA xVFxD/Da5JgGXhQX94Cu5OIeFAEXE8kykUTLAS4mLCNECk174eJ0sOK4uAd0ATmmQhfHxadHF7Bj MnAxXNwDtoAbU4GL5OLTwwvJMRW8OC4+PTrHxadXZLiY0Ewm0bKTi0PSSqVuN0cGLJJK3U7SCuo6 mbadLBLUWSp1u+s6zPxU+nYWGiSkojojTOWYEqvFPgH5DP0ryVAgNc5yKTim9Ej5GDGVKUX3Jnp3 GFFDwCnReHXUHU1U0z8hGq9ME4CJaPKnxOKRQHcwcU39hHB8jukOJ6qJnxBN2bxPqAA40khnnaRH NevuaqKadHc1Mc05gZaYptxdTVwz7q6nVSjnd1+nz+jiYjS6+jBGTiBBf5u3iHnrajI4n0wgdGjy OCDuOYyWMAcgBX421qDJ02D4n/VsPlu/nk3+GlxPBte3IK0lfIcoQpXNvVDc3Xq6Lo4QJoXNsFDY bbEulivURRyEpxb34/NqPZ3Pi4e3C6QUpikInm/ex+HkTNPhdPm5WKOzPyc/HSvTs/Hj8JeXp0/F 8ozkQ7R47CJWap7Ak1RpWy1hYH5ZrIvV24XxXJqSIC03/l6sFi8W8j1IfTtim9TSGKqpLrNw8bL+ UiyfjwBcCpOqETZePMGLhysE76wQYxtnJK+yRuHhAjLxENQx/a+T+R5nmCk0uUfuxlLGhhohGjUX GFrG6D1T5uYGY8xGBz3rtGGraJcSzmolw5ufD3glhADNpYRgbrZLZySEcDl6L4TFkhACacIxvL2L huCJUrysMS+wYCSRYCT4mozddeW+s+oavTmJKHgEClAEuob8nSTqHUg/wvi6pIO0BPNhjsCCwpXD pTDmYD439wIuYvwPcajOwFcB36HB2WcC4F7JkZAgR0h39tK9b86LEcnhGTe/jcv3zBnG3PPLRpf5 3ermlazouG9DCbVc++2h+DpfvBYPiL6jpQPR6mm6XKOnkiCBNwztTg8Rx36/turQ+unG8xUpsXJV YiXCpYkqU8ikTpg2cF1bP1j/mlqo5HHh5OK3+hTudRlrK+umjOFhX++H7rHDRYnQWuA8YK0at9CD RYQ49Ff2J/vPIqoyscpCWXmizK7aev2mbOoSW4+gYgEKxwbwSZ3x5lxltAWuyjP18wPgjZNMGZnf zLVxz5xN486ASUBx0bk1drkuHQje5FngHL2Z69jjlepcBbB+dulkjp18p8/wS0fAWAUR5o03bRQM eN0AsgaJqnhC4qwixWSTnuae+gVIPSe2CtL+tiPD6gwhpc5uoIUWPuggPYWLDN8eKRthxz7WQepA CrtO0rXbhFnRCXwekJYfaf7BpatsgFQpab6bM9idt894edaA6R7RMLP8QNh73PrNOvcIR9RjeXsg MBQLQ6QdwPbR6/YUOKJpN5b4Tdv2ZvR1+vnwYukkiixnVqa9AUdnLOcK8OFMSSdV6SN6vGBgIDGi PAONq6r+XM2q9GZkR+/j+mnjByFi2PctNXiwVvbGxZ/+IyLSgGuFBIuMUGIEyjokF+UAcHBK3hoY gjMtSHsAqfulq0+xhZCwx+72dxlJKnsd5c0Jw2UxL6aro31FWKZ1DiL5hqv4Ua7SWU7z9igTzFUV nXl0VNFgSW1dXBOsX8XDbIpgAp/dz492ENMZVQRWJEo3PCSO8RCH7ATntocfV+RdGDYcLrr1wGhD Wu6SLFNMM0CHN9zVNe/9QWL44/U1urPr1a2l8Fj63ibX69HDu5flt+IV/UYQxYQelEo2pOLM9E3w RJ5JAZ4wJD68W0/XBfp1eUby4eLzcvqEzg52sN2ihaxFD/8Y/lo8P69e59+mz7PpH2dv9wOhKsOU KWsy1zktTZ6cKTxcrKfzQ5Y2ufAeZ1jD6/fI3XxH29RwXqtxfYce4prabGyltyQrnkF5kgDAkLzj WL+DlHu7RyiwVzm9+QKlERYhcP886El07bya/7A/f7m5DF81e5dZP+wa0l5wzSd197m7r2Y3VtYe rjYIjIP1x96rpjfZubCaKb3Z1JL2uPx+TA03+CF3a48+zFbr5ezTy3q2eEb3iyeQNCtW6Pts/QWN SOlsdP+yWi+eiuXqiBJv1Ho5N1wv0Nfl4tvsoUAryyB2CFyhAvQCk8DjRuf6y3R9SPH+gDPqB7we BLgb3quhoJqqaBNkXA31rVWuem4ntRtvY5HN+8ILnNixZPDq2dgFvLXr2oS46bwBURw4wAfibTnV zltvMtK1Ltmcq0dOf7q6dEZXLW7ctLerG+e8CnjePDNOq7aq9vpopzrsdNbBic16w4K4RX6NN7DH KH7Kz+doWUzvv6DHF7h9KL7OF69PxfMafS/g+6ficbEs4hMR71DPtQyC4c0F7SBY8FvWUu6tk/Zs lTH5kStiY5xqSsXsPYyEVpAPTWjam0edDsKzjG9HUKUc1c560YSZ5l59iRHFF2UtBNOSKKelqj6Z u+hNXS9H7GWNGyQO3cBKs4x6Rj1a8Hi8po7WoFeaN9LU9ppyhYzjeI8O2s+FN1SOG8rpCpsHnbEm s9ZoysetblWln3Rp64IdEJ3HCe2UZxUxeslSBdUGmjoyFO4M7kqInAU1aFo8Y94+VLG3Y2WhW+C5 184rYlRN7dapIRowwqukKrTVbmDCWaVC0EXa+9mGMzs5gfJ9RCQq9sfezCKaVrcN+FHk0ywB/vB7 sa1qys99E5v9vIqvgtbuxEnGOYcbRbKc1r6xu5M6atVUsLsageHQ2X3V9Kc4x1DMMVTdk11qVdNr mUbHrpUsz1SpWG+4Jl6o7xqeCbWJJIFrwu3GJrKfwMobY1r9ixCf9o51leDwwWzw257Sx3gKupGU rI0rylFbJvLGT95cPPw/69X62rgRxP+V/ajAnboPraSFYLDdCxR64UpyR6H94trqWeDHYSnN5b/v 7FMjWbYSKQER+TWa2Zn5PR7uf3+1tOmUS2XMhARXKeRZvfMx9TIaq9QEbKsRW7HDajfQ5koRJcoZ y51i0HA2jhKbM+IdJZDNhPQmAjOxl1/6id5gKMSV89GYJAGTeJJDKuLseBeD7WdnpdFYYyT8V3HG 4ZR1ZdHjjeLRCrQw+bQr1mAJ1zcD+fZMFuNZTLnITGyZJqmPndHoWK92U0KKXIaQ0d3QrPZFUipO OWet5CKYpBGeFhaRGgrFoRj9QAejXWdkFM7MWkd1+rH3GO/By+snZBwNL2pAE/YKjN4BQvP+FTHf 1W2aV6x4fzvwhDqFytB4HP8lNyy3U6In8G/O+Y1Mo4rsj1UNlmwNHmz3Qgq4q4sN2Zbftx9PZQVe bIrYxQOlN9tvcuJEX9I50bY7tSAjuubtgmIOmkkgW8TanfSWyHRggbqB/UVXo4km30ZcDiHN1dZk opno+kjsUJOnQ1lXBF7XhWnJ/lgXZH08HKAlv2zKyt2SKdMvUtZuSMdc8cxaBUHPR9PIPiMFZyK7 dZKQTUL+zjL2LQkej/dRDqA/JeWKJIzHuQoPN1i/HI/1IknjTAH2IaxfH/cr8uXpn125Hlyka6FF EkJHX+tyV9ZlUY2A5wD0kGsq2BupoznRjzRmDO7WxN08k76ncO6fovd4blzGK5OmJngncJ7FTLML Sj9i2SsYoW8bhbL80gom+VR+wUdrtUxG3aJh5DL21smslj1d2u9R5zU85/jPwusc8cfCLXKHTwJn OedoLmRxzQJrHrtrOMzy2CR0g2H151ntV6ea7Iu6OFVkddiQ8lAXh41BuU3xY3d8gXfJarOBgT4e Vrtp2NYaN1OcppO8r8Br7mSKLULdd9TlTaOnEimb5gVqcu+FBrlmDhrJ0IeunM1jyCaBdBSofNsL NbwklwGIgsuSuUTYVvxcVeS+eJ6Ca1zJEDb6XPws10fy5fhcnKZAG6Saqix5R1nMcxFCRvefJyTH M9ZEevxzRKQAgajMSKQf2DQMxNF4Mllkt5oAi8CRjOC/OsS7azRbn7TQS9unx/xCGcWeWY1IvQ5E S2aQVrURL1HNs5O7scY1lKnnF5eZeCwRSC4uEdYwZAi4TSeUnzlsegNWtRXajFOPOQv3mew7YrhU S2ZPAHu8GrBt24I8GXnyQsqKFHuN8OXhO3nQPPDwclhvrfHIwHiciqrcgOsoNexP6gJaKkO5PRZM 9JxgsGvcdQvRremct2RzN4COmhN3ujL3KI2QHFGu19U+j6Cxl3qIZ8IO7rQBlCqUftuxRtRlyFDm yXmFIXPlvpcgrrogTMyJLM95q8VprDlx0wVnas1vPr0L1yKQ8YPP3EyLkcTJEg2IggjG9I0FRMVG YKFkCrhNh2qnyT45GPM64Gyvx3I+YFHOZSd1PiZ1bRKZDtWX+pSWdQHzEpYb4ba06tRcsjk4vT48 t9co8GqywbxuIIp81lKVPDyd/itehsTo1dCY6P+A15QNdeKCTiIQL1Y8Udb8Hcq62AxndiGU4E2o 33a7p315WNUA0KMlTWrSy1KRj/aSfTE5DTFvw3SMFUutFEEGf+ATtJJsR4MtHmk/A4TjcK69uDVk Czq7PFRwpjv4yKZPrLGaItH0LKAzvmyHvEyAPpyppzdKnjnysv73slF23q69VQZNoxHcACdVudTP G4nDVMZMSND6SR5T5adOjKIQCu7NhGql2I+E/cJnEK+vohiakagFjQBpU9AR7Xc0BRqpiDPGRNid cjcirQZ2IBycG39PKGN631zMW7tJPBkxrk3ANGsFhP3iizHYyC02opojRuVINAvg+D7hAkjhcK7B bTzMUv0Ih4d7PaIVqY+TkJEphk8YC9wkbQQtFsTmfS+As0aEn5k1v5kciXNvC7x4Z0jII9uALYVB w8zZknykKmsK7syo8zT6gT4R8/C0gfLGddoRNIXOXSEL933qXETa+CeJ4L5bkBF5y37oRy53SqFo d7T85M7zmKP0WUrXGmnlaDK3GZlKzfYawnmt7PxIY+A08vhM+nCwBTj3q2r7tCIGd4pd8f20+rEd wp7wHKof0XUEeSxys0VpnOdui1QyEmyZBDKAP5vstxvFo+K0Px5q8hXWElazqF6dbR+uQfiUpekb wfdqSJ6HkNG3xxHM4AQkzi0SfCJGtqPR1wjI61ONT07vr9JymdJFOpPytgEfs19eSnkZ5eXYEr3O m994Wed31QOPxgS8lx4bDGYgeSd7JcllKdfFFrawknDY6F0/IphgfES4BOMzBSrXpZOkPQpWQ6Fy aS46OI8w3sCmx/nUfzZjKrSn8boGcJbtFrHEqeGgvu33hcf8ZYg56VjQgvzlqU453FMNBbUEfNKh s3nTXW8GPKJT+M+UPWL98ow5IA6fOyHr2CNRbWp0An9EmQFmzxdkxhi7RZNHG+r1tQq3Jcag3GG6 n5YLmkSdinQD43ZP8pGuA6wCDE4O8UWsEgcuSmJc+X8A5KPGVA0KZW5kc3RyZWFtDWVuZG9iag0z NTAzIDAgb2JqPDwvT1BNIDEvQk0vTm9ybWFsL0NBIDEuMC9PUCBmYWxzZS9TTWFzay9Ob25lL2Nh IDEuMC9BSVMgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2U+Pg1lbmRvYmoN MzU4NSAwIG9iajw8L0xlbmd0aCAzNTcyL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIibxX a0/jyBL9nl/RH43EmH4/pCgSCWG0D3a1S672SqPVKgOGyWwebGIWcX/97afdNgkxsROhkNhuV/Wp qj6n6p/exedbCB43vYvrBQRXq95vvYvLdT57mN7loN+/+BVc/Dx9XT3nYDAYXo1ADwLzh8DfPQRm wLyOzOvDSe9iMjEPJg+9TzCFRIDJHfA/XvQrYLIBCJrv/+mryRog7ExhQDjAIuVC6aWLXoLQ2eR7 bzzpjW+cw5RLbRhqn2G3hKcMCKxSRCSQ+gJT8InIVAgM1lkPYZJCfSus0E8gY5UVHKVQqGIFEymj JF6BkUw5xuUKnirIKysE045lsQJDngok4iVU4hTTciOKpJhVjDz0/ukhH1OLSm8jVQQJqC3dLXow ZZKaEOjd6f8Cgd8/6xdedCzBjX7ru/78CL78CcG9zQY24THm9KsAUaZtUTDv3erElo5cfAiHjJzG n422FJDKk/hzuUNK0dO4s4UgOCToJP58VUF1onAyg+8knjQTGDe0EzdSWBKAW7xoOFTCVCkJFW4P R5d3k2PWDSxPZm9hxe5Oga52qLtB54l4C7rI3QnQ1SikI3BOQ96Ci7ydAluNr7oBF+RvC7rI3wng 1emxG3haugXblrvY3QnQOTI+gSPNxcYL7cTL+1xMFE0hp9qVao1G7m95uoPViItPga5Gjt2ga8TF J0BXY8eOwDXg4lNgq3FjN+CacfEJ4NXJsRt4jbj4BOgcF5/AkeZiokGzTrzs4WIuUqwwVO3BYGan 3Pe5sStUu6m4QlZduWvGjUePZYWsOsPWhBqPD63CVF1ha8iMR0dXZaqu0O0kRs9UR4dliIrrCHfh ZA9PUW0aKQ4FOwlRdYWqGU915a0ZTR0/lBXm6ApbE5o6AbQKb3SErSFNHR9dhae6QrePpo4Py/CU 9gI78bKTqCoE0pm7ZgzSmbudFFI7Zh1523moa3Xfjbvd56xS+J3521n5uiAFVikiQkKMrBf7RNsn 4KdOFJMrmErOsGL0QPsQELFXKdvD2F3gkZtjoonOUXs0jST4iGiiY9oBmAaae0wsEQm0B9NMZI8I J+aY9nB2ckvs5ohonHgf0YHmSGOdtLLeSKzbu2kk0u3dNBHnDrw0EeX2bpqJcXs/tYNycfs0XYJ+ fzAYXo2AN4jA3+YtZN4aTnoXk4lOHZg86MeTO/18Yh3ZlRCYfhUIHXG9LwImi17yn3w2n+WvZ5Pv vfGkN77RdmtuKkZLUwgLW4VVc7f5NM8OMMaZrbWqsZssz9Yb0MacTlRh7oflJp/O59n9xw1ijHWR 4sr2viSTM4WT6foxy8HZn5MfD7UZ7fFL8svz4mu2PkMyAauHNma5oh1EEgtlz001Mb+s8mzzcWNU cnM4UC2Mv2eb1bOFfKetfhyxLWpuNqqwdCb/OGMsyXS6XSTHy2z9+LrfNNxZ5MY8JfrI+8QLmKx0 MbUyyVhhMvnpdm8431rSCoFMpqO9JZScQwj3GBvhv95Y04nR+xKsYq4PIRL6M9Q2r/U3CZ/Bh3db VFI1lH+cSegyBWYb8DSbr/LZ8hFsFtN1DhaubGdLMMs34NbcuzUr94V9K77CPxcxPqbxMKY/GEJ6 pT9Sf7i+1rihfkZH+jdyv7GOgSZ3yC7dO2ateWbWm98mRnbdWH/pe8i/Z37r5e5d5mwT7yPcK3xx /5ua7z1xfh9oVGBf+h6VdB6MZ4PY7srcYwOMTLZhicYgs+uY2xn1O9sbMeqjEl3Ta/ex1+/uI0Rg 8PGjVSKnJCqxl9l8Dr5mmk/PkEoesnV2D6bgSVfWajmdg2xp+FYlj6/gJfsKnlZrfbBblhhB1chT H1VeomVRpNiorDN66aNsamPo64r4aNVqyN4PkRNlBOO6ZVGdhSxYG8KvwW6dq1VXBaTie18m3g8F UoecNhuta1cnNCAL9Yer0akjpsrXLI1qjHlb4VqWJxiS6DRTv25U3nN13IbxYMk4Sb4Cm+cnU2Vg 87rJs8Wnl9l9Bu6zp/nqdZEtc6P7jv4OYfHgk6nq4d9WJnHJ+fQj9Sb9DZMWaMvYHvryjtaVgSwP fVHmpjTHpT/Kyr0aqrXvykDDbYiByZIYEj1cTZf3ZlhbrJb5tw3QqZktnuaZycI5eJnl35wCtUuE qHHBB89lEdhQjZeRDfSWN4i2gfyJMN9Wr+mASMPutEy0uSaXAwn75emq65ENPm3KyO+HgVV4IKho 8EZrJQKF3+3IXdaV2Kgn1u/jkfu2z5U/1157QuTgMNKZKOL7S7uN+jJabTNU6ZjJartgg1DbjDlD oX2wwRAulTYYI/Ps44RU9N+VjrFsq7T8bWYNxjdvmKWSWNP2h0kwllwblzgV3BtX/ICzw/T4hhBH b1rR8WFEXOKOWr/kh/HYtZTgpskhf9du3MrfPq//zV7BbwhgiPABU5IZZxjRU5yeZ6zF/95l8zDD fHxKcPOGsCapkuiDI8y2BJU2oSxs6gRhfXIIPixJfppBlX0mGDYYZ7YxvptmeEfWikMdW7NpiYcW Z746u0z1c3OpRb2VimAYB9oNB7ubQhoGlFGkutw1mixSZBaodewFBTtaDjRbkv/2IQbX/JgCsDQt nK8qbbei06jSjIziwJPSS2fR1wyokbRiFAslGQg/aiYLqY3b7tC3+J4kFokwBNXfeTPw+Od2mBrC yoDTUkap4pUwMFImLe6F7YSBow4h6B/bv/0iyciHIdgOLSQqC61o7biH6ovIyhwuu5UQ8jBlYNNn HhaLgnUrhNY/pEAHnEelQoYehwz9QfPtfYIpFBRM7oD/8QK27Tg6xbaIdVOA6eCToGb7tHFnC60j 46SmwZClDHKpHZFUYs9TShwoQpSrVGDGnWL8mn/L1mdIJmC0Wj1tbO+8Tzx2WmaisJzcPC9nmxbC ZrbJOGU1YWuwuXdsUlbYTLA4oDkoTRFSmtJ9Vp4dAlbQlBt1jMEm+FwQeM4OkjSCPKPEBsk5ovRc 7DX4PkdFFvuuRbdUokoKKo5pbdiBns4oi1r18H40HlhbQQG8hmHpxwEaddbSdcxhmowpkngFsPRA IyoLlMXbapap8jgQvDrVBenaJkOV0SDi5iYch7wd60tVJYmKSMYi0EHk7fWwfNYyANEp6vtx1Oji ZTnU7epg2JashU0WG1RBU13FUFkKVAw6Hm1tr3BdqyZWdissJKnU68PbxcrRX2iau5s9aWJ6zmfz WT7LHIfeaTbN1tN89m+2OQcvs/wbeJpPl5tW/SLFqOTEfqn/Fm4IKSl1OsBHXqMRLVMUh8emkLjn SEYjKhkgaUQs1I+vqSI9Mgp7fPDilqpoGtu1SLBCP6F5C6chnJJ6UdnnpLwfn45qG+ujcBkVjHh7 mhBqMahWSDlz8+ltroske5zdHVIYpeXDOAmND+SC0nHEBbb3Keh6wFjfU3hNIlo2iPHxM/Qz9JlT rjU3HyMWphpsZQSuDT1gE/57N4vRIUxsEs2U2Cp71dq2ahCGkzC0CH/yhhEh+ntovFtF2mWXqGpZ vStJe0P6tmnkKeKKACJxKhRGodVT2LV60w1YPYCb6SvAEOEDulJt3fVXsYeEsHOB5Tls0GC9sYgx d3xUsciVsXaYxSIIjKe6iH1bPt7ks4UmhntwlT3NV6+LbJmDr6/gDBOcHNSgBzeURm6usrts8dUM ACoxQWYHWC5DEiFIOGsQkovPtxA8buqFiJ1pDMykQiEGmKNUVzcuZsJIj3SFi37Zh4ZOwNbkZb0F s0uZLJnQLh9F10XX5JZeRsuuS2dROxH0Nm5rwtvcSV8hJrIgwIrx6lu7hPz/rFc5rtswEO19Cl7A griIIgHDgKzARYJUKYN0SZMyTa4fahZyKImWAv/CgG1SM+/N+pS1k86tDVYMkk8/PfvcDgG42RRf 6DcLAjBkWDj7ApzlGIpteKqSDsv3T/8x3LeJtiYNnJJow9rOkXNX2CUAV9gxlvf8VKG7DguN/oFW zJK9Oa88PLSkxVmrPJ75BQFNLxMPfHppMsobBxIILjoG4ulFZgPEFyCD5CnyjUKPOfdUx3qltpjR U15uFDxlm4iwNtghQUWEFxtE3sm6Dmk4ifbm1xidy8yI/uSVw0d1jsaSofFcfkKb1Mjr2IixwUJ4 qBH6EnkwLlUPZ8llh4akSA65qay9wGMG0ROLU3H0qMeVCInhYgHkKOshkHPFICO2GyjWfFi+e9uN Mt8s0G0ZrUu5hVxuI0KQfRNy0bK4lVMvlhkR3IsZUbsIey6mop9pzuLBscm4HTvZJDxh6lyIEjmL etoOFHTBe8VhwVYhPTY7Y0A+Jt06xGp7Gx5wUj4SBO0HquOBGPBbnjg9MXK1d7KieU+TVx58aG9h vJT7Ov3kjfefFp7EhMVbloovy41QnTYCfsa/TdZsxCKpY/CinaVleH6X2X6NvJPp0XVx1dh7vH1k cOnQDjU4OMxPkoThgQecaRv5IHtJFxcyPT6crBgfzmBaPuZ5t+NtzcTeo7ltuxEuNEY2gdsf2qs4 NCPoN6161Y6ADEGIzzkvGAL1uoTeKQPfVyoOcCYI9lHjtH6nv5glM2fcrEHwoYPyt+ORW0v71oml d/gk+LHT3fW3srmzBU2/RaDBWiuHcLguaqTHGmKizpSHAG7C9t2PJguUWURWzKS2i+fbmYfXTMz8 DTcg7E7qP3SwJt2KUKFqK6qtfmq10ln7d/Gi2nfGqr7rgWE3jurLRau/yqmv6Y/f6fNZff/Rq5/q khgP3iqdNI0PWg1Jy0ajlY5DZ2JUf35dvl3+CTAAhLKhQQ0KZW5kc3RyZWFtDWVuZG9iag0zNTg3 IDAgb2JqPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHMgMzU4OSAwIFIvQmFzZUZvbnQv Q0xQQkJCK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9Ub1VuaWNvZGUgMzU4OCAwIFIvRW5jb2Rp bmcvSWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzU4OCAwIG9iajw8L0xlbmd0aCA1NDMv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJXJRda+JAFEDf8yvmsX0oSWbunWlBBI0VfNgP 1u4PiMnoBtYkxPjgv9+YIy2soHCaTDnnDty02G12bTOa9OfQVfs4mmPT1kO8dNehiuYQT02b5NbU TTU+aP6tzmWfpNPh/e0yxvOuPXbJYmHSX9PDyzjczNOq7g7xOUl/DHUcmvZknn4X+2eT7q99/zee YzuazCyXpo7H6R99K/vv5TmadD72squn5814e5nOfL3xceujsTPnyFRdHS99WcWhbE8xWWTTZ2kW 2+mzTGJb//c8KMcOx+pPOcyvu+n1LLPZcqZXSKE3yENr6BUqoDfoHVpDW6iYKc+gDZRD75CFthAu DpdcoBxSyEIeclCABKLB0ZDT4GjIV1CAKHIU5RQ5ivINtILoc/RZihxFlgZHg8VasLZYC9YWa8Ha Yi1YW6wFa4u1YG2xFqwt1oK1xVqwtlgL1hZreVhzK8KtOBqEBsetCLfiKBKKHLei3IqjT+lz9Cl9 jj6lz9Gn9Dn6lD5Hn9Ln6FP6HH1Kn6NP6RPMFDPBxeMiuHhcBBePi+DicRFcPC6Ci8dFcPG4CC4e F8HFP1yYrme6wnQ901Wm65muMl3PdJUGT4My3cB0lYZAg9IQaFAaAg1KQ6BBaQg0KA2BBqUh0KA0 BBrWD2v/WVVkX38p5hXy2BX3ZTLtPPO5qarrMExLal6M83a676WmjZ+7s+96M526f5N/AgwAgcg6 9Q0KZW5kc3RyZWFtDWVuZG9iag0zNTg5IDAgb2JqWzgzIDAgUl0NZW5kb2JqDTM1OTAgMCBvYmo8 PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciAzNTkyIDAgUi9CYXNlRm9udC9D TFBCQkIrVGltZXNOZXdSb21hblBTLUl0YWxpY01UL1dbM1syNTBdOFs4MzMgNzc4XTExIDEyIDMz MyAxNFs2NzUgMjUwIDMzMyAyNTAgMjc4XTE5IDI4IDUwMCAyOSAzMCAzMzMgMzJbNjc1XTM0WzUw MF0zNiAzNyA2MTEgMzhbNjY3IDcyMl00MCA0MSA2MTEgNDIgNDMgNzIyIDQ0WzMzMyA0NDQgNjY3 IDU1NiA4MzMgNjY3IDcyMiA2MTEgNzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEgODMzIDYxMSA1NTZd NjZbNTAwXTY4IDY5IDUwMCA3MFs0NDQgNTAwIDQ0NCAyNzhdNzQgNzUgNTAwIDc2WzI3OF03OFs0 NDQgMjc4IDcyMl04MSA4MyA1MDAgODUgODYgMzg5IDg3WzI3OCA1MDAgNDQ0IDY2N105MSA5MiA0 NDQgMTkxIDE5MiA1MDBdL0NJRFRvR0lETWFwL0lkZW50aXR5L0NJRFN5c3RlbUluZm8gMzU5MSAw IFIvRFcgMTAwMC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzU5MSAwIG9iajw8L1N1cHBsZW1lbnQgMC9P cmRlcmluZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4NZW5kb2JqDTM1OTIgMCBvYmo8PC9T dGVtViA3Mi9Gb250TmFtZS9DTFBCQkIrVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZvbnRTdHJl dGNoL05vcm1hbC9Gb250RmlsZTIgMzU5NCAwIFIvRm9udFdlaWdodCA0MDAvQ0lEU2V0IDM1OTMg MCBSL0ZsYWdzIDcwL0Rlc2NlbnQgLTMwNy9Gb250QkJveFstNDk4IC0zMDcgMTMzMyAxMDIzXS9B c2NlbnQgMTAyMy9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvWEhlaWdodCA0NDIvQ2FwSGVp Z2h0IDY2Mi9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNz4+DWVuZG9iag0zNTkz IDAgb2JqPDwvTGVuZ3RoIDExL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWoACDAAAIEA gQ0KZW5kc3RyZWFtDWVuZG9iag0zNTk0IDAgb2JqPDwvTGVuZ3RoIDMzMDM0L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGgxIDU4MTczPj5zdHJlYW0NCkiJXFYJVJXXEf5m7v3fQ1BEUTBRwsPHoggu YMQVMaxRqahY0RgLGpbgBq0LWnFtVSQB40Jck9g00YgKLrg2lRpTt1iPISoaj0tbjcZoXGr0CLzb geT0JP3n3MPc++beO/PNN3MBAfDAAih0HzayW8Rjr1lzZeUvMtInzpzusJptHQ1QB8BelpWXPYXG Hl4JuO0GrDPZk2dnfZXosRrwnA/MaJOTmfHGhT3uLYDFq2R/rxxZ8OzR/KTMZSAwZ8r0gtLmx3fK /B4QUjJ52sQMPSnQHSj/vczXTskoyGv5pjJAjbfYO6ZmTMlM8Ns4XOaRcp9f3m8z816fPM8HqE0B 3O9BqShaAQtu1norEmEU1PR3qPoAWdyaLGZLWdpqpvR1uMupBbFyamO8SE2OdYjmMPVWiSuBIu0B dDgGdOTaU0DlW0Mbb4e2SuTWofCX0UHlox1gbsi43Thcg2XvJDhdOeafKlrs1/w0fvyCsBUl5IFC LEI8IvBnnMIk5GE4KtAfD+giEqHFahY6IwYN8KEMJFCUzErga07JL6+ZO3wLjHVYiEeYgQuYiL/D hvUUiUD0xhcYYLLhbdWiF5Zgjfkadt0TH6HWXDEuJOFPqKX+NFItsKIxGnMwF2+RL4VSb5qLYPGh AJ+imr2aVaE5kvErpCIN2dirSe60kIIKOq9i5aY0FNPLVG22CyJBsjMcg6gXdzGH8BJC0RP9MBB/ xGqsxUXqSgNUD30QvhJTBg6SJ/lQRzpiNsJfJBnjxNO3UIZtOI3T5E+p3E2lW5+4bsMT08TDQhTj PB6SO42mAj6gdrgGmlyzxxyT3VFyTxwGi9+FeFei24J9qMbfBJNa8qMUepfu6+lWRMNC1znXdeNj HqKl+DoKOZiK+SiS3LyHo7iMf+MZaXKjVnSUu/Nl5anfs3wNzNKmnHfDIEGrAEuxTOSg7PicHNSJ Imk6XWBPbsmTeR6X83eqSO1S/9LfmFiz1XwmmN+BHU6RYIyQrBZK1kold9uxE1U4gBP4Fg/wH0Ey l4ppF1XRU27DO/i8rrdqrQdmk6mXKgwUhMPQXSRSEEzEq+LLVKyXTJ3EGVzBczyn9tSH5tFSWk4l tIbK6Br9wEv4LF9VZeoTValOaNIROtcqtq7bhtszXGWu9WaIROctZ/cU3kQLhpnCxd8JJzYKjrux H0fEt6eoE1y8JdpA6kcjqIDm0kIqpQ/oEidxLk/jPEXKTzlViFqm/XW5PqcvW3OsYlewa4zpikbe uAsb+onfaSK/QZbcMkekWHCokI5SjePC2jvC5ieok9tY8uxBbSmAQiheZJRkPY3GUwblUCF9SOV0 me6zF7fjjlzKq/lD/pK/Uflqldqg9qga5dLG8rAiRIZYYyTecuuRbZStyP6KfYJ9i9sXDaENJxqu upq72rpCXCNdf3AdNmlmppllNpstZoepMNVNlaqEu37CL4dICLpK5QzBUIwX/ychXzi5HCvwjsgW iWEP9uKYMO4cvsRVXBO5hduS2btNMT1BvcTUjpzUQ/gSReNoAmVRHs1pkkW0ltbRBqqkI1RNp6iG LlItXRf5gZ7SM27N3tyNoziOE3kYj+CJnMl5PJ/X8gb+mPfzIf5csnyBL/JNdqkOkol4laReV+MF kdlqodqs9quv1HlVq26oZ4KNlhwFaKcO0n11tl6sr1udBKc3rFzrfZGjNg9brq3Ctsd22nbbbrN3 sifZU+wf23fbjVRKBVZKlf7sE8Ztpc78mnip6DPeS6voDO/W99iTxtAcBQ7XYcLxZNziIhVE0aqA 2ksdv41XWQmGnryJE4Xdjd8IqeJI4WGqVaPb0haAl1CO9Juzwp8hYrMMhxBkatEK75hJqCJfqahM s05qYQENoWqpoWzO5291vfISht5Ql4Q3t6T2e1KZ7TTGcRdh2wC8Dx/0kXxexWxycFeMxTq1TDId gBcQqidb0sPpkdqNbVzGRbzXnGTgO+l7Y3UiQZ4LWKHwp7vYKb6d4houoipto800THzooNyEH8cR yJuQqWaQ5gX8WNfiEvfhsSqMHukeSiFF8rQYY+guuWE7lfEzCsAaWiDR36S7fBPT8ZgMN6hSzqET dJx8uAu9orrDxTdogngTiPuWL7lxlNSRTXh1i7epLNqAGuuouqKT1T5o+itFcb1ycBwlq97mHoJs z1QL13kTizg2ZqX2aPhe0MnHJXNMhesMPbiuqu4s+9JKNcVKM49chdZijkaWdcc+ALM5VjrEWXmL KhBK3/OLgru/rPQVpHz1iro6Hg4/fkBPUEClUh2BEkmqdI4KZNNWsbXkbRoor8BzLpeumaxmSJ/Z h2PC9rnS2715orwzOTQCLK+EbnoP1gsbHuo3MVv++0jBp/Kalov2kvWRKwb/kL73a6nFr6lYqi6J ++g0jJS3dBE6xgxKjRkYPaB/v759eke93DMyokf3bl3Dw7qEdu4UEhwU6OwY4PB/ya9D+xdfaOfr 07aNd+tWXi09WzT3cG/mZrdZWjEhLN6ZkO6oDE6v1MHOpKTwxrkzQxYyfraQXumQpYRf2lQ60pvM HL+0jBHLrP+zjPnRMuZ/luTl6I/+4WGOeKej8kyc03GAxg5PE/3tOOcYR+W9Jj25SV/RpLcQPSBA Njji2+XEOSop3RFfmTAzZ3l8epwct8vDPdYZm+keHoZd7h6ieohW6evM20W+0dSk8H8Zr/LgJq4z /t6uduVbK9k67dgrLZIP2fUpX5KtRbKEj5hgYzqSg4l8cTYUEoKBDIlJSg2LYUJaSpPOtKUHbaEt 6wvWhkzplE6GmR7TTgbzR5sW6mbSKWqawXgIQVK/XR/B00ynO9r3vvd9+/T93vf79tv3jIH6MQIl pQMo0cI1BUQz1yQjEEl7oHdA3NARCjRlW63hkmIR+/u5PhFxPlHjVB5BfsWNSPtFteKG3SGvBp1g x4qvC6MSg/oizrQBbqB3c0gke8OyD60T/DaJxkNzps+G8Oc6f2jkSWs2KQRMO1h5KAgjrPjdjtCT VqvchsPwHzCXsAcjQhBcj8pBNJUCEBm+vJTFRQ1yAVkT2cmKyZyP2y7sjAAfFkFEnQet4xYLP534 K7IEWKErxFlFbzYX7m3KGctCQufBCTPPmldbSorHGO1iNMcyNEtCWvqTwuCKTZGUx2WprXMlnFhG xLVAFohsPwtIQhwspFZuBmuR0F8Lj8EVxjBLHAAadojJ/ojA1Mt6eb5I2RmOFR4goJ2L3lut6V3S 0HbmAZJFOTlW8gvsy7LodIpFRXJeqP1AJGBsVMaukuL9EvEvbg/DQgfhQxtCMC1cXwoxt1plVk9I POqDgTjcEVocs6gvexzxpc6wSERky/Vli36TbBletqxMj3CQvpPKnlsvJjlWfhrGkBnYXi9iw/8w Dy7a2zZybR3dITYgRJZi29a1arRor12xLUlipj9EZhNLEpFNKlbIxM0rD8uDUJqossOPVjJ5QFIn QSoqGswGRSbSvNiGU6zW/3OSlPi3PEvpPpu2BFOsd64eu1eNV8FLE0gArHIQbV3dgpCyyhaEsiMI QY4NChGhV0oM93EswwnTsAMUhT2ByDKjUmLmRLYYHA3DIrbjeshWAvnGOHysY4zHxzZ2h6YZ2Pce 6wqNE5jwR3zhsTVgC02zCPGKlljRyiNWHqE2DJk+TiQppuxpHqFhxapSFMq4X8JI0SUt6zDql4hF HaPo4CqBzwEcLakcSt6IqZF3ksAPabVEbOUzEaV6SKIUteohRuYkmnpIkBJunUj+3p9MTmbBE/Os Z+Y97TEP8oLMPIamvMyqtWrt0OAcFXrMktcf8xRsNVnVdfg8vZG4SR+HjwwJB4M82GZ70O8mG4fd LlpKvM9nVLiqavnUjKpsuSmTEtcnoM+EnteDYMw0ZRvLTLUqElEETjXVpUi4/DJTp6JK6qCMl/Ma V11+eiNvdjUajRbOXy/hossV/iLyLo+u4hHYWhbh1kk1vssTEh6ZYNX+p+CJcb0/HZjj0yw5VWw6 Tjc3+J41OWFZPc722ELMbImZLFFmYakHzfrAYNMHTuRtj8aiXvn2eGHRuMepXBh2ntYK+OQRnM3h qtIZbWqa0GcZKitqqnWuKgeWbTT9+Ub6+KOtz1Fvf3p/izB/fHD00zfLC5t3eoqc7LohN/l07+iL V7oGTnzytUpH0153QZlt3Qt11K5Hz1HnvnFoJj7/1oEpzDjzffHbh6vX5vpw/ldqfbGes4dfuHXg 6/umcWbhGm/8jwdrfFY/LnqpwS9z3Ze4Q/0Z2CgFHprR7YlugC/hS7yNIhowulxc2oDKchoKVBpb sEhdShTTOoSxpuYZG6m7Sr6F9CgN87wpuVHjb9TrNcmtw+6GqlaIPXannedTJXxkQn2eLZLw3qmC jjLd+aCE7VMNHTl2f9U13IrKiCSUQ14Yr9+SJ+EkPpVfb+LhD0zmlv3T2IUUEpzt0fnofGwhyjyY /zvzwLwANMA9t0yCp50BUuaYOW9UV1fq0RnrtHAzUQwlWWllZrBVT9Owv5bjXKnEPn+JgZpquwO6 6kqFFbXOWA0s5Nura+Ses9HAjZqmFYaqaxyEyoXPhHa39a8dEjYFSjxf3RwZDXz55qGpX5/tx2UU devs1qGfvt+841uOygT6pqslWNs8kHLmlxfOHVm3t58fIt51pDV/6Y1NN1s6W9Z1bWy+dnbiWGib w5/zm3t7N+260Ry/dfPqHhNL/natu7OXb33ltG3TePMf9rzyQ2dwAPtgB4hG462kQJ1CDPJcUSdh nJms1clR1qDzwFtggkpxJ0v4i1MaP2XW+qYJZjGIkKlzTCzKfIC8XiUeake+w8XU6LCRVhIQH7EN VRWcuYLfNk2/9OZMvJv528+PCdiXwLW4gDt+4b3YjxeuIZywxluJPMW//0oy+NcmZ2o/xz+fovFr qDyKoCwA78OxDTKKhZ7/glFjgL0hoyZwfrWS/7jINlRZeEaKb1NgUC9n3gUY8Xfi8Xfjt/OEn7xH hAEGxMGOTqqeVf0KpSI/76Bn1T0ps6mpKKkweRZRs6oePIuSZunUQgrNvgoF1Zz2nYXFN7p9HgrU HCqdByDzUcbDgFBeZtdaXVZtpdaqt2oJQ1yDP+7E9+PpJ/H9TvxxXNMZTwefiX/GE5iBo2cWKuXT UFbWR94M/GoGztDO4H1IRUxdQY2pZv3zDxYjfm8uikp79kaZm+VlaiWd8h1y0FdSTd9WuoZWlZFq d0Ghd/ToHVtVgV2nSSpL1hqcjb6K8OUKWGc1PkQM4gS8qTkT6HUCS6T2MkWYVc+fkr3MtTOwlhiE Um2tIQYLY48KceLoUZgXSPwDsE5AfHKn4T0/PU6nQtneN5VsTlsGGEVemFmjgFFeheoLTrenqMjt nnDLLdzyqq8m7pDpwDiJgrxtGzpA/gjBsQrDMZTMIghZhEpM9iALhXsA2Ay+B9FY8gCcy26gPI5Q X3COHL6hkA71kUyP0SEiQZ16tJH6GZw90aHEh+R9ajvSwYFmlF/vMrjZZrpV3ZL7TN7TbJexmx0w DBh35+7O28Xu17xo2Gd8Je9l9jXDUeNJ9ozhtPHb7Pf1PzCcM17MvcROE5P6ccOk8Z3cX7BrMj+B r5qEt/GWlHTzxWG5utttF4fJ35N/IT8iEyRFWhwz+ClsQMsZqmQJgIbKrqBVKjmUjqVyoaupNtpo Qr1ctOFcU+Ugbgxfem3/lv9QXS3ATVxX9N33dlf708dC0sqSLFmShQWLP4mNweDEIlBaCgTKOAED opACNmA+BoynEAg/xxMIEAiEhE/4mECDmUIwdvyLIS1JCC1h0pmmM+20JRNDaClDmxpSIFJ6V+LT Wpbf7pNnR+/cc885t6pswvqTU6oOztswrP6lYWOnxp7Sl01qmMpXf/H1x8nZu+sH+7+4fvVrsLw6 vXha8spXyT98Xl0VrQEemkFZPA+rthpLNRlR8JKLMY/JA8/TKrqCLmcfmHmRiDYNNCsnWrHBhraI JhBGKDAU3doDTcRGLSRKMvHeAwk0bZsVGBGjNqv1GhAHoHV3Qh/xMHNM8noJL5pUAl0sin3soUpL wArWdpYbU2zgwz3QwCd30ih8hajotjJdL9Nt50C/E+8tu12Wqic2T6MlX19tO68bcusmtts39e8g Lbnn0n8N+OKkFsCQTw0ZWpJ69XuorabcCJuc7PEVzZATCcskz0BnMHTdSVn/oGeIGX7CV98/8LNB kVxTJEIVuz+/nkXGKI5+4aiaMwOxwmTEziFWWaQ1FtwmvqzsE9+QT4jN6lmxU/1M/Mwt32J/5264 bmmcomZ9gBhlIj71xAdDY84sprk5F49F7MfsAtM4FwdKO6UxVWq28pnua8h8VT1LNQxG3xI/ESBI sig9bfcEOuEO3EqzZXwvxoJexMOWKCtP9CIOYICBv/k3/0FsCbB9+p5AR1ZMiUlWpnAB5uU4Eq98 opDEIR4MDib9HgJRkhYFg2aYHUqGFNFfJ+KUOzp+7dwt08JF55euOxUoXHc+2QEVk+Zr0QicB6jf UL2h0bZu23trpoyt2/6X5F9HlRrKOAo76RDikk8udRAHBqfRGb7yeN7CvOX9V+dtzduT9478rvtk XhftMrXKHe6zeZYZ5KdA5zjqHJSnklUdwATmYjmO/XnH83rybjtNnMPhoI5OthUf39cCYAl1MmQb 1Jz2mpVu2E1kirMt3lp4vRuB0piZ8BBsi2VAQQZknIW3SSGRkX4Ks6JaaC0FAQh0o2QUkAtsOjFi ZLwPxfgOqmWfoUp96OWGmd/sjRtY1dZCbVyHwY95U/JQQ10PotQDXdX8FG0a/6k/lH5T//zsHy6Z HClumrVixyvHque/dn/TmhF6UcTjsa0eHZlaN+E4vZoVWTBu3oSqzcry+i0104+P1A/Vrr7/yiB/ NPykyI/WPl8x8404qlMMMb3KjyMyMcOzMd2iwCoFrFRUi0gJN0RZJjfyjcJv2J+YLCmSOkeuk7kK GebKwGOobdEyi1PhtgwvQKUYqEXMryaRKYJZpYpAeP6aoOA5FFmS7qmKQ5VEVRElWVHNJo6hvFot Uhe8iV9EpU2tTBR5gmQ9EJPlqEw4IcqbWRc9hh/jlNBCJBlT8b02RSJE4vl2Fm2V8NGS1InoixRa VbNZVZQuNoBI+DwlpgiWqGITNMEiX+iAG//X8n36yivgLsBaYMTCbSjQV/4LN/TUlc34DJd/4oJt oBvSoNtukgwjiCXKrqa6oVHM13nUicZ8tyEXVvxBYdD1pbW1cawtQJEpzML9gkOAQZBdTSYO5xyZ 9/r8pGsgK9iR6IDt/LjvNr6Y3Ak1r7KaZDLxMnJ8DNbj91iPEPkwtlgI2Us5fAdNenahqSx7Ij9J mGiaxb8gvGCq5WqFZab13Hpho2k7t104yDUJrVxHtmsNB6LP7RtlOizcFvig28X8dqA5otsbDDkZ x90LEUcoREI4aXB+O8dCIQtlKKWctx1q3reY7Zlhf7PYTSX0qwsp97DdQevoNYYCYxBCBOxpNTBk 0ji/gUpqqzQVUA1xrCU4MkDQFDQZMcghpEzmIZVx6wGXc6kNPspPzht7eOrmql3PLV8xZ3i0uP/g EVGPM6u2Z86+9fy4d455xtb9bvOXbw4qG+TPzykaHFSkL8+sPvUjC7Ji3ffXuWJUBAfi9atW0e62 U7fBx3FaqT+klYacJazI+Qx7xjnft9K3XlmbuS2wQ9mZucd/hJ00H3I1+8+wFlOrq9t33ukSvZrT 7WWjuMoMimg4NaeHy2aUCO2wtyU7W8UQWNVGeM9d1YyjVTCmFEjlErVKAYlKhr5KlwHAk6M1W7sp IWF03rKH2KH59sXjaedF+BIZCFQKsaIiYoQoFAGEC6XTKRBTWgBIeogiQ0og7cf2dGjnipuTPT+v GfVSS/K3pw8f64EfnKxOsm01o5d9snxSuJyvzo0mv/80v33freQvb+2/BNvAPyqaOJS8fHnBKpjw 5xVrNUNJryNuhamuP9JBOBxFn55YzLenV85Yw0+l7mNmvCilw1A9ZZ7j2mF/TGXUwRjlmEyJnDo3 LxjsQWXsRNeVoLotIIOcqXDdcB/zVH/Cs1VnIIBZtRvbVKX2NC598TKUxHQkQW4ZzOq1I38esQpS yKQmT5xxIBeCIcEUhi20KSFOpG8lexpmxQbw40L3eiLcwYJpmOKexd75G7JBQ+YWko86SASpMM9W aspYoDZoDZlcJj/MXJo7xvzj3AqYDUv4upxVhRugwb0hp2HgpkEHlL3mPb69/XcNfLvwuK3Z15Tz buRk4SnoVrvNnbazvhuDsiNuFU9qTS26/66d1+8K5mAzsdqs1NqJZY/C4ZiS5kTmE/nNrBO+IV7c M5c7ZzrXOq84OafnSdSiR6EscSeNQeLOA35kPLBa4+zYROB6HGKH/O84V/JoitMej3G4RVtmVv6n renSseuV5Z/sfq3t9Ys19cvilYuyBmbteqtx0dJ90+i31W3Tmv798cbaP85ZuHV0w7mjixedsUV+ sXBu3ZLKkaUVvU/faFzYcHBxRQd22HDE9GYK0wj5sIMEEdHxWqkXm4sLjRw8jOtRLmYyk9/tdvnZ cH4sPzfwontFYJN3fWi/e693Z+gEf0I5ntHsbvYdDXXxrQH7c0ZkE9wed5YQ5jmCiW/v++Ewybpr 5Y0Oi/2X76oPbto84+8ryd+xLctSbMuSY0ty7NjyB4kTx4kbi6TpBxDSsUKhwTC28tExCCxAO6Bk 3K1pBtv6caNQSkcZbVihK5TgYEIo3br2btc7jm1sHOyupWtGRwuF3nL8Q+PslRy4lN7tdPIrPZJf P36e3/M8vx8FrOyhbuoShVFsyA6rIOZH1TZ4qQJWILQVulGReRCvfWkyhKruyV/Ll2P5fwtMRZJL nbQNaX05oEALJQYQMylXV7nSGpqXz3rm/MP33BvZ+SpMH957cKT0ztuPw/Ffrrx/w3vdD1crbn9l ZMbF53zUmZ9fh/Ouv/phaV3pX+012ALo+2TVk6WhT5/c5Coz/2uYB9+GlIoLpE8APdIqwFBRRAul SZajph47WhBgmCoGYzzu1Q9N/iWEits0fYqIwadcw8FIFimabPZgpKm5BmkafFtzRDM1j8vNkZpm 1Yh8kEoTGIf3Ix8C4N6jFQE9+nnFBAyB670e6Jn0glNlnh0rKNaKFntlVSVW6RHu+HJ1VPUmkUfu aKGc6kTDt7Wf3gCHyq41l156vNaAxwhjNhRpmdnqXoX3N0fVZ9HmW7uzbX7abqqzOOhIS2t929YU 1ajGLAj/SSzEe1A1G0CqAJEljxfx3YpNR+TR1noW+e4xDp+A9eX0Z8mbWZDIdoxnb17LktlpSSdS uuoRJNK3/qyeeM+csTlonw+Q2jukW4kmRRwcVhwGj8Hr8p4xXvDqdLKNTOHFiXODpCMlaCulrh8p 1bQ7dZq4qLtQhe8hDuBvmgYEwuNfiC8LbDcRfgNP7zNnWBzhdq3CiLNrTIZFCT7Hd/I4zyYd79va XEWoDMpgAL3RrViqZyfkThmTPYm9d/xH3Q/xw7Hx0bJEQxTxMuLb6izVNIbW/tBgEBsawG2OqNb6 nRRMkmtC/w1wrKi2LYKUXLVm/tx6XyApitMO/Xr3KbmpNLKxazI5sKO3CMUFubbOVRLN0/e5hHht zfznft+9oHXexwdL51GmmptRpgA2sQcA4nta5ILweWUrzoBKwo0HjIJZ1EuGChEmxJzYKS4Wu8Ut 4q/E3eJJ8TP/Tb9FF9CJOikZqBOSUjvfLswVVvGPCcukDfR64XfCOebvgfPiPyRntZCkk8w0nqgB sjfBJXgipHiaUtWKsynlDIoULYki0k+C30xZeDMfCBQxrzJDCPh43gSNvIljvDwnMowYEOhAQBAp kaF8ZWkoBemg6HSaBIDzHGc2m4y44BAwAYgBhpYIqjrJQEadd5amFFPEW4+LWwTF41WTr9mEIt5S AKoFTFpAEbYqVqiQTSk7TMBORO2K+OxC9XZRAP5h/FG8S2OZY/noWDR6MxoduxzNq+0cJTSvyil0 5FQKpYJVnXRGlT/aEIEk0IV7qsZEn8ard+4MNjJr0JHZrCGb1UgmwgZQJehaiGszoLIOydC6Wk2H pgPliaAp0waNfhJVy4125/QOy/jnFtf0Gp60mMnS5m0JdyprKXVbZqxdg0f2l56Ac3Urb+3q9IQZ ngsGOadc1fPmyVza7Y9jwSCe30XMLg2OXwH4xF8QJk4gBhEAMkjDl5UNBiQ0MUpO5oK5ZGeyK/XD uk11azK/SO4wvxLem3zN/FbNoeQgUTCPBE8nnfPkPxGYkI7FZCdL807oBTyUYzEf66VZ1muqlxJx ZyQO03EBEb54QngW5UxwQsxpFNJyjG0Me1nSZArFaot472AOjYZh2ApCeG9BrzgoVZK8O0i60Qpd hYx8Kvapt4i3KzaKVTN5hH2XPcviLHqp4KhPspAtwp6hRhPrYhvNw7AHMrd1glqe0Xy0beH8E4BF W3KOnPqtwWqXuv50MOzW7odi6F5xZNRSjS6AHaNaMUejHVfG1l7xqIpB3Q1JDpUgA3cuhyz58Wuk dqiERxeP3p18A6mlOT/zSPi7M4+s/86j84+mPMHixGeNjQvAzCNRZGxBxoIUFsNCuBFZYR75qVQk BSZTKwQyIXRq7uRhOlBbOUVSIiYe0FDSkHaWO4pzkjqg3gKnXCZscHTj6cVvnN60bsX+njlvlezW 2VzY4Q7/tyrd4RiZzp/9cHO/1Fj67Y/u2fPVjgF/XBcKzuqftf5ULL6ra2lxmdsRxKwOrrofr18R CUbHz2CF/uU9Fbe6bCP7Nm3DVR66beIT3T7UWULgWUWSyDZLG7lQv9yyzrzB8oSvj3yRPACGwLEK 6wD1AYXp7RArwg7FZJReMNaF/DhTxJzHHY+5TUCtYtx3FOtHjbb1aKhfrdZjdAaM2RBAFIpT7p+Z 4hQ6s5eD3NLw0qfKrVdN0XgU9d9RVJrjo7nstavk6LSkKt3yEBdDcVzttoZJbpWu0xOiIKmsXFJF jGrS7VsqETrpgdVtg32Hljx0ubj9Qj6xujR2cmAC9H0J9/7tB5sa3G4poltZenB1dlF76PtPjY78 4f0vNm89/Pr2r5//CL52I0HTCdRj3wNAtx/VEwti4OMTgJv4j1LnQMh5xPuT0Mbo9lDBp7fSNt6K 0MlDL8f5aIamaUaMW+U4xKxGOh5maLJmGO8F+jJE9cPQBRKIw5ucmTUJmPCe44ZxCBi8/RhlpyGt oj5uol10/FuoX6tBnkYQR/vQk1BXV8WCsE4r7gx9N97zqNl1XCkDHbF5hOzbPP4buNYYPUKkn6AY 2oYRd0FRB7W2hWIrpRvKnAzKFfBt6ISm33T1fFn6/Oz4H62d3rCTl25wqVmwo3QxwFBs0yvQOm/j C5fO1yMMbil99fLTt3YOPRLEKhx8pBdPLUmHItVfm37sJX0603QlD+87+8W/Ef4m/oqibkdRT8M3 lAHFc8yDPe3Z4Xndgz/D9YVe5HbGDngPxE4SBarAHY+Zl3MbuD6A6+y0/UEPXqd4EQdmMh7BybSw Xmi3A2gnSWCQbbbFRt7AS2hAxVPp9DsJPq5/AMOW6Hi992cu1w2W9xIylINRXgYk6UNDSpKC6biM xW12OyNjrjhvlBrDQYn8H+PVFuPEdYbnzKztPWPvjD2+X2Y8HnvGNt717Hi9Fy+LPQuBAmEDFaQR qK64LNAqSgMV2QJtwiY0ISkNVeiFpBWlVR+aTULFnSVpIpSQh0QtjaKIh15piwApbOGBRoqKTf8z tpddIFIt+fwz4/Ht/N/tt084zKRQ0R3IEZuImsFQMQrIPi1+qRjdn9/fRSa0QCRWPNR1vYvuipTo 14C0r/ET1Ctu0mrVanUKpch9Tl+wmIKujZNzS/BSwVRD8AZnCV6u0f1UQ/BSkw0UpJooIJUIXgpA MAMANy/fvEwSTG7k5q1c7pJezV1qYWGK6N3QvYCo5qeuUe7/oFnFeqVxaLndnulBMNe0PGCmRUYm SRCjJZMN++tpXJwNp2R/wrotDQk1SR/4+a7nd3aqezNCct76p3d7w54Htr/3aVUd/+/VjoeiGSGq /jvWO+J3MedXqY6IMtx92MbUrq7cUveVO3PFcL0yrER83Pdfr+8BYAmx7G6msKGo5dT6mXy8N5UP CQRR5wFRqwFROlp80q/wnrJBNn835Bkb5+cOaL/R3m476TmtORDHUQj6DXjp6CB4CYhBMZD+uq6v y4jpFl78vE/0t6lIlVKiSvG8JEo+UZT0vErnOzjOr9IBf7vYnZFEwArlMB30Hx1/d9CO9H5K69ZM bYW2RbNpEYP6hCeIkMAGXQIvxkVdZMZFJBIkdGP45m4WDo/emgGEBgzERvvFZvvFlgiI0H/xHtPb OgKt3zrd+qEvaj01o8/3dn4PdP7Jcw635YC53KyGN/rdSDZ3Oq21Om01+me/PLb92xXtxQz/5cdP jMn9j7pq0OFIxhtVr4uRnmWuttio5lxSyuy1tdWuLN1RF4bS8xbUNz+WUjMO1VKN7DhjbBiIqIJa nyhn5o+4WXCrfbcv2n4PbtVHvWcu84KdpDpKvpKxxFgjbIpvw9s6dswZy33P9dP4KeokftP/J/ZC xhNNxMRoRAjDQFCgnYLHIykJn+LhlUQ0EtFVno7TND3J0KbL0dOzv09nuFEVR4mLNc2s73nqLRDy AcoJTsZn4VuzxM2yG/s3ftWyMeJi7s+IixGuDV2rXa6SzDG0pz2f4wh9SOy4S4QposLNDZUZu8cn kC32WlQhrHGQmOBg7DBPpGgwPNjoact7d6OGD79c/+D9g+9+WFi9ZoM/MudrMSddZEcWhT3a6Auv Vi/UP9v1478+c/z9l57QA+FkDNzv4QdT6w/U/3Kl/s936teEOKouzqW8YjqNlGz0mfrE3PSvEN59 BM37c+WRbm+wkzDpQ4qyPwlMGoa07xJCCu8tZ8nCw2B2HGqFDGj74MCn+Eqn1CsF+jn2pO9UhFlZ GWPHsswqfssCGiVkmaaU4eEkZhHrgfkhLEfE8BwjJ87Bg2hweK44iGkYIkJCUAxlkxkxWyoMiBDX BUmmffDm4WRSMgo+wyggSkkkdcABFRoslWCYoOdks+FwqN2Q52douWC4hWEXkIymvZSMXqCScFxg FlICZYBm9/QVDVPtJXJwPJcvWjWTtSrMjr0GiabjxhHjrPGRcdG4YdgNIKTJzsdy0AjKxnyLn49b /ASCNqWaPICmJw0zoFasj8Kg2YYpCeTMYq7RZG7jVV6qGON82Lp6GmhsjIdK1k9xWu84e0rwlo0W rZsPwu6pm5emcmR4AV6fnZ5jyGqF2eYww7WGGe4+w8xda/U+lxxNxT9HiA8P1PqDZyj+9t+OuUuk 51CcUI56G/k2MS0ADs3RQO1sfUh8kWA070ef09/aEAsXl7G04lqodAcTynWpd9RZu8GBZggRbWdt 73fE4mh77VrHchCRiHZDDPeOuOigc4GsB6QUfR0tX99HtEJFvD+hj936w6ZOLW0piRBL70aH6utG 89MXsk8zPaPF5u2+ROdOwPpZimIWA9Yl9KMTSOFLAYJtE7BNxXmZfjj4ivd4lBmXEY0ZkcYCEkJe UUBhiIIe1i16QuGwhFkfxqzgoWnUjuMZFrtDvwMghgGELO2FsYjHcazjXfiH2Iah6xi6fSzXS8rp nl5saukiOTaDmd5xfBZ/hC/iG3AnYAGbYGOYOEUc4yCOW5nBOyMzgDNbjSKOYfqxKTgr2PS5YAl0 wBLkKrgFTUygSc6Oy15SLYjiJkSt64BQ66elS403+ZMVTBCLmyht1rJVk9b5uIkBytjM+KxXj/pm wXcGimsznGkasPfBafVOWK1uzeXU+2OnCbUA+txZ+5hbFe30J5LXpAiBhstpxrt09VM53K9ahiLp O5jCpmIk5bW6vnTXrfNb4+GkF3r/5u1/tK2F3qepqTMUBX/K5a6kJxu1jWzBKrenbKNs6VBbKHVQ PKi+pTp2xne3v+xiMqmB1DfiTEJR5BBCyEaLyA36pKRFyma3S7ICAqYEo54jTlClaI8Ty5mMIrtt T9mVSbTIZO0fy/JaeYvMyJPMItPJYd/+0BucyZc48r18bLC4nENcOCMH5Qw7dIZZ2mx6c3gi23mz iqYuuWeEvSGYaUt37W21xW+u4elVgheUaGyhg7gMTFXgMDCfNqetMt3f2Ow0vZQOODevyr9hFBb8 68Vt332w2FWKJDQ5v+GRYcX4SWJonW2ZipYcqr0+sXr7vkeXDa3oS8uSxvmVzjVPPXaYprfGtG47 7PMHkMw+gX0uowtnqDxJt/2VPEGas5QndFM7+PJ2agf/RP7Z/K9128rOrwz9gP1F4aW5r1K/Zd9m T3iv8qyQa5qPSTbooWiyaOccoj0ohcRgugty20C5JA7YUJtoC7j9YkCLq6LWr/eJ/RRCEsf7OI4v U1Qyr/vyFMrrnF6mkM2EldH4SeYBM5dn85qN57l8Xu9yd8F0IMV98Bzo70+nNToYCNjttnapkom7 3ZMMMr2CZKrpIi/FJV1iLko3JFqyfKOCpaBUYTe3Eh0JdA0llRqkk5qkk5pOIIEmSGQ7fFZpyKvF m6lckzN3RH9a7NvPtZ+jIGDkQu4pSgiWEDxbweP/dYJ7Vyvuw489oSvuEkW4IA1VENF+iZyS4iYW 0IqfMBYQQKFAoIdQtZH40f10P3mHuwguEoC10g69D61YM7bWWXsHLyyx7YX61LOJgW+6a9ZwAKp/ PdrzP8qrP7aJ646/d3e2z3dOsO/Od875ns8+++yz4yT4VzJnKbmOQKD8ageUEhIKLQEKVC2bgFAo 0EF/QDTQECoqPyREaStabawkhJQR2CYof650naa1/8AKW9GEpq5Tt47E7L1LAunQJk2y3jv7zmf5 Pj+/j0g+OMK16rVW6hn4x2URwUxy8LS3fXlhUj9Nj3yzZ45peoqxiCbNhacqrevMpDXB9JeWrYwT Ed/bVTkB187IqEHBcJmmL2Vwe0jjuQAA04AZakGvXfCKIYsSFsr7kr2pXusEOAsGwp6UBVkscsf+ A94x52e9Est641FrELrtWLQe4hCArJWKAybDpi0v6wcngeW3ohZtXcrUDOFE8Dq1hMWWnvayCpt2 ysWl+47uEIUdJQrrNJUQ2Z3Jj90xOvk5tWC084+qn2APWokBPOgAE1dnnOsitQXPo9KUmsG7X5wO lINjyiLRdxrvoz/RFfs2fAaByxiPeWfsc87i8eC9YbH60XBG0uN/jTTNDnA+Ks12zVWF9F/C4UDL zn0LphS1dhXDwQuovocur5yczEDTTKTDPx7+XWciJE9KhBsjm+oIEkMAeFZgJHKU1ldDQUjU3oIT 7XHYEaEEgy2h9vB09IS2CK0C/bHfo38gLqV9iKiV6BU0gOgkgnUGdm0wGS8RcvS+m5q64Ak7xWUL +TDK+aAG8Y9HGBipoyejgJRIoSQzGeVElGTpHOUEVIt/5DJ+Xb4cwA+WdHqnyYftZ3J1+ErayyBa VCUkJrP4ywIXQIKpkykROw2ZEiGFcCngImpYUtUw/hNxLSxpWrgum43rEUnXI4IoaknTREhjc4Cm KEAhDdKqruatsBrR/ZgVJ/pV3ABU4hVT3ymqhAohVHTeR5qd96elEtlwegSKUXW7ekyl1SGqFxTw c5wDstiLeN32B4q67asq6mM30MduSHY7gO+kb8uriq6oep5ruVdy/SOOvHG+jHfd+x0UBgjZJljS t2yJwc7jmmhB2JNCEyfQ/70udgyollRQUmkmaSGMPTLwAshCmIkdB3ZBEcaC7vEmQNiI3YYwEtMV xul7BuSQFCax11C7X6RFOGudGGuK3pHDye+HvCOXufBsS89lrw3fsrb/TW9czVce5sNPZ6NxmIq1 PMa5Zt85z7SZHk/V3OeGT8yqTUnINGX/4jdo4c77zLzhD9aaJimX+UQP/ZUR8piEwVfuXneHMIPT 8Cl7g0dUBEtqFJqT08E0oT24mtpMnQjxC8SNof4QvRNCXvAhHiUiCKVNPAJxlBdxmhxGGiGTFJQk SElBQiFRkEQIRMFMJOIyKT/BNM9zHGEOK4leWcxYghiU/bBBHKSn2JJkN2mtkp2vabWl56Ud0jGJ kQbpuj4veCNBcoqXyQUyuUAmZBJJ9f1lX7qu6Owo4ex2jVpqlefJ2+V98inZJW/LeEVFVkQ5M8G4 yFR0jyi4lNR+jY9h5cbEsaX1gfz6P/kxquN+GPVWF0Et5gnownUGwgnuNDZVxP8zf0bxnwXf/Fwr tvuqeNjva4s1KNFY5VeJykNfhnOdXOVx7GBpCSVgVWrxUh4D/wdafarRJD7ljBYb7hxneob7lhXG pwmU3UafaqmjMeYUeOHuddcF11rgBwb42Zmogau2QprNDHxQrGnWmo22mhnaLGMBtah6vrQw2IGW RrqDa7Q1+kbxBW2r/rK0Fx10HxCPaIdQf/AiGoqEPdWsSAUKgFYLrFcZpLfbAZ8tlX12Z8lnt68o +rrjUfJpiLFjD7cyeJLFS2eJIecYu6bEDEJl4PkETHR3hmr9XV874Nzyk/0WaYu3sdLWE5zymEoS xeAmiKug0JhQDBLKThfED0/AT5f+8tWPNo5UVn969LfdZyswumPFxfOzOvcfXHLqyU3H97vWbri5 5dNKbLj3xtoL8IffvGI/fX3g2pW9n3U8uxueHHztKqDu/gbn6z+xJjScsEW7xk3JVHvsNfNA7LD5 luft6IDnTIxzczBDGPdkTXORDaVj341Ndy2ytphvUu/FBqrOxS6YvIxLScCY5J+CLI5DlsULMo5j oGgIBHicyRbPR2QFa0PhWKQn6wFb0PUAoIQAy6G4nLYU2R8/R28HDFT6MtYn/DmcyAol9gs7ZCgP OqEsK/JoKL90P5S7nFSWR1NZHktleay+yXbIkc4ZoSzbgXvdjcw8OKPn3BqP6DJxzVah3HCb9HTB yen/wnvS1ls81S2OGXbVgvVdMEYquhujlLpH7vxYNKdEAtWoDDzQpuSPP9pVGT649Cfrko0ruZGb /Jr5k69Z5eUfrp/2bF/31m1tuLef+dGqX282Knt3ZaIZt2nOfItmehvi9a6Rn6KO/uXdGwOE1csr j7qGMKtN0AQT9tyiPNU1tWmzv9d/yH/SP+Rn07AESrCca26aVj8zN69poTY/uiC9MPNYfWd+SWFF Zln9muJGa2vx5fTe/AHrcG4gcy5/vhAuEXlkiTy8+GCzH3J88BcwhGsRpNtO058Lg3Skr5pv4Abp /bbXc7Z6UrIQoRVS0qWGeuCFQFaQEgdQAkoIQGUQHjkLQCnLnzTkc/g+WayKKhVrQSVaULu/U3J0 YhCdGEQnBj5nkHOGPbVkODopw/IDOrmFp6sAwYvU6lqMFAyUQaj19k2snpG/42gcuem/AUmnwlaE cQJdLhcZpRgiHMXBCiPi9qRgkioVASg4SgOM+IDAqEWVykPF/EKorH7u8MzYqsoXRxcd/HNnPJtV 4KELl6AXHr1y4OoPKv+qbDlCtLdk/8GOny/tOb5fv8r7Wud0+A/sNAqcGIZtKlSPfQY/gbDnZs+f KtZXrunjYly3B7579tWPMa53r2I1HsdqTIIc3GO/yMreVEtmBpideaS2A6wBW8AmfXPd6+5Dde9m PlAuZi7WB95293sotyZru+toOpXLMT6xCvl4hkO8KtUgNWngaSvHMBFRkkRRihlGhMADYAymG+rV dD2EQKWSPh/PA9aIQcBkxbwlif4sUeO/Ca/62CbOM37v3fl857Pv298+n8/GsePLne3YbmJi4gMm RglrAukCrA2bRla+ysKHoNA2JSsFAhsw0aFVfHVM2tppdBmhKeGjq7bxxzqxP1ZVmrpJFUhVq0mL Om1s0wYJe9+zU1qmbXZ0z3vn13Z8v4/n+cWRoMwyCj8XY/FGlUOwImRKoFR8l0RCVXB5UrYlti5P NZSIqs1AKco2H+6W0dtYCVVHl/LCUBVde0OqylCXzsvwW+TmtzgvwW8ZlYGMlN8OG5vc/uA43mxq zdbW0LTDkfu6vj8NNbUtfTKCO0PQ/+xtB4XayPVmL9MJKtOYZh6ITu6OhvrdMnQ2N0C8aYid6H9v ed/OoBr4KjPzV3ZZpFVOpKZDPUu84Mr7198ef6Hwlc3szGq7/fyvRkYSbfiLQJh9oq8jF5LodJrw imr+KaK00rRskH710L731Nkdx1dTafwPzFtHh3fRED2Mu3eLHIAO0AW+aO/f3/aNPL7Wt5Zby2/y DXPD/LAw4tvL7eWfEUbNUeu07wx3mheyWM5XNh811+tD5rP0M9x26xB9IHfAPOU9yZ0UTpRexV7z jnPj/HnhB9aP8pfBz7zXuLeEi9Yb+dtWPGCtYPu8/b7HzEfzFKUElWXepdwy4QWL4k2fRbqzKvQG 25Md8qc+1nU/gV8FFoZhVXhRdJfKZYwRDMlzPlEoFPAC3DqZGksmxqDEF01q+k0d1xuTDioXw9Ey qnY0mSnn9bo+qhN6ZIFxXrKtinQDHwNdYwC98WXsJvRCuPMS3IjZwQp2BTyE1cBDF0ZCiCJQ+TCO CdO3DZTJEGGa54OICogb038SplGBCxQoENzbwSC2DWwLyqWmEVTKmRb0rJShhUAGwCeyhxKRamCN tmGIBBRs1MhX3NzWpHv8yL4xLX9jXcx694ed7drK+RQnqrlYy4Yk+b19G57vB8bqLTf21DZsz0S6 dA384+HCofPnNn6us/+3Q8UVa47+mqWSQZyIF2e7a+k9J5/uW7J39ta5x9b/fFPA4Psg/scwzNUO nUIHhp0ikPZ8sAVP+oATfyQWJh8XMYYnxnRcABQAVwka82A6CiViVRewArYV3TuCtoWo4IHduRGJ mJgnCl3bVjBcfxNguEeW6EgyGxXYdyQn6UAonWpYjZpqbdR4otyIPKFIeW/k5cg4jDxTePxSkokE I0nP+svEMqwp3gYUhoHSbsSG2cGJTMFq4/Mk5/SSJHdH0ATc7NnTBpI0hMyo1+7CEFir1ea6tPG0 8OdBEMobaHUTLjqN6wBCOlP9tJxhw0Yjle6gBlFKAQfe++EEpJD5p0AbSQ23yGbyyObZ2yV7heWd mWAjj+TUfA6EV+w8tjqWdi2ffam3++F07O6XftraUkynw+KabxO/rG3fCHH5PcwY+yAu7aD/Mqbd e/8iL3e7UEfdAhcnUq97J31XA2S/a6W2w7c/RdIWna9KXRmSiRkZHFC4CqKJmBrFzHYVcwycYph4 zlRyOTORTKYkRZEkJRqJQNvGuaE0wwvivJRLykmlrJlThOSYZEPblRyjDnejavvEakGypT6JECQg XSMewRjo2Tl4z8OVnINdtuxUw3SqLRXnlxM5kNtdYnJBKQg/Gzb8+oXh+5GigSCAShp0EuhnAuj0 A3liLm/+V6ttBAhbVEKMWJbQQZGSCZILY0iUBooUAOVOhJ+bw2GwbDbpbrw5Z8GIgdAjOBxqsFKe s+cM8OIL2NU9FfWbabf39e+uOz38eGq3uWCQBePs8sXt2ouff+7jCzf+xdLagVh1h2t5GleXDc0m RrN2x55Xeg5+tAucPZXX8650Wu15cpb52x/PfHSia3Hbk+A3Q/l0KwWTIAbzxduODgdtG2Mwj0ek FTpK6ZRftAVc6hQX+LvC1URVXyosF0fEZ+Wj4jH/GeW0/00/9zVtKIGfFn8iXhMJmGxTCIREsozq hFpxTiNR5/SiNd+pdluuwvAelYkkomqEBm6VDoshNcwLgtPXBREDoiCk9ISi64mpe7tsScD0RCQc Zhga1zEmLwJxCj88ITynXyG64Q9YNIkhxiAbtQU44PNYGJrDKEZi4SQzRay48IvQXL+FXfbvtz8Y xOYSo3GQfCAy/j+ImXXi8+L3xQmRxAbXODM0MmX4cMZ4KJcJeKumnIJmjQsKGtrXoB7saqTJFEQa zWhuAsAm3ISeQpcA6NhKL146z4MH2VULZQ/bh4sDAd6qe8FLnqLasWXXDKmRGwfiZg0Gx2RrYP3d 3+Hv7LS0YDRLptMkH9l07s5foIL/ee+W+whEtAhu2iLVBnwky/tETuYVyqJ8CAtots4kxPJldG6L cAF8oJD08mXOhgcGAchWaPTiNFuRbbhBQQc6zmhMgk97TJflKubTtN/yF3v13mRvptfoNddqa809 3DPJw/Jh5ax8VvmOMWGIdbNX600Q9UzdqLcR9WQ9XW8h6lo9UdcJy7QKeDCW5yyN4BVNwRVOVhWB BrSXUWnBD/zRgOrPmFk14waU6uZb8i14iwZHQi0eT1mmYllmNB6P5wtKPq7lC5zPlyoWlGKx4PX5 HEL5OMgRr6/ARWNqXDNZLNPS4vcrCk278SKa+QtcPKqZVB5uIrDSFDEwYY3lp/CxieKYwyk23Ao5 pcFmE26/AnY7bcCh0xemb09/IAZL8A8yqtbkFHpC0aPBfkRwXYcMCzUW9Nxi7kqTa4P/SbbBz5am ezQcBD2wbci8tmFNUiEKtTiM+jSfKBxe+OQKohxIyQD4d7oXDbDgLvtED9cDtyzaQuNp9st6SPcQ 8ENfWzKvMJ8Gxz2VlZ2JoZlV6a/PrNLITQtT82s4pF3P8Zl5RFThOmtueMazxS5xduXsUfxbmwfi MQPGPbKte97JOx+SkTsfwinv3lOwy09DLtbB43bkEHmK/DFJhAIDwhb9ldJkyUXTdKAjRFRQf1nC Vxfa4ULZRgf4/waDgVDIFQyGstlMa2uAolxu2OUqFSabbYW/q6MjA1yw2/ABQeWtSl61GiBNgai9 7t98V31sE+cZf9+789edzz77fD5/xHZ8ts/nOLEdx3bmYOKjUFY+QkohHTRNs7YUASLdQrehbgsD tSwiZHQUpWV0w1RCbCubCglQA0NAG/5Am7RuYpNadZsmZROgRUwqVNO2OHvu7AyQ1lm+e9/78p3v +T2/j2I5gGwWNmALe5oDYdSG2xKtgbZiQYmJRuMSFSai0YCkPEiTO+FyuxOGzng84jG44I6d+YTX 47YYzEtUmGozE5JiP42kpVQbaBbYPilst5kv4NuEF6Cgl14zYaUSTt+d0RkfaytNPkZtI3X5AGq5 f+RzC3/vf2DBxJlL5tIoZx6Ztk3rk/q6ZJ6u888ApEOsVxjzbjFINBw+mAQS6zpz3/RjUl6QGtjN N06T45SEf8k8e3Ckdux5m+zJrFjJzP2NeSLq9w3W3h9wMkHbF+naYqav0Lsfj21vX9FP479Yl6a9 nqd/tyvt4P0rQXdsG/fWDtcmckPLu0IkRIAmV3PTIO6rXR4MOh1B3myJxcyh9Dgex6Nn1gFOHBG3 Z0Nt8sauHr8gsk4SeKsKWHkSsJLBI+dRChBxjS+y2E5YSavJarZb7azdxtrhJ8hx07h5nB232yu4 QlTIirFiqph/RFeYirXCVmwV+yGezaqgBWbpneYTbReJKdfZlPEt8iR5zELuw2PkGynyMbwVDxGk 2Q484wuDFimZREDRSUYXpHhEDsTDDg5Rkk/hHI5gWAJFkuwYoQhnd3GcHWUyCAWliAtsDcKZiB1T 2fZMBJMmSfIqceAXn9eMslXi4DnO4vitZKlngy7IBsR3VUu4XZG4cLidvoBfwnLdW+K0bhMxxMBp PAfLX71pjy5XpZIXMuACgsyjDb3SJw+iLPkAwP7/uq5okzn4RwP/NSh4x3ASP8gjGm1oydH9UHRs 4EjjGQAS8StMbEq+QON3zN1iNJLeWDuzKSYG5DX03DVrX1ObW4ruPBhfspbG96zPsO6mAPEbvPV7 cXcAcGC22JtbvlUr1E7vyoSaaSuOxQirM5jaCUi58W2NZUwGU0tT4nmNTe7UllPO2hFEIp9qJRII +QzYS5XzGiHPcJ+hdM8s/JFwPkw5//UHKlJbvh4BI2Tmb5JXyX1IRnn8keqxNJvDefwqfrVlAh/2 H2o5nPpZx7kkk9E4SLS6ysfdx9uJQsvKZsIqefNWm6TkbNqxIkzKYq84KJKLM9iqwqZV9ebPuz+S b8okJigKud1iDNTFyrrj6awcc1PtQmtHQK6SEyqP4lFJQiYFUVRIkF2CIKer859MBZ3ldJVMqazP xzFCQZEFjh2zXsJLEUWQSIDnJ9+Tfy6ocJ6gqZEtEsshgRMyAvl9UMfq/O7JdXnhEjGBWsk9yIkC mtXK5QLauaIczwV2r8tXAncCRCBbEEShQGc/qKeYuiNK6r5Fu+hxpaxdNAWRRR89jW0hUh/tjf3w IIG6OdfH05q/rX829ty6mxwAaboL2eWz2STXSDzcbHLBSifBp2lpdQY7ipBgHUX4Ai8WMXd9VIcz mG5uWiO2AQTMtkPnN7TqVMu6Vae61j614TLKz99AOViU+ZsoPn/zC/ABe5XEA9B2OtdpYahT1LMs +OhOgKg+c3YWOrJusdMkgTDq3lt3X+TVD9wkbbayQnyJ9Ojr3cmkW3jlxd7VK7ZdPvTS5sVrheg1 9bHNlWWtQ7tPPkLum3uqn7VwVgsX6PdsGUom2h9fdXJZ+8vbKvjZbevVlTuaSn21ydFlvW///s99 qzXsFTTsGQ4gEUWxQeX6/dhMY5NlLfqS4WITJWsvsimY00aQPV/OYcA4EvV4kPio7bbizog9HhaH fdiGkIJgryfE2lwsawtHg8VwnDKxM74ow7AxxcZywSq5R7WboN6vmX5tIkImbHrO8wsAkYijiIUb tWR0tzep5PVB1gft9mzd5vhyV9gP2b+zJFvFi87GWJGN0VUidLoBmIXUOzM7B0Rxa6G8s7Plen3N 9fpip15RZ/HebPLf+B7Us1Qa0So6rJUSSkoWtEoILoKKSHFcD7OSKU9CSQpOzSJLRhPRe+3Lr615 cbxauz36ZgW4lRPbhGRi0+oNl/b3dw9MyoYDcz2bVr4+8nbt6uQwJb4s+FinSf7nPzr34OwPn94y sRf0pATvfjv0vYJZdTlSRVtZ0VYp1IqT8ZTSjbpxl6E73q2ME/vD++IniePRs6GpKBdCPsJHeQ2+ eEgx7pXxN+Nj8RNh0m3AWricdOiZc9KtD9CP+YryrkIoUCHW66hi6kwgSptiwBhTfq4M4yeqFCzG 4iSDrru+6o2zUKA0W2Z72UGWsrMhlmB9LZJWu6ARDpWNvcZB41eM1G7jMeMp4xXjh0aD0ZtIPlk3 ncPJnltruJo2zs7OwNtPJqECoAnFInd9oG4IhrWOCUPHpKBjLkIouYmCWqdsRMN4GGoYazSHM6rX odEg3US9EgvRtNBJ+rfc+MaBykkc3j+0XW5KhBL2NM0H8s9dWfbE1zb1vPnMxyNfPzb6A6yc73+k u1VSgnxzm4sRbK6x7xw5snlnzwuAf2hRaj3gP40W4ffVo6Ygdklee5kB4qRhYdRCKUdrK8aTy+cY NdsBm9l8zk/7mK30VuZP9B8ZY1noFQaFvg7q/mVSV66QXxFcsagvNZp/A7/lOiKcQOdwlT4bOJOb ytvWIyxj/GkeWz1wKq2dr1+0WI3lF6uRKEya8i6XEInKMr+dxjSTrslV/KkqK6lMuifi6ihmZH9X IeIiea33SJQmQ7zs4nm5I9psKlbnP54MFosaczMej43hS4rMc6hKklPyuzyjIYMuwHNmj+aYMRo2 3yvAky89mqOreKlKkzPpCcRzPMHXCZy/AAReAAzY/IABPzykXw1Ec/56u/r1jAasfseP/d4SL/Il Ovvjh7sSqHd4Zg58AyCCu/sQ+ZZnH2xPDSpOjXy1Lm00KUBH71PzyPRCpgUUDWgcnNyBdywQPPhM bGxw5+dTLN9wlXpTa+2M9EsQtb72kybHf7iu/tg2rjp+7+6S84+zfbbPPjuX3vn33flH7CQ+J7ZT ++rEbRLHXdvQdA7JCGvX35RmHawhbfkxRqdK66BdkEBj06gKAtZpZGtxVShohEllm0DaHwhNYpMI HWNY+6dMmiCG9852WyH5ve+dJT8/vc/38+MZLY7AjsD4RS0QF6TvPL6rMrV487nlA5ntkYfNFG1z +TmVn8yeaX5c6jsI6Xn+3/sWBJPD4llw7TuVimcXTr0/kz/72ArYdXh3fBDMhd1yj8tqp8IbJ7Tt zYWblQfA60h3Ncj9Rcj9HiyMNbWMjTGHPYwnTGIGxoA7pg07jbhsjIaHjXlhnJowTBjHTZ817GF2 hy+SPyQvO1fJa2FGQse+OaIaA732oiHgMBcNRoOxi8cMRpcPO8drBlPBwm/ikzzB8+ZgyEF1SWaz L2dziS7c1SNhEziiNWeFkFq/Ju8oWjW40AtWYPVGYr/1dBy4+un6dohitQHZXGzAkDcfa7RRwuyI 1u2Yj83rXm2EwgK3YkQCYzcVDe1KoWqkC+h9FdaWI0PE5p0dPnP/R3uqW4JQZVqSe4c6Mzv+5BOu xp8uPFsH7ouH95f2/OT42rPzy8tq//6/gaUBf+10/pFNH9W/uAKGr8zkp6f2blZ67MrQ98rR9J9h Omu+0NxK3IJcHwX7r2ME3M5sokigM3TujhW7NW4LV8pipKOsyUo6iL7v8QbTmAanMqR8WXPD4YHD yqTLKFlY1FZE1Wg/SZbHQFCD6wTr4IjGhEJY9+DK5lACY1b4kNGGFTfW0WeE2YiNoMNLvs1rMX9A kkQCHy2RwRAp4qNSCWYvUWLhgD9r/f6+VZ1oVbSaOCZLIpPJZftTdby5yvVb6jihMSmnBgl7ZUzk xDHTwLtt/t2Z32hsNO4SrtHaA9wMs95JPQDlHAjo2TV4hTvbxaxZR2p3edaOYCQ8L7gRHCVNHj6Q gRGhiGsjbDEQSMwW/Wgqa85O2KoB2DqAChI4pdNPgsBm2ri2UlBGD+rBodZD23NbHdChJwr3+F7H hWMTk4eW5uZGouJgmA+7GMrojH1u0m/d/PLL1unSUDyfmbw0PjXXFxKlHqPFWxwYVflxYrHUrDTf e/693VtCXtmXDLjdTitl7KIyRx6JfoRfLnFbaidLtVo1EUyFvEzSYKVMsrqY/wdsjVswx8cgO5PY ZmwKmLTshdEXHT91/sx9afTKtlccvxZuiK+OmhyHmcOVJWap8v3KS5Vuu80mFibZQmHSZi9MkgW/ J5I9Z6gTg6txDPLsoiYm3xgMxalyyGNz2NlxPEkaIqlMwU8HwQo53s/+ihjAerEUTMkk0a8ZFToX PKpsyfX+EsYjKL2YArU2qiqoMW0ROc0o4I8KUK5X35zyIJVdRBrbYFC2/ZDZgBEWIaqPVtHZe6cB 0W9A5ma5bAf9/pTO3KuVgMVdtCGadqqNKTCIrrC2MYWItqmpuzAHL10INQQbwg0CqZdIG22O0rmr 87uAg+4O9Oj6FiFjm37sPL74u8MqG5p4/cX04NKHT59668FsjD/Tt/OJY1//9A+VhUS1Nr548aFR de+Y3PTvnB6Z+dEzb1aO5onKwUzymwcOmH1xxs767YlIWi3veqqa36fG5gXntlBMns24zu85/77g +8GOub8uVx/O7X9+40vhx4ZLscLnq9JWNw0TmAJV+CWoCBnwgPYFx2eoGeWSQhzqPmQ8IhyVloxL wnJkWTJMY0ci+LSKkoHqhAMAPBqLxzEnmyn3zcpqKlMFwQTowzCKpkXex/K8D4tjmbiY6GMTib5g P0kl4iaPmR+SfXxfgmHPOaHLvkpTYV8dhFbpMI/sNY4Tq5l3EijzwqiL6iqX1Uuvqn8LU4Feo2m9 ao6c+nECJLxDPJfg+CHTwLdalO8IN9LudQg5bAn9ttNWgOIINNyuluHCHvDEYMXu5uKO4Z5lrKfX 4H1H1wFotZVXBmBiy8DE9nNfYBi2AmwZzQg8dLYPDpgg/nLNyRbYQEsBagA42nQn7jmyFW85srOl 6a02oqggGNJfKRWvNT+49tZ8Suv9Cmc3W+zZYTGwtCcQTgZPuL3spvBYzfNUlNe+CyaCMdERdnWd /48KHK+VhkoPNeenDFaHJb7dqX61PxmOnwTfrsRYjzv6qPju1um3yZOneuRuQkLe++B//473dbkx M6aAkCZxx3Kq+8s51RHTHGpM8/LpGg28QeDmlLJ/VpZTSpXGjnfXiee0HpqSaRut2ETBzwqCnzcL UdkvMNw5NwT0NZvxOEHXwbZVYsFWB8FfKEcdgsarAgItl08LbfBQ1YwQTUETfa03p9OdTgnPCLjg jQqcEDU93sbyHpTovM0CcmhBs8AJLea26LV9x61V1zfWbzNttHWs7wtW2CcNpgMuuu3M60te5TSa LVp0+LIcRA89XrVlOc2WbQs51PH7pNl5H56dYHUXUBX8PprLK0o+N/QG67TYXNlccGxurKCkvd/w iby73OXORZV8Xonmmic2RrdZGZZJTHMHt6n94fAM+M2xXnevGWIEMBYy8wPIzEFwVUvRATarahZb WtVcqqoxqslsoj1mL70Le9J+maGGuKK6lZvhSD7sjfQkiLYti0CCyVgW4cUAGgqIsKRMD6QGqxhG d8umgBlSoVj8V8Pu4LJ6nkn+cxAVXpMInCSBk2U9UKZCkh0AUpIlu4wJosVuTVlo0pyiB5uxOujV XLK+JOvxiKEIGwpFAAkwEtn1gF1i7XYJSPCPaQnACxjczSDcToxVlJiF7lZkk7DSIwXMMYWx9KjC ObEOrl/zrIfq7HrkJpGEvfo0JuMEFgM3VgfeUXRl4NNKSxL0V5hUlHZX6cZgyqmKN61wevqGvdMW gfWN259AGdhobGduw9bAilWURYojHRlo0R/yv+UKd5UB2YMHa7cNxjQA7Cl9Zm5RBmbEMHIWzadR arAya2s1va/0fgVgSI/ZkUgwOOSnunWiu5Fd3AvnUoSgCEj+TvPgk831R28MO+j/8V12wU1cVxy/ d1fWWt/SrqTVrmztSqtPS7JkWZItyeA12GAhPP6QbcY2gpCUkhADgYYSoA2QgRRDGNqkkNJATYZA JoBxA4EIhzbMJKWlL2WmM3nodKYvtA2duLwwTfOA3Lu7wjiFVqPV9b17Vxrfc87//P5CRNDBq9rC pub1/LCdT1OU1UInc8Kml+MNdLA0seEkXFlX4xPoBBKA0LpfrGQMGrPW71cF/IX6ld37vggGLf4i M7HKnYPHd1ROqbavYygHrxWkzOpF1b8OZVY9DIkrNACSgIOcyKYGwWDdfe4bWqXldXGdqOvTqXT1 XbbRYF28HqUMclj1OEfarCRpM+lIV9BGmh9vHNfOwE/QV3pFPe4jAQlvkndIjCzDnKh1aUiadGl3 rKyqs9SrZaQiUeBoYzspy0GCaSfFoFWeXfHZlVVKsKFVN1oVpY2i2ancNzHVp4w0WjUou686MqRo fwRgjzBs9u6Dr0r/LQco3o9iWpLEoBSGW2V90Um/o5U+INKBD4VMte3DpxQ9nI/busp5hjIiCcu4 1vblUv5mHprc/iAdQ/ZodMRqslpCw9zrKX/S430JP/89i4MjfCgSwtyXNZsRZRWxLnE/gzpGaxSO aMb0aw2rrKtbS9lSbk3b0MDz1Av2jZGd+p32XZFX2ibww5HDbRNLT+HvGN9Jn1r6PrxgeLflg9bp zHR2Onep7Xznma6rrdey17p9L6afb9nYiQ+Akc6BAXwifbDzZ134+syu9Pbs7s7vd5/JqIPQlwks jw1tGaxxe4qVglTPg8GBeLEHGLIEzHcYtFkICskmi6WjiSCKtwBhZRguFEcFHNdms1xusTWXWwy6 QbGbyxes+XzBr8t3d+dyWW1oEDWOxblC3uw55Ja6PWP1xctSgjC+kGhMPRP6SwgLlbHktS1ZOJ2F WQnhbTlRSOVEZ11ySw7m+rRQ61s8lZuBN0E3hn9UmBq4nVewQB6ElDxw8nAFPSRPGWXaEJGnIh1L Jrfk7+exPDMYonN0ng4NPiaFBf1FkonZBw9mS2ZEkrOlrWh9ATlUE0j+q32eHmqqGrEAI+62mRFj ygbRohAFei9sPCX5peSbxYDYoQ1dwKPPrEBjWvoPTBmTTJ0ZlTIAZbGoDHQVNTweamGuS1YSl52E gh0E2bIAQOgnCKRlockQ5okE2RVcoB5JUgDeeG3VorWjqWxiCb38zJv9vY05crNXo9ZqmUzCzewZ 9Qux0BiH4Tq9qSF26JXerrcv1NnNbl/br5LMmp9edxBBzpDT4BOVRZN9P2jlxURTbwU27e5sX5Lt qOzeYzRqCSrSbQu+kYgL8Z/Aji16imSMxvCev779FVZ61u1kHYE5sL2l8gV2cJDS2AW9VDkB1B2n UOWk4VGFwaJVBhNPViGsNmYHTswZU/UTA5oBVz+/E+6OTrjOBd4LzmAzft1quDr4KcRHNaOuUV5G 3o0uBXjVww39qXE/qptvA29Y5t2owrvIlkYgiE4KEMGtChALwDcM0mEuErVGItFI+BH0RiNPgV4p nqtTzjJ27HLqdlSyOWHU7CJygkeUm/KQlQepx0WqGBxRWmBE1kgEy/cjMCJhcOR/YHC4Z/bu3Qfh J0n4KRyMkncbrKau+Vs0/H9gGCWfZMBQ38Ofwr1PcJLSDuezDuXZ5wc++e3qREf9LptZo7ek2rlS Mdvoi3hetrNUXWDF6ZEYlzh+jRdYvcuvRumUgfQvl6TavlMZy5uNlKFhmDqQCUT98e3wzUKDlXFE //Du0Pqz2LattN2tUnsR9bahnLmCcsYAGDAldtRiGlytxd+jLjlOOy+Tl+2/dqjHHCPMAeoNxzHq lOMsSaSpLLOcyjOraofJQYrQ6vUWr47Aa2por0pnLeP7RJLYWygmib1LU0eJSQIjGNYoLQeA1EGA iO4BcWkKiAl0uVIA8CAORHAa1IDPnOHPHChC/1Ii1HNPCVbPPWRTJYmRPhSxQEdrxVTy+ZFedLSy pcTksyXxK5OVu69PTH0Anfv3Xzg31v3W18/kj3yN9R2v/Oni9OG3YPDipWWl5ypjd9ZugGcQT825 Kivw36FTEEACFsXCEDyiP6Wf0t8w1GRsBbDMuMzW3TCkXm/cbtzJXgxer70Rut5wmzUu9fSBYSMe B0mPCHBo8DYljEZgZ+m43Wa0xm1Cl7MM3xeNQU9c6AFeGPND4IyV8SOiRyqPIDACwcixTivLOv1e rQ49ZWIh2xx0subIDL4PECihG1OElNchZQjIg2jjU4TIpXoJKBJ9xEvEaeImUUPM4DlEJOGPnIJQ ZtG2jxMpVnSR7azsC+vQxFmfvM9CJ9PM0myztoxnPxxWyqJaFLu+dMTMsw+VrA3fUwhhK5DN4QLT UJVyqRgyT+FAhH1t6PXDz+djRaSV/AcoYgG5BuzNhLslnX5sEigUusW4PFET8Dddmy6MjLxa+fk/ Ez3xvJ1O9mgqIW2pw/uQ5vj65ObFLyTHNwx05JvG/9iET/xt73ePbP1zJWOvq1RW0nbO4vOpWvfg 40Wr00UEHlIrstuO/f65vqF/n5NYrwEd0iIU7RD4RuzAkEa60dUPh/A1mjXagdB5/KLpvOMsqznA HmPnwviE6oQKc3EcBF3ufwRDcdADMSuPcRh0xwzQUIaTosfqU6shEYRoE8fxbivPu3lOG3Tz5rhG 1PRpcM0MJgLUES6HbvNSNBrpDC8mFyV5MZLiRS+6POhCxo8X6+qTgIeAn+Q/5e/w9/k5Xo208eDV ME8nZFp8UA1POIycnUxxjyVLiQ5allvtQrn6kdSSm+KSJqFQUz58vhVKMhTwz7e9xyokL70IR348 fbS/2e33OKK0W4URtTqLiU0V1zW4GtT8ieu8yeq2teL9rRUWhnd0BnxL2qIujlLX1hrFZ08uKW6j X8U2jTeSerMGnf7cLCLtv6PTj4OPRW8CQtrjNLfX6lQmh85mygZqgjrBdALHY7Ad9sK1yDeVoUrU Nt4CcaLGGyKYMvJ+SdstB62r91p02CFwC4r/YbvaY5u47/j97vyI47fPvnfs8+vs2I7ti+3YTi72 8SYPEgTh1daEjk48hIqg26pW60oZQ8XTAK1C3US7ZuvWdi0tg8CaoU5FGssUtqmd1H+qSVWnhW6V FtFpwKa1Dvv+zoGCNFm/++p81ln6fr7fz8Nnr69HCM25+t+XP5Y/k6mn5RPQv8uySZ7q6FdOCU1+ ljNkoVji9DyccKQ4xV3mSO6b6iW0Ej1CcGnPTbwCN0AObjQaLdiH+QWgnbo2v9C+NoxpTmNHEVXw lMIUsww00Agt0KkoXYCx7sWNy5KlInSXxfdl8m+DcfPudbWhLvXw6JtH1m4P+3rY+GDccnDn6DaP NF343n5ZcO3ypruAwv949MmV+bDWd/ykvvvHEUcWrfzBtzbVkhHtg72lh4+aqUQOJngCerjT9AwR RJZfEWYQ+APgjnR39afm6+TnLmqT2CRuISrW1U886KLccpdMPg2DRAYJlxuZzFYr0SUFRSRIXUHO zJtQB3AWz5tM1HPEFIkstB2kO8TwsKQ8E0ryjIccclMhirxNIWqfTJy1upuuSwgRVjCnDh+j91WL l5n3GZIxkk3IBm0J3Zds0tjWuRmcZBhd8sIFWMkIEa1bC555PNHzba7BLGNuSy70vGU4Sxhltu0Z q1Vjis2ahjxzbd8IybKBBbZgjf5fbY1ikiH9Yy96Xzgjeex8N7cx/NCGSjVTkV99vvPR7z9gembx s3rr/KTk9UX9u/ijZaWc7ttPrkgEH38OswVWyCswrxp6Xj/S0c/3k76Sukad0PYyTwSeZM4Efkv8 N2DblJ0Y2GujRgITxAMBqo/QAmQ42V0l37ChqlJPjicnkzcDt5ibVat/QNNoW6eSqFT7GdZcCGi0 khAHs4XCkldKWzXCQlBUiNb8NK1xLrtID4Jb0mhPZ9O2g8KRQNTepEFDaZ3ji7QeKIXocXqSPkG/ RJtpSA+6oxAX9SzKxuVTPrHtlnCZhp8b1R9o10zRqDofTRbzoi5OiZTID9pElmbhTzsf/42B4X2R AKC8KOpRX914AWwerueYdiZch5PCgvFLiA13TRXOCPcgqxmREyOJWQpHAQAYA4qFo81RB4w8gMeG C3D2amApDQzAycMJwrmTZWEf28Dfiztgfr+7slgTfeX7TViNLJepK28lnHZv98bg+MZyIZFxekZe v/aVrJ7ZIns7A6nh0MiE3hfPJbcn+EB477nHljHUgdaZ70R93tA+9qkBJRONVIb/s/jpB7o6chqV 9osOb3AH87VyOhfv++7ir49EaXb5X3/34SiepAxMUhMmSSE+15e9jVBS95SSugOOq7SN3Er90vRh 2NQtDUhDJFWJoA5bJ3I4XVbOakVyDHgugKwh2R7y5Xx1H+UD3XnbneCwp8LUdj5VMhhOVErXudsc KXM6d4g7yb3HmTkhGWrKxJCCnzv8pboyrkwq7yom5R0qipeYkPEoZIty+z2GQEEeBS2Cl6+XD8kn 5SmgUjkv6zIlz5DSdKL3Iw4vtjESC7Dg856FsaX7daA+2DFoNxZ4gDaHAFzY1APGQ6JBx4Ee4GOk MiNSGVRpCJGRukiDTDMoHKJFb4frKe6IP+y0NwrRlO4Rjv/IfzXOjfL9fJYaqQ2vO3B67ItmeDpU SgZFYWVK7l1VKORG/zzD/ol84sWCDboevf138wh0PY3263YuwItkR8AmkimcixIOZ22LsDH1VWFH 6mPBnArkRI1ZK06KD6UeFfeF9qR/lriQtvt68KTn+4u4gh/rabfJKCGjTAfbD/U8KxWF1BxCHBFp xmfTigKG0CqJIs9zdpIymS1mLy+mBSlkz9nrdsoOKF40H3Z7kXeGKusOdI1vcoeFdJO4JsyQx/VO sSnFx2OTMTI2Q+XOp65J+N+ARnE9ny7horuzfUVJD5fyki6tlyjpEqCaoSrn2hAtIQSWrdVa8MBp NQCg9t4BrdYNim1flwCb53LnLOSKia263YEklEGKmEmZicY2I+gsccAFEVaQhSae91Zh8D666K0K EbexlNvA8aVBKhFt4HtHDA2ErRYSiBphkA2YS3GGZliInKve2j3YaSoz2Vh31R3csvcv5fiyxZ0Z a8wd5QtdPSik+SwmdJo61vL9YXpPjvHaovFAKD1YKPZsfvblxU8r5IXWKHrj37tk1hJb8eriK9+O kNjt3X4Htu4I4L8adeg7ndgqWAlrihhENT/BQLqMomFxMzrGv4x+zr+eem3wbN2zFhbTw+4MPxae 438fNtuijtSGKGXiBYFMpdI1vabpyXCEFIRQUvcnk3otBeLpLS1vrp4lAMdTeijQ39lJWEuz1UQ2 q9hNKb4Wbr4UeS9CRuac5PyqS2gNoUPcFQ4nsX3s4udr+sBIsaZ3lWq1NbJTd55wnnWanMLaXn7N DPJjKMdAJz9pADw4t4JH+WQBGHkB44gxbM0bF8+NBYzqXXr1zFk7PFoHkK/nikGsDZQGbPD+YV38 0gAuuT+auVdAEwpFtuuSm8HP+sqAnAEd2qXyvu6t0UcUritdcEuxAIQHLlzbvIEWnAGpnIjWHy4r lXBg+QvbB6vJMJeR5ZjgctC5n/A1Mzu8lg1Sx4rF2A+P5Ld4OrNhxcXbPFLx1OJr4yE2O+z7xlim nkDdi/8c6+1i4uGMzHqULyr/ci3rI2MY2R2Lq6mjgGwF0fqDp1Wkcv0lGy/w3fwg/wp5gbwkXEjO 9M5Ss6ar/FXBOSRuE/eIlEnN53LmrnRQUAWvKZ/L9qSTktgRVs0WK1Cu3dHBmkrNyqyfsMbm0omg OzyDLutl1avbfUW3N+QlvUnH11lMjSfZKZZczx5if8FSMpuH7yh2qL8y9G4Z1cvj5ckyVZ6horrT dE3FrkfFrkfFG8sCuZ5Up9TrKrVePaSSsppXdZVSMbVW71Bro724DWyP4Maw+vNEvfUPzKyGJ2qf KuHDV8MZma5obZeKDiKGYem7JPvlDloI4FlDGtsGtY0qfCgD1QQaiQjOjHaw/D/OqwU4yuoKn/s/ 9t9kIdmYhbw22YRsdpNAHstCSEIePyQQQIEQyBaQIDBAqUERKWVKJ7YC4oggiGABwdGCYJO2DAiy aHlJCWAFCjUyA2NnLHTKY0IdhjJoYW+/e3c3hOhMx2bmy7n/fT++852zE3w2S9xQb7F7QNX80GeX f71+kKtomMfR25po1Q1L/JDRMwpL40qH9ymJUV8pn7Mh5Bi19Ynl9Zn2BFtcoj8rb+Boc/yfQ9Pu tU0pcnnNGL3Iqsf2GzOrSlm6rdaSg/cLtYRGaqS/RjPphukv9zaPOzj20xxt3PgMl8fjZFRdVaXU 1tW5AlMcgcCUKkVxOT0Op9NTU2vMJLOa8KOoeV9WVrWlOMjcpmuoO58m2uI2JruNeKfiqdIKbAHn rNwpAY/TPn7VuCCrMWPrhvgG5RTsrv1r3UcsmwLq86Z9luOqrTzh5qxAkjMJ/WOD6nN79kezHvsd SObdB1fvdMI8zGbCCWk1fK467HcRDY26HWyyzHVehtfF4beZvSJO+KJ4GiQriqWbU4kXMZIibleS iHxVlqqUcFOkX/i3GOJjFrIc//cmurIPerHNzw5ZuX3i4DJzQNbgnFR3tqZoDpvpa/DFrGjem+Cp KUhNaZ53ZOGz84r6ZaUkZtuT8+u3PVXJjPkN/vTTjyXEJPYdUJfz5OTKgf0HpaztY+mVGFel+kJ1 l0N7jhQ43WnZmb6sPo5sq6FbC8asTmEhtstMTfB9/srshvK84r4Jzj6FVmRUc3ZdiYl/UFWZHJtg dzU5Xyj3Fmf3m8Ruj0m2WeMtGpEi338u3n84TWAOc/EyH9udz3bnvlv426L7o7S8keUj389Qe49e 7ltbqpaWUU1trZme4XanKWxCvVqPBDnNjXzZXejzucxah2nWEquZwFwTMzMnWPLzx7q9hQUFXqq0 2Q4mufX4kbVmmuqu1wqtZlpDrjut1rSXzS89gghQCDnxUS3bTz5W88HXJjOD6pL9DYlBa05cUO1v xjSkwbXTzAZJjpWPkqOp86r9ak9uCKeU9BDE6PQXdXEkmgRLhkiq6GAI/tsj/yM0QbJETQtZlqpQ 1FXD4dNwJD1ClZIhj4m2JMiyn30fLRIfoY/qDK1cuDj01aZhdYNyMjx9bapitdmrChoGeec//YEj b2xFasuNzXlVA/vnZ+SGNtvttsTkwRU5TQGwwd/37PSUXHuyf+JbTTVgxIhQSWhLucc9MNuR6LBB PQ1r7pi1P2F72A6zXwkzDtuTFXvf/wwtTe2VkOBpSF1W6vV5vY8rR1hNakofX0yvWHvTzmvI0Ij0 XmcaQy8OfSq+4t/WFCuJv+2u4CFhT+z55tR9/cHq2FZrMSkkMjoxAjCyQiPoR7Hl9/Vv62NbKZkM 6vYX83dLGXOKkhJFK21RpzEPuPcGELC00jpLGc1iH7LeaFuttPIsjVg/fS4dVojfRF0Jxo1QyvjH 6L8UaAEygVrABEYDLwLXgHHAUIxZCrgxx5vAKWFR325Mo5naFb4VOK8HaJV+kh9H+QJwVj9Jr+H7 U6x/VF3DP9ID/LS2iB+2tPJDKJ9E+1L0Owcr5jiP+eK0RbQW35e0K4xwjm9QvwR1QYy7r6ZTb6WM Lqnp3K/OoFKN+L+UVjYP44qBEnWNqCMvrKmUhd5C+2l852HMZHy/g3oHyuMxf7boB1SgTwZsAebO x7ydaJ8k6tF3AM6TjX0HgWloO6n6aY3ip07Vz3+sTSJH5Nxvi3OLM0fPJPcf3tN3gHnF3GZ3hPf3 EA/39j/xJfb0OezzgA9nua+cod9rRTRfo9ABi4NeFTAu4t1b2WaglzabUox0vgF7HKXvo8H4FpgO TMX429pWfkG9Qyba+lvepPWoH6X4wLHBtFf5BV1FgHsS5y3AerrgCe5tneTCbHlvCmyG9g/+J5TF d46RzmIj97RV3I2xhgowvgRr3cI+OrVFbBWwGHvbC7wu9oP1i3DnM/DuB1gg1IZ5EsC9nwKFOFdL GPwKOHwBdcPQLwO+9cvIOhe62QuCe90ReZ8oLkUh776VQkA7cBd78QDHgBaMuwxbhHrsgzWAi+3o 7xd8BS++DnOTnxTcAN//gvohYu/yDOC34FjYb9hSZS5tBxYAKyxE70awDH2kvwjOin1G5u4U3BKc idoIN04obeyWPKfgVcRK3/sbeeUecHbBrS4LvxPcl/Y6fFrYjTRacFbM2WVPSj2oEP4ofKLLRvYj /BO6cUja6xSIcL0iaqN30WXX8A/R1mJJom2aH9wPwge81Fe9DQ36Enf4DI0RfqxtpC3KS+QwblIR 3nI85trcw24SMDrY05jvKO6zXTtDm2E3aR1KP62D6Xobv651sqN6m/KCKH/X9kS0r7AC3dt+aP3/ A+ULvY3monxD7+Bc66D1IkYYN1kxkBm1qN8L/ArIt/Znm6zNLGg0kh28uQMs0Ewq101w7ihVa32k fuegvtFC4AOjx7W3aRE7ynqrjcxjaaP5aiN8FGspX9ByATE/7HNdPApzrTxqv8OliI3ytYc9JTRf 6G7USt+Drkbs5Ee/ebuIDUKfRXwQGi0Q5iv/TRcv1yOGXH7Izx48TerGzzeUcvL15GVPK2KL0HcR W7D+dKy/DXO9J84v9REaJzRS6Bx8fmy0f0/bNb6VHYI+HJA6fIamRv0aEH5+DW1PRHQEOkz7pB4u oCZLgKaoQ2is1KNRNF0/R5kyBkViqraX75JaBn+KxlIZRzv42q44ms5vh/WMn5B6c4wfFP4p4ybi p/4OS9RPU5rUlUX0R+mHwgfvUTnWalR/B829z5egzqdWQntRr96iqbLtIrnUJRin8Q0iJqrPUI6M jxf5ArWaquXYl7ip3UPc3olYEZlP9oHVN4KTyAUsM+iY1IKpgiMUF9Vj8fZGM//YmM4/scymdr0e 55lFX+EsZ+QdBHm7vAcxNokXiLswJvF16l0eQp/PJMSYZn5Q3gfuqPtdyNgscgrMaVlAG+V9iDHL 6Z/WyfyqgD6Pfmb5FutgLb0SsWQ4P6wP569LbbUgxv0c53QhtvWiSsF7YyHnqoufjcZh9TDlqC38 PT2N78Dd5UXqvUL3RU4i8g2RQ+h/ELGfB+WY88jTYskU0LzgZTPNVXcAL1O8vgO5SJCvkLlCB+Wq Gm9VW5DfhPMTkSM0Sn9ZwHfqe6U258k9YA3h+3iP49DSALRkmPEqf19TaCBkZTARHw/MAUZEvj+J 4HgY7Fy4DxNp5X9pL/foLoorjt/d2d3fjwAGhEMsMSivBChRXiUEwpGHEAQVqTQUjI8CpRQsAgLl WOQhWKAKIcjjSKC80QbxWNDUIAkikOChAVItHhDwtID1WC0IJiAmO/3e2dlfftk80FP7x+fc3dmZ nTuzs/d+70jzGn2J60yc18eJxBy0pbAOFB/Iv4t58rCZLeeKUVQgjslS83bab4bhxyF5Q3xAo41L VCTm0wFxH3TTVCoWR+QFcVCeMxvSUDNNbhB/pslioSwR02m4mIL3raDDYq28LJbLLLEaZ7SM3hNH 5fNWL9pvNcS7zlGR8XvKMb+iHOd+aoL5+qv3z6csvL+FYiHOCcZFo3z1qenzWLM9NdL+jqnmL/vq ++n76Pu3HLlM+8fr5veqcehjDaGh2MMzoL1n3RH4JmM4rquYNQixJ4wY9Cil4XlLosor4E1cZ6Nv ObiA69ngD7heAr4FW8AU9Pva+250B+7TrZY0W8eZp9D/x2h7EmBc5d9w3wrXvXBdAn5EVPEv2Gng Hlx/A9BeYWt+BmIxBv0kz9VVt11C//XgNK43wz7stVXswXVjbfeCVWAu6KL0a0CX/B9srfnou9pA HuoazCnfyw76TrZ67tHf/2ZW55bMGlbvg7+OKH/qzXm+xfkpjIZjK8c3jqsc2ziecjyJWMRUFdc4 nyAQeFZ+wrGU4xnHUo5n9kKd97MQI5ZRvO8X/q03uF4VPcE5ms21mj2MUlVsx7VvEau7a83RizWs 05f7UKKq6d6mMOb7VJRTH+u8W6Jqy62oEW9R9d1wPy/qGm8o5yxnEC22M9wSzmeq9piAMROxDw/g vVz3KW1OzaAfWnDONNvgPanyMU/jIgc/TSXIm88gT5+2NtBZqwV/A61rH5aPgrNY/y5wGe+5U+xG rmgq95hroEPukq2MdbTZvIc2Gy7FIG6ui+ktD4YvyIOhBEoKkyx0XpOFFmJL+FNZHMqSxU6qql3j /e+LLbvqX0dpEtZYv4loLr3mGroI/sGvSZwnouf1x4VW4VsVy/6+vrrZP6bPWutazlyt9UKNuqB6 /fChdQV6orW8L6IVB6NmvIh6YAQ9FNnjgC/+XNiXPXX9k/ofeUIsVdqti6YnxjdFe56un7DPOL8F FK90EOfyX8ljYj/rIXcT9qeEEWXIv8fp5+IVmqnX0FHp2VRqqOJHoqoDB6vzl0qONZmGwI80TVvU qYvUfLHyM+XjOACNZGXgvQnyTBQ7QYX5CSWBbOSYInESJMhXzWHuJoWFcz3MPYK9u6bmQplgdYQe +Tf01zK6FWejGVthUy/eOwW+PygUQykE5gASS1F3YK/EVLx/Pzm8Rus2Xoe7Hn0LRCv1Lyb7Y5xG lORkghis43fIkatRqyTQSPu4m2Nloi5rCRJosDiFczEIdS0wRsg/GcWwxdSXMdOpH87EAjOGwkYe 6pBMIxE6eDfI9nSzcVaRTEfBP1HTJYH24BBj5pohTzcbE/EfbcUZHA0kKMde/MJMNbqj/ZpmRxRh IMQthm2OolwjDj69QRnmAGhbzCOa0Jog6D/WA/VHLr1uPW3MtEbRmgADg2As27uDoJ1t+yC6vWUQ tLMdEATtA2rxo65+dflRV3tiELQn/gB+1PXetkHQ3rYe/4YFQfuw7+FHXfvcLgja29Xjx4NB0P5g 0A9oqHVgKXQU9Jr8DPFqOiy0NcXDVsI2AFmejpOTvD6q30OgE5gBcO++C7ZWIZ9B+y5cf1m9vRLv dKHR5YewKWAHgA/uC2iDBpR90OcG7jsD1mnQgu4oPa4RiME19Kp7N3DBRRAHeEy2N58az3Pfjvfh Of1Sr+8yrrmueNnzXUI3utdhMzHmtqo1qD3h+mIZ7h3tN9ZPgz0ktKWcDGYCCR4BT4AZeo/GYMwx /R74In8LBnpxQebgX+0vKhAP4akdR285t9J4tlY7FXPvsOaR0DkiGbFyEzR8Z65LxVvyFasNPSDW o30D5VnJ0NODZCXy0jVrO/on0VqnC/TPXLkVcbubohx5rBtifQ7NUjmiDWJ3HjXiOaxYxM1sSkM8 3abibCqep8rNnMO47lQ5FbmgQQvoijjKQXybAX+SQruhX8aj/nxJZlkZck04CfqlnyxyTskZdgu5 qMEC+W6oOWJ2ucxAvkq2N9HH1nWaGsl/mQZZ06izb8NnoXfioSUH0E+t9dSB53Nmce50UyJza62F Oucd7OUs8Dq+xXhSObYC9UTF/eyzyn3QaFyfeppJtoJPechTufDHhT/bIlpR0izUbGnOFeT1G9Qx 3EYethcjnmfQcszV25tTfo08vYJzpHp/X/ivNaSzCPvzOBm+Zb0R0KVN7MkyXzwrt3u6VO7z9Wnk HbmywI6X26whRklQ1/g6KqIptFb159DrOaYs8qe//iob0B19qZVYTLH2WPoH644a1vfpBr7tZOzf 25TOmsD5NaXbW2BT6HM7mZ6zOtDn0ODPhXrLfDtRbmd9Zq/AmqDX+IzZU6gkNIba4vuh3pIv6e+0 kpROlBmwQ7z/X87x/g13N9qguw2oblnu1YZ0zostLseJA16fyn2wp9DeD7YYvOf9zzQS4xDL3NW4 Rtwx8E/TVs0eD+Ne0Jjbova5VGn66ra1Pmu8jwd5/QHbOHAvaq/dlCbke4pqP4Z/bWNED/t6slYr N/r3OFdLoKVmRPSsr6MDFlq0EM+bVbdyuGddqc4aznHQ+rq6upXf6HtRl36N0tPHq2oUZavp6+pW Nojo65vZqtomy1sP/QTrGQ0bh/WUBXR7B21FDT1/3iDsD2Io7WHr5BLWxuv3rK4N90Ws1uURbV/d LsAaL7JfPFb14/o21d1gdcdc9cHnDtjpiPvp6lysj0bp+1qwd9IysM75iOaBfN9yrVgfThYtAytD 79A8kB9lTzCqLvAYGHUdQUynJYz1R5oH8qPsCYVXZ9QAc74Pyvz5nKvw9yr8fQ36vx7sPpTtHEV/ jxNcf9SHk415sul8qADzFGBMGeYpU/YE4+97ZC/1vvjr8/2NzK/f+z9/x+vy2/q42Xf5odZdn+/R eLUN9de2CLZRdZ953+B3LMRQLJXiW5aDUo5P6H/ew+gRdXbSNN49xy0gTtIXoBR9EzQ9apyDj+RT Cn3P/yLjCMNyBObcSWsx35sexsRa9+eqYXFscspg36d4RtdkBdYl2svxXaFjX3iaLEUsGM1xlGNN mGQh/vFd1gGaUKX5PLCehvjXN+H5IS/eURJiUj9t86yh8jyD9VYCF362Az2ACVaD5qA1nj0Ji7rQ 2Kj3PQZtl8RdcgfYhmvkQ+oOJiK35WmdzFqa9XBLr933y43xY6/oIldY2XIF6wYxEBpkA755U1nE QCswyEHUQISok9iJ+27ytPVX0BB9+F84gv6dNGsRQzOop3ge7f/RDMaYSyCFmosYuld8QYug4SbZ z9J87O1fxGP0ImLDiyJFfmWWyjMCGd2aIPeKZIzpCt8ELL+jnFaKLXKfGEnjrFU0TjxCS8UYcBL0 V2RBw50zP5Y3zDhaaubTq+K/7JcPcFRHHcd/b/fd5Q/hT9NgSKC5R+Au/8pdeC9p0mDIJRnShvIn hFDigMYzucBBchcuR4FmaqCAViqjtqPSwhhktLaQEnoRGhoa4ihqizajTp3SQUEsVh2BisyU6dg8 v7vvYtWpMtM66jjvbj7vt2/3t7/dt/vb3d9ep51cR/zxCO2Cb+zhf6Ld/MfQidOzIh7hPcjPpOt8 XClXH1WW8mLEMxPk026WRxtYD2xl0WfBZ5Q3aCvoYvVUiuhgDfNThN9PYVYI6qmHZVAUcifYymrN 15Vm2seaYedR+hL2xd2skvawcxRidcSV12g7WwDdTfQQyzNvwl6qctO8xJrN37FKxNx1ZlR5zbwI +RLbZJ6HzscdKear6k56UX0HccdmnC8H6AfqDfMN9SydUt82d6MM95x3DwPM/bvfwfxeVbuVPXwt 4mlMfDKYkOwIgFRWWXkyjdsHIV/8hL+L8x5z3eIYwx7tQDyXLGPLA6IMdaIiTgDfFGcvzmuVX6YA rOAeNC78L8OKtc2zWJ8lf11Dou5exNcu0eT4EHRwpzMnsy7zZ3g/IuMquTbG92O9TUI6Q8VdDW0c ZRfMPtEW1s2YPF9xn8L45vMz5mHHk+Z3mcf8vlhv0q//QAVqAdbWhL2fj+9Xh624B/X7xVoW+VL3 DjNb2v3J+EFx3uOMHrLsI+azyBPxmDwTXGZQxNTyvNtrPsXuG/+eXAd7zWeF37Bs+EE2+Vgj9Qhf UdrMr4AB9gjym2kv5nkjeBzca2F+NZFXpJxB20UUBFFWaAbgVxFQAn96EH7Yg5GdD1sH4FcKbG1g n5I2D4Od8K0dyjW6H6xmM4U0r6Me7rfmCoB4d/xXkAexbzzIVuNbs7Dn1CMuqTPPIn1RxphWnHu7 mCPsJ1duda69Xwzwd/HALc7vW+o/ROUiBkTf2tVXcXdMxMUY6xfEnuo4LOJi6ZMiXpyOvfgQytbi jpoh7qlCwu7yCX9LxGtDExJ7ygK0kTlx58L4jIDj4Dz4sjVuJvbUcdwjqEHso0lTSIMP/FLYTsTN pXIdiP3017TEiu2wn07E5u/F2jImFPdErKmX+SL4Zyctht0NAOuV8kAq2vsW2gnLuP0xc1ScN47H KIy8H6FsFuQl8Db4BfgNOAPeAZcT6TjGKyDGZSJedWwzn0PdnY4RxN8xK551BmkOfOEYr6Qtygk6 BN5CnScEOF92KD1Kqhmz9gJ5cvwLFNzA+FMWqgcctXDkAtyyHK8QOWeATxMl7cL+g5Mq5YdEk/A1 af24IL1ONDUd/JboNuwY6VvBn+GI/RYZTovpfotMzEoW9qrsbxDNwsmWg9ufhhvibOw6cw8Reb6G 4B76hU8T3akTeW9gUmBbx8ZnYIZL0aeyUaK7wYJmokrUrYKdavS/9qdEi268P3WFFvdCbzG+7T7I ZTm4UOKmugIeshL9WYV+rV5o8bF9RGug94m1RJ/8IlEA7bbusghi92vHSbwOt9QQvnVjlKgTRJYQ bUqz+V+hG2zOsLGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx+behEKVcpuv0UXqY HMRoGvloFZF6jjWTineiKXQUT07it0E+RTqJXsGbQtavVClPpDm5lM5EWkX684m0E+kjiXQSrVNe hqaipgibbH4irdBCtj+RZjSFnUukOfLfTKRVWsjdibQT6dZEGv3hX6dnSCOdivEvR6qJ1lMQcilF KAxitI26ZE4t3qJIi2cA+SGp4UVJNXXgr1Ej8tahfoy65VsQMgjtB/Bsg2YTyjtlrkbLILdIrQjy ArCkoVSUBEBMttEGHVEWpY3Ii1D7B+ifsBqWFq16q/AWwpvokUYrkQrIN6vlMHJ90oImba+X/deo FW+bUSr6FZLa3mc0vbi4XGtaH9SWRsKR2LauoFYbiXZFooFYKBL2atUdHVpjaN36WLfWGOwORh8I tnlrlzTU1NQUNYU6g93LglsaI52BcMPKefWxQEeodWnThyuW+RoKNFmihbq1gBaLBtqCnYHoRi3S /k87q4XCWgxlq8KhWLBNWxkLxGApEG7zRaJaBCVRrTWyORyLhoLd3v+gw9TSEmqgGvkv+hv3sZzn PddpwETOo3o5mR3QakVvmqS9dZi2DulCH87Wf7P2/9Wyea6JqtP4KSoGfnAQHAMOc5QPDy5apPuH IIu8UsbzC/STsiDbo2+vvp0PUx8YAGNAxdY5TC7A+DAboDxyQflk/CMzZa2heE1NInFXuZUYLJyn X6hO5UN0DTA+xE9SvlVrMN+rv1U9FRnYcPnzpACeTDA/wk9j1oTS6fjcQv0kP8F3xCtcU6sz+SBN 43HSQAPoAheBE70bpAvgGjCBSun86filz7lGeJ+yUXkSVvfR48mKP83Vq/Y6WC/r5axlmB0jxRxV MuNZ7fqQOToYzG5Hv7cr3SLjRb5LyRQdMkfZQHy+4R+C8EoxiHGS0pNnydluS87SpIzPsbSzjIOn ME7HwEU2cJz7+ewCNHR9sMJTqZ/iD4s/VSTTcZffvdbIGcJ3rm2DwtVBt9fIwKuYmNAI34Ex2iOf U0SeT58mylas0dOEXLZCzxXynqX6FGGizkiF8Kd47tHT3bXNUimuG6JOvNBIF6pllXr6MAxWkmHe 8E93Vxoz3KVr9GluT4nudBcaaWh/yBz3z3XPM9IqfIb+hPuw+wX3S27V4b4LpXq5nlVRUFFewWe4 M2Hw2/nucrd6iu8Qf3Ink3+aa6pLdN611cUmuYoNfNUfB13ys7eLP7mgNN1V1pI0kMRanANOltsP /ZR+Hxo+70/td+XquXOKGsUn9cYLDClyxaD0xnM0WHvz+ZwiQ8/BYAhP6z2xZLmue+40qlPNq7yX 7saH3YQsgvw9qlQYGmoOVtXpOUL6KvR0YclryFd4qbTvMVTxWr+4REgMpBSzjRkQ/rQ7jFxPsa7n eoxytH/Tn+pB4ymembP1PSNoSuG94k8efJjXVeZy+pxVTt7HBthpNsbUPj7AT/Mxrkag9QXOXdzH q/hy3sIdU6tL2RVMbguefeAC4OTDswpE5NsAfEih5XjCIiIPH55VMlUlvFiWtPxDiVgfCo/zOLuC /zH8YcWfXaZQseJXmKJQisIomTIzEeKk35bsr57EetgcKqHJSqV8lsnnTH92yeS/sF5tsW0UUXRm 43g3j2kcJykubjybrL1AtgksNqSlJH7EThErIKlT5C1tCO+GVijUcaWKpOEVCSoVPkBUKhAJBFKU hWq8tGVTKkBC4i8S4o8fhCBEfPYLiUdk7sxaDSAEP4y898zcc+69s6PrXfvVFHkxRY6kiJ0iEyly V4rsSpEbUyQbkm6DRw+Rotzi34X9QtgxYXdlrlfJVZV8qpLXVXJSJU+q5CGVPKiSvEqyBA/D7zKC hoS9RdhubvHmhbZ72lDTZ3gTnqKkoQpH24Wo1OXqKepJna6eBlDc2Cc0u0MKopiCgW2Ey4ErUEf4 qRfgfoxM/hTAvyEN3w943tX7qIc/9MHhObNdeBnpPAq/j2I4AfgecsT6XWQKfKeOb7vaMQh7i0O2 Cb+JNF4ECiRFkROuPgD0Mdc8TrPt+CjU5O4jKC5kBWgRjul6mObGlugV3INiEl+iC/pJugnxCZf+ mvQU7NJf4p7kuPQn3cOw+hG4cy5dN2GVaaE/mOv0e/Nl+rXuSfgS/Upfo2sJLwDCj00hPK+LJB/E wAn6JXOSntWX6Gt+7tNxIXoBDtPJdNDn4ZYq2jqdgTSPasfppJ/qsCZ2cGBDrIqwH4D7ksJ5r84T d9B95hN0VHfoiLlGh7VJegcF/yW6J75OBzVRa0AT4X0xuDnYyU2aQ28wHXpg8Ar+Esn4NFxGZkBe kJ+Wp+XHZUvOyLvl2+V+uVfukTuVsBJStimtSrOiKEEloEgKUjq92ncZA8E3oDMY4hAMcBsQ85DE Lf+DAO8YCSsSuhuxjgZLsoo5NmhYnlzbz3YbFmsae6BUxfgVG1vs80eQ9bDKfi5qHm4eP8gatRxm YQtZE7kIiJn0kofRRMnDNR6xGGXhkRK8xHBm8UyUo714xrbR9hPpSDo83L5nNP8PZqpuja0RMf46 It3sDatYYivdNruVT2rdtsX2FdVDpVVpXnqmkF+V5jjYpVU8Ks0X9nM/Hs3b12TQUHMgg6ae82UL KMZl0N0LQjbpyyhEgyzBgcuWERUyipe5DNqM66oOLeSrlApNYAY5QuMEZnxNQmg2/qRpDKENodlo DIly1wlJPA4SM84l1d44CKrxXkGPb9GaT8/79Lygn9qikz694tMrQBv/03gs91+KwnQxh62xUlVB OXvkkI/bQzPDog/aLw49G72MdzZ8g1oMmzVrOdai5VA6HTFCd+KbDwdbWRB8Mlxcvrcncip6OYDg yLm8FdykTvVn+7Ocgnbm1DZwt9WpyKm9PVBkuU6FwN0ORaCPB4rQl0cLrG8KQMvbKFKYzsOnDmUY lUqlXJ6t8AEBetFiQ+MHS1VdL7AdU3nbKESm87P/cv/IYn0QlOZBslxgGQgqlw0RZxgVfwK5+fTv Y9b3CSkyytf8mOct8ywGhiP1at9+FNsp3roXjWREN5KrtasNz1XDSS62cZnvD+Ihm5+jLPKWjT8G AG9bqJMNCmVuZHN0cmVhbQ1lbmRvYmoNMzU5NSAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9u dERlc2NyaXB0b3IgMjQyOCAwIFIvTGFzdENoYXIgMTQ4L1dpZHRoc1syNTAgMCAwIDAgMCAwIDc3 OCAwIDAgMCAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCAzMzMgMCAwIDY3NSAwIDUwMCAwIDYxMSA2MTEgNjY3IDcyMiA2MTEgMCA3MjIg NzIyIDMzMyAwIDAgNTU2IDgzMyA2NjcgNzIyIDYxMSAwIDYxMSA1MDAgNTU2IDcyMiAwIDgzMyAw IDAgMCAwIDAgMCAwIDUwMCAwIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgMjc4IDI3 OCA0NDQgMjc4IDcyMiA1MDAgNTAwIDUwMCA1MDAgMzg5IDM4OSAyNzggNTAwIDQ0NCA2NjcgNDQ0 IDQ0NCAzODkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NTU2IDU1Nl0vQmFzZUZvbnQvRFRaSFBaK1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9GaXJzdENo YXIgMzIvVG9Vbmljb2RlIDM1OTYgMCBSL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0Zv bnQ+Pg1lbmRvYmoNMzU5NiAwIG9iajw8L0xlbmd0aCA1MTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJXJTLauNAEEX3+opeJougV3VVDMLg2Al4MQ/GMx8gS21HEEtClhf+++mrGzIwAttH tPr69IVSut3v9n03u/TnNDSHMLtT17dTuA63qQnuGM5dn+SFa7tm/rxbvptLPSZp3Hy4X+dw2fen Iakql/6Ki9d5uruHTTscw2OS/pjaMHX92T382R4eXXq4jeNHuIR+dplbr10bTjHoWz1+ry/Bpcu2 p30b17v5/hT3/Hvi930Mrljuc8o0QxuuY92Eqe7PIamyeK1d9RavdRL69r91VW47npr3ekqqAg9n WfyJrGQFb8lb8I68A7+SX8Fv5PhHVcmcEjllTs7BBbkAl+QSLGQBe7IH06GEQ2lkAz+Tn8Er8gq8 IW/A9CzhWdKthJvQR+Aj9BH4CH0EPkIfgY/QR+AjdBA4CB0EDkIHgYOwK0FXQgeBg7ArQVdCH4GP Z1ceXXn6ePh4+nj4ePp4+Hj6ePh4+nj4eGZ6ZCrPqDijMlORqcxUZCozFZnKTEWmsnNF58p8Rb7y vIrzKs+rOK+yc0Xn+kJ+AbMHRQ/KHhQ9KHtQ9KB0VjgbezD0YPQ3+Bv9Df5Gf4O/0d/gb/Q3+Bv9 Df5Gf4O/0d/gb/Q3+Bv9Df4r5BdZDueVkHfL4HxOCEYoTrr7ms/mNk1xNJfXwTKTmMauD19vjHEY XdyFT/JXgAEAP50IXA0KZW5kc3RyZWFtDWVuZG9iag0zNTk5IDAgb2JqPDwvTGVuZ3RoIDQwNDcv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJtFdZc9u6Ge1rNZP/wEd6JiQW7ncSZ7wldefG uY3V6UPS0VAkJDHhFoK0o/z4ttgowbLsNiE6HpobcAAeAed859sMvLuF1prOwNsKWpfN7G8zcNb1 xSrNeuvVK/DBAr+n22bordPT88sLawYt/oesrzNkFRbvjnj38/kMzOf8xXzF2swz1mh+z/5Zc2oh yM8/+KPOQlgiYMsLLRy5YZRE1rya2QifzL/Mruazq/dsHHDbpjWbwX5Y1/cS9j8KPKtb7+YtB0Zy YKRmBzl25CcuDMKQg3+yP5IV6U682CZ1RuhvJ/+c//XRWOxT67XFWpyoUZ8Bx8EO3EaumvkO6Czr h7Sck++9Zf/r33/6888B8o/kZOUz29I5OUbME4iB/wDxk30zVEvSWc3K2jQDJZumzKm13Fq0T3ti Ncs+LWqSWyvBUVNZf3dvXeuC1HSg1vnAnkY2SYeX1qbv298A+DYU2Ve+SKibiUbuurkD31Y5KOqc fHc3fVVO5hh5e46xCY41QEMca4ifbMXN/f39SRTYrlhwkZ0JakqyTkvA2F6tHLkO26brKUAnkW8j B0aOuspJlda5IxmnbVNT4rb5ajKZEO3J9EyQqQEaIlND/GQLFn3bTUnrZk0FsqIvfrCltilakHV7 CsFUZsJ4rxO2b4AZHdAMMzqiXGZUW2eMoWZTNIIlmt4RwJZQ08qN/IVkPbgkq3Qoezel7ffJbEXR nq3ABFsaoCG2NMRHm3JcTqS+KyRFdUXqnu3NmtxT8KbIXyM/SSbTFGr+EJqgKTTtDw+mqFjq74ua bzRC3WXx40szdHVaUkHY/hVTsabjZwxhAhAEOAR5WpRbFLufXwjlP2LkP0NeoAl/ZIK8wLTw64iP 1hit0q5fd0UulL8VUi53YlXUNaFNny7a5p50ouGCt1yk+V3KKpN8UZGedEW9XhT1qktp3w3scxlE YpOFDlUy36b9Ik/7dPJi9TVviE3w7Zv2Bh3xEd/LgbLihdJ7Qr6KtZq2bG0i7EAfXCbz+e9X72PI S5LJRGHNKhITRGHjVoEPrUIjai2rCqZ3JNtUJC9SSRcr+LOSbWi5zNIc9E3r9KR2xAJ1+AJ1vBAG 4AbByRwizUAQNEGihohcbIJE9JyD3BWsjBv6opRCyRksalrkRPFHG1kvZ1wqRykA7VCWrLIDbbpm z3OTlgz1Ql+Wke4IOoVXDRe5KAoNEPtgqofEtpLMikURQEl3V+wYFKJ4ghCyjSSLINEMBpmIFjqi mTWoIz5WvDURVJUk7VhJnMp9ra22PWtUrTi2RFmVw1yjaNi+zjYkH0piZP0FsWYfyES20BENsRnr /lGotZSxdNUTRYogVOYKRislOelZUeNmq+rNR/nk+vK1hyMvwtZkykLNSJCJ0KEjGqIsfMZJlmnZ F1WjUuogyRt9GCyps/zhsEWqG4ieaB1mzxDGKHwJX3p+iGESvVwxgXR5abmdzG6gW4yJkKIjGmI3 OLQYPdIVvaz0JK88mZzV+dUdM24K/hDb+ZyxwejHyHb+ss1la+eStGWzpc712N25bVb9vZIHp2+c 26FtG/aLvC/WnZQC/lD8SO94wWpED3wtWCAT4UdHNES//4wRLTdSXdNlM/SC/UWaSYlgYiDueUyM JtdCgaf7kImkoyMaYsp7zofKNPu6KcqSkpoI7VxvT4LAFvRlA9vNFXegtCqY/+Tku9tu2smkYd1u TMQVHdEQafhIXNlrodtXWU16wRIrtYuMai/35XiMoI8dwbHDSf78gjIV9aFNMlLccRGNnIo9F46+ F9rVUOcsQJoIPAHUfcpE4tERf5brC7yAx8jWID+9gtA/hzCI1OFBiC7ZgeURnI3HaRSwtojZkB+y I2bPkOwjrgPZN2B9/IuDd2hsc+rFfDyOd3Ea6Hi8H4OQY4aqr6/OF7LN+Vt2fquwQtkWs7PHMDxv fz9iiQPL8fk7L1RzU/PCvhpr/J5oj+tH6lvUPYOX82HfkLxSHDDeIOuH2EDI086+vNbf8fl5sZpv dPAOqvcHfXCivl19M58T54vzzK/95HTicvUTzfixiWypI5qRBh1xJw3jlneXDdNM6fqsRMIODBwE hQUBD4VBFPnBAi3kZpehCGPbaYfMoUMrbb4iTsYSaO98YfrLI9RUEfBjzc+ZsBlgNTbt5zriI5fK qjZrBKcfhu6iqRjmFtxwTtlOSAS7MEEQR0bCpR9ppo5NhEsd0RBd0TOmzrLhltQ1KYv1RnoU9292 mKEn1Owbm0iLOqIhS9Eh/5ulcDkTVhEq6dflPjhFCI++8Fbpd6x0W+m3aIjkWbQ7U+2SI/4RKP1O pH+J/rH0tEN9RQpT9OcTZB+BuadcSL3FUGmz8gsU7r2Q9xP6PLbh93w+Z+pZpK4Ddc2fXch7gRHs 2wlt575zrvUZ25xpY11M1n9fK1ewb2Jt+b9erjyx9TTEx8GP7TaS70KfTHHqxpHyXpKUkjEFqkYx b6S/XrDC0eMG4rb5avKO9XRXDUyw6hl3Ve+Iq+4FrcjSdbMcaFETSqWkSccVLsvJAjdX/7hFJ1Fo IyCeJImXAPFzOA/sFtryh2jKkqVD557V306ffiXMp50tSbvpdot1uw1N0I2N2y1+zm5LpxUcbxh7 gKZ3ZB8Owbph0WQt7thj0JZpXfT3BSVuStvvk7lDuvdGJrhDxr0XPee9Tf3U/gdtx8sVVlH7C8zZ mkwW1J04NkEWNO/E8H934mPhTpgf3JunMNIzee0rI9wFujMVmI6EOL3/Dk8FMWGusTQ0Yb6juZ+r EHel8Pl4WIYj0c5Xz8bAGar3sRYUR7zxPtbaefsAx+f6VKAcQ6PgIlbzPxgTHwTbaBdsH44VHRlL GL2vwuK5NHfB4bnG19up5u7FurknBparjmhmb+uIj/d2S6UQRkwITwLp9uCWdHc8pYF3/GXak8Ul q7zvSLe4Eo0TrppXOwEd327B2ftrMFUCvEizdg+a4DQybe06os4pdvuiIjQvaJv22UaQOVo8t3UI VmQJUAiWTt5UBQoX/CHEKHAwgp9fsDXtpMzQse3EQZJM5zLUfNtDJrgMf923n5BTHfJX5NRXbUVG OJCMeCcZp8Gu/YGM7qRllDElwSPWTuZ8KS94lCyVgUYsXb52EqzmwNuIecZq/Ei2O5SwnQ34EnOH dcQydvMIJEb46uGcf6ZvdKQvTk4R5jqOWUfP/7/oZ6DVRh42sT4D07WRjvhIP3PSy4Ko6Hk9dKSM RxH48Mf1zfWHG4iAuIce8iZvbF+rkzzPBHH+r9dJTxCnIT4mbmDxZF+D76xHVJUPUqUqMENWdBko MD2sObbnmyAOG3ds/Ixjk7p/5Nc3jLTFx0av0CV7IsC8ufm4uL58jYIkmMwe0r05MMEeMu7N6Lg3 C/baIWvcZlM07rr5D+vlttu4DYThJ+g79GqRXCSiSOoEbBLYTrsI0KDBpr1qAYGxFEe7OtWys/Xb l4ehNbblJLV4EUTmYUT+4nC+/9V7+HP2u3efZ4XQ4pknUG7+XN0U2ZW88mJ/tGwEl+HQhWzk9DJ8 RDYU8a8zrRc/uxRlmS9e8nrTNj/ksfN9qk/cWEFogu/9yIEgOKIjLsEhT+KSEFmfBPjEWizglkFb F/R8oW2W37OJrenbdsspU2Qt1bwE1haABVJ/M2iztggsk2WWADGP5adkz3KpZx73jMApmjsDZoF9 BsgWqvUE8d6+naIEjXFFjF0cqfj0injsSKGQ6kjhY8PtsXnL9cZGSu10Lara8aEZs507geMydMTw UZDj/Bie6ejPEOL6mrj4DOHp9fXYZ0AhT8rsKXwKkHXQVSTQRlCfdROItNVYZjOII7ehCRye7S2C nIXO/KSfv42J3InKPA3vcg0UMpjKtdPYOABGTZv+9OqmIPA/hGelxRTmJSYG801M+ivcONu1jD46 AYILTlwcncA1XOCIB3BRZOKlsYXSN2jW5cvXYp4/FWVZ1AtP427eFZnEuEKUnm0XlS2uz+OLK0e0 IRncgY7cNW3giB/S8dHoOAW9viINbdvk/uuz+KdTEv48qOF7+6SXYRjppVFGuZZvZ4unfAuGQIe7 MLg4oqNvwd4wuEPfos2eu7c+yOT+Lr3N27LZVLIlvRftpZwy+lhTVOC5C8uLIzqSkr5heYu23BNS tnhFneX/3rRikV/dPfymnNxtvhJFST/d5/X6ikREXraEfJJehFDCEj/iNNI1RlDyHPz905xFc3Xl B6PdHSWodnPuQmFyeu0+ojCKeKBwV4nlarEsslrKqBWWvytRe+36qSy6F+9B3r/RWfMtn6+69I/z hJ41Tfm9WHXeXS29Xy3Sx1VRrcu17mXQexExcvmyqsqxAvsJrnCBA4FxREdwhEOeBEdH+fU62LFG HJ4nAEcAM9o6UNOvwQKgamubOLIh5BCm1Bw934LQ3hgLUTvWaIqAJ0YgNIH32zXKNv4LwNUU2lgP ZWq/8ece1vB7MdxtYdCuJTbvIVMDVhqw5Fgm38vYtVyWDEpkB4n7hdOJEZCGPZGqoMSS3g75DdLZ B05D3BdquQaKvCmFj2g3ainR+j/9R837tS9kiGTJ++Ls0eW4QuxHuBCHLlIvcl2IccSDuy2vc315 LTbngfy5aF49/TufN6/5cuNt7760Eq0sz1/uvjzmpbzoiqbu0plY5YtmKeeGZy6KsR/iYhy5kDN0 XYxxxEM5m/pibWrEspt739de16y1oPNc6uM1WZt+W5eblMrLIFX1pMxXK128mRsFOS62sQsFueti iyMeKFgtclNin5r1ylMKebOmavWDEo2EslQ7qZoMV83EhVLMtS/EEY9jic7atmcQrxJZ0TV1uhBd Kuos1Qm7LOapFFa+eaNnpjqrW20dzbRSZnO3SjOxEqPFpcgsBsSFuNS1WcQRD8SthbrhRKlEgoTW J3LdeYJd+Dp16aXo2pusma+VIbmSLo+N1s1H9STwXejmn15PjhVvFFKhHLNYJslBoQGbXSf08y7a 6HYGVTyAij0zOKX7LNYEBtlsn2pT/YoKAkA2XeVnhhA0JaDqbsdigiAWx2YGwahFMdWmUInDs10n AdQDcpgCXajfun9gv2xovyFCzMCQyFYHQFj9ngnM42b80BiNgRT2xI1+mtzUfm97jNX62vfNYO9q f1E/fouoe/tW+9Faqn1P3yO7oaQKwksWR9HuMb44H2CsD5wy4u8ahgipNOmZz34VxYgcTpfZNZgH PrTz64jrvsFd/o+EjVG5DaiDfI1Pr7ZHhEQRTzFegTU8vsmaAwMy642Z+ibWiNls1eYJ8T0ebzNY jVGH1cbfzxrfZn0M77Q3RbhnsII9o4VPOR4D2aDa9P8J9EOf/h2bPr7nPbaaRH3GSxM68hxFCEYC 5uAcRa5ZJHoDReq2zUyNrIqdEvifAAMAQuWf8w0KZW5kc3RyZWFtDWVuZG9iag0zNjAzIDAgb2Jq PDwvTGVuZ3RoIDMyMzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJrFdrb9tGFt2va6D/ gZ8WEhCK8+DwsXAcyM5ju0jbbK1vyUIYU2OJLUWyHMqK+uN3986D0nitOkk5MMbkvM4Mj+69597f LqJ3tyhYy4vo7RYFr5uLf11E864v73nRB5eX0U9B9J4fml0fXF1dv74JLlCg/nDw6wUOykBtx2r7 9eIiWizUxOIe1iwKWLTYw79gIQOM1PN3NdQFmBgEEtAkIOksSfM0WGwvJphOF79cvFlcvPkBzolu W16rG7zn9TqYiHp6usAspjn8TxkNuvXxC8wVsLkCtvdE6pSUsBkjOdbHsHhmzzkeMS/6Ha8W4nMf TP7z37/8dTjq6xDxjDD1aauLSeB+waPPeB6RxY8QP042fd/+PYr2+/00ZZOZXJdFJXhX1utNs5Ni 1nRTmk7W0avfXtbNSkQkQenfqruXePrvxT+/zOEzH4apQxXzQZWD6IkqB/EJVfu7X5pdV/NqVjTb qBZ7GecEpbNNv61Gk4OwQ07igxwH0RM5DuITcmrZc205TV2VtdAUSUkjPb5UZEWtnhdSLs0LmJ0U MiIIo6gX9aorqxmX7Vgqkyx3qEw9UOkifiuVN2SJznDpQn68RCi+RoiltlGE8GtoxDQ2H9pVymAt hqAXv4UWw1gCLYf3DNrcGVMNxhi261VfYSGLic0ejZvYs2ASq7Nj+27Xa0zb1/PXdi55PK/uDrBm LDN9/WT2DGSxhzOgf/32dH+9NzVcxDf2jvPTXnZjv2FYa79BN3t2/MaMM8sbJldjzSlNHXPKfJiT g+jHM13EpxF+y7t+K3rRSe2V/UaE2h8xSlHYrLkIxWc4aCVDvTTUa6cETcKVaKvmsBV17yXIJYkr lrkPKpM/L5Z/5JkO5Jc8c7DSk6Vf0ezSeJu24vhkxdrCscFQFqzW6H5i98cnHGwx2bV9z05eSudX Ob20Vg+eRWKLSc08+dY7ETtmMXRkubHrhzsNnoft+tSc7e4b7qc8esB45MHE4kOfJvb+sblf7t5P fSOzd7dRTOFpPixnxygHeESthzl6bZ5qP+QsiGI7rrDOR4GvMAZ2ygcuLabCV5FM3SW3kUzxCN+F 8jN3uTHvBNZQZL/PxVF706uvyU+f8YPYSR8S5MOzYt/pg4v4JEi1a5MybA+bZiuiYid7eHZSdA9l IaJTDNNZRDZp1h3frnjPo9FBiTjpQoJ9UEf8pwtkZLrArPPFtj+3Dp1bh86clGAIGHMjudhx/HOS rwxar2U2cKSnIKHOiBMneFFr/HNzhpJsFQwI7Cepmb9BFsfcBWN8eYqcOvLkozUdO5qeEB+/Ofau 6fgZTW/rvXaJdVeujhXbaE9Ajjwn1AcryHct6yIaVqRLiygaHUbe1A+liRO1yl6iH8V+Mc3JRBSb uqma9SH6wNdQe6zEPd9VvSo7Po+lj+VOfZvEHuhzEf3Q5yIejQrsqCwqIWftpqyqw5SlE00iFGYk RHGIWXS3k1DUSRlRTGMWU7bEy305lHFSmpxRqrxyeD1lkWYZX8HoaI4zV+eYD44z3zrnIj5x3D2X m7Je903dNrLXNO/bcHWoo6Kpe2Wq9tdQ7KMI5REm0fxn1UE5RFCSUwa5+KfvxmfjLHGFL/HBZeJd +FxIJXyuuMWDLoBgpTYjZufqTmxFyNazx4x3ELAh2317yoh1RjsI4ZCJJqfMdFg7ZKLHTNoKIM2M sOnsUIloajO9xLwjqFMxYOFrI4IkP2X0qq/nqG3XZj1hSjifzuknG/DGaiNjrjamPsyC+dZGF/Gp Noq2aDZNtQI/MxUvv2t2faRrXq5VodiUDxD94ffKB3/TEvCqKFcvMUnJaN+KXSnNfJAY+5ZSF/Hj pKyBkb7pQAWarq94vVqLWnS80gxq1iDScylWoucljN5vX/1sRr5//ZKCH1ASjKaNuhKa+6CNepdQ ekZCj7Z3hrtm1y3hCfCHSA0rKteHpew73gvIRHQit1SZnH01AuonJyGOXqY+6kIX0ROh5IxeHqs8 nTtAgmGYgzQX8hM2Obn1Tg6OfXTjV+DEhObxeC9GjkKmPkpDF9ETew7iU3PsFDdDoqZJUwPhkLiB 88qolWIdtnqogaREANef4fCVWA2j645vw74JN6Jqw2IHYWKrMjzIWKToHoTz24SwD1b0YQGB9hz7 X/gels2ylD4mPnTJ+Wpe4tyRsbumDsW2lLKEK4csZSRNMwJ5FGRRZ8C/wUTizAn0qY9K0kX0YyIu 4tFElB0YH2u2MzAB41HGiZarUrYVB09LJjrQD+PgWJTFY90qTp0on/qoM11ET5ylz0R5yYvmTpt+ N8UYn6qlCMUQw3fgAhDvKwjjMixr2fOq4j2YXtjchzrE2xopGs1k4oZ3HyWni+iJyeSZcuj/ovq6 eYhMbCoaINdqo5LG5Za3Mrp99/27W4hbhWJTLm97UNBZu7ofzWPsBnofZaWL6InH2A30msAYTLFr a2HqSM1LVxbRBsKzYU6bGZgomXjJJmLqxNTUR8XoInqiiaZnaLorf/8F8rCaV6YiaDeNqMvPkcp4 y6ESQFmE02gF2e2BZkYcxhJGXHXwUUu5iJ4II2fUQUIG6yT+slyJui95ZXKux0HM6UwJnoQr0VbN YQsb1CAYpAzRaCKxKxk+6ikX0ROR+DnJKAyfx+wJ1KMsrJtCIlWD7xpyl+6QssLR3CFXJHwUVS6i J+4QPuO1a9EYdSh52+xdsbVlwdEsz0S70cUozRxRyHzUTi6iH95cxCc2xyt+x7dfog7kM5p/uFne Kgp/sBTSiQ9ZpamjF5mP+slF/FYGb8gSnaPQgfx4iRCbD+0qjaGPMbyzK5rCe5zBu2qpfWfQErMm hicDHYEhyAShH9t5tfbGzMdvzT41z6jBzQbcxDTKTH9Yq3GS0z6NBZgU+lSdDfMYsHAODeZwZt7R GzsHa+F6iLy2WNj0MbP7VLs26yk151P8dF4/46s0uRxwr8aaR+KoY+ajdnIRPTlYws4FJuNE4EGi 2GzFquTatdZGLUUdVuV600dtI/tIQkzfiK7WNQGvD6EU4lcZUpJsoTiwUqpS3FD25XZX7caXBZQ5 apn5KLBcRE/EsufU0nJmKdO1gSJYk7U8FQ12QBcIfFt6ydlo7Mhl5qOmchE9kRefk8t2V8ykKYn4 DMzoWBDoEF/0mOTRP64JxJDQ9JbXZVWpQH9eK7/wYTifZVmW6sukEJ40YY8+6s+wT1zR9VGJuYie 2CfPiO4f/ghw86XivKzvGy/VGMWuuvqoxlxET1Thc9XYKVsz1Rj4eliLvYxoisJW1LU8VA+8Lnm4 bR7Keh3yjeCrcF/2G7f0+PSdrjd0LGiqCmKGnwCAXFnyUbS5iJ54Ra4sfSKEfnhz81OgpSX4MAU7 m8yDKc4m87Y1/DzwKmjuA53lBTrNCz5UvH4Be+Pg9sf3L2A5bNqtoUAJcPwigDCRj6WS/I/1sttN Gwii8BP0HXwJUh3/4L+V2lSEVLmNqt61UrSYCVg1tutd0/L2ndk1ZCIBUuW9sIwNe2x97MyZI7gR uYhtXNENSq5oUVpGT2gqyluhyFN1AO8Z2q7GEw3Tnm691aC9r2Nte9RHlUX5XGmt1sPPD/08CWfb nfed3Kuv1kMD/jc4VGD6xEf771jc8cIR7oJbl4ukxxUd4S6i683TlDUWvOkKTbuBIEoQzGQuGTMV 4SLJcUVHXLIbprI/6m64a+3UE1CrtEWNlGy6i8OZ7aBaIjrpv91Vw3pfaUWdcTLGlBmOcBHnuKIj jGl+HaNu9p3ZWiVWXbtH+wmsC9k5khh9wdHTsC3h8z6ZTCxhViJcJByu+L/EVvFLeAkZk/xBYfTB hlZzUOh7tMHThNbl6bjP0082+FKIzU8hthgDL51TG1zpNwmFW1ofjiE2Gb/Px0CbvQVe86xT+EzG 5yTjfbq3ZJ8fRj3SQK0Frl9kbL1g4TW3Ife8Di/jR/vO9Gy6vvRcWhPj/cXyynud3sno3k/dMgtm mcJFduOKjopscSG7SVND0Hc4VYA2Zbau220Qh9E8z2ZREOaBgnKg/m7yrvJfW9ujpD+uNVejgItR Lo6ZIQoXWY4rOoIZ3zDERqrdgGGihm0vu531RerzIhW48f1IZOeEwUdj5UvsYsUMfFxBwHtZKTrv 2g6UG7YhN1UXSY0rOmIb3jDVA07GURQhZNAG6ssGtKzqQISFKIKpfCLB3dJFPOOKbvhwxTMfs40w wva1/GOsEJoSzM6bjKTgdugiWXFFR0iK9AoS6lllpY/zNJvd/S2x7BowRbY90oj/brCwoxf0h6qE 4NWW4u8BGl0ffal+wcbHK6WrtlF3UnXvwP4TYAA4DIHkDQplbmRzdHJlYW0NZW5kb2JqDTM2MDQg MCBvYmo8PC9MZW5ndGggNDQ3NzgvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgODAyNTI+PnN0 cmVhbQ0KSIlkVWlwU9cVPvfpvSfLtqSn5Ul+lmwttiRrtXbh/eENG9mG2E6DU4wXvBCMN7ZgbGrT BhJMqCEdHKdDC0kJtFCKwVCUQIFmpXQ6kEzcH+lMGhjKj7RO6IyHTAuSe5+AX33Luefc5d0z3/3O 9wABQBpMgAi8q5ry/arn13QD/GMR97av377VmPB+9QDgfjOA+Mueod7+D09k4RXfegFoX++mkZ7v JbsK8NwrAKdTN3R3dP2toC8GsNiF+8IbcIfyO80OHB/Bce6G/q07zv85fz+OrwOEGjcNru9Iucrs xWtv4Hhtf8eOIbWDPgPIocbzjQMd/d0XT5VWAdzJBSBvD23uHiq4f0OKx4MA8iogkB6A0lOAsxdD /TkCXSauAg1i4tp5oMgYcfWCCFLFgnMRAZdCU9fwOAEiZAcJ6kPrIMPJPCyOFzcwi8X18WIowz7z GBuf16QwKSzYID0Jj42i6495Ch6BkbyO99q01CV6i7oKFnBBCE2d00di6DDfonopbMvMj7ymfT1/ n5cqDEaDbcEe14h2O7fNtd07EtpHTWedoc+Iz6rPsn8MfBL6D/XfkCqVQ3yKzUqRpCnk5jJIo4b1 W9xkyMpRJFJp2Ix0m+waOgQswYEcZOgo2ND6C3J5OoWuoN8CidaDCb11wWw2SNFldADjxqIDc2fV SB1DB3mN/+4xPdJnQgQZI3ykPfJ1hIzIjDGRjZdIwdRuGjKJTDFCed5xVxJD3/DpDBihDQaBBC78 PjqMEIYIo9Nav7iw2JpEqnX4YWs9DhaYBYwXc29hAds4ju4plAXKggKFVrBICLRCcI4mKprXvAfc 0oM5iTJojS094KXYoRhsQoIBJ75afN6KEd7h8eXZs7JT07y+fB9Be7L9nSgvzdEJvix3J2QbPG57 qg132dLSgSlmip1Jg5xOx258wXAranWqAhqNVmG1WUPBcCQUYDVaHOZYrTaFRsOqaTGbE8IBUtA0 q9aowpFwOBS02ja50qYP34mGLp3iG5dl/com3b//8dRn7/Pr3ulEnV0da85E85YtX/UL1LDvDRlR s7+vrn80plq7lpKJSxPzR38mS5CzJ8cmP2cmJsicPFEm+iy9t6F2/PFBaUbOMF++fZPA0ejSHeoR 1Qc+KIFa1MJbIfp1lGCiiJZJdGlGjUxn5JbTKxyDusG8wcBg+U4dTfpRNLZ0fU6tCQot75Ipg3Y+ YPNGK2yd4nZ9u73d310y5N9a8qUxPV3qVNGl/uV2fbqUcNB0DNXx5lK9urRULyJdHrc3X4wCegft cpaqlkskvhkgZvAJx0TPXVhWnSOSxIhxPo1ZcUujYdJ8uLpiyDsHVVb6D+htKEWfAgd24pNL+jJD VKvNlMbQT3gVZ7Ai6+72EApdLjo3aBgyEIYYcvO6yuI2bpAb56a4o9xZ7hp3i/s79x2XynEro3jd nKn5xQyns2HxCZPws5mJN1R1V96vZxYXhOchLkShHhlMrLKFxWSL+YTw+6rM49zFfCQwTCHwDb/M n3xefPLOJAE2DyMTS9OEWKMJ+MMRLU3nmK22pBUYYcU2Eg74k1zQaPHh26w2S5IEOeYkJazCbOzg 1SSLjr/QNDvQ8vqKqna1xXK8v/E3XWOfDr/7we8e5Jt/1Lnr5elDsfHJ2WyNPfHjsdGW8hdazH95 padkx8jktrJtopcs4rLEB5MbmqK1ugN7WzYOPD+7c+TfuzfsKTn9YvWB3o3H2u5e+fygJ1dHpRVN r61ZN1LoG4lzF06MVp3o6HvHD4CgObGSGKN+Cioo5HOmFScVxN70fQoidUaigBmkwmKcKvm1zLya RvSEunmdIGitC/HiJHoYOZ8XMCSIxeVAhBiICMCwam02QYy92X3wCPI/HP1lgylz5a7EoKWu5xCa /AKF0dKAo/JfiemP/3p28uTPcQ4enMMPkjkU8Ll20pFSQ4nw5gqchAoQkqTiBIy0l+ZpET3Brjn+ /0mgVlUI16GSZUAcCoeVGHQP4ZnpnjqSuPX96NF6Excdo7oc0Z43Ei/PJ24m0ICl6p+o7+P52ckT QgaHiNWiIZxBI3zDH2Cb98h/GH5Pdi1zrvpS463MD6u/yvyiOiVCFcmWyQszi6yhSLg60JiizmLM TLF6ubpcXeHSuapKdCVVDbqGqjZdW9VIxhb9loqRmtcy9ur3VOyrmcmY1h+umKk5lXFC/27F6dqb 1psR43O1FQWkvy5YHSYznbbcLC1DGlKlYAv7yVQnaSjzjJmLY+gSn6MMrhoTA8xI59mgYd42E54v KzPWeetu1d2uI+v2NG3cmYQE62Q8vhjHurm4GC++hxmsfUrhZPvMTZ7ZcKsTPdGwp1QVhOqpK/A2 qWUCsa02HCT95OxwRBh/RnbhFqY8/Y4GfUtmmH25Bk+Ijrgqy80md/kr9YFgdCTqzs6uLbWXEGyu V2fJZj3pVJGr1pKpN3vtdl17aVE4OprldmebVg6Q6qrKTgveye9+uzLHv8rqNlgKsxQanUxTbst2 OWp9zoKK7c68SBbr8b4a8Nu8jRrGo+ciynS1lNPJM1lTvs7tGBfYPZA4jWbgBmihibe1EC3ajzQi ibadu82JJAjEJClPUcLvlXx6GlkoZw3sBCtiY8jBpxnkbXJCzmUcOf70/xRvxbAu3FMWoCcQYtIP q0LhZHnnmJ8B8gTAgd5hiVicZlGqfYXRcHnvVOK0yzy1WiWVqCWFAV/1lrbec0J2TWiCWENosXKX 8UaCmsjqCo9TWDAJmBWJgGDQatSODqJj6DaisVgGL8IEKQgbVq9Wgfv5C9gmlUllYk1NBBV/RGjf FL58aOkeGvwf0+Uf29R1xfF77vvl51/P9ktsP8d23ot/kNjECcShBLnkBgqUXw1r1VIoWUJaQVja QlJggxYlIGig/FxV2m0w4pbBWsoEISWYMI0NdetQkZi0TRPaJiKWTrAuWjUVUVYSdt5LKP3D19fP T8++53vO53wPuYTOK83ChIkOjslsRq3M6mubZeiVT8lU3uEcT5uOznTaPNuU6sTUCdHxJECqWEMm 09BwyVozVcx8Lnd/mM7EOuHIk0wmwqelq6dhgZrt3kW5IkrxbyPXHaQApaxI56q5Fm4dl+eGOJG7 AL+gn/IFWNt33fxVE8rI3/pcj2Dhdkp1GiAGdOZY8RL4XNj3v2eEE/gssuD+Te6c0EY8JE4Gz6y0 6QUQzwhCsfnmcoUKoDCfHCJJlqQs2ZLMJ4eSfNJrXnabPqOL7Cd5IhAtMQjRh25jxPIZi0cm8IHO YBHEY/GyOBUpcEBFKREuiZRESzhRTSoJRzKoBTQqGry3lZSKoVYocuPO78RdHPRWKLHh4vMUtxLN jotpOMBcUtYrldqqZn1mUwj4vUXUKqVHPAGrfUzzmv3BSiG6YM/65S2HXzu084+tl7a+9PGcuo5p 66OZ6nhdxYzHah/P0iM3ofHJht7fjp3699jAwc9+c2fsZt/BlZ0noe7moVeqjUefGjuMGqGf5kSM mJ+8w4pYsCWYDw4FeRJkQbqRvE6ou0GFNdCADjVPytCrmnsb7mMo8FdEgTXEj1cI/Je5QVGoTEGQ bU7KkUG4g7fPZz63W2He2mqlSzmg5BVe0QKDNA7DE8FN5xajWbO6a33OaxZMHbk9cg9up9MT5FET Nd4iNFHFRu1MWmsGwDz/F7DAUHMrxmjLdL9dSoQSs/hP3v26p3N6lCYSNDJlM/3bWyk9Wmrm4WQ8 44d4xii0sW1S0FEXCIYfzQYZLpq5KFG/v0LKSfOlDySR6c/xy23PBZYH223rvet9hx0/df/Ye9Jx 0n1ZuBz4ffBa4FpwSL/L3w0UF0OE14SSYs2vBSJBSQ44go5IVpun7Qrs16WgRmkgpDk10cVpVBCD JhgllUer0sZkmRU567tlkAtcDRpdIbRfA9OcUG2Qq8HA7e0H6owWYC9zEfFGo9qsrlW7VF4tgMRU hocKEZ3p3TrXoud1qmsX4C7WmQsYK2qma2kX3U8v0qv0Ov0PtVGtdBD2Pczn4dzIhHN+YJxHRps6 cvWjHeP2+Nx+GS7KV2VKmjqWpYcnGoJpceqoZ/yWj7ZoezX8fpk71+MRtnzsxpKEjs4mVAyTmKSB M2pxirJcjBSb6BXYCqhkTMWuwH3YfG8IVoJ+5OUXepMJ7eqhY3+vXnD87kxofXHp3BAIY18nYBb8 6IOtxzd0nP/dnw6sXv3e2bEvpnumVJokxCp/BvWcCovOE/v9oTPOOtm0ozlnXYM8xz7XsbCMvypD RcX0CpZtyV7NDmXv2CWShQa5K7Y5cyJ+Pj6YuZy5Hrue+GvmX2W3Es75tooC7OkvL/eQAh3u/0M1 VBe47FlO8PjBX4DesxGWrspGCjC73+OqKL8AbaSIyPQfzLEENaAHLA1Qyf7TTnCao45jSWV3JT1Q ma+klXj9bLPUhWcv0M+YnWUhn/11lmaRezPPMfWiSlWtxgTOzW8EstQZaer40lyGcR5E9KRHOutH mkZ8dVXjDJqWqYom7QovlhkxI24kDF4UEu5k0o5wqeIrWyGq4M5w4IRilzNidSuUuiImbcZnlPSD McWssU7SkU6r0yzmoE5+Syxjoklhd7foY3lTLL6YWYemslLbjL7tR5fOGtzSve7Nsc93PV9laCHv DwKJ1Kp3YqHS9NtP6I29j29tOdTGL9h18HuNy986MmXg1dNb339sUmSyTagXHUdebFw4PVLeELV/ d3vj6q7jJsN1rNbzqK6duMhfWLnfBQqZ42IKxxRIOaFYQuACJwsi8E6Hi/BOFy86XVhVYeaTbEWS ZLNxvCQ6bQSHUNcFOExE4oBe5hJAlG2iaBN4p5O/APOxXmywijlkWeGglzvFUa4Ad1gQ6q3yUqAF eTWkcIrIJJA097dqqCNnKZTDAsLtPz2jKFB9XZU5/+FsMNqZ89Z5rYLpyaT5ifFAURQkWica4I5O KI55Y16jFmrwDbjzA8dGL9ENLx8bi8OX+8Z+Aqu6uW339tB3R5tNfrVivm8SFhEDomz2z3jwLYuu iXYJXWJXZA+/NyLV0lrjae5pfanRHt4obAr30DdCb4SPcu/L+dhQTCExUDxen4qzp60IOy9nhsqr G9hyed0IlYQ5KcgLeLW3X9cNdRBJEuRUhjGFG4TeMAzCI81nkhKYd7Zbypt5DLcxj2PAYi0xGsMC uTvgoXkDDPMhTNaZJ++hHq1sEA7CLStiw02IeU+TGR0rtYe/maashEbqm5TpsWXSAoaLmB/GQcNc ndBJO/VtsI1u00Ukjgka5MzsFc8yRzu/1vdCdJ2wLiI0LUOTJRkSb/lP8VseayJ5TecJ3KYnxtqW gXxox9Lt33ll0+a1mVhoUtXCxRv6jux+6ZfAC4tODEw6srPQPtA96ZGnpobTHiPb1/Xqn2dUSlQx s/NZ1KIPszNIysk9ltogb7R/371Nvpa4lRBFDrZwm/nN/h0BPmcrFwUuppVrIqc328CG7BjQcTxN KmjO9vYHiWCak37FBRhcZmrEfI4QSbEUZamWVD41lOJT2njc8SuielRdrVaZekDNq5KqVTy0KPfQ cA5PeBQLFQh0jCrOseaQ+jCWHznEEpFaIUR+TA4nZF8kHA1T0ZtwJRNyDAnhKWklhht3cXuyFcI+ vZWUOXEhDzyKCQ0LGVDs5qQHXDc9ijfri0+rAXNWfRBxhD/39vafH22PH/jh7iurX7uye+Wv3gTl q/bRK755c2vmL921c0tyqdCWcDW+98mu54dOn9hzYkU//J/qKg9u4jrj7+0h7Upa7eq+V4ctCVnG spElG0HwSoCP2NgGgmNCCIYU7Dg0wcEc5miEQ2KuxpQcDeMkdaZAwri02AYsEwKlAwxHaJOmU6Cd dIyHM435y+lw1KJvV2obdubt9/btoafv+32/7/c5jsHKdOPErK75TdcToX0f9D10oSyoeXwD34+y QAlODwPi8cigzjaDTD0eEYJoYqEgiefRCSAwTUwvcxFewK7Cq9gIg1wKlRAwAoNjJIEU5TuCFcf0 OI4ROEMKFRFyFMqQkY1CBPMU3HusVwmVFhV5HLsDcOy2oAIERwhEPdFLkMQJ7BZQZf0udpU3JLoe FytokBsLZvRpl3rzmSx46XayXbaV3CojssBFFfI15EekwJF8dSMZJ/f/EbuSnr4Kvpfe2Vb4TNhB 1vgeniTO2gqalIgIwSaEtx0IbxbgA2G4QTi+ELW4YWc4z/9qeIMnqUyqktakrdOb9O0IHzTvt37q HVQdsQ75PvefVZxVXmGMcqCAMgaz0n4jY7J6Ga+6Gu6CbzBvqg8C9TQQg9WgGlZNWgIX+Z8Pt4JW +BLW7Gv1t4Q3wk3+tfmbwt1EN5mUJ6lOTae2W99t/IB4n3pX8762x3jAd8h/KJwijlF3ld+p7qrv +u9OCcgZ2h8DU2HpFHIWBVRWPyGdOJOkxWXkZNHoGEecRrxOI+SLoxDNOcTFHIgIEUyINEV6IyMR IpJzAt3AUQ7koRxQFJoE024TbrIUH4f3ssQiyvNxiVTGboxnFLoIeCh2XQjkU4Ih3qMxEpTB6yZz kByXO5bBfH3eMlCgRRXRQ6ASyYtyPGicvAyENJMzUM9iXayPItm0iVHz/b9lkz/R5HqjWayLyNfJ RJOtlnD7J4u/PLjv/Mq+w1Nr/tZ/emVDByxaL6xdsSIZKYrOr//5T1d2+iqwvq29DVtPDbxW8/HL 22pXtHVf6li6+rn+v67cXPfSurV1xS2h9O3y/U1bejY8Wzm1FXHQXJQJnyFMmIAfqoTwRv818orn mp9oITrIzdQGep1qPdOhW+faSb2hU9BUdwCbRpF+s9tvJnHeSwA5eRy+CMxQOOKvR5UNMZNAh7yv epFyBrwYHjWJOGrXEZMJMGaRgayQHQJaTuvS4toUXI7YKCAEkgFcCDQFegMjASIARQ5zo8cExSkF prBMekLPjGUEzUSG9cuy5MSNo1BJvC9JSyleebZcSqPycV67L8fnZNzLgIMV2yYKzVxKHvVOGnTy 0N4fU5IYKKkmmCLRqLYkw/wlWTGDIXaCYoAyEZKoaWXnyNeBj17v/nLFxnOfrtvzj3OfnMTC2kTH nIVvLYwvKfiZ3Yutgbm/W/7t0MDOgzv6Ho2mO7a0YsOdtUuvr+/9+Jt1DfkoCocf34C78cOIj0wg 0Y9bUtArOJjm6G5LL2r+BCBXIUJnBQMu0MW7Db0GzHACelHd+DMEGfYYl7S31FLCxUE4JQMpEVG6 H82huyAeL0AjPxRPiBY/LF2iMaFLZGYJsTK9ne6DKbwf7ScHvCjY3N7TmuboOfaMB1MxNp2Bo1XH zCpxX/oUXis4ecGsRJKKdtIYHbVxMdbtdCfduPu8zZLbukEK3JwJ1B4gCQrKJtAuQ9wNKU5SqGDb ExvGI1EJ8GJj+r+6i+5Ca3bzLzS30XK50qvVF8Wqo4nmbrxfyOxdePgw39Ndr2NoPR0LF5WvXtLc j/7N0nS5PJ98GyTAM/BbofUAOBD/Po4jGrRzFoO93rLAvtYohxyYdAd8Fx9p+NdsorH+gOGA8asG wlXvmuuat8RMuIELIl1eR7SA5VizowsQHWAHeBTH+6l4IhFOgLp5RYk4BgglYc2ri4cxYqYNpPCE QHMz4IwWMBPORFdDCbbcBxJy++d4Av2+Da84WrMlypebUvhcISovLyiOKuY1E6VFRQsalOV5ZdZD LluhTbDhNmvD1FK2KlmFVX2mi7k8hR7BU+8hPJYFDSl4bdD94QvmFCx5MxisFVME+boWgUJkM+Tl 0MRNUDY+gSAycYu7WVY2xv2weGLxTSlZMjmDHuIudHHq6VLeTJtVXfIUWVhRWV45uxKXTYtNj2Gy fB/tNfhcXo031zcJlfhZT1W1g+qSKgeQhQgHoCYr26HRiVrKNYPA7LAiOwTtNouV84prggOo/eiJ ytjMdvh0aY0DkIVyB1AE5e1A7zZJb1nsGavNYZE9ClUBth2CbFKK2Skq4uATR15ehlTFo7QUdZgQ /y9laiPFWG6Oh8AMei0RdgFdGANuTy4W4bQgPIXQomTO5rYsY7Ulkr4rkYuFNPuRaImY7GRyTdwe dFVd3rM//c2x2+n225fgqr9AOTzYHnsu7Ut/fS/dMnofnnr0Jzjnt7/+9/aaOdp3B2ZVvPLFh6sX zVzIuf9QPaetflpFfiy5y1VahZ9Mt42sz3Xl74GVA33Q0/NDuvj+rfS20xAxY/pe+jfX4Uf3IQUv QNiXHhoeSu/dVxkvXTTY+nrrL2BL2/zZs1/R1bWf3d1YVtc49PyvfpKoRQjnACAPky8DO3Bi5n5M 0gta6OQx3gGQKgMOJ0TaTH8SHwUmNORoKPBRwURhdh5nKbvRAZyrYBJiEFIsRoFQmUirl7+6HAqJ +ODGxu59D0OZg9vcdeYMh0aRiExKzbIMp+BpZ71bZmB1nFVjtdnsZofMnXr8+wFvRDSDhY3Fkg0W SHYgkFl2+TLLVj6zbJKWBwySEX7J6YoZVok+PpV9mi3nqvg690L2WW6BvpFvZZu5Fn4tlyS61DvY Lq5Lu53f5uxhe7i9mh5+mB3mvrAO85fYi9x5x0X+7+xV7p/sHe4O/4C9zz1wPODzabbahjmR+kJO Ag6et9NqhY022k02I4XJbZRBo7cZ1vMs5+J4u92j4fSaVRqo4Vi1OoVdEDQYr8cw3unYD0DGcSl4 VFBRHIsbjEaKoil7Cj4UaPY/ZFcNbBPnGb7v7nxnO7F9duK/O/vO57uzLznHdnJ2AM9LDgqI0rGk K8kgwiI0UKaBVtuh4afLEqaOAFoVVDQETGVUDI1WnspGoQE2tlZVJTppE4IxYD8wraQw8MS2rJXK 7O77LkCZKtvfd/daPlnf8z7v8zzwN/hRp+GewtMnenjAT+F3DWfEcPY67zkJ508iG3ab8zvIQs4G WBRpqkjY4AuuMzDk1PITztkkM1FwJgPahGX0PS2AMVXA/PqL6wQz+l6ezsO3GW0eMQWUYaYRzb72 e8UsbOw5QAe+2Rs0bhtw4vXav1dFv/Rsva8vqHeBP0vgyrzCM7XbT89TvzV9F7x/uScupGhFcQXS e8lV9/fvfNqiKGRSTKwGDlyu/Qk5zCiGkdPQV/OYhs3FR430ADbA78J28rv0A+yr8Qpbid9m/x7/ KNU4F9sW36of7DigH5Xf0K+wV+JXVDuZm8I/OuFa35lDXRGKZtBu/M3rz+iGmIBLkM90GJIKFy6c WSgvVHaxV8Fl+Zp+U6FJGSiODobwUhzbzPtkn+pNJzsWyUszXwcrggPxfbibwZhcHxiQB3PF3Hju cM7KptmOXoxgaFbm1WCKpHCC9/M9+k75oHxVpyM5I9ebG8KHiEHLIDVID6ZHqGF2mCvym+Th+Db1 JWoHt4Of1MdzH6Supe7In8rBlVaXwNnEKCNwPlHSZYwgE1hWE2Qi2jI3oRPJqJrN2nwtqt/vw5Mq 6pQ9MMmhts9lzW0B2sZPdM/PoNsTTyw2d6MZ1r+yOgTsfDqEh/pITZibaEdfMIuyHgMmCqg9h8kb JEGiot3hzmAkiJAAxpQLhpKgmprwvkSjy4VWhwOuUdjLLgbvc0XQrevQvNwvwAVMxNaAAPQUUEg0 Lb+sCnunVihphdITK05j7UTbbc7cqivhOM6jDi1XzQYrz9ox+EGKUzVFBX5mI6OmmcIyP5WR1AAP aJYLcjhFxWRoE/WYGojpIEW360DiYzqRAe06EedadJC2JHVMCUd1jO8gsjpMSlAA8o9ZNRQgoQDA uV8ul7Fy6ZHdxqCBA7PGmpLErN4BB7kbeQopK0Inh+qKz5zwptum3Q9CJvJ1NPHzlxevGb9+szau 9yn+cHyZji/98dC+Q9+uvaisnvfK3q++e2Zt76bSyXP97052reDwt/gFq7637nSf0imViY3fERNK QH5783OvuWi6+7vLNh/z3X+eO7Kl55XlpAWD2XPpZ3+1uOCslgFuLLDxKZDCU0RK2Oc6wB9xHfGc cr3tabDy8N+DUeJF7xbfy8Ru36vEPrZCnCVsjYSTxMNLiJWEJWVl3DL0GMByEucAOAPdxlOnIgct aogAU/j1k27tOAOYKWL+yUnHjxy4Y4pIGalmG17BAAAdTOVNNxDc3W7czRqwAW35SAC4AkIAD5jt EXhSWTtkOjetUF4G7UTh43IJGooScnClmcLMdHf17gwcOSgxnTfhjXg5qpFW2FhDzKdQnK0Na/TC xRq0tAG739GGXDZ43GOXSwXQJJmHjmQaYTDHT5FSBEUhj4w8N0JuDnlBELqmX5u4NjpS3f/SB1uF 5+r3ztbfPL37FOj+5d7JVg/XzDZYNtT1353aVb90far+rz2lY80nj3165r+/AcvPLvE1cWnkaiWo klvhdPLBdEEYKxu4hvAO5gfM7xnLCDPSPMHsbzrgPc+dD19irAG3pznME7QXTLA7eVy1UgIH/QMt cA5R8otBQXU6HXhQ9fkwayjf4wGzkSbtMTwWz9RnfzmFztDzpIS42NWdNSQQkUBROizdkAhJ9Jts 9Jts9JvH7Yeuo5GBbKTMIsWiInUouuYBBoiLNXOF6aesfWyC8jnl5j2kWIjlXV5GaY7xrlA/YL1w CbuFfsA1BfsfHv/27cgplQsl/f+JEYGuiKEpMQ5PHYOzEvJC0vtlXwgxQAVp8OV3Ku/UX/jjWP8t 0FH/7b2BYWWOOExsHIsklN31cxfrN89dejYEFgM/CIKFYdTrrVAP3oInroNOo9vIrg9tDv0w/Xqg kj6bvpG19geLVJEes47ZxqlxetI6abPJAhcWo4rAaaJkNdCBWEWnU7BxVhodpYgqtIjjAsXRIYbD gQT9R1jHjmpJrI1pw9um8ItQKhIabKijYe5WKBS22ipWK1XppsdoHKMZuocm4LOmjV7zWSPJSkIT 2lLwpxvZSgQ6muvQbT/Tmy1mD2eJLMaYUDEmKowJFRNVZBMq2SzKJlTyocyN02DCDGMIJhMryJlC dabwYQ3CVajmGROwu1DR4VY3pR2Oynwtj6IQU72LMf/RwIMdwQlHWAG4RcQA3S3F4pAoorsZji3E E1gjZgfb5wAiLsErUAGtm+IZSlGcTs/X+uqXGXXu9PA30l3z1Rfu30mntYiflZenSa8r7tU71HUW vHZLSm6qq0MhSa3PH4j7I6mu0XpF8TPGEFHazqtK/Q8ber0uhKgIERUgom2g9WdqagrwxhxlbaeN tNmPp4j92hntfe0qcVG7Td623yfv221FS5EagxiPW8apSYixlbbbWnFabGycAjHDYeXosMD5xSgF QUWVFgtHOU3t5AUuJkpaQrVbG0kLDqGGx+9vw6QYpjIqriKklXg8hvv81rimVrAWgLWkW4yWYgvZ soeiBBr00OBXNKCRNUtiThNJpwma00TSGeXDJpJhsxg2kQwfSn6BdDOQc3no0kq1DyGEEL1/FB6B 50YRCskcpOAserWHO4QQTjionsCNIIMgJnFJcjf7oTLpuvcxXXqIH/weHPmkr8ehKCC+aOEnDnsk kW6vnUkvjwUcdgE2BfFPh8QuWvdNCNqdp56vZ3uWKvX+9WLQE1CU9sg2YuPsdf3y6pUqwmsJVJs3 oNpkQMFYbicXJ/FgnFVxJsAE8Uin0TnYucVaDBSDW1r3BPYEjweOBxvaUiMNEw1EoDPJ9nYWO79P /pS80Uk2/o/wqgGO4qrj7729j72vvb2P3L7NhuztXu4uySXZ5bI5SHIhG0I4KlqipdBII2QakVoY kshnGW1mtCJYlRkLnXRsZLTtTEdUylevWCFq2xmmMMYZpdbBIc5QpVBGhmJbK5f43rvQQMeOc9nd t7vvMsnv////Prhv+yZy3DKe1AW/p4dp1RIW05+jTH/gUeIAl9vd859ukDDWXbUNnFCre2BGrfZT 5KsZyNUuCnK1Hgr1hveFUTC8Iowodz4Wngk7wg5ajTAh0EvHGIEW0Ye2z5vvTcFgSk0hYoSu2yL9 NSmRvk/d0zK4d7ZWhBDJnBkZVipWNVKra53XaJXE20o1y5JWPOMW+WRtui5dn+ZcfmJEglqoHcZV MeTOeBtBIEFOYlxoB560qxH6kkIjuCuE1pclLMNmlFoPKmSkinFqsctKFqJ2okWrIDTqqggRH8Jk jQwuy5lsi+MdUvaVO09Nl3YPH3hvdPkTXWrXF1BAvnde9GtTe6a3nx1btf7I/jc+s3PzwkhE4YjE rTz4+a3nfv7P305P7E8l4XfWd2qplJXcND2wqO3Wrz84+uzvHl6N6yoSzaTyVO2eIZPaA7eXE+FL BZuCBpLFmfeP04okreLMLTtMlxbrfYuVyIqQDXaEPo5AndVOZ/OiF2cu22xgdLZRr+wSSZKcR44G chjkaAJ+cvaQo5MceZIxfR2gpqapAzVVeRHoNFiyPEcC5bvvshM0qCRNnMvQ618zE/PNjGIPDxUO FiYLUwVHpDBeZed6yRKRjvNpuq4qVZpuqUqTpveoyiJNR6ri1RIRVVG0BBGORi3RoiodWoIgkKip URZ1dPh8XtTU2FhVpfDhiI5sHV7UYVw39SH9oD6pT+kuvYjidqVYWFeYKHDxAiz0JPWWXmudhazx pQMXcOZz4s0RQgZ5cXiEkUEpP5fSyKdMBbddKYle/RlIA9fcbLM2IH3wyeHXPp0OZr8Cn0PbCA9k TBMtYeRNiKDBNEuvmPel5NJe9mp+6VezFEHeoB4CIjFyb8JvbSgTgyR2Dd7aP8cS8Jnph+7gjEfu 2EY5o5mYpR2kc1TwG3uzxlRYY62j2bUtsjYQGszxqoI0HatKWNNlVYFawqMqIS0RDhGi5rGMaNfI PO0S2UG/KuueIX6Un+K5GR6afC+/jufW8hP8JM/xDrqNZx3IF2c+PEa/SxbT9jxmAAbiQ9qoNqVx ptarrdO4CW1SQ7Qo95JKMJomQz88MsvVjKDLVaDn5KfgersSaMcnoCOgMkiTd/EpXd96kq2Zr5n5 GxciCCXAO3Z7TxiujayNokFpSHrc/7PgRNIZxtBM2klUyZeBmscgiuEqMSYjiMyoHUW9URgtct7j cm3AM6+qOPMR+7/J4uYxigdd2BrFpEr3eEze5n/A/5j/Je88zV/kZwhqaBamK3aUwRRj+FUmLxLX P1WTLKL5R7Wpn9Akd6mfmZL+YeIeZzG6dq1/uDPP4tnH3lGsVLz+Sn9VO/R5FZ/cDoiO5RnPjZA4 NRyZQ46Qmc647DaT3Ub3LAMQdz+75UsbZa0h3pyWahSD4elMMxBLD4+d+l5/fr6s1q/JLV7JjX+M qU746s8E02502C7uEk4JaCOAj4GtaJewzdzZ8mjutPdkgN8EYNjR00RaMIfuR19Go2iPvQ+N2UcD x4STzSe7/xR4MxsI+yAnIBdyZr8LdmfHwSF4UPhDlveR5AOQ0696qgP1IAkNT6dnhecJ8Lr1Frhh BT0+2WfCFtRsL7Z7e56HP0XP2SfQCe/hxefABTAJ/4jOc1fBVXgd/st73X8jgGPNMcvKmtZKOAae DBzI7rc8L7oo09qaEdSr89U9SypAhYkEE3BpHJMV7MJ8XUpJt6cRpY/Sa+wUCkutw6wQRimv2K2u gFtxUZXVdENVajU939Wh5J0Oh+IMMtVVVSWtJdqtNqUdAqALgSgJI10AFNEZe6VpRU3TAjBgdTl7 TNBlOdoCEPl9Xo/bLQwJpwUkpNwOtzsWkw/hfHt7bW26o62tri51KI0lyeVyppGTz//QIZim4Rh1 wiEndBbRQttvB3oDaDQADwdgoIj+bTcYQeaogkwLgkwhgjoRe9qNs2LPZrp6fEnPKzBPrOMAlAFt yDusFTFVIyXSmZRFRaLYnWJ5WcqLc5/yDUGo3yBYkR9Ijt1CU+br4qvkgukVA5Fo/ARRaHq566aP EDKJO2B4pPsB22M0N3YZixu7Hf19/ZnuBx+wvTkcC3R649HWbHFm6oTYaotCKyRad0RoBeTJEXY3 cUSkdxMvkkuZ5okb6KMxlng8GItJhGjIIFipNPy/lB7KLQAL6F72TEBulxsNwpu7frG6tKutOdIy 3cBGpql06g5qWtxkNKg4uhXWLVLqsyq80bBsw2djx9H16eCuPmL20xinLPj76eV3uUEdl5ndHpwe iGyE4praailB3GWsc2n0ZTJ1dcTPv0SmLg4O24oIRBgHcWjrq9FX0Ha0Nz4WfyH+ctwP9SL8vt0s DObuRw9WI8L1nKbHFiihDt2rKqKWiKtxYAIbcOAfVSERVSUQx5Ox24iK6FXbiP2vwOvxeFmreNlT L2sV77g20D9nvstsdfMmDU406F7qp2RF9XWE6CuUOO3uBFuRmpVYlpFyjgPalv/8vXlVsoJF2PUb V8dFf/abD/3oGxvgdvf0vuTC+BbuERpfk7De3nnr0H1qRbRpa5mLXDcIKiY8Y18OYigAXhLkQG2w LljvMN3hDthh9OHNcAPeZOzET8GnjTfwX/BleBUHAhh6JZe51ORyOGcWMBcz0zhlci7sNCWJy4A6 ctcO2qRW3CK3mJ3ZFdkN4FGwDe+Ut5h7wR78uDkGnjJfAM+bB7OHs2elM3gie0F6C09mr0lX8BV5 Kvs++Ej6wEwug/dIS40vwj5plfFVaYf8On7NPI/Pm2/jt02BMIVH0+OqUqnpTYxFiE/itYTIspXG GITadACjAMsAyhhT+lhkGlETS6aBDWiQv12qlGUJeXgeANNM1/LmGuIN/st32cA2cZ5x/H3es+Nz Etvn80dsnx37zmf7HMcfieMUJ6E+xmhJAQW1iC/NoogV0W0lH4QUwtDCRzHJKmAflGqTgNGWBYEE TZoQViroNLppXaVomrS0TFortVvXzmunsW4d4bL3PScMqmpJ/L6vbemUu+f5/Z//35tOSaGQeFq8 JNJZ/K5YJZ5Um6EZML2EhbOFbHaiBSeb9CFNakmd0yqu+FmRHsjUSWukoPNwVwwUQdqeL7GphJEi zRKk6cHzPz9FJnwvIbhIgRXSnLO2AJWFy3s89ryH4/OI9eTrpuamJ+rydRlnnuCZQJXXBiADTNS5 vJ9KatAB7nEE93wNzEN3bgmR1RlNyayV3U7risdgCP4K78NQep3s9kdWp+9cz6wLu+/807BzdmBv sCESaQn1MQMblUAscvumQX87O3L3i5Hb3yVzbu6DuY9IIluJYvC6umKEB/4oAFa7ckcx8AEMMZx0 LHLscjyP/4jnsMkhSTxHHa4kUocrMbSuYSeta5jn7YCxxEtOnpcIoWdUW+wCVJvNgAUfy5sZvR61 /GN2e4jLcCrHcETOXrGT4nALNoMeJil63Mk4UTeVK+TUOITicDr+bhzHHU56CZcoZiS4LpE0oLt/ PYJJNIxV67nAq2w+s0BtxWXQcvf2JXTbQc5/on65UKl1uVyqlBnxecjrJTZxHU0ZVKTyrJh5Lx+H AsrzXegRfhPayHejb/CD/I/hHLwKE/yb8B/gP8FAk9cG1JuAXtISVxCeGx2v5wuY3MM4UXMSIT+c JE2l+vP0ODa/Cfo26c0Tj0qPM6qNz/NuPo85F3l58yT6zIzV5MllpivbvyeceazaFzSfir7+Q7sK FRnSVC33ucrwF7ssSqVfgB5mMe0YmKG9JM/uF6JdpLFoI7Uvbg+0G1fOmhjrQqvcHjZ8dfa1u41z cVmjw4wwWj73nnGX8ZuoFgnoZbXpBD9qOld9jjM8DbtNJThsMixlLQpiXEqV2dMRZNIMRgzHhJgM ozJGpjNA6+sr5EIBNYAD9g7OHDJjmzloxuZO/9e36AUs9q0qr+J6E5/RA7GJhbJuDZtBsEVqor6o I2qttSeRAJ4kOE3k5DaSE1dtSYIXk4VnXUlUZyDLvQ8rsY8ATCaLnUMiXR9orSMPy85R78jbuVgU l4GFA9qg9rH2oXbgD9f+Nbl9+MhT49c+H95OQm+39jvtTW0bHIEOWPqblztLo9pV7ZXxw9AAS+Br 5w8TSaKKbUjomaURdl1BKXKrP2jLpVM7Pf1Cv//bSk/quN+023NZ/plyU7jpf0eu8sa4lBLNR/Kx diWT2hh7MtaTGkrVvIHA54/7V/h/770pGEcV+LX8dt078tuxGeVjucqvhgMKa6VSKkFQMIlhIrQu MYwCocaGgFIId4VxOGxyNShutwuzJpZHPs6X8am+Hp/R15miJXiwkEMpUFOXUvhU6npqOsWkGkEf kKCPQtAHJEg2q06bVf/Qqs9H68lkagqeHhc3b/mCj5rnrbhqKYEhyiT/IuhbeYOeh7gyMU/pYpl4 TL4yQUlR/XK8zu+JKNF4XTQLsp8sMW9DFiJCOIvmi7dvH+pcQ6JBPZGfcLtBqg+1kxIGEVDRJhDs 0w1QH/RRHBNforAUjWbyLJw0MsTcelhoIbormeBFf3RVy51XyXx2CmQ+w98nf3vs5q+a+pbkHg1s O7H84JrsarxH2zkUJPN5UbCf+RY9rRgbPDttfbi6+idD60+scFAqtG7jbkKFC0XRHTW+DNabjgNT ZYV15LQVBuAQHEPPsb+0fYDMBpuKvgLMWpY5YZjC02qadSscg+ovsCz1Lz1oCBnQoyxrYRJSR9CR dmDk4BwhR8ahOoyOTmWBIEVVsOLr4CwhC7ZZghZs6Yx9GUHvk6deLhKOOgpl7laFJdUcDUX80Zra 6lpc5YnI4UgYVwVdUhICZh+Bx0aWqJ28FZ31SXJXQi3ZzKzX6k5CmCcLcbUd9E8vUAP5na9C0Uhd aFSWqdvEuQprTgR3UXugVZ95zKGt5RMj2hvan7ceWzNYghEglgWeIewNTnY/e2T7xNUdpUfyr9ku na0NGZ8Yf6JtyWYQXocMfF97Snvrc+2w4aP9L2iXtMtjw8NnoOMfZ4d2UwLDJL9tIwQqqAVjdUz2 0LaN6M1bkoB/JnojfCPJdMo/TWJPsC61VWbMYI5EIw+j9dCNu+U9sAfvCO4IDUi7IiNQCj2fPA/n I5ejV5NzsqsqdBCelQ/GfiS/BC/is/LF5LXkTOaT5FzSwiM3+DCvEMqa2lJtma3yk+nqBhb7/eAK CjZRQhFFQGxQsIphd1Dwi2EVN0ZkWcLgxBjkCziETQ3xl0y0uHX03zVxptWmx03MMdNpEzYh4YK/ ZQq+p9qalUDAj21WK4mRLC/STLA+Rzd1WVcOiRdF3EVMERYnuFZQW3tap1uZ1hZWJ5vVnwOrk81K bpdOtkv/0KWT7TqZ23xFj0cL5lfHmiv23Sr2JhKU6nSF6vQ81fPmqVzmCNbFvnSCpiSvjysvJCLg 8z7PfARKlDjj3l80ZTyU+2RTfTgYSYbTWWiqJ0tKasyisJwJNWcBLXTWvn3QR7qqT7dcV1CE5KBa moM+HXPmFZqTnPrAJMdPJ7h8hrOREQmVyUjsViIhiqAj//8kwURzEzTPiwLRBOM27Tktlw1Z6jl/ dGVOFwfdvMPfZt46+sJ58Dw+0j272OE3//zGqQNtW/AgBtAG7peIwrmde6ei2p5D62vxD2F0/3dO OYjvQkNz7xmMRCcW4XWqlz/eCDaw4RoG2QwKihsTXdCFzfa2KXhInW5d1OpjBMMmzybvJt8mocpo MVpRw/U2Q39Nv6XfOmDrqe8J9qR7MsPsoZqSpWQ9aCslRg2jWY63ZC0tllwgG2gJ5IiFxklDqD4U jMeT2QfhQVwwZLyZ+kwwIy5uWZxbblnesKZmrWUdtza+NhEIQhAL2WBOaP0v2dUf28R1x++d76fP sc939vnH2Xe+OLbPcZK7S+yQM4ic1EIpSSFslojTGJAKNDRskIghEGKgdRXQVWr4sQ0yaaPaOiBj hTQQDEODrmJTJaTS7R+0PwadGGVaUamWTWM0ZO9doJ02W3fvx/2Q/d7n+/lRiVZilXi1fbBjsDhY GuwcWOD3cFxe5OR8mkuVF+bN8qgwKh5oOkofNY6ZJ42r+nvNvy1cLT8oh1YwXTK2BZfPgA8BDvYA AC5hdU+P01AatxJycosqK8qlJJopxsZDkDwW+fwhn89f8DX7iSzrNlQazMIEpFuetB5i8dPAURqL AKhZkK2DtMMbwStB/FYQpIJngreCnmAd33dBPa0UeFjR6Ab1J23gSttnbXNQ2pznSk7bh3DgwdpS bSYUPKLtMliK2WApiM7DvVYrjECyHJ25PwtFbHbUNgrz3sPVLRQN4AmiuuBHmQDjP52BkL4PUyHq 1QA/cv8JtXY2mbSoZ7kWtgPLB5CoifBEm3DobfV1YJyvpZDjocQF/PnmjABljjEohPmCK2fuad6z QPRD7NegIWVf4jY2vMy/VCBq1RqAGouNYG4K8XHRgE2YAbvDDLj2sAqC6TY83UiFIeQjCu5qHsoY jRSdDnYo+DzMc9mmbLZU7OxoR5zcucDzi4xQOz04tL+w+K+//l7PZ5cXFtX347EkncnE+89v3n1w QTn3+GeHe2//cvPOrkhc80JHVNh3fM2eVYs7enZv/MaRVeO3WLJbMcBHhw6u++5A+8YW5f1tb1QO /aEUUw2E/MXQG511vdHnTnkADOADyQFlGAzjw8lhhTG0bm2ldpT8oXyS/LlM4yCpQJrktUYWsWea jqYxFecDjFbHrzoiCwqYE/F3CwH4uj7sDNTLOq47cYZ1eY51KY11eY5tjEhqQUH86EdPYAqvrFWO K4RyCdcxae5Th0MsKLn8J8G3T6XW16IFHoaGmRoiPAUSLFdCL3iXCxThAhfu8ItcWpxxdwZzuBI8 nl6661qd2UXQuvAf8B+g1AhdiZjOoj1I/w8PIbcOt0Uk3gpkOVF9uXIFOnJj9j1kz3+6Vi8up7M8 2fv4N5Wm8oJHM0+tOOHzi5sHwWK0qtzcbXISrmobePUiZsLY0WwUTRQ/Uk1u61SkRFGnylQvtTNA ZNKZXHu6PbckvST3do7O5+wc3mdu43YFxnNXcv/KUov8UKJwrVFV5ZjW2KzKQEuLqhzV0rFoFOoU ntEb2GaY0T4/h1YNdu66Ac7toBXMo6TGsyzj+GzGgSaFMRmcgfHOCYZCSHtcHaLQw2h22hWkuPtL n+0u8SbYah43z5q3TcJUU+5mptzNTLmbmWoUhD0i2CIC0dUu0Y+uiQq6JsaMma/yH8p77iatgJbU TYCFmmtQ3UlU1650FVwb2rNq5+QCBpZuVtO9wUYtreFUIJPLNPlTrRgfzPryrYDzanymFdO5DEoV YN78QOeDahTWIjaCShZ8mcBClKs7Wag1/x3MQm79PVEgz0fgdkdfIbzq/vU/3TVTS17owJcXK02x ZO+bQ6/9/gWoOGQuk3lGHZn94/WP3xr/TvUfuLB7RSZTahqdnVx5fXT5tvM38cyeVAvEgQBT2Tuo unDhnDdAqfgkjj9T6T8nAYVvqHv+fMGv4hLth0bC6Bbsbn72xo2rwLBM2fEJvAYkhrNPScB1E1HX TUx1lIpu22K4rfNqKl38u/BIfaB5LkUuRn8VP6s9pMlTsdPxy+Q0dZEmJ8gT1Cl6InxCIn9EjwXG hHFpTCM3hddHthE7vXs1ckBaHenTNlCbaPJFusq86F3jr4ZJR+vDKp7V5NcpMqUVia7wUux5P5mh 8rTO6GFdIqGD1ExtnXZDIycp9KecBObXUl4pLjVLHoluQH9R9kMdpxnVj6P6q/Gz165dg2mjBlnb tmUnhJFAxgJhXg74GXizGlFktT63zwlKNJViaBq6oRB0AyRFIQCXpAgcRdQAtFkYTlPsowiIfGJK jjQmPZAI6Z4ZdsJ94bPhB2EyFV4X3hreGybCdfxv0yntB9rw61FEHrXYTO1ODYu60Qd+95Hz2gHb qNspQBVBtuj/z1VIGyO1rz6uo4HJZhRRPuuNCnbAEWyiPndvmrcZRrShbbw5LdpeXUSzNycD9tPU W4U+CIQpGi5PGiASykEwUkgdAJgXglyJfGdZppR/nMs8JnJ87PnFePOarjZQBY5RXkL6yN5Mg2Zt ePRt4uBASE2TmQzb1tT+yhd/8QS3tSZLHCQFxETy3Mf0bohA26PMY2+aBV35bCgI0ecEBBvP4QnW lAlOwDkGMyAMI3a3C8QvoRhjqQbax3hZ2us1KZsW/FHR9sFDRkBk2CJs96I2AVvnHux0siVjOVsl +tkTLJWlCkwLp/t0UY/n5WY9Z3VSdrxoPkc9S/dwy+QK1U/3M1Vvv68/3m9WrE3UenozNxQfkoc7 thPbqe30du8ObpdvV3yHvDuxI/Ut4zXiDeb1xH5jv3nAOkQf4w6Lh6PH4kflI/r3jSPmSWaCneAm 4iflU4mJ5Aljip5iLnjr8XPm78yHzEPui+TD1PIhY4M5ZB1giS55s7JF/WYrsYHewAyxnh62V12m 9xhEVV5trDI9fXQfM8B5CBrzQpuVkIzmRF61aJtjn6A+iQkLy7LJJgguOL+yssDQHOAYOycg2EPc L3KBj6DvGhYE/RY2kWBY1puAvktRGIyChSDGQ7KoG3lZF3zwLTklK+dsq0u263Nbp2TOm6rPbXFC JkOnfBzXKMO75XgiobBeL6qOsJyAEwkjyTCNphEyTcOiaBpdSZgWHFqikNN12xYwnPN6GYZmF/6Y etuCe/auU7IQxZTdxsm2mkXT2muNWZ6V1lprnbXVHdy2HliMdY/5hP0aJ5+Pc5fwFBYH/3Y4x9fn u+Hz+E6UF9bxV6bmC+2ftft3/sN41cVGcV3he2dmZ/bP3ruzf7O7tnd21vNjj3dn8HrtHbN4Z2MI OIBxobRAYnAChaI2xZg0jWmAlQJYDlWbh6hKIlVEjUBxGykJtRwTP8RSkyqoQuIBqvahFZEQL5VV KrlRG9il984u1G1VqbPac+89ez3Wved85ztfHN0RUG3VESl67e5jXeIMDeTNtJ5qIO9fE/epNVj8 32BcaznUWnLjD4dKBKOP8InrPy7+pGsjAA1rWrSl3EGMaGKTEnhf2dlARMleGJGacGwiskEPDiRD qqo0PmucTZxmCtypwhMdYb1+Xqv/tn69s/581h/etB5+KRSKPdD3hSZiFReKx0NdFOos9mUhA6me 9qiyASNY6cucvb9EH3zwM+bw6Zgiy7IpZU7XOGpm6uleJdTCu1ns6sqfqaWoP79sxjR3q4PqAACu 9zGqy3RPk1GCDCckMabn2cEBTSbgRkowDXKMEi9SChV3s25Qxg9JQYdm0IPHAEfTQdgS9yiD8CXw g7SLxyX4tt0asAwUtlDF1u0KXSGJ8ZNUpu9F8FLwpDSpn8y+Jb2ZuQwvo7n0nDSXuZydM5YyS/KS 8nFxofw5+iz5mfi5tVy5xd8S/+G7V2njDSTyktipaznD2IBM3hTXp/tVU98MWnhQEStm5UaF+U0W vpB92TinzxrMsL7XvzdNezLxTHSoXNmaGFZZPpyDnblvpS+lL+WYJgIlJlGxu4JKjgqCdI5JyuQq kgk24SZXkVSKCoGhA8HmQC7hEQdtzYkGzKZFA0lBJPFlALN8mUVckk2I+C1qVsMgLA8mLRdkkq44 LyTjikTeagwki1kJIQlmwxBmceXkCdiGRCMsikYuHQSMY6BkFYs4gahEPM6yLve3y7CsA4glpghN +AycgJPwA7gMb8N70AsXqa/swEZxl3hIpMVeIL0tUdIi9esFu/LTR8BaHcdSCFPYIzgR61SWhhBy kNTahNT/BZ+1NoAfjCEwjrvoK/hmMDAIlODx4T0LBuySjCEaax3SYR9NH9KPGRMVon0wB+rAQVng sHq0SHULGGAZ1GJRmAztkN/KCD4rh7+ZLVFLMaPEv7wQtSQtSpjx9pWoFcbDgs8SEE9+vGf7eCvr 5i1J5K0ifsmVgKU2Bh4zKR7ExqA3hqF/p9fHD3CscwqADcTtA27z+wdws4d7PZWGhHMf+wYgXMPE oVBjV8NDJAG9EWamv7+v9vFgWyTp4cy79TtZvn9bPZWXhya3QLv+t+ffOEidGFtv3vhrd8gfyG2B X1id/ft2Un+pj84fwBwNfR45FIsFN8Nn6q8PqhGxm5ZlF0rseRq+DmcuHsQrOtcmb65fg+v6tUgE RYIQuwKx0aME9yGM+zlHV9yadwHIOx36u+WCbe4X9sfHTKYn9sPYtDKtXojNqmzcFWcpYEa4iCaa Y6bL5cKn0CIUkwYi7OQ0tVOTc6b5JLTNr8E93L6OPdqYeYI9wZ3QTnRPmlVYZc9yZ7Vqd9W82P0O fId62/y0/Vb7bVM8x85wMxoNOSoJG4IwpYjJFNBySdCQhh1Ce7KjUxFiMSxzwzj9ObebwENSNbzS BCVmaJzp1jhVEVwpBAFIpTqIlIxFFx9+NU8kBp6sOjKGTOyAowQl2+2hHBmJfR85SvI9USW3wLcU RNVUbXVMnVSr6msqpy5Sb/zKIKCJo9VxPYE1RikhNJXGWtyQQkC+M0yzFWSa9AN5qwkgfQ1EGvNG 8ZkfVAZVCqeWQzvHjwMsOuAUJFC4ClykjGIgQI0wDTECSWE/6QvJQBL6Q79FcpQkLmkJHXbBLPQf ipSk5X9xD5YqN+AfEolDO0v1q23Kzp7aMlGo9R89YTwVVqiNHcaODTAJvaX2/n7MNblvPFur1d97 JFdhhSoe6s14Zbmnp3N/fSv8+f5cW0+cZFkCAOYXOMuCkJrnbazqyP0+F0r0FQNFtNH1VOA8M9vy kedq4CryyHAUbIKj3kPMc9xE6AVmipsMnWde4aqhOTDnvdTyCViEn3gXW8IBhLPPRdNs0MX6cPmT PN4w7n88yO2FAHs90LNI23be7fVlgkGAVW0Gp4zHLbIma7MXWYZNGKFyaEeIDgV7RQTRj91xPjSd /s44Loqjq9txV49F5d1xRIK7vUbiWyuhuzwJb4yEdyan45ACHGfHg66hayRoOF46aeDnAcKhwJXn StjyLj78+4dhqxEUmO7tH4jR6QJMk9BkQsxbD85RPdXZQtq+/wF9uD763WfzEaXNte0+O/lLtv6m zPzO2HsS7gIUGHm4Qs/S74NesIEeaTC1LZZtkrdlm+R4JMnlZLfPR+2W/cQrA3++Uf14anc+Srbg 9Z/mEXImq3aEJH/e2Zu3OGfksjkSINGD/ySXBx1MV4/Z57c9+KV+u72d2CD+yb/48KbdQTb5/cwZ AQqOV3B2CEju4Eo9DDBWyiu46xrnLYMUzutGjQDjpn4dGnjhFNPl5T/q+qfo5vV1pq4n7WO+tlfz FL+rH/JiyqqW3/UseGle50+BU/nz4ILvQoFt56ODqFwtM562ba5t7CZxk7Rt0C7Ptru9rZwIpBG4 1TviGylsHRgeHNnwTd8R3znPWe9ZX+Dr0VeiVKp8oExNuPOgr5TryvYt4UbZD/yYPjyWX/NZfnL2 xGAB4S6UIq3ohJ8WneFFP+MvYcT93u7yWTuEA8IxgTaEMwIlnMYFh5zYLNklCh97MlvNUtkCvrdF +kk7yPhyy1mYnZBBvsXv7+vDF/8AR4DdnV+CR0AnkMl/bLWAnJKr8msyY8v3ZKoqQxmRTfISNQw4 EMENdcqKLMIjdkfSsNZxdqslcmNclaMRB+9xcIyD3PDQ8PcEfRSXp+NTU/r2ldUVHdV0vNBLNb3Z JqMvx3FKr9bujKOV4+WVKUz+etAie3TdaFShK7Qf4hq0gmNFwrXOHJ62NxfWt2VcoYFif5FiPW6v m2LTkihRbMFniSDYHmr7J9flAtvUdcbxc+7rXNvX9vXrxrGv43tj7DzsxAk4JA5hMU1KWFqabCEB Rt1YtKLT1Gpx0NDoWmFGOxRoS7Zq7KEioGOdBtJIC+FRbZq70kJZI2Xd1LFpiGhir3aZMg0mJJZm 33edFm1R7jnHx/f4nnPu//v9v0O8PnfUqdPa2Boxq5MOOWPQtozDq6s6ddVC0Sl16QgnmAQACgr4 TzY2Nu7duxcYB6yjxXGCeUK313LYJLECqRVW2oymrlrVOVe23XChXyPzDMwtHeDzhiNbBZeOag85 snZ4le31WNuhtkNtg9qWJf9n6FthnXGwsVhtoi2Dlg0gjNUyKVDlr/StXrWySqvSAh6/piE82wPY X+dBAwerX7WS63thxeq1o1+rafjl3zcPdccTXDoRT08dfeqhNbrXXuVWlUDX2I7WTvqd1EDvSMeD zz7pqf76l3pae786smJiR21tqrN5ZaZpZLIhel/yuY/f3bfGz5xdHYd7X6L5rupUIbthlBBu6e7S Tf6i+CLRyAr6fiXyX6sRMYJVjGXRr5CgHaM3CAL+s+V3CsoMu6wGxrmC9zvxfkUJVhGBs/kws/f4 cza4zR8g4bjNYW7lGOmGuO2+npy3/MyK0+vJsvoOBC0k+Mt5Mpgx4eEnYByOwbE1opiIkyBgRBoO cqhenM6ds/gZGv84j12Kkoh7LCBA4JexNbP8vBl8HJ4gdqsJekI6J02zD6OCmOhx5lcbia/wu4Rv 8PuFV/lTMutjtFP21znX+Wr8vcEqhQhhjagm/XQmrVFxUuQKYgkONrz4kaIRElyhKKpz0DnmnHQK JSimnDxxqk7D2QLNsnPWyZwQ/ee72pyF+C8esAIJg6drI6If+J8fn7dmOt7tqcrenv8PvW2FRn21 wTtYwuBrDBqyB3VSHXQougyfooJp0GpHWCcRKWyQijNjEEJj714QPGgc/H3rVgoy0wJ+VtEWenEt q4uv8nhQdKuXNUnXPPf9F95/5eCpwR+OuI2g3uiivqZVT2a3HTnyWFtbPffvi//81a1vlzo7+emX N4TU2Nhi/eIfVq668vOpn4X94MPrQUP94B4mvf26LNBP/IMLSQpqQlJQI5LlAZIWd9tYwRwzORO2 ZBr1ZEaA+Gd9fm4YGlfPoaNEWnlAPOA7me++NG8JZeYSKsQbQ4zubGzKkBi+vSrnZpHTfZuEIXFI 2sS2hLfo7HFxl1giJfMsHO1mjTnyJ9HWTvvoSHBYH40VggV9V3BcP+B90TfpmQy+Sk9wp2Nn6Jv0 Mrtc/Tf5pv6hcYsGJa7fu9l7MHrQKMUWYsxj0J8uzREDrigAg0QIArgFdFEwSyZHTNU0zEET1zVp HjOnzLI5a86ZC6bT3BG54abuy1rcxiJ4BvBnscp1eLOwSIf5XlShA8ohhVPSKmkhOVIgY2SSTJEy mSM27ODIyZ2hfSFuMESPhmjoAlVy3gWJEkmVKjmHKPXU9lzkvkksYY0XN87nx4uLxfzNoiWrZLJ7 fr5oofumdznE7EORRyM7I/xLEeBxcSvERkdHB+2gRUwzxgkgu5JpBLNh4N45X1ZU1SyFrQdWAhnL r6kV4NEkSKwIh5NYLdeWIZbWoF1npYFIO3+FbXx//Nq+l/9K6dn9P2lNranxOGKxzzy29nPHJ7Y/ 1J6hD0+/RaUb16jr0MZEOhHYFa3p3378xN2e5t2w+t6lm4IIhIqSJu6BZW0l0jlUVoMUtEQlVwRm iY0YEc0CluYwEEse1JOhoNAM627ovZOzJGkEcYShv8H/kUTQqOFTJOpFdKm+nM3FDfv8JA4vLpXi rYwDyZWGiy5nGNchvyhb4oQc4xN8fd4Lo4jh4Hkcqo9FaC5SiHCRqAN+xqFZDNMEBBbM0I+1Ibjd UHL4jWGkmxuse6zFScOSlG62qDaTrMAtWZ6B8yJOJp+f6Z4HsgHgIDYukvRS+UxfXyaNIXJfsjlT SD8tPC0eEErp0+lymuXSpTRH0lpjIDksDsubkocZ28CokW6399lH7N8VftR4LM3K6YUkZxjEMN8A tTvABe/vMgaMR4wd9ieMp4yj5Khxkl1k7zQ6ErKvTlnnrfH1BiJ12jq9JtIbhWEOIRWwdi2aoqlU lHdEicNUDEwwvIGCVtJOa3xUm9Q47aOGQQnmeqa+OYP1+b42qae5Z0+Fj5BlLI7nuxa78A9SZYDj POJRtfhI1HuYDCWSglwXT8gNBkkKUNSzuEEbxZQFRlpBYr4DFQ76LtLxYh78Gdy5YsReMOK2e2Ss 2HGVGGvzNHOfapi73FPqPzx3563dA0DIUNJJPU1uUws3OT5eaJa6Hk1vuX/b1BPbHl+/9u7bb9O+ jT8+YoHy7vXjfbonVnyXXusdyw588crV34KiHwReDvFTxE8i/DPLiq6XNfA7xQ0SJC6rclnAdAVa coQagAaOEBUK2CiLldjIeTweaBFHOO5hhKmMY/g1jmYWXeE+JlxY+sAaAY2r5zEahFaHwwIDZtCg IFRVPp+3ZA12nJ4p3zPjSKBEjgGOeMOiE1+ZROWJMj4ktwIlrDKDTTGesAIkjseYwL4lvCK8LvD4 KAZLw0hMoJz9/mgNrBObsFqQPa4WKjh/QpfLFa35XwtPzsyii+cv5fPJldZcYaYo91y1dzSYry6Q gv8DXqw2dEjT9KyW07NRnJW9pz8jR9EiopbE6jNW91BjcyYsVdu2+B7RRqu+ENwWYpS3ScwmK2Lg s9IE97y0XzmgPhf5AXcqOO37Dfc79+/VW9y/eJ+3wAryGKxuwvYmu+JeYOB0zPksx9swTiSIk/7V tvVcn20guonbZNvOjXMTvonq7/lO2E7YL8jTtin7Ze4v3Jxyy+6XZxklbJZxRaxx7yZh06aYxJ4R /KRFC+BUfd6sdzSwJ3A0cCMgBALhXwsU3uAsGIiAKaoPq2u5Dd4s7vHDYYpvhL0na/XhrFujX9b2 aIc0Xrvl95dk2iJPylyLfEi+IfOqnJNhJfKUPCdL8klXQCATqCs+lfO2uHKuQRdPXKrLcPELLurC mdhgL109NT3LmQscATYuFjFtKf6X6uqNbeI84/f67LN9ie2z4z/n+GL7Ep//xLnEIbZjhxAf+Tfq EBIgJQleIAKkqZWmJFZhFV9IyxhjrZaIqe2CJtIvZVP3oZQaMNUo2RQhtVsK2ge0daKlE+qHlUys q9C0NWHP89qZOid37/s+977v+c7P7/n9flPQrIPOF5BoiphS8aIdfiLQ2jMu0NpgD7qBeYB6stTD ZjLM3BTpmyhxDNHp5iapOcAPVeQ3GCPcraYpW6upWQscJmScaNZYabBGXPFVRr7KteqIr4z4yshM R5rVnHUJ3qw3aM9a4KCl4P9U+uTkZB3nQR3U6akymAMZTJGBvaAccJ+QY8fOHjyjBlwf/fytL/9x 7cLtjbPkVwbBezS9/7Ru+x9eeOHoi85znxPy5y+J8fdvd02EMtpLoIdGGIY9aXiVietMVXQrKuUr VUPaUTUEti9OBCtHTNYYMeGYOOBd/01zIECtDgp9SlJWDunJDJzEm0KK38MwtpitTHxXHJyJacut rwgrubV1Yb1CSisop1eF2/i3isZ3i5ZuMDa6hoGlWkOMC8FOphihQCQcIpBQXU2/xp+0GopGGofx J1RfW61qyxYF3ccT3H5tDXUrwrHnleCSaynM9rP9tbu8Z9gztYYLetKmnpIXuUXjsmnZfFG4aL+s mgUO6tTh5sNxnWSylvym842k5DeWWZMWaPIv+2/5dX57SPGQ+KhAhERzzGHnTEZegAQvk33vLYDh LeueXCHN8TIRNEs0Rhw2u3DeZiMhTNb3pqeTtO3qqrS5XKUNtdNWc0tyctFKMMUPW2etK9a7Vs7q bXmf5VhjRUFNVZJyeB1Slzrbbmi+mHpYBBbKARltFLtzG+Bs4UVQ/nEoEac7rLjCijsqMRFnSCJV 1kGqYeAAkWR3QqZ1uOQUpFs6ZW9KdYAFpB6QKqaKYALn5+pwkUuS0rN/434s2uu9cmXi6txzE11J v6cjHwiEWzXpEbt749J8Y0soFO0/oju4q/vcB8f71Yw/JX+/rq79e/d6d0H6MTs2B9m/gCbfzjzD TLJvaC873KNvhJfSLKMKBd2J5hP7dUwz18rteyWoz3WOFGY6j4dnCwv6BcNpzw/FhdRPek4PLAz9 aOQ1z2vi0khZf8NQ8pTED5MfDq0U7hYeFB4XfPVBV4eQcqYDBcMvTfl0zse42bSc9zHePoddsFkt tTW82VxX5zSb5hXiUMpPPy05gIcU/DmctTlstRpHTW5ZeUe5pbBKmVy8OhGfB7MFUzULznUsy+/I t2RWrq6hLSyRYa4mLuZJXoNoXoNQvgWhkx91EmeZmLS6GRM5ZYKOHbYxpbilPtJXZtu1Wm+eb/OS Ue+8V+e9qfsjwwG4hpluuMRzRu9esrelxTb8AZsAvvPDOcsMswktICTITGIhsZxgEyLya6IWIZFI ZVvZ+TEyhs9mAbRC56OS4KSdT0s4BTqPNd4CQBpTAlESpTnoqU8uRMlIdDa6Er0b1UetOBMufV1C yEPn75oDC0b0eLCQKGiFN+GdGwq4VKqpTRasC68PkkEBFw22B93E5p5134FiX376lWbHde5aFAZu +h3dZd1NrW4pR3LtCXaU1Y2yhGEFVsfiq/Q2JGkLu7J4e5TJ2LmOz8g+d7DwPnkRfB3/7jkxHn+C sIBavl7coJ31ePGhEJ97QgfxIlb/+JzwELQbGFphvUoKG18gReSE9SK63ilocD5MBpYo3ZE/k3XA E8Wv10GUxTGifKZApIjAs4O4hYqDB8EW/iniTg6Ndw2EUlKDRySGsLKtvaM92c5yO8Mj4ValOXxA GZOItN0vMUOp4SDTS3JBZochJzGj6rDE7IuPBUm/OCiRZyPjEjkw3tDlg+m+7czu9nyQDOVTaU3X F4Q63qPvlsietr0Ssz+2N8gMePokhjKI0B3Hr7d1omj/36cZgI8fUpxCspuj1KbxrQLkaEpwZFsh Id51UP80ScIgQLEKAO9gJTACDzVVPRSHytND/+gVtFWpJJipdCddRRphAqWvVDISJty3RzBOjR1c e/P09O/iVpYzsLb4DzKrb/V/pyUgJ6TZj3dMzTz/i//89sxQjT1lPJyMZ4krf6w/Obr7yEDH5r/a El3HbpZ+3ZG88DnZE/vZ5I9XNQNn9tTzBm7X7Pw1ZzjrtAeNetZgtszumzt6fnxbWhSVXvPRQHug 6ZDu7ImTF8d7iyeXD/Z+81LHhJII9ZzalXS79UD6jAWK0z/BzaV1C1VubMhoCFyBt/OUCHkxhGOx HgcimDWKCeg80KjDE62YpGIY2TKAgbCcTEVUIutra3XPynQPWRVxD7X89N8ljELnSQkvqFsYg84j zUZJme6nEnBhO3mgWgccChxROCJMEojXltLMsDaVZiL2hha9EdK6rQ29ILDuo0eQlFU/SEWrsHp7 m7Aar0TWwCCufssbTiQdCMkUPcMdI0nYFLe0R3hKvzylXJ7SMi/SkEhDIg2JYqaTyDQs07BMwzI8 zWNabaDzVQkvQOeb63hNVTOdVdampF3tr6HogqcAG7lmp7iCJPZpbRmtOcVnpkE32xRbeD6zmNFf zqxk7mbYOEdGM9OZWQxpGRI0iTG/vczaNHujGvNH8o18zC/km+SYP1xmrVprUyrSujPpT/WTYCTN 0KcEWWW3C7xXDJkXeXKZJzZ+ll/m7/B6HouUojJyqDWgjqrT6qyqn1cXVd1llQBjqSvqXVWvTnde AncoPEFBicpyo9ICLyMS4Vm67dksNYb48mmpcNZLBhOn+MKSwSsRo6ne2ID0DKClBD1XZKYIFK84 UjTyMcIQudpd5epOIGtqDjkjtYYQ3daZ3gqCYyTDMy/v3DPrq7PyCW2zx6Vt49lAf6L9+bwrO7jZ taPJKdoC9a42K3EYfrpx5OTAge9qb2/+ZjwoSqFQJCzsIf2vH2pLjmxKh1oDoVAdnznA7qi4RwZk eTecjICXGqZR90wFMTeYEBBBA6azw0LT3SKLmMmyiJkt14msGRiE1nLoPKCJb0YXiJeh8/E1nG22 iFsVHzp/LVXh9mALbveuUrQFy4AAz4g8I58CGm6cAQxPc4SjShYV+XXcgGvk6kAN3oOivjYl3K9Y SUiyyhkgATUzvoo5toWE/3JdrbFtW1eYl7JIS7oSSUs2SdkWKYu2JDOjZNe2rFirqMSxu0ROvcaK IwxG3L36Y4/YBgYMyB7Zr/wZEhVDMaAZEAMDhv5b6rqti2GoEQTGfsxDhhV7YRuKbcjyqFFjSIui S+SdcynlUUG89/C+yMv7ne98J2wyH0iyEtfZPHGiZVQqnuHqhYJQcwXCCesCjw/lODM5IEZxex+7 fTgzELBSYeYPYR5hH2b+gDvz/EFDx2f+Ay1vey5kpZ7wAS/HhHf/+255d4nlIy1X0BsWWbZWrIa1 bu1bftOat3gXCwsD5ujoGKsnD3v15/JenRpktevo8TFwkOjxgXA20QVukdYrZiI5TXUabcBWihw3 QMVoV7ARIIEixuCNo+NYuVJ53PcNSsN62NJcu6hhW3zi8FhDI/MaWdZWtIa2ru1rfm0jtfFz5g74 2nvoAxB69zyZCpEXtia3nIFtCX4A9SWyBlgfbclOiCPRR7hmsE63cZ0dnpoaHi5N/UAfqTSPHnV6 A2Ii3peJkJj/EnaUhoenmsmH5ukiADleqpEXXzlk6pK1wvEHX2nOkMv+y4DaLLnR4vlQJsqSoKiB 53d/EwmaGS14vt+G55/dqIdPD9tBbA4bWwdNNgWMD9gUMP7Gphg4JYBTDE7IphGvNAMNIJ+yPb2/ k7nc3m4O2fqPuy1Y2nYbmPYO5C5v/SxOBJ3Y+KXLhfGwvQH059rzdsN+LfJa/7otmHBzwfbJ0HLT 9sU7M2mzkk5kpnXcklCLxgPDeq+ZpWLPFom4YZnjqAhPlq5GSXSLvOSWhr1jdmfHfY6tqnE4Xw+1 HQy1nQy1lmE0TCKZZNlcN/dNn2niEHPr4CPIGGGAuTFs/z6JZ26fvM+UWGlORilWOikf+9r0rbn7 cPogtiA+lcuen10Tdns3Gd721uoyEGRRYVKqyy5yDBuMJOW+RETqH+yTjD6SiPSiyiHt/AXCBCQw nwFMy8L0peeZz+AmY5dKNsDjwm/Wv3RmJBnvVV5Mak7PY/RcZt3DdqlpPvj6vX8fSaVGw+Li4OLL /I9/aicZggincFwHBd4r+N5t4ceOs/Cvs9KkCAGFlYSV0III6MEStMFthhE0XNsTCRNpxyAtedDB iFJggsFh8d/pQXA5bZ3gtHWCg0yKC4DRdGXWJBPF6BgKqvHBDHsQSvZfgVoY4sYBe10TTC1MFLgh nbJXowDJtwI0zODt++frQQFOyN6zWyLiob29vY1S9wkZYW/vAGsCPsF1Oc91kZPekYpGke8SZAL/ nwReCTZCDXpFelW50vWqcbX4RjBY1Ivxs/JZ5azxTfmccs64wgfuJfYM/kLgR5Ed3450h78j7Skf dnWWlbJWNibNcnFGWgt+R+rM8cOyOWgO5YqTZFIWu+UaeUFeMDtS8iJZlG7JH8n+LyjPGdcD14P/ CvrVQI9s9BvGMf6IJIQUKRqO034pETGEU75axyl/XV5QFqKCLvX3J4xTfEeL9nMTGsM0kX3B9Dh8 o+9RQs+DbwQFPU0pPLqlbihTN/DRbzEeR9HMeByMTxmPO05x8rGuYbIG9cwuBCAmaVQmaXrdmiwR XumKRmXdiCd0B6RKeiDIBxJBVCrp1EQ6VxlPTExzOS4EvGOZRswkvGmANswTPkYIT0zONKKkI81L QVnWggWOU7fIB25Vo78NhYICIF/XtWAoTy9Qfp+Sm/R9yq/QbcrTnKpe1YgWN4qkCNKGs3I5zpGd a862c9PxzzvkgtNweGd5srhFvvtG8hffZq69urYEjg3q8qS89jGa95dA8TySOSXsKpd03DImRQAc uVS6GHE0O/J9+cbFzpbBwQCtFQHkPSJve+VF7LshinX4Pmtrq6tL3NIaWWI/bpVbhWTlHU4Gt4lB vmJkIPOCq98F4GWkIo9xKlQMYaUUJa8KeBWF6nVgFwRrG7J1AtShYM4yPjaUHk92C4IoRllOgxFn ApMVgvFH9XRV4Ulh9fyd47QzOUQuvfCtyr17Xx7IW/qzzaNDvZnmf3RnrunMpLpDUsSMdw8rRPZf erD63nQXpbF+3jR5Z+ovzT+dT+YiQcsi3VH1GfJS82Z9UiOWpYTU5Bd9R67O9iopZJrPg8KSgGm6 ycttfaWCvGD6KkYFIhLGGYRxBmGcQSjKbKQNMO6yDIO2JRRFoYWEAcY/3sQ51P9rIIdOuEQuCgQR isYYQ8S6oQEpYBQTCdLOGGzMGeSdJ7KGdJSppFiMxRqYxnEiYUKHMGchLIjgS3mih3rkxQxP9FCq 9jwl/MvgI57Oebuhbqv7qk9F9VKeGcPaPVycGiPqRvirE/MqcdV5dVldURvqOgwUaTYhHh8g2YSQ TsXS4Uo0EZuGVxKFIEesMG0tQ5lsGZ8aa1AyT8kyXaENuk73qZ9u9DwhWzz5Xi49FipLZJUg2zGd 8rQ2aSPjvD422yyXnXjE0OIZhSj+S/+rnJ7sZzrE516Z9dQziyJC3vdLbtH3h1YUUess26y7eFaq wo5WqVXzbb7P44Hi8WGLK+EZ5202yh4pzLRHzbRHYYubxFEzldkKG1dhQKkwoFSqMXxatT2v2o4v 1fYCYHzq6ji2GsRlqjabbrPpdgEO0A1hQ0HGaXD/nhvCeYU+XBju77oGDi3wrJ/HNQoKW0Nhaygm xkC2hplngXLr4Lq3hjmMa8D9X90QDjX5Vv8DwCisY/boudFjz6GgMmcXai6OydXI87VztR/WfLXT wuyINngoJJYO+UXUHHs5jGhLSyCsHm7jrx3QHimup8wW1KEEvNus3mFZgv0I+SVYHlYPiX5xoXZa 1EZmFYZ4xexgYcQWEOY2a7MLFXZXYXeVKuzjLgO/aZ6B7/QJcw1m4Cgw/st6C4UzVYzx2FhtexAY n7DearV+puU4yqNShjdnF2yBY3veLZeRlAG918InFs68y80c3OaOwZWDK39w+824pmuaNun96r1u 35h4s/5hj+8CQLy+DHLTDpNGnZidZjahbfEPNgcK2cQIGG5ooJpNzB4fULIJdcsX2UzZ2UR+yxfe TFWyiRkw3GdTtfRcZSFRm+7MFubcYjbTyYmDs6cX8WAGD9FgSBQ6/OLszEheU4N1UJ+yYiXzJlkx r5m8uUXGXamQdWxrMl8gK4VrBb6AbT1zixXr/2yXfWwT5x3H77m7nM8vOZ/fzpfzy53j1/PFcWzn Ao6z5WhoITEmbhk0AUJTFJWtMJEEQQujJOpK39at0f4ok1YB08Y2deoI0uigW1nWbtWqDcGmalL3 R7U/Kk2opJOmShtqMfs9j+1AtVm+5x4/99z5eezv7/v7/LZsUWv1Gr1YW6rRVE2s0TWI6zf8Un9t emLyEr0TctaCfAnNnCRI2iJSqEOgc/uj5mloK2ZTCHL8GibvGklgBHngx6VasW+Q2gtw1N+dcLk7 k/FUwhULI8HdLSTDYAnikNGEUmrKQMCkkwjyBTCoFGy2UsDjDzbtotTOJWlwDEg5wbs+sjZs42z/ v/IpofqMN/fV0o7jgX3fqY7OxaROx8CXGkO+SizoYEPpHeb+LTQdGHygUdhSdnbEesYHzG25rkK1 URkuKoRz027kN+ibM+5UduaRJ6vV7YPHG0d2aJKaSATFuKeOXpzttczNTqNR3dMLg5CVHoKxghXp WdcI7BwIJRKhyna051RPm4ddFMX8G5ysRK85mUmcrI/wcIG0Au+W4tgSevGneCSh88SSeOIHPPED Xkrg2yQFX5BcOM6ltj1B50PiStD5xErh6RIVITdHyIMi5BERXcaP0Ak4621A1puIRjpNk9Oxtznw HToVphN92EjsBVKZFYqdVyAhinB0w5HEVxLuRNGm9NDES/J5yIk3b4oAyCCRL6LxPf4hYgPBDXaN NdvYk5dwFOOfhtteIH2ygELz+e4ET7InT5yCJ67BSzQeksiQxOMhSTL7qQiZGSEDEXIxQjaKR/W2 XejYTPAMXTf770Jpk0rXcm4etoXJtEzIFOP8oGllTd7E8d9n1s1pc9ZcMjtyLLJIfxE+LZvcsnnd pJdNNA0DKyYT4SU96r7EuC1Pt65HE2PdvB4VxuIRPRoHg7B644V0dkNftLAxTMWLJbLjRDzudguO oJSwLfFomUdufpY/w1/jWf4S/ZYV0kuRRFbV6/q0Pquzi/qSvqwzlC7qtI7zuB0CXp/uh1CHtE2i HGL8dvPcplIc0OXyWiiTQPbKXQzHJruYYBh1cHKH0g5jiOKpOXhTUwgYAEfy/wRwiwUhIu8dvAsB JVT9wXerBzRJcBbua1R8VsnBbqg9ccQp4ED0P1Bwq+04XH27umPoeOPow2pXOJFIp9zj6Imn5p5u RKakCETaphn0lXObFRxnNJj2R8xliDM3FaFdrUgLAwYSonMRnGvWdKLTCa3C4tjBF3HH8uFBlkxj g0neKSapZmYk+r1KhAvc1dapHV/H8xR8cwhrSmH9RHF+l0gITiT4xhIOwF2WjbpcahQLi6QiLC7I ReRL4MHW/d7FAPqJ9Ib0e/Se/XeRD+yc9x8OtNl+v/Rw4CR6yf6C+4OQTbWKJquOgOzOqOjdwHsK balolG+vxsviP90A/h8HKbLoOm7r7DQ7yy6xyyzH3nRZcNFynYESZyQ6UpWNreKn80ZtdQozXXU5 s626XH9w5wVXdPSCyo4+tHPiLcp1Z4Vi4VDvrOAUODLxa0phihRL+ZniDfFG6J6PkB0mWxsCEQ2g iDcppOhkOOVIcimP269REaRoSLJDT7ZBz9cpaijEQBNwBjWqqwOaZgGy9oK0gTBvgurQyITlOUwf 5o45jgnHvE9Kh+XDYX5qEgohKH4se1j0lENwBOBHv+As4ydNgkSLoE8/x8W70ymzf2Ag2M1xAb8X axIyB01dP7H/yLWFa8f2PfWnbeb++848/eiJr21izp9+7vw3Pl88963XT9x6YsPw6eN/aHx49p1P X5qGouPOrcYY8yZoLU2V6e6W1vSKhV216Mjik4PDUnLIvi5KY3Qf8WCfJhE4A3P9RZvXiO9qWESd BOyYjOFlBU55E7w1iEsOwI/epDAwydnSxIUp4sIUAnWCwwK5rRLDJSk53zTalRXxXTDWPFFs21ov U8U7n1/EQiw6sCZl3HU4KoOwOqJbH/FIn9bMARxe1CdWiMCaBrMynJCmUJcAi3Hi1eAF4H96WGw6 I2o6Jpjn9aZ5XjWwqk84KlitZXFU3CW+4GGf7UGVnuFKtWdXz+Oex3sO8Uc9R3ue4c/ZbvC37J19 lYnSZP+BftaqoDzPZHSvD7Cq69luH8BVOk6lY+PpKLWR9hoZhu0VBxBeCW3Da+qShWJBdSw56GnH ouO8g3F8rNG+S2ifFdK0emw2Ri/GEBUTY8uxldj1WEdsevDtaquYGRKJK86v4oJmFbY17wmWxZYj MoKI+YcoWsubtk4+2Z9ypfqSpq2ooXwnNCX7gIYKzl6NotakC0Y5Nz9FzU2BBJlkKYBJB+vQRnSY bgNMSVp3t0DqaBomIJDZAh0aKalNL4+/uHvu+dnXxgYyxWC52tC61qV9ATEelZOo3y58fdvMlx/c bU305RNMef6vRx898Mz7q99fCLhzjRt7StFkEknOwgyzd7JPFhYarx2MD05sfezyX+a2yl7QMrWx McZSoOUIZaD3W1pWUsQqUwEJnwIcskURkTAScE3iwRAhEA4RCIfA6N+Jl0LnPxexpIUOrGAeFCva Ipw76o0nZU6f9DptQlM3IBkg79UWHlw1Vohim6JZCWWxhYayWIehLNag4laiO0QG5Qhya3K6nqOt 3GLuR5mzObZP6YsNZ9cb46KlWLHx7GZjwl1XJqP12M7sI8ZBca+yN3Ywe1ycUxaic7EF46TybeNV 9yvKq9FXYt/LnjZ+Kv1Y+Vn4deOydAVW8DfjpvGZkdVyh5KHMi/7TvlO+Vdytm0+1M0LetSW7kZ6 lEvHQ7I7qjJxRUd4W/FkRLbZOCEUolRVwLLLUypaQvQ0WkTnEYN4vAv0caogBuoB+jeBa4F/BpiA iEcDIz0jC8SJjbn52uptYwqnZxxEWI9Dq8O3sR695VZulhMZXzARTGlUxgdNUoprKO3Xtab2MGaD H4L41hvUPHZAtKa1ItEadkIwQorw9zqmqT1wRBDeALNfLo01ir71Eb+86/nRk39G/nfK06lB85vp meHZsz88VNnNnP/ssYliOJkUnWVA3wPj//rjDZTUtHDidh79HPL1ld9eXilRQL6dIK9fgrIy6GJL V5ks8UhODXrSBE7Tsoo8RFlfqHzVNteqbSJVsRt5sMRUP1afShBWJRUvmYhERpa6fgWik6kUyO6/ fFd/bBtXHb9357PPd7bvl+3cnX+dYzvnHxc7iZuGq0p93Zr+LikC0WbgJVs2icJY0wzYplFq8cem ahMNtBLLMsjEHwiERLtoPwJSWDtZMNR5rcRW4I8yhKKqoHqMqeyPTUn5vme73YRE5Pfe9+7dvfdy 7/O+n88nNGEdtU5YjJX3aQEGklULO9w2+Nv/UaVS83c9Jdrj9wwebgDePeo/4af9MIDmhZWSRCkT B4vX+BFJlBD8k5hQHLyK+1KpYuGOmITxqUqt1arf1pAx9yjYN3GEHhFd2hW/5/G5RTRVRCmc5Yhf fDJjWeb2gaS1g+KFohw2JeTRGn7kd6QACkwyDOUDRzjlRa4XecupIipScjaVSpmoYc6bNGVK4BDP m5dN1pwu/OxhAq7bHm9u7dgcQZbUnmvX5Y6Xc6hewgONOwf6DogzgsUdUCfgpeu6unquZ9K6ig7t f+Txsd2bsplDESUyOKQG79q2UdrZr/NsMGOkLB5FmLNvvXW3bW0eDxfu3diz3wLxlo0SPzXzwmfj WMABXh64tUa/A3gZ9mzq4sWqErxUXazOaKTh/Uca3m8kxgzOCuD7VlrspR8RE+kI7heHfZwlpj1K iUWPs+ghFrG5CkKo6NMfTaKZJErmTANNG7MGbSgCVWvW66CBKtBCUwcyrWGIgO5rvd2S3u4w6W10 jKRFi/MUo0mlzNLFYV9nGF3Zx6Kvs0+wNJsr+nYk0QPJbybpZE4REF7hB66B0SKK1RGDCxEXYym4 sazqSJcxm522CRqqXsdFajbrNampONABi8LQKfht3aYVpewKjp0XHC08GbhnYFE6k2V5H5/nC9PV 2Wqj6hWrK8h0n4J0eTF4MdTMNnN/ylzJ/sW+5rmWuZb9hy0oNbtuPzx43D6FTtGnmEakYTRijfjJ wVPloIhEmmf8AW+ct9/o/0OGizPRsBKPJvRCzF7wL/CL5unM6ayglIJ5e689UZ2qPlZ4zH4y9PPM 2ep15lo8UOCGk9QqnUQpVEE0WkGlZWq1vIIMVy5qSX01ljRSBpIME74c7tRXo7izX1GymaDgES3S sEn0e6pcKQ5TFP6oxnd1XVthdrrhaAV/WPpNBSHlUvrd9L/STHqFCbvCrIimxVlxXmTEFbTZ1S1D L6c4xNlLFpq2Zq2GxZjWkEVbv0EmNYLMF/f1DseB9txNYo7W63cfXr6VRvVJpwK6cvkWghC0QXsN +oG6sG1akzqSC1egSnnwadmgEA4GhadC5VLouNSc1Cjpxs12fQ5J7ZvtTkzCDoheKpv+4CaqNEly ejxfSJmS7PWl5HQceQtcHI5wMk758mwc9RI79l4wl/9j34fSh/LHeU99Es1RcFThpr6EluglZkl4 LjgfmTfmY/Pxhf4fZZYGAyCPS+gYpgJ4TKhkKtmn7cXsos3WJ7FolvOm7vjzuoNc3qGhxMBCLPOO gZ2EzjtluGWT4ncCUlKphUxcgYRcjjmk0Z0siIJl1cl0mgA0r6iOramdsZTOWKICUygwheLYpoLf ed8VRXhMdBgpCPME8QDvu0oQ5gnCM1A0mRSq9P/+4NtMknQlZ7pM1hft6+vkLaKiMnIVqyoQVQNZ YgGwEsM+lZ5PDzz6lZ1fMlNTP7y4+q0vPpSO9AXT6fhP7h8/dN/GXwcHF5/YfKAqS0qAObvxxumv 7R38TL5Q3jXz0+MLSd5Au575/ued8XvntziHjj3bJ4Y0yGHhW/+mt3ouUDG03s1huYSrQA5LuDhB CQENs1cgoiJWJaFKiEwF3UQIT8XMR8wC/hYB/I4qcLYYDXtWUGyZQl5gsvXLrUq72eWwq6D2K5/O T3pfANNQlNSRT8SwH9dfInKqF+hYz4VxNCsgQYyhyJEw2hNGZDoXoAhzCzHEEnPAcpjmWMKCLCzw PTIEXinhPwg+epVYCTURv8N/pcst7AnXL9fr56WW1KwDwZCVw7bGfk0FYQHbA84UmqLpWmJBXtBf i7wWXdGv676lBDppoInARHAqMBX8j8Z6tYhmaUw0oukGg3AVjr2AmMhQd7XMEE0jb2AULzp6KfIu 0VgPhmNvUsIKuuHaJpBnuZI4l6ATFEIeD5sNH1RRQ0WUKqnn1PPqZfVvqledjv/yZM8arOPTvlWq 3wTt0IY8sZWqra9h6pTa0LWGgD4pos6Gh0DsE80/V8JgrEYyMtFUY1WiuAZG5czoZuDNMbT3ypVq Pr1NtjKNHeXDxR+MPTLYV/Bc2PjjzvVfTW4r5O+fqU7N0F9NR4/sHngQMyN9a41ZZ85QOXqoi6qo 5WL0cF1ZLph5fGne1kNmsusw11yVGEuDPGgocfyc0oOb0vOiENx8GT+oZHvWM6TlvIIZ0rwJOyT4 ODjDL2PryfFU5WqpBTvakfA3OjhslUhz/mrpkzrqkM/lprlZjuF4wRS0UDbXB6N2hhS6mpjH2EEE VMg0PPjKIBLL4PE9Q+G4AZMgz/QSY2oOwGo/INhTsD7EXTgg2FMUa6CLPRnXUEktuCDVeQzEGoCQ CDHQgy3MqKPIwq7CtDA/nLM8m4Sx1BZzd2q3yRqcOoGdZ3oimbMynIW2+5LcDlPIJbgVNO6qPJXL ASXh/yfEC7wgpE2s/UPUOYRENIuW0CXkQSv0qptTdCOrKAfVeZVuQHVOZTDozC7sAHQDr5/4tE4D KgL4AfoojLdaB4htvPLbSg2oQ4rFRTkuGnFKkmNSIg42TtoKbAEeoE6AGCaWso/NjPZwCLrNN5ru ohOurFFmRkxHU1Zo473Bb39n/MAxOz62G22frJW+sc+5hzmz/s7SrricOfZ6467JZxpoYftIDOXW FxsHN++nfZ8bo3OAURkw2gaMmvSFDkZf8fspQ/GGfwt4kqGYUGjm7y9SkMLa7Rs3ahVghApsQBcr wxrvj3F+f38a3hPCUby/YdUrE/8nK16a3IHzbZLAxOO0Snd+CtGxlast6SrZVr/yBf6w9mWdgRz3 52VhtB+z0H2R0bAeNjL+fj4tm0pWM3XT2OJ3+C2Ko43qW4y93B7/Dn5cG9f3GEe457kF/4+N52JL /b/4L9vVFhvHVYbn7MVz2cuc2dvM7GV217tzY3dnnL3YnpXRDmrJhTaKqUhQglapBBUtQmptKYRU sWweyDoPyBKUF14SRYL0BdrYiS+1oK5kUF5S8kCqNhKCB1NaEaMQhahSY5f/zNiQArs65/vPmfvM +b7/+6nXmZ+zV+Qr2ddzv2FusMvcsrQiv5Vdz20M35EecY+kT7ONSywiV1lqPt/2sHbAR8X08dAh H3Xdx0rFR0Hw0HXlfJsfPk9No+nAK+HzpR+EfygsDLNdps21JSf3u6GN8vtZep67KA3k4FjisBRI SiklSeVKCpXgBAVYcMGts1m5JMnyCMulWJbLZbNVloGIoYfCoRADliyZANtEDWXliLSKID2d5hDm qtwlbpn7AxfmZtgcWcTYHbIvM2vMu8DeGVY+k11HOapEsXC/fKLNkvuWCx4uNjsEVqIdit2AcmkV vb2Mh9HcsP82YC+Cy3yyXSbCKuMaFLoP+0QvsjvShzKseelhdpvgtLTtlybeWifqOvDt1CBsSV5Q A1+1jfDGkz1kFHDtU/uOwFv6NTQN/uYGV8rEeiBeH60AslXwy1AsgEvhAFwu6TAlsCnQkJ+RiJk4 eTJZTvtGIpkE16CDreiU00NQAaEK0jRd0wX0Rl4303feE5nIcBvV2qlKfnfd3F3LGEWhGXxN1UqV kd2hQGy8EGf5iKqGBOXg478Hw6M2ZhlgS+yzrfB1YEs9eGuPLVpZEeKB+ipRXorVJCZkqMUhfogs 817PtkUH79yG38YTnFmjNMieTxPdk/JeSeH1UCcBQRi/lzQ2RBneyc/VUZ06oyI1csZARsQ/e73e KJetBqEOaCW5Vq/f6+M/9r2LCV7V4b3V3LWERRZpvtfJ6FBgCqpesk5bL7GvWB+rHxufqJ8YUbLD YrLj7XczV2yXLcv81mhBlou5CrZCnFbQ6pqjHRevilelqxoTUceqY/ox6ll0lD7CHKoe1I8aR815 eg7PCT9S5415c876GX6N7Kyu4zV1zXjbuqneND5QPzBuW0UqHKKH0iGRVWmdNYbMjvgUfkqYDD9H n5CeMy9GFvC8dFG+WJlX57U5SxywF8SBFoyxJ9FZfFYIASfga6oqh2hgBRYFBZcqZaVEmXWF4rm4 whdlRSkCqZYYQ4dkOuO6klotMTTD0lXTSJmmAatB1UcYNsUwLLgTOV3l1BTHqZVqdUSSU5Ikm1pF lkQO+MfBd1hH94BECrq3VES8QEaYioM3gSyIcbFYKlEBMomoOuwCJJXW0XcolWLQL1zecOFmq1Uj UnrMv8BBTXXt+gb1gllZRYybdnP2pIwuy+jX8u/lP4Hq/bhqA71zKyVeRRg+OqFiJNpW1xGmNCoN DI+6nH1aQ642pwU0MEjX2RndZt4CmjNgp7gSZaA5474RMEjuh0ONyzQRhtykieZMRJnYLJmu+aa5 Yd42afP5xr9d0/bDWn9Kzm7vbEHRM7XHbZjKwgRslrayYKVII2QnVM8SP9WbIBZrYu/vx9t+nQXs 91UgDirA7MsB8+RM7f8Jw//2NGYmmAlPMKZQH5RimpQQ/RrRCg2noj1SmCwBJolOFBzxCUgRuL8o OiqBtDe6lvalg/x85RjyhUMnOuHLxr6Q7I1RJejrSAzNQRre/G1b0jMT6PphJcXcfielO6j8dXP3 XfMvu/9Ud+8WxidAT0JKvljf+Qf65WBCjAdVNSjiSiq98wB9OlpKKgFVjb30+G+BIzsrwcCRVox4 xhxFBf8KCjMefLDnGaMaJ7W1UIOCU9mgM9cbSRwYh2CZaiiCLzS2TVRmw+u8ApeIjTtIfJlDC7GF +IIw0Abt9yLviXf1uy2WtzROjVSj09yZyIdNOt+1+FOjIasX7uGeMK71DKc90j0SOYaPCQeVI9qz xjNtt3tCPqFOds/Qs5FZPCvMZmbFn9KX8CXhqrSuKfEwj3mBrxdxUSjWTc4U7S6Hu8fZU6OT3dCe U6jCfZ8bR+PkQb5nI9vS2hIXoizyDIpVKDiW1XX2Bc22ez3yJJ6ibfg9eaYrGnBTzGT0drvDRaLR FtgPmpa1dqfd6qiJhYwtIKEDtjQTLczIkwpSbPXlymwlUFmooIqsWpbTajwwTb01CW97poM64TCt yjRd7aipTkeNZnR9pBVNtVpR+PISGxVbuipHxm1N4oLRNt3h8yhfhC9hW+QzQAIXBJKVrVADNRqK UuCiYDFvvJxBGUtdRfGlkoxkoqtR3HHlN+U/y/flEJkg2VheD4xSLYpG317sWDrowRLVQq31wDuU Q3UDR5fKt4CatUf97YfbeKfWr01tQz3jc6+/n23BanodnugTI+UVNoR6cas2iM/4RCMBkhLOjC3d w1t98o63vBedcPp2H2awN8Tn70FEM3giPjGI44mZzU0Cm8wmDcDA7Elg4HS/T1L1FDUF5FujIsAp zolAabLCOmJJSfQg/mgJME2KVDYv9GJuDvckMgsDgm5SjPfCbiLSoyXoRknUJVYE0DR4crb7y7yj lniS8N9f5B2aEJl3mgDLMdgQ82ZcPuFoJdIEmBPIcWAZPZOwmPBB8C1DLuZgeAECNNFNOBjzjgCt 7qadpK8KGR8SJBWmnSyM3GTaGWXSjjGSckxoApNxWO9kGcd0BWhpp0kaXFkkV4dGDr8m/EdbPv+j /muMPrfBkyHPv2REcYwIz75/oZOZjJgud5pkVteJNHljUpaOEZ+TQ2+Y5Uok86VnDg9raPRA9cDx ma2vHXZ2Jxty0r3wk6cbjd071Zx2auNXX/nqF0GY8qLUxMMvvvjNbLoAsiQNT1/dXT13IFitpuKi 2N/c/IYg6YFqNZwqnP3s8XfHgCvR3YPBh6BMzcDwnjKBO619IUh9X0d6ASoGiRSiKSJMghcKJAx4 YYCETS9sru4XE7Xt2j349+xb/X3J2lMKha1RhZQQeLWJmlQC5KHyKrkG/y+6qz22qfOKn+8+HN/r x712bN/4QWzHj9jXduzEj8SJE1+cQBFgSHkMsuJCW8J7I8mA0W5s6SO0pdPopm5DU7WwdaqUspZR 0pCqndSpCHV/oKGpmqppFdqUdowtXVVlqOtwsnOvXaBasX2+e/z5873nO985v/M7NlsaIJO+RXre r1zEvlDDBrW/ak/9WlyzaetvwL30KTiXPgYXAj0vduFryK2c4UQML3PsR1GqMdPm2Jl7nJ3QURzH WvVOvYuL2VxhLmgNusKxLpKzZt33WPdwe/i9zl2uh9x74kf1D/MPO7/pOuQ+Gn+af9p5Ck5xP3H9 OPYGXMl8oAsgJ4nF4rLME42pO1V6H++o0/uw3ud0uVIyb8MF8VhMI/YxGf8iuziG18fx6kSmoQ/U KX6rChhmtLY1GcgvEzKS5HKqbMF9kidX+Y95agc/wv+Lp/ljRW49t52juWPY2JqVZbE/Cj4i+CZ9 lO/k9jhJxotxKu5MZ6b8L2KXGluHTL08Vxmdqy5UFrCSVtetGB74EIrl6lysBifqQWjwob+jcuNV hZa7FurbxZmMqtAQuxsV17i41s5mM7l0h6R1sp0krBVdIzljTyT8Vy9bGvQtMSKHIk2cc/GZ3Nl7 e9Z2pvz5CN98T3D54gXB7xSlNMZw67LWFYsd5LNoxMoZTEjWm/zm4s2vTzw1EJfTDqFvaJI6720L GEUjRm8U6+oBjF47mVKSVj3TxEwyk6ZJ8xQzyzRMSsQkHTa15wZhqzBop92MZG4U7mc2CFeZK0JD PSojhJYctECZWeMalnyLJYPsDpZiU0bdgEAOCWS7cFCghBTFQ7GKIKkNKiLXOtw8trZwQxSX25vB MEuCSgfLTvPNBsYsCEGasdE0QxsoRiBGs2RSn8IMsoRNmYw6cbtAhBSheOENqg/MwFB9SpwmbZO4 rbZBE0mZFNOIiTa5klJRWi/RkrHNkAWKUE6H9PNaCVm3MFpemFsnVm5gACxU5kR8Yx2pjhW04XMb VTNRsHd78tjFJiLOI839d/2iQT+MxbBJ03DfvHRF4RDl6RQOjBqwJlQERf0WdOSF2aU/zzjyTMSm qu/N2PLMiFVVn52x5pkmu6pem7GjKmjqOeGLoImIOERof5b4W9SoCXT67cTfoQIevc1w8z1qx+K7 DxQa3UxER0P1p2Td3jWSaCDOxb8FadkZ6Fi9GLr5biDu2w1AQT+9m97I7gcHJOAxPEYwM01SyO2N tOgthojSMiNZFMMMSDTQSUw1IeQNjYdorN6yIri7TyNMvy2YveZxM21W5zim+6yN2JxtyVly6Lx/ 01drmVWer6J7cagnVbGMRBk/d4RADaRIjWuqwZ/ucNht9XwIffk0Wbl1Lc+ZTHFrtHd1Z/+BCeq+ YcVgMBrijmhvuau07zi7P9q2sydgMgu98dSKQ5t3vhwOd2/r85jNYk+sfdXY5r0vw9LS514gNFwE YF4A3PNI+3g7BYSS6Sggm1b55+v0MLmOvnLBFsUP2MhQBHg9AUZk9TbFNAO0R3WR6BXHRVpEd7zG dktOt+dNIoMf/kB6QfNG+bYfygvzNUwB8XcaRtS5NW60s7bThtpWO3PkzV0ht9Eg8Fa3JdLnjeUH 9m3tYffH+rKtWZ8gNHCFRNoTHtt05AFFtfW3aOsnmq3rlWWcE5GTFTkbzJgUm2Yl2y1IXmkcMwLt PC9+iZXVyvxtCKwfkmpjo1paVdwKtNwyrm7qR7tDLoPRbLC6VBPl7v79Qz30cLI3G856ayZ2eMKj mokEnOjpXvb7oJCzNRB5HcLE/WpU58AWTzGBrieTAN7HewUJk2BxWhR1m1FZUJDAosZ61Al2dulD JSgIqDnUaZYtLQdJWyHp1GmJUpdJUexvrk2r06j8ZVr9BZV/XFB/DIVKy9WyiZn11vvqUP9yORZT 9wzJQvHy5eJ8cV7l2JtHkiMZanVSyZ1InshNJadyp0uv5S7l5nL8ns4dpZHS9dz1zv/k/tvZMFgi Pr0QbeZbW0LTzb7jLWy0mWsNSNPN3uOBaCjXJdHtQq6rZ32GZGbpAcXUE0qAfRCLeSpCM7P0SiUR iUZA5/PyHN+eZEUhyEyyZxFVXSOl35eokiIFwwdDJ0NU6IetzuWlWXLfef+ZF2qHt1ApVAsaphXK 1YIGaAXEs4K4gIQYkW1+ftSS185UTb28iirtqf6HFUehKMf7ir1FShcLF+KKD4pyj4+obEx+9FHk t6NQGUKw6UxbbLdol0UrYgGLSs4c6TTOYp5mLYFsOpNTQ6OesGolC6iIZScHyXdH/PFsZbHrQY+N 1yceuWrkPHGfvGgMruw7d2740rGvfK8/4W1J5f0hj5webnTRz+mq3QeLSLtizbvJB5VGwVL91QFf k8UTDJafoDatuXD5SH6otaUtcG/SLmzIrprW0G3xIr0R3gEJkvCM0vu8+/m2qeRs8p3k35O6R8yH pRPmCYlpcnpagTCCXy8bm2ZkJWiAGatiNLQXPd2DCSIkvInxBJ3QIO80Hs/bTLdg99rH7bRdzR3B mWq/E+zUxLlRqVbG5tHr83P4UaPoTowbVXPoiylUhzX2LvPfGC7yBhPvcDjkQrmztP9J8tCWMs8b TQ7JgtCXGzgwsXhRzld6Edj0+kIstWpsy95XgnJiuCdgNun1fbHUysMIfnDrdeTuQr1SE+avNWF3 oVwDaHirJvr7UWYBOBHlMQAeXW04BWDaAyCsBBC3AljmABpxnW0TgAPnpY8Amr4D4Fz7/+JpA2ie AfD/CSCA64OXAMJ4v8gqALkEEP82QOJnAG2fAHTgvdJ4nyyu7bIB5FMAPTJA4VWA4gaAEt6v/xcA K14CWBUHWEsBrP8MYMMOgI0v3V22/BJgCPe4De3f3gTw4KcAw/jcffiMrw0AHMR7jBXQPS8CHMU9 H8PnjOO+H/cBTPwT4Cn83wn03clugB88C/Bc5n/sV3twVcUZ/32759wL2DIVhDDKwOERiBCSgICA lofhEQiBGBJeVfFCbsIljxturryKgkYeQxCEiTxaiFAGAsaixYI8bA0M2CLykjdVHqPIo9WmFBk6 wD393Us6dabjdOyM/aPd+83vnG93v9399ttvf3susHw88HPeJ2sYh3XNgfXNDL4PbGhBcI821AJV S/89Nt38V1Q3MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MPh/ABpiM58a0d+k2DOqe3GIJcG9XzfpUadrNJOiOt2iPqdO91BfXad7kS9baSlW/eiYqnmdLkhR c+t0hYZqW52uWb+3Treo36jTPUjRbet0+qOzsQkOuiCF0oNaNibCz3cGgigmwpiOklhNKksh6tGn j/WBmEUSW/qhkOIgi3X57B9Gaazk59tP6yl85tIym+1FsVoHw/ieGrMKss7HkRy2Rlt8RDg2Ry5t om0hFLAuiLz/wL/oqMWxEe/1y2EpwFLUIwcjqPlipXszF7M2OTaCExt7Ysx/BxNYeo6tUb8CMeuk TU6XlJQeTvZEv5MRLA6Gp5f4ndRgqCQY8oUDweIkp19hoZMVyJ8YLnWy/KX+0BR/btLYocMycjI6 ZgeK/KXD/FOzgkW+4swRGdnftT5W4bDGiVU5gVLH54RDvlx/kS9U4ATzvtUvJ1DshNmWUxwI+3Od EWFfmCP5inOTgyEnyJaQMyH4XHE4FPCXJv0Xc2MshjInMrg/Gej4jUy5lyf/zJJM7lkG26Mj5HNP CmP58V17f9/2/1OZDq27yauwUc/+mf0IIPH33noN8lQjsZXyaNuylbYuoINbg2n9yFBRlkJ2RqqD vnDcO/bCyEB5xNtKdvWFuK7L3hX2UJo4sOxFAPWWRHNdgYcA9yLxOXElMoR9C9AmMsm9oBvT/pd1 AOKxDK+jLWqlM/agBkOwgdmWiQoMwmG8RQ6eLgfIfW3QHxsRLy3JjwMRJzZW4gye4vou4QISkI5z 0ojjDGBEm6Kne5XPdMx3d9CqAWO9GTulUEYwWqlIU4nSkTMv5jLjkOAedE+ztBqXpK37K6RR+wL3 oz1mYQkakes/dO/Q07YYjyqZKVfRCs+i3OpqLXAL8Bi24oSkU8vAdPt0/a3M5SVYJ3FS4553L+O3 ljD+s/AS5tPjLahRSTrVXsOItcOPmVU+tv4UZ6SxdNZ93fbuE+5K1lbhuuqoPtBe+tERgzEOr2At o3ESn+NruU+6yWqpphyVr+zT9C2duz0Ds+n5BvZ9Ezuks3RWcSqO0YrDw8yi2ViM9Zz/HRyRdBkj NbJbr7dTIn3cB9wm7mXuZQeMpoevYzfnuCEptOEMurUOWy2ssN3l7otcYS5W4QiO0o9zjPvXuCUd KBfVC2qWO8rd6F6iL/XQkjzzJE9bkLwwFb/gru7BXvxFbqv6tDxs7bNn2LXuUsa2HZ6g78NpPYJj l3OXtmA75SRXeb84XEUPGSZZki+LZZlslzNyRnlUKzVZXdNv6wP6E6u7bbu9OFJTtOC8bTCKZ6AQ LzDaS7nejdiH/dJE2kknrugk+99Uj6n+lHXqsDqn5+jF1h17buRC5I+R2+4C3qX9mXejGc03GIU/ S1P68LBMklL5jJ6/qn6tG+of6Ta6m+6ns/UYPV9X6N/rQ1bIqrbO2oNtn13t9UWKI0fddPdlxkJ4 U7dgJiWiKx5l/uQxmwroXwklhJl4EQuwiPmyFGtQzXW/j/04gU/xJ+4ApBV9DnD2ImbdHFlEWSlv ym7ZJ/vlotyMimpNSVDdVR+VqgaqfDWHUqGOqJPqim6uJ+hZejalUm/TZyxYluXaXShpdrld5Tng TfCmecfX++jOl3c73B1z91wEkQcjP4ksi+yOXHZHutPpfzw6kTtmYh69XMkcXE95g5m4DR/gI5yK +XpdlNjM+GbShtmQyF3rI4NkMCVDnqTkUEbJWIpPxstEyiyZLS9Jmbwsr8hrMVnBta2XTbKN8q7s pJyQ8/KFXJPrikmsNLM5XrVXyaonV5qqBqnhKouSr4KUEhVSU7hDVeodtUOd1I11vO6kfXqyXqk3 6z36uP6bpaxEK9l63Bpp5Vtl1mHrqHXaum23tAfYE+1Ke4/nIU9XT45nkmeF5y3PFc8dr8eb6R3v nek97nXrxZOtfsd1b8U3f8mew1JqP2BNU+d5LprpEnue5DBiHpWtC/Ui/bGdJ7XakbOyQAd0gbtO D1S3dFBGqveltW5p99J5WAhXqtVFdUNdtppItroqCdYSeVcFdaryRCexj1lNrDL7CqBOoZd6XmrU Pl2my9zfoJddKeftSnUUjnVBNcZ5nup5ajk7HVIBVY7RVlf7NgKM+yZ7GuPdW82XDvq4VYlLuo36 q9TKMrLGQRlitVXPqJ5STca9Ky3wpUxGibyGvrJLPpXtENmoq2So+gF36231Q3mUH7MHdSs5rhtg TNRHaaeaSKaqVTn6Pc8R3jNClvgYM0RLCnPnH78Ib6Q8VKj25LQBZJNj0gXNsJx8fyPyXpSx7dN2 OfNsrU7kPZuCp9UB9OLZuEQZjbn8htnJHJzP7+AVmOnOllzyfgb5U2G7TEKy3Ee2jKNvs3hfNFWt yYXjOOst8v+HZP10+QpTxeHJqkGCFW1ZaA0gMz1L/i2n5OJpllZhqWerfQzDJY6f8U6kkln+CZ7h nfMZ538Qj9O/sVhrJdJrh8w8mT1WRdJ4P/alhwdE4Xn63JvnPNNKI/MucydxhQHeUUN5J+5HwF2O VO5dllvmlmOcu9Z9il9AI9yN5N8p7hZ0xzx7jBppd7S6kmP3y17eR3+QcvJ2Gs6Sj+KlGa5Rov9M etu7sMA6Re7s4y50T6AJ49GaEfo759Ue2+R1xc/3sk0exHmQl0n4zIfDEjuER3kkhODhRw1hlJAA dhRtzgsF6NpMMKpuU5epolADG0xaRauuQ0h0FUjT57SanG1/pJsqtD+iaZpSNE0bm6DbugGtUKlE 0PLtd679GSfdpm2Wfz7nnnPPveeee+4910OoorfxErmHuMWUadowv0dOW1FlHBXqJvVYP7RWSEU0 Zj2Nm/dndMWp4e6ZoEbtCnL3jHpIXgt/m6laaoN0QPsBUXDH/r7g9q5tnVs72rds3rTxiQ3r161t W9Ma8Lc0f251k2+VsdKrr2hsWO6pr6utqa6qrCh3ly0tLSkuWuJyOjRVkSUKRIxoUjebkqbaZMRi rdw2BiEYLBAkTbyAzejCPqaeFN30hT2D6HloUc9gtmcw31Ny653U2RrQI4ZuzoQNPSP198TBnwsb Cd28K/gvCP684EvBe70w0CO1Y2HdlJJ6xIyeGEtFkmEMly4uChmh0aLWAKWLisEWgzNrjPG0VNMl CUauiXSkZXKVwimz3ghHzDojzB6Yii8yOGLu7YlHwh6vN9EaMKXQsDFkkrHDLPOLLhQS05iOkOkU 0+iHeTV0Rk8HplNnM24aSvpLRoyRwYG4qQwmeI5yP+YNmzVfu137uInBK0LxU4Vaj5KK1B7WuZlK ndLNSz3xQq2XfxMJjGHKvmgyFcXEZxHC7l4dc8knE3FTOokJdV4Hrym7ulEjwpLkEd1cYuwwxlJH ktiY+pRJ+573TtbXB6esP1J9RE/1xQ2vud1jJAbDy9NVlNr3/Nt1Qb1uoaY1kHaXZ8OaXlqWY0pK C5nRvE5wojtz3fvycZXYI2Mn0sHUh3V4Ejewpi38M7qFUsNb0A2fhAQrcwT7cdhcEkqm3B2Qu9ne 1HxuQ089IOy/cffOQslgTuLwuR8Qs5wl+USD3uZNv99saeEEcYawo/CxS7Q3tgZOZGTTGHfrIAgf 7UVsBxMdbQi+18vbeyYTpCE0zImeeLat05BnkoJt/oQpJ1kzbWuW7WfNhK3JmycN5PE7qOFEy0xX U/5b5q6ujIx1mFL1f1CPZvXdvUZ3T39cj6SSudh29y1oZfVb8rocJ2UVCLip+hCpnQZSb19/nAX4 ar6oETmcjOGowUezMhRXPHIiy8keRQyF/B3Ij8yNeAmPpfocIv9HMk4XElhIJD1qupOx7G+iyOv9 L40y1sdsJchjs9yazA7/wvbWBe0F7pWkFDisNsndff2pVNECXRSXVSoVNfRoKpkazFgTQ4buNlJT SlyJp8YjSXv7M9ZPznjM6NkEFjEmdSC1ZdqRNqTTPemgdLq3Pz7lxh+t033xSVmSQ8kdifQq6OJT Ou5nIZVZykJu6NxAzcOpmJRdor9nKkg0IbSqEIj2cEYiIXPZMomGM3JW5rZlMmRqVhYUMv7wTRHq ixfmgDhYiVbxKODHS8lM34zy8EtlnQ9cdS7xCLh8q+HnTN9Lf3r+0fF/nHWTa6n4pykJC2Hn9M5H 6KCbHh2fu+mmnDz/Ke11tEvLmZNt4LWuhOmkiv+TwNOOqxRztGP1X6Ee6PqANZBfUF8kH/o/g3Yv 6AW5nRTIdwEfAwGgF9CBISAO7Aa+AfSgrwl8m8ewoZyjAecXaVC7Tm7tAK0EdoE31FvUoh4jL/gY tzHfBqWBWsCvhK7Z2YC+160PWI9+K0W/A7A7RhPQd6FdDFQ4z5EHtAyohLwe47zFPoN2K+/yWq2P wJ+AHzvBPwKNwtcw6G7InwK/DSiFTafcbg2DLwe/DbEpB18CRGD3kG3QvxQ+jkBfhbbMfTFvKaiH +2LMZuWG5JFew/vsBqXVPqoS675OS3ndvGZ7Tew/+/RvEGX/CpH1T4B9lR/79hnIizCqbBB79a3c Wl+XZ2hcuWTdB284qijCcN6gRqzvDtCujlCds8H6K3zcqb1DG9F2AbUCPObr9JLyCQWh8zteQd6M UJe8DoqN1pz8dWpw+OhJrBfxptXwPcG5h1xYhX69wn6EGtUPqB58kIGs/7OIURYx7H03aAhxv+ci 6y7GCDEwzhTwLuxrMH8bx4D3XTowfw19P4TuOeAYcqQOqIH+jMhh2LA95vk8z5HdB3KLHAQ494D1 NnL7Y6PYhoj/VYFqoAbYDPC8rwA/BfYADdwH41ajfyP8eIFzhnOT84NzQ+Q/8knkLO/jMcSGcyx7 Zq7Ih+g0UAUE8AfnpRxa0FecF95H9pnPAo/NucU5Y1Pom3J5f4fXyTlVQA0tIOYWZ5Bzq4A2c+4z VYJiDc3yNG3jnM3G2qbChwifRz4TNrX94fMpzgiocpQqOXa87za1Y5Gnl8gH3W7tt/Skuo4OKu8h /wfA7wXdjPi8Ic7gR+r36LZ8kmTnNAWwl3x2X11ELzKcs9IRjDeNWDapM/SqoLPySnVW0rRr1ofa NfmFLGy+kC6GNJ3VMWUU6v5X+f8D+X3tGh0C/zdt1rLUWfouVwnn36W1gG5TyCeBCaDF5Zcuuo5K Ged+ciNvPgGeVYPUoQVpszpN29Vl4tz5IN+PsdvUo7QVdgr+9b2s7KfLjmv0hDKLfcRc8vv0IoPH Bx3P59HinPtsLglq5+u/oHwGSm0qzlS79Qdxrtqtm+JMtlvzWUqdXBv4fhb1gcTdXG7naz4vv09N yoOC/FyUpwX5uRV27sV5uZjmakupfU5hU821htcv7scD4jyJew66Sbv/Ypq3v0oZ+ar1O3EPz1C/ fa6BdYAP+l/k7hHcw9hvrh3nrAHHc9aAsssawDp/7DgFet96W15tpfM11Ufrc3dZvV1LOU7aDC3P 11EfPZW7z3xcT9W3UMOzdbRS1M+/UK12X9xt64W/fA75DLbh3luNOv6pNadW0DPKy0QKziXLkSM9 rFNdtEz5E+7cXXRcecP6jXJB3EERZZ4Sih9nGLaIWa0m03ItTN2wITEe9wFlGfvvUJGffBfE0MZe 2fcy771jjkqB1do92oQ1+7SrYq0+cY9fpFUcB2H7VdQVjOX0U4Uqkz/Xxydsvoz3gogH7sCCWORq cxeP6dgncrZM2Gyw5lwV1M7Q3qRNmN8n5opRh6udmrQD1j3xrqigPcp1WqvEaAX4epH3p1CjmlEv Y6iPgHILmEduurNtUasFtR6Kev9NUc9LtDY6KN4TrHNQo6OZ1jBUA7oktSpvYpxnkVdz4H9kWeJ9 8Hsq57khj+beJ/xOkMV5+TXsfkmtfMbYB1Fv2J/XkG+/ohVcE52XEcMiKsUzkt+R/G5cD1SgzU/H 7xTgfE72T+7LPziq6orjZ/e9fZtEMBAo1GDAEMKvCEQotBQDCEEjqICkkWIp1FJmbAbUgjj+aCl0 VGplWtFRSltUxlIGEdrhhxatCg511BKc4milTAf5UWoHddoKFEj29nPue2+zedlNiKX/dGc+c969 7/44e+9953zvpb6Nlcbflzp9F6+VQ3wyW0RMvepA54DMcZ5h/7ZIqTOL/L2H3DiGHD6ZtXpbZjoN PPelfi0sQfstlkK3UOY5h2k3nHe3028vY6zjvfIAfQ5iN0uV86bc6ryKPjisGkFK3Tuxs6FaJsY2 SX38jNR7o8jJY8wv7PjKYnOzZR1583DQN8D6GpLN57vRdln8tb5m+qk+ZvFPx9BxbT/auK4Usk4H ody3qenxlfIsPBU/QNvr5e7YBrOTdb06Qk1m2R0Zuw+GuiPleVjG8+XYl2GLX5Y18Ge4n7F3Ybd6 XBWU+ATOM5a6tbAa3grfZaLzZKvPJNHL7GxR3k6ugdinZqcSbe8uk1HMN8qtMjsV50NyCHhLpXty iXR3BlDfm36RcqIXcW679HPEnG7Pp7bgV5mxjuPP5z+eL/rtan6+UOOdL+zvUphtffiYeGzPkFwc e9ccxNbF3iVv30ksBcpDKHcL1zPcJ+oftfWR/eOsiK55tD5aju5re+X4VpmTSXgO0udhlYxV3HG0 h2g57w0Zq3h7eLenddn9VTvMQqOsUZ84gwNal72pMkCJ98PXYu3DNwfp8j7iKmhb278z+RL021Xi 28jFkH4/kpgPGes6StfVWeO/D/cn3Jfo/uDfeLcBZqFnG6QSOwN7VWgzv9nomY7WhbEkW5vIt1GZ a8z/J/h23oTX4ff/67liwlmFLmA16hiZ5I1Ec9YJObXpDyKN3bHdyAt8eY3k1aZ3eL4FKnh+nrrV 2BVYQk1jinpDHnGwa91i9LvICmCM1O1+36ZTcJc/RtOLIuf+FLDY79/4MLC/TSizxm2wATZDNX3C cR6hfAf2NcrX+GM18tz0ATwIU+AJ3zY+BPo+nzneUz2S5R56QW2u+8f52vCeEdpWd4iO2DHnZVvc NcL9b8+Gd4ks1q5D4L+X4U+bd5zQcn7yM0FLl6mmVB2tWjaBflb9mLZ6b6uxtlswTmgLNQeqdlb9 mhiBZvbveRUZ98FJYd7IjK2xT2UtdIFega2nzRnuOg3EnkJi6kn+3zMK5Ys1r2HB7OO5kFz3irbB 7qVcgj0Z5rQwtraKse3ktAtd7miO/Aw5dXjAnAi56kO+FHCtEs3FHaW93P2Zc3mOHJ2Zp//bcpjn Q/LHynAlOd7sVKK6tJUOaKfcns7taDmqOzpcjuiSsByl1fvo2Qv1TLEUp4l8dx1F7xbu9mbtH/oQ /Y7T31tQZo0mZUIcGEjOGgTriBfof1MC3HHNKuq+l9cow/Oe03uv2Q47qPsIO0/fYZ+MrSS4nTJN lJdT7uLutW1nBsxr7zxHz63qc6sPWTMbB3+i/sswGANF8BtYEO613j2Z+3j8JRG957qzzEm3ASIa sF07Uu6A5ygXUiZWm3MeGd5dLf2Iy48HVojzkxVi9tUa6737bZtq3lU7e/gujsgwNy5fcReZBRrT ocgbJJ3jSZMiPpdR7kvbruSiIc4Hcom3QuvMPUGuqknOZ/wV5IERjCvmjLuIeRfJQqeE/LBBLou/ Ki59uzOPBHZs4p82L1/kjbN+dKKuGP8GudOkAsaprzCNd5fDYOdh+YIzl76MH1sjT8fHydOxlBTg 39ECfMyvlbLkSqlGRA1KXso435GqvKPmGNrsmDdaOgX5yuZVzYnhc7LE/I21uTbIZRLYqvA/RzWB +ke/0vho883MecN+yZ+SS++VvqzPscxcnkvbxDea/Yz1tJ/rTaqVBqnjXG0k54Y2kutZ5++zzvN0 Te3aLpMpziCptTldc7Xm7HcC34M1jvoSzsWZPNGGFrLahPauO4w9G2ZO6xmjPFH3Ss+SPU8ryZGu XOd8Ta6B8e42Ge/8SCbxPyvTbZ7CF9aWtqI+qsZQ9HzFB0g5dhQMhCrFfVKq2MP8gK6cgUrry1nO jfpWANUyxV1g5/lXM9JJ1wx6atk5TkxTWC/1R3G+ax7DHtG1s+unazpP5ju7sf7+d7Zz/UNcXTvn NLD/cCXMDs7p7ODbqnFel0r9v/Y/oqnY06X4+6lzO/HCXx/b1quXam837GdN7if+b5buiSuku3e9 THUf5D/fAyXUv4+OXSW9oX9srPlj7HfSGxJK/KvS21nAtzVX3Nir8sP4Cdgov4Vd8AKcVmKN9AH3 BzIAymGGEt8YK+X9CVgSPJf4z9SNlh2WYAxYnwHtzCfOxezXTOauZfyt+DiNZ+ZxunAuItDnlgDV 5T313Lg3EaNaMjEKfdUOi0K92vIoQX1xFOrVTohC/YQsfuRql8uPXPX9o1Df/wL4kWvcsijUl7Xh 35Qo1E/pgB+51rlfFOr7teHHDVGovyHqB/Hpr/AK99KPsYeI44/5dUbvtmSX1DGeuV+Y+UH5UNBu RTP6MzfDbL+fmUMb7rzmBHAXMdObSe2Ch/w+4TzmAfhWoBUa/L6pF/25rX/BnLZv6OuuSLkHbPfn s3Or/zuxZbAmaPN8MO9u3+/Uauxyv33TUf8/2n67mzEO3Mj7Plj6m7dgBiThc3AX7c7APp4vwf4F 3oHBlEf665J6Hw42xwU54BbJdOeUzY3dkn18646yMVfIdQUZuWohMb+EnFTqPCo93Z8Rv35OXDsg Be5CEY97qI3fH5EvKmg/mVixkvZ1lCExnpi5nvarGa+IM7CX9z2Iycxhy8RNzbs2zlYRd6tkoOYw yuU2pxJv87+BfumKPvk6/WZK7+TLMiBRL0NoI+4LInkT8WGTDElWSFHiQemZ/yz5+140fVzyyZuS OE59XC4N/5O3XL7s7pDRoc17Db1DvvGKZTBxelL+Nqnx8J01+2J67kBrxTdJb+rXw0vBuYHGCtCc W67+qkZzXsMuUr1hziQ6U99H+uBPBf58nrHKnSPSx7uW/PG4dPIa+J4bZWjeBCn3pslQ3k+xuSeY U3WAs5R2c2m/H/0xwpx1PdYhyRrOkYLQqt4I10DnYM6hiQVS5KSsZilT39I2HKMEXdMFX2vkYFTX hDoqQ1OoTrounCP8P9aSP8P/n2Fb6o0aGePcJr0SG4knqqOiNvDJOyvlibnsX6BnvYUwGOplfuKX Uus+QS5/UmqTV6FpXemk+owca+fTHJ14BJ3/tnRib1STv+F/I+bXcA3UwWLq34NNQey40a+33yZ1 TWuC+m/DfXCr/17fmaX+c9Mn/vj23X1++6bNPD8sEourHvVJHfYxP4bSTJ3K2ur5OJfFpnW9/v/2 bFR/5rR8w5yRqRl62NeT7Vj6oOPM3309a3VqqKNbWOYZZLWdtebDwB4P6gv1rGmsiNpmXZ3L5tSv vgYOvrP09xbV1xGb1tfZ7dxW+ruF5U4XlKO6vQ1bFKyTtdwteqkGDS0UqlbOsN1a3J+iVvdktDFp HctZwp8e7hVyU1vouVO8WuJ2FgJ934pEIzEUkle2hDvDRW3hkTGVvMuyY+8FFrMlwATsV4ihoiSc 7Ni9z0L4f5L/Dqj0cU6Zs21hfR3cjN4/2sIjEijJcwG3/Yf18g+O6qri+HnvvvfCZvuySySpBJqX JQlJgGTDomJD6O4GAk5Ms6FIsenIRinoFDGpsThjSUOnFWVaTQQKBYWsHVIQQhN3iwVsJc5YHEpp 06njOO0IYaZ2pkMrQbTKDGb9nvvuhiAof7Sz87nn/nz73v1x7vdcT2beM/OYmZfMd2feN/P/med+ 3HX8uOvySX33/3v3ieBMvgP+pGw+c7P35j1ofQqcB/+UmoXPc5kiH3vmEngTXFYMS9hvoV38Dnvg bey7CWNu2AdjdJ8ksyY4i1IjwZNnzcN/PsXj2RdKf7jhpvNzBu8XBFB0Vghj/ibjI9Ze7xgX3Xud yfi+ScPQK64vmMG+ZRLJM15t/JbWKr13Wmm/F3HOK1kvod3n+jtaLH0u/IC+BT4qjZjwQ8RtB2mr 4k3FTqX9mhR5GDcI+4uJiCrosyo5vgb/9whIKL1drMpgLOnWj7/babxLifTBJplmBYBuEEepUryF PR7CXQ7EjwH0Av63Vo/TVGMZyt3QVq7+qJJn4S30XYExd4MVUlPcJR69drbFc1Qlnk+nJdBERiP6 Z0MLLoT1ANfP2uwn+b/wLfVGjHziC9BffEfhf/gZRg3qoItEK/ZrE/bFp/HdTDu+/SMXsQFspkJt F7iC/EHU/wvzew/yKfADAD2qD4L9yC+FfQ82gT7Qxno1yszjqHNgvwc6ge2iXXTRvwEbg8V/ifdh o6AJ3KZskztO+yFsL/i26tdCpv4jUIe8Azsb9jCoI5Ofp/1R9W+Z0GfVtT4mNHv2WlqCM7Uk637s y2j6uPY+1RotNBlrarvxw9jrbtwidRTHGDGwF+VX9RTFGbxLg2R3+rgoA8qaFsWNzbTIuIS471ma ZyTIZy7AvfoBLTLnUMB4nErxnC+CRgb7569Yt0ViBWVpB/AuE7C+THmeV+BDobJwPihj9UMAVlvh 1sk8q7dDriLjc5bRuFY+6dZc6MgqqZ383IYxj7E+kRobd768X+vpK0rD1eG9OH7ks3Aa+yUbY5aq 87sU31PK+0rpwHXgeb2dOIa8Uy9IH9ebOVaQY+93Y9L0o258m27Ac39mHqEaRvt7egczoXyc+aTL xmOIHz4LFiK/8MYy1jKkuG5dra10F2OE0Y9pgZ7czWPddb5V2YpRGaOX4D8KblLuoilZGxBX8tjC W5f1F+D3gdxrZTeW8U31zPh336psYy1BZq+N7+f/9f2UPiD97kGawj5cajVe+4Pplxjso0L46JeV Vluo78B5fYWiVoCmwPfNce9++Er2XQ/AD0Lzq+fFjJPSl09mnz7h2VdYt8r9uSZdLf0YdKL0cdB+ uBtlnMQaX2mNCOfZz8rz9ATiQxwNjtHgi0zpV5i7lQ86xKSf0wOo2yp9UZ72MOwySYH2JE5DTPmo WfiWp5X/6U3vk/5lm/JRP0Ef+EXtWHqr8lUO7qRCfTdYrvzQXFjmW6AIlPMZGdvmku6AfUneS9XK T/Jz78E45Fnv87nFXVPLZxBzsvxWWgn3/xmlCTKcUTpB2ltpwgnjLt2sP/b6cuN17JMq6ATEb6z5 zTM0PRNzYc1m8X1t7pW+ZvF4LKI0vlwfxHps5T2ewD6GT/nvmMDQaQXuszpzPeXyvYV5Ogn+MMHG Xdhnu3d0Vg5kMu5SfraKwSphs1k38HuouCFnQryXieNknCFOUtRcgjYP7su9VI/nLgDLAFzv2BXX N47t431m7qGZrGXYKr1wH+wFWB/sexz3wn4I/oF8jpv/92sqhls8HgsdIeiMsa3mKdSfRKx0laZZ OznewZ64TDO1h2gZgzG7GMzlu/JXy44fH3EvQW3RHsrCVeCnIN0LDVZqXCCT9GP0JfFBSsxywtE8 8S61Yg/3ir/QOWCQHzV+5MKgHfk0MNND4nyqvj4UOQo7u0raZHlF6Bg3JAumh14W5/V+KiMHFeeS +dNky9lkXZ3KfO7zbiY1qzJ0LpotztJFoIuz4hyVu6NS5VWh0aiNCg1Cx6dpuFAS4s80CHQc5LdT JTNDvSfEa2h/VZyiB+SwU0l7cggP/L14kXLJEb8SR1TLkVTO5BBFO7CCGg0hHQYjYBQY1Cb2Uxfo BgPAgA7ajwfspyCIcY04JA7hPfsw3oc0CNpANzAwhQdRv45TcUA8SDMw9imxnfJgnxTbpN0HWwD7 LOoLYX+OMtteVf4pLLfvVvW7UM6HfUbZnaifBrsDZbZPq/IG8bAc9x1lE6IjWej4o4VoLwLVQCC3 HbntmLrtKBFSTTwuvin/6ZewIdj1rsV0dSYDxXKNOlO3Tw0lMKWdmPpOzFwnZq6TDDRtzPTZ6Pap FBvRZyP6bESfjZiVatGB/+tg+YHUD4qAwLx3YN65fhDpEBiW9U8g7QEJLonvYh4r8FZbxIPJcgeb 7OupOyOh8K/FWkx1RKxNTb0j1H2t5MnmjQibo6yP+66RrWtSntu4dk2q4A7Xote6aI5YTY8AHbfo aioBnwGLgSFWJ0uCznHRROsnUSTH6dK7RJfRZRrVi7XcEyJEzTjsDrxOJdWiQ4UTr9Xmt3raPZs8 wu8p8lR7Ip5mj9kmukS3EI4IirCIibgwj6aHklk182AiS62aeT3ehHfQO+Qd9pqD1pA1bI1Yo5ZZ ZFVbEavZarXarU1Wj5WwPD1WT5be6m33bvIKv7fIW+2NeJu9ppOlJaLfF1/jU47UD9pBDzAwx3HU F4lVII7ViGMqVrEgREoo+cEw8iOwJko+9POhnw+1PtT6UEtIuaUZtIJ21WqNt2TGcP9RbgFlaM1B bQ7mdgTpKOdAA0o2SjZKNnoN61fxhn6kRaAZCFk3ArBrkGbaqlV7K7Bk+6jsk2mL8Fj9auSrZUMV 2mCFlqjQeiq0SG04GorMQJKbmxsvjpfGy+N9RltxW2lbeVufESuOlcbKY31GuDhcGi4P9xnB4mBp sDzYZzjFTqlT7vQZ3Y0DjSca32g04o1tjV2NYj6WLpWcXR2SdkYp2yPJqQWh+b7oAn0AnxNH2gvO AYHLfoCCIAzagKEPIHUQbgRBGMRAHJgYcZjdC1JHtXF9r2zjHLfr17ULfHh/smZeLNoAlxsHvUDg 2f1o75e93dyArB9EOiLrY6p/QtY7SDNjBBxci3RzLTh+LXD+LZC9LVh6SBV6Q6zE5bCSn4zUAe1g ABiiBb+VYqV+GL9+vV/Midhz8xzKz8c1lDt5kj/qh8JqIFs7INNnZLpFpmGZlkRyGuyPGuzfNNib G+wyZCCFomjYLtNAxBu1X4jasahdEbXxtNspgFswT6YWp9oFmTbJdE5kSsC+ErAvB+xLAXtPwH4o YC8M8LjpOLu2PkWmXk61HTJtkOnMiNexTzr2Ssee79jR/7BedbFRVFH4ntm2M5bCloJkk6XMdmYH lZmNUEIKMoH9mSk2Q0zbxWanktjtUgsGA7g7JBJDJYZEYpBEEo2gNIo2xsYwO4vNtjSBYHzxQWJ8 MzwY4ckXFRQjidZz7qz8JH0x8WbP+eae893z3Zm5d/fuUjgHqM6y3K/hPk4ebl2MWlH2yCW4xSys BIH5hFwXGAdYCMwMwt+BuQPhr8A8h3A3ME/L8/An8J80uBMkb8qZR+E36Gui/u0G/gp9+F9Nhl8Q xxGnmAka4seBeYz453H8Gex/xBSJ+B+yfj5uEvp4/IPGuPcDYxRVzwbGK6h6hhlc9d3AuInR04Fx AuHtwNiPcCrQaIIvBuY6ObMcxllSIG6JaQLNZGdD8WmsvB9xRzjYDgwaZZFAHXKBugHhMZrlPKis n8vJgcpvspOpvMRqpvJJx5nGcRlE+eSX4kGLUArUY1il5aJ2U/7DvEQ3zn6HaHBOvjGP9zeE3R+h L5iWv52lxxXI14w6aDPyN+ol+atkHYYC+YpRlzBx2agL8IVcxYfsI1eAGfmCMS5/rvLsJypm8VVP min5rDosv6dhP5CPGfM0DfYS3vEQpl1jm7zTnJZ7tTpgOm2iWLpVfkp9Wd6C4c116KtNyxuSdZrK eqwxPSOvQ8W1Kp/Ksz1zwiYmgpc2xIo4Kg6JA+JWcaOYEhNip7haXCl1SO3SMqlNapUkqUVqkgSJ SSvrCz+kdTq8rWxpJ2hpIt/Er9sF8kJ4thNAEnDv+CsijuDks+B3OMzZlfV7dKcuLgz6m3XHl/qf K1QB3nKx5wtv1IHtKuACpdDxuN+RK8wygCePn4wTvnr8pOuC418pMWc04d/J4320Dgz7zWo2xlYd 3h7b3rFt+ZZeaxE30vD6/RbTH2yxTv8dJ1/wP+t0/W66WOh0HX9HPrG7MCscEg7Y1qxwkMAtzMIR 4ZA9SHE4Yrn3aEwRDiKNmQREqzGFaEyBGqft5DRcpoptVRUlJF2FPiLh8rnKSeNhrSRKYK1+AqQJ a1iS10oKa4iG6yEsFn2wWBuDKC8WbWO82GoiVTUNKYZGlGqPhoSq1sPT0/fTqhZOx2Ua19HA5ToA 9zmPhxxcBQ2OICFH/z/bWPY/kKFWvL6nZI+p9ohqj6GN+G8e3hvzXxtNJKp7rlMi4UfWjoyW9hIW x/zr6pjl71GtRLVYWiRdonRRtaqsZO8qVEvpMSsopou2WrTc2tREznlI68Q9rdzEIsUmqFiOtKac RdIOpadIyyEth7Sm0lNcyxnMgtNfqEos6+Z2h1gTlrTifhiJd7nZVe0Ht/HNsbUrdjQ+18TwZ2uJ 7vptatZfikapVCaVoRTuTkotw3C0kYod3doVn4NPG6l2DC9Xs0xnMXufde9TLpcrZJ6no694MR6r 4Kbtyjt+78BwwTd90/bTI5YL9Dq8RssV0u2XzWumcMCcME+Zk+YFs9nzXAx3XFauKcLzygFlQjml TCoXlBZK7C7MpM1J5Wcl4uFqggo22+KaHiJ+qFvxytQYCpTRQjnd03OFjMJKeNoFPJmn2Ao0FW0j Wh6tmX2J/ju0G2i30ZrY6+hPo51Hq1Ekkoqk7Ng+ixRdnb50YpHu2vpN3ZvriMUXQswPh2g/E6KZ 6Y4hBts3tmaiePAGNof+a7Tv0X5Cu4vWHOmOdPPiXrhq3TIr64DTZ9ipkCvrFdDxAuhxV8q6zsho geMbQKoOD697BmWP4aPAF4KAJB4t0zCP8N9GCfwq/keAAQC86uJFDQplbmRzdHJlYW0NZW5kb2Jq DTM2MDUgMCBvYmo8PC9MZW5ndGggMTgxMjcvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgNDUw MzI+PnN0cmVhbQ0KSIk0VQtsU9cZ/s+519fXiR1fv01s4/vwI/El2Mm1Qxwb2+RVSAgJUKFAYyCi CUHhkSDKo1u2tE0XRpeOCpVAywZshFGxrTQFYjpaGAlbtXVs2rNiGwqaBJq0aGuXsnUk8c4Nra/O /zr/Odf6v///LiAAKIQBoCDSsj5cYe/YNAzQ1kaiW7ft38f3fvrJBuLnANhAV+/2Xd18x2OyNQWg +XT7zkNdQ6s+y5Pc6wCeyu7Ojmf/3PLSswBdvyexym4SsND2gwDb9cT3de/ad/DOb1deJH4EILZu 555tHah/2Xlydob47bs6Dvbav02T/FODJJ/f3bGr87O/fTcKsL6VvE/bu7ezt2d3op3snwOwrACM 3CTu1gD591qouYzRBKPNUWzGAhp6goICLT2BYBHLaCYwdR2tAB3yow3glLlHybnkGm4m2TyXhDSx uVkiyiOCSTD5iUBuGmZ56uZsRgOPgadvqm9Yl7/PrNX0QASWQyOqznzlJPO663jdaO25ust1kxXa Ev0FN75Sd6vudj11yPJiHa5iOo37jVQapXE1TYXD4UhwFVWiD5eFl1JhCKMwpuTScqacYVJWj9Vq 9ZSXygytT3hSq6y0zDNkk67SWVelPLTUgG+hyC0ClqnqgoQacnh2zFFYkMNzGZ2pMLIF9gCGHCVk rHq8Be1BGC3R3zIavAZsuFEceA9/DtH8zYzObI2moy1RHM2hG5nCcCKdaElQ3gRK5PD/MgaOP8Nj fsxY463BNTn8+ErxhqY931SrNZ2dyU5niZCnubns3Ew2yZEF6Wn1McfDyWlu2mR2xNWFvjSGipbK Rf3c5FDR5GR5BGWf/CCbRYKtCGvtDrtSsczBaBlJDAQZVcailcsCqlQq7DYrQ1IqY9FA0F9JVDAg iYzNaqfIAaLIWZJLv4rONLQO7OvKlMmNydJ12aeeWTPc2f+XAx9M/fGj4uL7bw+PvjXed/dYddX8 3h0rE8F4uJa/3CqEd73RHNhS9QklBwvSD15t9y3qsJ+tU2rbn26688rxe2tXfLX6zB+GN/edrf35 g9H9oQSzLbgx3dusNKbLe+d/Jwaq6je/1yUI/wFAsD4/xfg0O0FBOzP2Ak7jo/xFpQe9h72DvkH/ cOnhUIGUyw+8qyuI6r/QzBc6RHSmlhjd2u7CA4UHfNeoD+gcM+4bD4yHCuqkhtJMaKj0GyHNycBI 6AfM97UXCm/7f1mqbSxyZlxcuteJFn/ocbaLjhyB1koiX3cg04cehygpHtiEPQjlkDUjwqbIW/Ji L+K8BofTKWpiMmWIiTowcSZsSqHFxTH1vE7PRWPmkkXR2HW0HgTYjabInMhrZppr264adV4d1jX/ Pet6R9c8vXENJz9KNk9n4Uv0zfE4Igu4f8xMI256ZlpGWVld5RFoWn/onXq29lCmgg8xxsIAgTPo CxIU/XpJ54cigatBvNfIMSHiFQQNfjDyhhpgSzV+JJNLZC7JJYkRkl94AbKoj1wsy9CHTFLARzoC 26zmhV4wRQMBSYoJNkZtEBNDk34KBAMxDoQKx5N20bzsr52fOX3iF0+3/2q4fHulvb5cwseaEpzu xfmHIz/NTyxrQD9GDZ1rl9w2uyNWTc+8OPnRxfk7Zyfm7x6xWVFxazjg92u8Pkvj/IPqxI6LPUcu ogp0nmObSuNqL3jy9zUjmtUgoL4xs1nI5f87ZoirKnNAH+fcbiPn9niMhmoPK4ouniAl4mqPVpRM vMe+WgKBE7Dg4T0C53Ygo8eTAmQl13pcIpiMRQh5HALLarWAHXbWqEO4pMhoQFsMyNDfKiGJM5W4 wYVaXQhce1zY1S8u3++UCcn1ZfeqPNfMZR89sSCdTqaTal1V4EzmuJnM68K4DtH9k0CCTo7geHOh 1ENcsn9yiJskYJRHatuuAeQvZWRLDIyccRns5XuFAX5AeA2OGo/yR4XLcFkw0DwthOhgoWgJFTNc Lv/MmCVG1PmMxRyjEXBWxHFH0Rn3Je6SmwW1UwiqG2vb265wrNWVJqlThKqcaWCLLGnI5f/1hWe0 po25/MN3SQ7Rd8eKHGm1RUg7yPJGhEyEI7QxlVtsJgmZrHZFsQkxwh2mIOmEGJrH35EifejmhoQg zvb01PPz3t42j1yT0qyeHcdPPS9XY7+/UGrZ+niE3jH7vefW+f1o007qfV+liP2EXsl3iB4l6BaD D359DXiCrj7Oq+i2F8ZbAmjE+cjxiP9cpEOsG5CeJ8iKiPcwomTgPWZRci01w1K3m7GYsZZhOQEJ 97baB+yn7ZT9SDiAAi4j8hLiLjOAntPjVv1WPdb3+wPXESbzuBxpn8zjAoTZJ2guzCCBkswgIWBS CIrTJMlnjEzbYq9kLXY6FjkwI1mFMPIWEyHafGHEOxaHAdTJkkMLI5VVHZNKqaRcFWq91FGKCfwC BzOUSR0ewsMSLnXVt8+1bK51ueqyuAX55s8d7XgomJ4fHHwJd80f3h0X/X6pajfVq1q/OTV4XXTi E3NX8WsnRr4FpILt+X9T96gJKIckbszYGI6L0zwXr8gk66KvxI5p34xRKZWMOppiV+Poa9rzZT9M jpf9rOxj4U9lH8celOli2npto6XRsSrW5uhiX4c3Y6PoKrrK6hUtGkidpN8oO1VOQ6o1tc2+NbXX cdz2NhqtvoGmUgWsvTW1L0GtZLHNbMMJ9S2Tjvg/E6hCYXWsVl5SIi/xy0tKk8pF5ScKRSvLlWal XxlWTis/Ut5X7ih/VaaVwl4FKQkrK7Cd7HMsjdnE/6mutuAmrjO8Z1fai657kbQrS9q1dnX1CgmL FbKwsRaMAWNMnCkJ4IwKLZc0OAmWp5OWpK3N5NI2D7hpJ+WBBwgPaSdkBooZ6sADdBhI6GQG0z6U Ng9hGj8ktBCYOkwfatP/rJRJuzN7vj1HqyOd7/z/93+H3cq+zP6cPcG+y37E/pXlvGyMnWCpkMhS ij+jmTBj/kCpdzNZPkY0SiVSsfOmFVQ0ZbdySDmhnFEuK8ynyj+V/yiUotgB3lJIjSG9wYJWKBXq BVdhQ34gmNbSZPouQZS4OjfFXeZcnQAkwfEgynPoks3b/dP9pN2/p5/s/20YhWN4dbnRXP1xDMVM ospXyWrZbRtp65D7gZtc6bbdo+49bpc7urbnKWUOdb+OZaLRNEfuNReb5h8afKO52IBAg1r/aAFC rC7WzBJ8DpKxCIHGLy0uQL2Xa43mpIgboSUjNf4Gy/cF+vogp9Hk72hyYPvO8z4loZBEY5cTleWe NXHDw1OuYDqRSaa9mVomoAoq4evkVKQba6iqSvBxv4o8OjQ9rl4VR6pTBMzWdQQuNNlsEHCjJhQC GEu3vUO6ggNXx/5AxrHbGsVmArpOgGO/4dgNgW69tapMDp3+2ejBOVSR7dy6ro54Zqi3/tTkxy++ flwOeEL+jphaHt8wOuY53JtNRleU3zz23BPjp49++2A1nxCVsGbmuge3rtr86sbm+q5jy2/bST6t bBkYfhvVNj25ulo0YrgubHu8QO2GuDeIh/YLX9EoxaFd3LvqNfKacRvdRX8nGQ+LCmRXaId2gHtW e4l7yTOpHpPel94PzZEXQxfUi8Y19WZaIFBYIqhAfJ64A9k0j+4g0oVCoBlJKaxElQcCEv6hZLxM crPLCwUjYCKIhNlytI7RjnGCFUToJDoL3+g4k/4SoioY1+JkvMy038N4IWda8wxiWq4gYDHRVM9R p5CYINUgOduw9ADvIwuTjgO41+T7IAIEiIRa03F//A3s9wjYoclm2mGcrFjVtqvD9Gey7X1yTOBq ytbWXzt06c6BV26/dXqwp3eEo2VZW6lb24eqw907Hyo/Oow6rl9+68wvx2obtu2rR6OrRk689rDX LGJVeQLYbQC7YaITVeydtDgcaoQOhb4X3q8cDjFpz2/I6+QN4RZ5i7rtvx3+F/Vvv2cqjHRbCltP UweoQ/oPqCn9VeqNwF3/52Gui30cQSzHmQTLs50sxTbcnRECbYzModz5WEZi3HNInfV5uQgmyAuk ReyobkWeIzB30A3ChmM6vQELo60IFaKjpNf13fqXukvvzLdkvsy3OXdQFVuYWWlhtH1A/DyP+Giy zb1Ti0H4FzD7polz1TRbDnxxCdfyxcYC4m80W+IvqIl0S/zjoqYSHaGIilQhpiI5DE1b/M0j4NDw JjVRsrUPrewA02SJsFeM9fU2hanG0mNubPA7fd/t0bfOHZ4ff3rpvaO37hvpsGEle9FXF5//1sCO yPEjJ49cvovCX5x654eauGrXcQOo2AhVsweqZgF9+gFBP35wzlsr4hWWhiuWeyNJjhbniyTjdtMR OkO7gn5CJwqan9f5Ai2eCVwOkOBnpJQWmCM/sQU9m9J0Q+dSmt8w4iktOUf+zd5r5FJawTAQ+KQC oRxwMXoyGQj4PazGIa4rJNnJdXXJHtxkSfbaimQPwF1bA52V3dBkc9CYK6DRU9CoGjS8YN2UUFBC ndJNieQlJGGZFa8UkVY8WyRLxYkiWbT7K3ghszCVgzCbgzChgzCTg4Wig3YA4q1ItBKuK5d1huCP PciiUvZKdj5L4aHZ6hrLwVJ3C+FPOa9yiaSVja7YdqSViXBBCjpOgG8rI+gwiHZz0vzm6lvChzTH 6UGg4CR1hikeNBo1wHB9QCThN0RvPen8RshXD8AJstWTIn7oyQFookFo4IARgPFzyVD96/l3oQZO 9EkwEeDBkOBorSO1MnZe1baV0GlGAK39nzFwY1dHpgd3/jifW7ucKUdF0YzlthaCUu9ypjcqZMGS LX325MC+n55c/tV4hUmlmGTHfvTO93uT1cFl776ozqZSdGdknLpw0GKxN+sCITDgFOYl4sQndkSd FuR6UCBEIq4JvMjHaTmliXPo/nndn9IE/GAoKS1+Cd0HUaZhtYK12jpDI9oG5xanRcHDYQ7iMNqq szaV9/mCfs1P+rsU2Ybp8bHr3JoKhtlOw3JQkh20SytWWmdlNCMjQuZlUn7FVkdVUlP3qCfVs6qr pNbVGXi4ot5R6cS2K4oJFXfyUQOranvboNBCcmJzV7/n5L5DtYnK3xQ26f95Bk4z68aese2xsY+L A8tMvxoqrnc/7wzY9jPLvUuxvVVXKkXq8l5Sh0fM2xbQzt+DdvrhzLLdVj7sQFkfEnewgYwfEYyc YTjWm7BdTrCCVrnsDNgXF3J1GHj1wxUHNrWg7sBsba2F0U5BHblizBskYdjGHgM/ggc5YZBGUNRE UrTnvcjb1kAHYWqMF0D6vFEd5pg+n630NLHrdSK+0ao97Qh/hCvQPWCo7x6+Hd3bgKD8kmlN7VRJ OiSFJZKmM7F4Rzwap+igX8zCKhMqinCiSihMIosEXyCLVCqgIskjq0TcLWcJh2zTOXF2dYHhGNhp d+dQDQ2hIf6wzz1BT/mm+InoND3jm+Gnox+R1zXPFDPhnwhOKTPMtH86OKOwUP0azV1wrkE4IUJM qwSKsk47tgM7Edg2vGsZtPzyn17Y//Jf/rzwxc1VQ3LAu7m4Qs36Q5l0B3X1J5+/+eEbp1Du6g1k bhr57I/jjU1bovra3Sj53lQijL3FMEFQL8IO5lHW9ngz3po35ONbhIJ2ePF5KaZZJu53Wxinz2kV p5tQW8NB3kE7G4pYvIl+7f2FSXqjfjALCUIl8lqCV/k8jcIRWSb0U5rqpJF8XUs4aWSktDw82AnD Uw7aal89aMer9eCzbsrFEP9lv/xj4ziqOD6zu/dzz3e7ez/27uzb3ftpn/d859rrxHYvuk3SJJQ0 jhPqUKu6pMZJmt+x84s6tBTRVBEtJIWSqCigSkVqlAglIk7To1Q0kaIiQIIAlShIhAhZUQn1Hyhp lBDZx5vds9MKEBL8ARJzp8/Mm9m3c7u3+977Tt6pJLyBKvK+hTcgDm948yXXFdc1F+uq4bdMHuUD sgrR0Z5O2W9TysqjhmH1zZrVmyEpYlxM4bEURikhxaR+1z4wBAEzFy0QLLduVaenhSk7WuBd0HWy F3L5hTJJcw90QmpqRJa1VcThBR+XIqTCkRonk+ciN3aMhr1l/En1q4t7ly4u9gy4vE2JeD6sYZev 1DvrWqS7vblO9uR7X9+wrLL00w9xzkiqMrL/N719QnOMzWQcfQcZx2CkJe7IwjNaU59i3oNn1MWc hr1iZ1iocEJTPiQk8pwzFAm9m30391vhhnBXcOWFbHuvsKD9MH8sfSxziv9uusafT/MOn6PJnQ/7 VvArfU6TN32M1KWiE4yKMcnX2OSlyqsY4xpeZgbRCakEE0bpph5VYyea1XichBW4vBTH8Rrebiqx E5GbkuTI6S5JyUm8ZEsSUwob+HEJsv+1856Qc4gYptcTYoZQUkgyVlXg+YBhj1KkGpj9EL0qSM14 wMAlY7WxwdhtPGucNZyG5NbIIqRlhgJu1c24TTjZtlLxfNucXmrDbXNasy3WTQKexDsonCnIfPDc oE694dag/LiJmwynuM1QsuIuh9PQRLIwhHtrVCSSIG7vITJ17tSkZle0a6YH1kiuh/PJnUzCElYP q1g9LET6c/Nr6cNT+jisYMaw2RaFP7lFhEZohsYvQ9MUsR2HQYWRH1IUJVBRavU/TvpCdg8epD8H 7paj5fcD5Ki/YUrg61DA0aGAlyM05yJ8SBI/FqZvTSPhQ3IDZqBkesVKyfQEoIF7IW7EyfYiv5zt gEuDUL8yafdwq1Cysx1QvGH0a9MDRrYD6nm2Vv/LpKySfurNqFbxtcSSFTSvF4YR6EeiCKtViJlg 2qrdJF9xJFosaQjRkma7SQJb0GNYQh4qUXeXLR+ZbwZSi55bnO8PaThXHTiybumYwicjSSHV8Z3l nYvKW77VseTY1x5Z0SxKkSh7afbSkS0LM82x/I9fXDdwfLCd78KDhw492N65fMW23rWjO85mA4E0 yXG5+k3mODeDYugV03+UP+pjrIb3oVgNX4Dnw4VCbPg5Bjs1vpM3eZbf49nk5xm2hv1mwsFf8MWb McehgEN1MI72YCQ8EQJZCP9+kLxSQiJllIIXg1eCbDAWJ9nFFtzlVcKtsgDFGPTTgHB71TQMUWVm qlopz5QtzV3G1lZnHMG+pzucnt9jWomlR0xDLlmIa1evBnLC4n5lzYXhL4jeg1/8/hJuZvb06Mw7 a0qJ0cjF0UWp4/huevjyBLlXsT7lOMeeRAXms+clJOJCrX7HPCmFDMQijo/wsoAEVuBcpVApUpIr oUqkIq8OrY6slh9zPCatU3Y6Nns38luk7ZHt8kZls3pAOCg9E3la3qtMaE+1Hi2+or/v/ABd998o 3EEfeT/ib/vvFXJOr5N3+jnBIXKKWRwsPlH0YMxIkhgMIq/Aq96oElOjXCtu1dvUVlsRcSCv5aAG VxaMqHJOy6o5s1Y/MCmyjFar7zW3qqig6YXCclULqaoWRB7kVBm0XlVgqHCsh8XselEIiaIAuQcx y0UJbEngWIbzFJSghJFT5DX8Z+2exmh6q6prKsyKAoe9hdZcVPZ6nAWWQXyR1LSCLcYX9tqiW0va ojsaixtFk2zF4J6Ys0VclOV4635NreGOC+YT4pjIiD/EHUhDHvAOk3TkedZT97CdHtMz6GE9sY5i jVk3mbw0FK3hwvOgRW5BLYnHQHnHozPx2Ex0YNmmh65XbVFC5AgpQfCR5D4sSn191XGwRLnv8Kqi 7n5GuOw4XIzq4/6/t4ih6/EoEqaxcNFqdbu7WP1EZ7eHBXfZXSYvX5Xs4qzEotSvTfLWTnKuvwOp oy/iDvXJALaD3IHZNEtCtycZtsI7GLSqXTLstEdWZFtDF2an6uiecbe3NdaN3+/MaF855FU6SvgP vUri0FPx3EIcLi7QZ//awpyZWcu8fqKk+bPZFkkcmn0Z74yuzLuzWTYmR1bCcPBT8dYMl806e56e iZE3/UHYGS53bEf96Jdmt1dv0/UC+0Lb6ba3237Wxm3L/DTzQYZ1Z/KZ/szDGS7gRGHVKYQ5X0Z1 pVPxjBq2dAiTUZ1EfqxNBzJqKJ1WAvGScTaP8zeMXAo3tdQSSgJeJCLBvB1dOR1e6/Ym04d9fwq0 JCbi/YGAGmAC7c0lKI2xV8u4/CW+58Hy95JkowWSE562vcmCRHC7CmEPunz+IQszIM6nq6L1oOc0 Ohofx3vGcfLj4jz5ie1PuqfbaOyUQlZOhQzaY8wLEfwOo+TN2XglFpi9448smY0sawmMjY1c/cbn Xl76yJJKLN0mxitmUheb2NdmMhsqoOldrZH1zMTM4cfldFMmw7aGR5mJ0W//aLcxrHc9LCdziYX+ CC/J2gO5/Wj+s+Nfw3z5vw935J/j3GHjOvOf433dxsfZNL12H8GNkGj+Y4LMfUJwvnwdoeiv7tP8 NuV/jcQCCoVCoVAoFAqFQqFQKBQKhUKhUCgUCoVCoVAoFAqFQqFQKBQKhUKhUCgUyv8ryI/OQMsi 8tlmtcR2oZ/DCCP704N7GzaLEnhnw+bAfqFhO8E+2bBd6El8GTwx5yFrMnrDxqifOdawGeRnftGw WZj/fcPmUD8rN2wn2GsaNlwP+yI6hTTUhTrh2wvWo2gL2gT9KrQb7QL2oQk0Zs0shdEesEk7AvNb LY8iHFmMdsBXQ2th7kk4fx/aa402Qb8JvA9AuxE8H4XjO61ZDQ1A/3nLazfMjcBKGhwlR0aAfdZv bAQfcmwP2g5zu9Hmf+P6yKq7rBXt84ZgtBVG5Io09BmwRqyR/cu7YLZkraBZa2+xrl9DozDaD0fJ dW21vIuntK7Ov3FbrcFVVVf4W3ufnRuCRh5GwvuES0IkCUESIIiUvAmQQNQgEGCSmFwkComGlIdY kChWA9RYEHnZggS04kxCechDMKIVq+El1TLAQECkIEaYjo8Wyd39culU7Ez/+KOd6V1zJjtnr732 enzrW6d/kps3zefmlJeVV8591OemlVc8Wl5RVFlaXtbPTZk+3b2v9KFplTPd+3wzfRWzfCX98rPH 5IzLickrneGbOcY3+77yGUVluffHpZZPL8nJ++mbgbcuX7uB927pTLfIrawoKvHNKKp4xC2f+h/d dEvL3ErujSsrrfSVuPdXFlXSUlFZSXx5hVvOnQq3uPznZZUVpb6Z/f6LUMlHNiGSw3LlIOYm4NyA zQ+gyWUJ45DK/6fzXA41W209xGJNDwDnp9v5X5z8v2oQ8pp+WL0Fg2Cz2iQAEnnjr16HqaqDGKWC tccYpZ0m9LUNmJNCZmtlN+TlpLk06trr5hF/piR4ImRPMsRay9OvmmyquHDMr9CT69anm16OroA9 y+c8n4v+Ua1n4fU/bJt0R97d+8bzz18knkZvXMQKvI0p+EhpZEg/TIAj4egMJUMwWtqhE4yEIBpe jGaxwjAKn8utqMNd+EIysVAiMRZr0YuluoPAfgHrZIS9hIU4JqXYzNOvSTL6IFuy7Bnci1z7Ju8A huIlrJZQ9OROiHjtaVqYiV9iNz6FJXhWmnW0ksvCl9k3MRlHJV8m2W4YyfTOx0qsx16cl2elwTG2 EAPxICrEIx0lWlfZ15BkjrfZbt+zR9CO+utp9UsV42Tar5CMi47YaeT+jkiglOEV7MApCZeBOo0T K5F3TcETqNPR9DELzzG23TJP6nSorWU0g1nkBWiSOdKgIsxxc9U+jg6ML5GeVqMW7+BdXKa1TMnT M/zD7RjOpmA2QAZvehrPcCLWYT/lPblNImQkLb8jp+WsLtMXaPlVNONb/E2ipVTmq+GqygxoWWi3 I4oRJtPGSIxnm7whUZIsk3h2rZqt5qsFeoc+5UQ7V2ySfZezLZ66VXidcR3CMfyZ9cqUHPlUzddb zTN2Hv2NJ2QX0J+N2IVvxEgbuUVuF1cSZDAjmycNclZ1V141QT+o68wSO9cuRQSxMoWgnsbp/RQW 4U0cxjlcRrN04cl4nhwuubJUnpf31GE9Xk/WK5xkZ4Wz2dnvXDftzX7/UX8Ts95qpz8bM4fWpuJx 5non5V2cEC1dpQctDZNRtFQgU+UJqZEXZYNskh1yQI7IJbkif1fhaolarvaoP6jD6ojurvvqdP1b 3ehEOCec7z1FLd39b/uv2LY2xibYGrvWnrTNgSp0I+KHkwDySRRPMvoavIiXmfNtOIhPiLszATmP q6zB9xJENHWmR73EK30kltGNlwkyW6plmdTK+3JWzst1BXWL6kXpqwapUWqyqlJfqus6RHt1ip6j X9If62vOXDOAstlsN1eDznsigxuvr2k57Ye/1L/Cv8YOJBaDiLyO7LlEEmEWO2w8CeYxSusomM0c Pc6MryVy6vB77MEHaGTuD+MkTgX8bZVLrMTXaIFfFOtpJJhyw/f+rEwa0VIoPtb2hsyTKnlOVlLW yG9kPfN7VD6WY3JGPpNvGBNUnEpRIxhRrpqkplAKVLFaqBarbZRD6lN1Up1T13Q73V731H10hn5I P6urdb3epv+kP3GinBQny3nEOeAcZeRZZqQpMMVmsVlvNpj95kNz3tigZUGvBO0MuugJ8Qzy5Hry PM95fufZ4znlscF9iKccen8nfvgtk0lOvKoRq3Yy7n2qUn+klsvmmzRgqulBCQrUTr1XvfxEjT6n 31BV/JhMD2wPI4s14i00mmNOmLmIA6oLviIfLtdFap9apcJlkB7qLHIayTpz6ecGdUZ5VB01LrMa BRgnnfFX5wFcYf4Pm2rmNFOdls3qfTWKSD6OWrUHq7AOPhlM70qwHdfwguzSruwg7hbgCL5E0w/e OvEtqWp4ULiaFXQ3K7RL7rUH1J32Mrv+rCzCSX2N2H9Axkg8NuEzVv0TSZSejt/piqNkvh5YQ9T+ BVvZgx86vdlB32CXTkS+08Sax7f80Z9uKvVT8q1KYTk7BZh7bCsbk4NXkqtaeTQUdUQCWSTQ0Zdx UHoxi8eCTmA1nsduHYZIvVE9qaz+wHHxazTpbN76C/JTN0mkpRkccnBce8FfSwsP83MoSR6UfKRz Jws97Ax6volclGwn21VmoonBIcmWMLxN9gpnFleYNv5mam5jH55ElizGVn8JGjhXwiVSBhBNzWaW qTGvm21mnzkYdBfmsGvXsIrn8DWnhivFzMUX+I5YT2X3xLJ/UuhFFmfYdDVR70WadOGoP8bpNZid lcvOL+GUmUN2XMJ+2sgZcghXpZ1Mxj4cZ+d0Yp8X8/5g2hnNj4ACam8iOz4lW/mmBD3Ql3m6JqGS pCp5XyvPriDPNtCnU7hA5rABv2JlqKSzesX4rrWXecMg5MoWzuQdGMJJma4b8Tl6c7qmskdrea6Q 2AhFdwwxn4lCrH+MTVKleq/cwWkYSlTlcbIPk8foxW2MowVhMhYD/SNobTO5LNds5PSN4WQIU2HO eDOOfp/gJDuECjtBVnvYAcmp4/KSh/9s2D1D7x6SNHhgYsKAu/rH94uLjel7Z3SfqMje3l4Rbs8e 3bt17dI5vNMdYbd37NC+3W2ht97SNqRNsCfIOFoJYjO8mYVufVRhvRPlzcqKa/3fW8QXRTe9KKzn Z3d95o916t3CgJr7Y81kak79N83kG5rJ/9KUdu49uCcu1s3wuvUH073uTsm/dwLXS9O9E9365sA6 J7CuCaxv5ToiggfcjPBp6W69FLoZ9ZmzplVnFKbT3Ja2IWneNF9IXCy2hLTlsi1X9Z28j26Rf7Be 7bFNXlf8fE87zBAnNEASKDYfTkicAKWwvEoxcWxIwisPqJ0x1XmAgIiVLoKNsaJ0AwEfYR1Ua+mG 2gqte4SpfEmrLqCuSlUNtj/yxzQFbe3aTKOboAXaTqWaWsG337n+bJwQdWya5Z/Pvefcx7nn/u65 1zMflkRBnhmpHpDJPRVOWQVGXcTKN+rYA0sJRNq7rA1NsUhdod8fLy+zpHCn0WGRUWtlB0UTCotp LD1sucQ0vu28GjrqGygbNvuGvNSRCHq6jK72zTFLaY/zHDlBzFtnzfzO+7PuVDF4bjh2KNNaqJiR Wdt9XDXNQz7rxaZYptXPv/E4xkBfORBNmFFM3YcgNrb4MJt8MB6zpIOY0scr4VUl17fFiLAmscNn ZRm1xjZzRwJbU2Ba1LzXP1hQEDpn/5UKIj6zNWb4rRWFRry9bvbAfWQ2730lP+TLH28pLxvw5iQD OzAt2yl4pmYWtqRtoiSac6mxOR1ZiT0y6kEIy9fpgycxA2uq5J8tlWR2VqIZPnEJvawu7Mh2Kyuc ML3VrOf+lhbwGj7zJoEBxvVr4zXtjkYPeG8SF5knaarBnipbwaBVWsoUcYWxp/DxYVFfVl62Z0h+ wdjl9UEgfLQBsW2PVy9C+P1+3uCjQyHqQMXqbYol6z7qKByk0KJg3JITbBlOWfI2sqU3ZUl3Txhg 8qt4vxDlWe6i9DfbO2N6ZFu1Jc34EvOWpL2xxWhsaov5ImbCiW1j67ha0l6Ztjkla3o4phTKTkku VIQVpNycbsyVmMdSA/jqgtRdQy43WCk0ki9qeROrk7/xKX7/PXYasj/mXkLc6ea4aVUHx9drxtXH uecxFTisFsmNrW2mOWWcLYoMZJpRwxc1E2b7kN3bYfi8hnkO75lic1ckkdrRIfv80UIr2hfHIrZJ 1WCrTLUDhnS4aSAkHW5pi53z4p/Y4dbYoCzJ4URtfGA+bLFzPiRdoZXTWq75uIZ/VmD6oOwWpsJz IaJeYVWFQtQ7hyQSOndKJ1HnkJzUeYUOHz7o4dZY5haKcxEvByWYFppn5PrxPVcezX7opjvfLd4e py8vi7L87cBnx784cqvPS+5laJsFSKIBfl3+2xF6xEtfHPl8zEuOPv2Z2qJXSbO5JKfQT2fVx8lS iRYA6zHTD/R+aparqE9m2U/50H9TfYoWoH0t6ksg22CXoW8ADgFLAD/wIBAB1jhyNbCC5wBOYowS HkdIoidcj9Nm7SJ5tU0UhGwCClEuUS/TQr2K4CsFlTmi7QyUF8JW5DpGJWg3B/UNaLeUJepFag/t gL0B5cU8JtaRCzkNyIXej/kvsc+QYfVn9LRK9nWUizD2ZvQNKsdoHeR6yPXQ10K/FvUo+pTK/fZF lOtQDiI2a1gv1t5DxcA69GmEn01ivB5aAdt0zJsDuQjIgT1PKaaXpLfoBcivqSXkEetGG7HuTXfW BLlK+DQJ2Ef2LxPsk1xlfwK8C1x2fKu/C+xXJog6lQepBrIXMHh8eQRrbiYJ9mrtc6phuMm+hXW9 D8xQuygb9avws0l7lZZxHZgmwG/jU/DpU1oHW1B/hhZCv1R+ABzbSgvln1KlHqAsrK8NbeuAHsE9 5kIXtWI/bMip6t+pALb5QBH28KwTJy/HBnXeX6zP/gh+XEObJqCFuSX41UVezM8x573PkTbdBjft q7B9HXgU66oBvgr7N8DhuOiD/hi3xuFhSVoCzL0MLGAfUuB9SiHJEcoD7nNQDLwFHACOA7uAGLfB uKVozzzpxpgR1OcxP5gbGIv3ocHhTg74XSI4ljwzP0YcG4BZQLaOs+VgKtrm8XlhzorzgrPAfGRu MWdSkvkteH+G/sDr5D3PkIXae9TCPoi1g1sZsoh5xlIZplIhS8WZncN8S0lxJpP+F/GZSMm0Pzif fEZYqkEK8FllLqYlzinHIi1nUgnGXKufhu/fokfUYmpQumml2kb1ioX8c5vns6+ro/Sy/DsKuoYF Z7BGem6C5H0+6RqVdmjD9BpiGVBH6DlIQx2V56mjkqadsa9qZ+T9SaTKmXIipOGkjSUj0/bf6v8X yJe0M7QV5Q+0UZydUTrBt4TrQ2kx4EtJ6AeBXqDUHZROurulIddGnCeiT4HH1BDOeogq1GHkhDwK IU4B6DfqPwLnuqkYY9+SQ3QB5QvIfRUK4XxiLvkS8gXA40OuzeDROM5NwiUhU3ydRAYdLgnJfEZe e9uR7zjyRlJSKd8NnJ/5fuAcDaxO8zXFy2Iqg2xM8XMiTx1+rnP4eTcvJ0jnbuHcncvnFHO5nDO7 mfMj5zjOkZznOMel2k+U6f799CzW8CeRh0fQN3mu5wJBoAz2vU4eQR62D4h82GXvdkXt3Wq5vVuv sg/rH0Jus/fI++yd6TtVpQecXOZP3aXiHn2dslL3qNZNPU5O43t3qVaDuyl5j4r7U18OP7aJ+60M 9Rl8DsUZPEq58j7EtZimqBW0VXmDFGUd7k3o1XLkZLY9TvOVGzRbPYJc97R9TTlOy8W9uZq2KAmq 4r7KIGVrT5Jf+zPusn32x2I8vq8gWcf+61tpJecCbae4e3c4+biM996tk8etUrFoM4LcNEa5vBYR gwaaJ+LAfZ/Ekwpjua7SXLVKxMHHEH0+Iw/Hg2M0LhbJu7lBjDkm8tk0MfYY5vw9bWLoc6nB9Q5y Js+1kxJZMi3QLtpXnDu7HvdpvXIa7yAPkeD/CHmUCirEXRl1sEp9AjHvQdtTzruCJfK+uO9vIFeB I9oRahbvCbZ9H++eN2kVQ+2n+foK5Mca5P7dNFufgxi1kiF4vSY5N/T14n3C9xS/E/i8LCePnkB/ nAvhA983PHaJiG09OLrSPQV3Swdl4xnJ70h+Ny4BclHnp+NTGfiho5udlJJfvkJxtoGzN/ACOEtk d4v7voLKlF/hfvwIOf7X4EM+LZc7qVI2qVLNwtvsIZS/S5XKL4ETiME+e0ydiRxeB/1PgEPo90fE Mxu2T9DmF+DBAfS9H+V3Kay8RpXa91APgKsXIMeAf6HfV6hPeZn6dC8dlDvtE2J8xr7b/2TweNwP WJSS7GsKk/r8c/JM6m/dHT/TPk7iH4/B44p+3KbCHkOc/gIEkvJ2k3yMzgAvym+j7zDtl56xzyOu 0QlYnVlX90uHgQ2Aqu6n5yHLIT8ARoFTwOvADXUZYnGM3oR8RcdfBYb8BsVYwv4S8BvgvZQtEzzP ZPpMqP+wz2fWtSVUxZDL7POMu9o/T0vVbyPHLrbPM5Q9yA+APg3n1o18/zfoN6HfhLq2gJ5VH6P7 lWZS/pNPXwZ8FmfEMXQva7xX8BuN7+f/13j3Cuzvv7kv/yCtqjKOP+977/trYUCBRWX5tSwswQJL jIgEKr9chAUWlg2lGFATFBkVXdCmNHIUo0nNPxpFhohiSkQLcDQSIVCMHSMqnMrMRhRIRValKVR+ vbfPc+45Ly93990VwX+6M5957jn3nHuee+45z/M9S+BGM/+rZZBZQ++xI1PBjtgWmR17KzjmrZSk Epali5nPVeQl+5+oX2bqI/+PtXKJznm0nvuRiitH/2trZd47Px+3DhypITJK8d+kPUTL6e/KKCWp a2xA03Ju3ELUycXMU5Vfhy/7mpaJIZVKfCHl5Tx/B40OuXId+aMuXJ8Kc1umMNeblfg+zqPg1fKs 1rS/XMmb12t0Xr3t2tf0N//HrfPo/6Gv+C+TXw5IL+67RG3+no2u6WidiyXNtYnsjcGF3vn/BHvn 99AAO7/QcVjnMWGtwnlgNOqtaNXZ7IvdcoXIySUix7eJnNjO/Qnsn7GryRFdsM9BJXWPYsdiL4Q9 PPuEPIJkz87zu8hjVlfyLFtDu4fhN+F7sp25H8j7D8Ea+D71/4J50BO03UTLHTz/Z9g3exd2GeVj 2DthF3W1tLmH+6dhFvfk/xOfwiqoDN93nHbHN6keaeYcem5tgfPHZ7XunOFs9AxxRvbW1m30rOH+ f2vWnSWasWYe7LnpvbyzT4tnHGdZP5l80NJlaMpeqqNVy6p+Vv3orDm3oSPt+B3zbDvVr6qdVb9i zfkucVCmMs+X5vxyeSQvtsYHyFzobCHuyVjavMpaO0zsaR9bGxxBWz6iaEDSPIaBYBf37Ym522Jb giPY3ZS7kcsyLqe52NokxjbNaV9o+Uxz5OfIqTWW+RFc/TxL9HmlpZcSzcVnSmu5+3Pn8gI5Oj9P n23Z5XlH5nIZoqRG4feopro0qgNaK7emc8+0HNUdeeWNSgvPTTmqS1w5SpPnTddeqGe6sN8ckX13 prBPx/i3Ba+7/ep8iOzjotx+s+XkEhkHVzobWytfIo70gwftuauMe/JZ8C3szPQJGZL+pZ57A3Js 8Osw5gQz9Rn2wdizaOlPNOpkl1JOEYu17TWWma2t5+i6VX1u9CFzZnx/hH/xX6mEEdABNsItuX/N 2ZOx93hT0YCcc70DwRHedaSQFixkOefdoec9yu0ptyc2VySLRBITeV4vK6wtIo4vhGnE7CnYsuQy 02YMz2r8vlJH3pzlD5fx/v6ggZg+XfNPcrRUxRdJheYg6gbRdhy59ALvQ+maekCuSzQEczQXaA5I 18u0ZH/yAOqEur7+fvZIvdTSd0JiBLkDtUOcL2ccZycmb5LqxDD06HS+Q3PeDLT1Q1LsP0HfJ2S8 9xTzslpKeDbEz5DXO8lQ7ev/TqpiO+Qn8eWyOj5SOlG3vk03KcnUSQlntZrMDCnHluNDRaZBuqVv l26pblKl+crlVZMT7T3a7SD3X9Pvplxi7WT3zVFNoP7hW0l8XdCQP67rl9ohFYn+5ErGNrmyeW0z 8pRWCRrJ8ctsrn8/Oh79ymlXZW11NNfDzfSdpnNq5udWWRjPmu8IczU5OzGff+vxL+wcR3WWG4s1 2VhICzltAr38x1kvj4drjP6D4CqzloD7wQkfu0BGQ6VPHvLWqm/BTf58+ikvMI/oC7831MsI9VPR 9RX/tgyIT5b+zMWbkI3rd7zBul4nQy2T/PpgqekzGP2iPnbEv9fRfw0ygfF75FFtGMo6Hio98Lm/ ovMVXxAsVZ/ifwpWxB/We7OWys2cHpaFvHsA7+7AO4uNr+Oko1mfJVKs/x+upTxR95Sxx2WKmata fFgrE8w3oqkYYzH+fuC3M984xfVJ7mfej0lN6nb8rmTcavbFk1Ke3MW+PMo3vwwXSSfvdRkZX0Gs hNgdwb54hvsMMbIUXpHu3mLsDTBKdnqfyk6+YXkejQaPPuD/kL0Vcr0SXxcr5fkB/W573ym8p264 /Mzg3rFOHs+DdkGj104GxudKUWwBvm1ljIn4wTjeefJoFPpcbynW/szpdP9qeTTC2Cj0VVsZhXq1 faLY+i5RqFc7Jgr1Y5rxo1C7Qn4Uqi+PQn35OfCj0HvLolBf1oJ/1VGorz4DPwrNc+8o1PduwY8p UaifEvWD+LQVXuKM+hGWs0RwG3Yb9svY7eHz4I8wz5Zfte1Gw9gQvQLOtMFgGBeS/Z6t/9GpOlPP u7P/CJ+5cVRjBHUwMhxL+2ZfsL5tPTXmab5ui5Q7w1vheNrfjLU51DHBA7bNHDvu86Hf2UHYG8L2 J/eG32j6PX+KwAvrTvbAbtKzFEyPz2BvdmCPsk/j1WEsiXeEleG995GJKd1jz2DZz2Yf5+KCbPWH yQ3+LrlMc0DqG2gHzQVZmUrMFX+NdM/LEYu9a8nZ+8mdc4h3O4hfG3juSZHRcR/LEOL3MM6dU/0N tD8klxALOyaENbeR3LaIGPV3znF/IH72hFp8wz8dg/drbJ+ieVfH82ZTnm1ymuqTnprHNN4WxYgr /5Hzk12Jv7ulT7q99EvUSH98a8M7MulXaE/eSB2UHvjRtuhtNNlJ8sJwyXjDRJKXSZvEvVKay38P yED/NRnhbKa7TE3Nov4xKfXXS2nmgExI3ikTmP9iN7bTWvFnBTWW/QVsseuGs+6JCpikPqu/RqON INbvR3+jnRI7ic8/Jp8OJzcPkxJ8LKPdlcmfMl9tpHdqDvl8hlSlD/EdaNDE3+Qy/0pyrtN36AA0 Wp/kYb5/r/Qm/7f175OLU234V/eJOKt6w81B4h2+f5uMT3xM23ukrdEOK422Mzb3joeYy3qZwD84 GtU1Tkc5TZE4yD9Cc7kx3PcY+5TRJz3tGM6erjdukevIbV0Z2+iOZmzo0xvo2Sv4bqtnk3tkTHIU 9lpZwDsm+S/JAm+9TErdzXeNlLaqz5IzzXjTNUcnNjNP/5Y+do+9gr0LNsB4QLEGi6h/DZ62MaI2 rDd7k7qTK2z9zXA3zA+f67NgSXiv+9nEn/lhG71O/krPIiKxuOrREI0JJi58E0rzdSrzqnquook9 petL9Ptbte7/tGJ1D7P3x+Tp4Qqr91u0VsfuczZPR59mGadctV1og3etfcfaRl1rqvWiNk9XN2sL 6decfrf7LLffTunqZq3T1wXspVH9XdBGdHsLVv93R2fToQY931loR31lnu2Qf36KWqOr10ln7Wv1 +yzmPeXfJVe3hI5vzoE3EhMhcdRi662+b0KSFa6k3j8d/wf42QKpSbSD9O4mFCvmXGAIXg3hLGkI 9irodVESG5tQrJh/3wypmCSU9D2MBal3Q/y+5KwWSH5I+6/nKDbnjxZIXcB7Ib3c0jlHseLm3c2j mxe+7ah+d85nO75779n+x7P9L+fqu1vyPR/W8tvwW2v1LFHcnN/kRkn+hbHXwIvcE2toK5Ziu3YO wwfWNsIhjVuKj8ryf55rb/o0WQdXyVyD+ycNZo92SN3CmGQR8in9gvtDiAHNzY/+l3tpj7pNroSb pNpqr7cTF6JviO+Ki32Z56RcY4HGUY0t6cP4KsSOF2We1Xu7rPbbxD6/QPWSL0GjjXc11JWamLAf f75KbgbG+o5lj+V+q/3aggftYD08mY83CH0G3H+F8ZjR4DGrt8tsGbLPhPU533bhSz8Tg8slkVgN 6Aa03lj270R/FboRvL8CegF/+3uVcpH/HuW9xHn0h+oFsxcGY+uxFt5T5Xs8d3tlhEz269BPoJrI aNIa3vE/1ss1NorriuNn5s6OvV7jnbWNTWNgt+wmcTCLl1kejpvasyY8CjLYqYsq0taWmg8tRNgt VRUSwm7StHwo1PuhRLhUwSK0aYhUzEzTGoxh1UbQqh/sRqg2pLItCHm0ILv0pVbB0/+5M6Y0ScWX avS75z7OvXOf5577uid9OxthOym+iLfI66izncLiGG0U1ykg/8Nt/JY09ovEDuRdoICow7iZHhD1 OQ0uwoe+jvn4HuK/A0n4rYcgvwMuAfjbIoHydyFZZz54Hjq/pID00RkHedshD/v+eblPwOdLvh9/ yvfbv+H79OzPb/I54vvy7Oc/K/Wi0q//vv8fC/JxyLfAegrI9oK+PuvN6Wz+j07gJnzrw7hfK2h9 0eOYw4x7Rnkffe8gA2s6D6zCWvN76Be+H3URbAUvIT2jnqOvMuKbVCIpuGfED4EvA1+GjbuGN8Y6 +LPnsDdecScDa2HfrlJDoJ2qtF6qRTubAazRLNbXncb6tWs7aaEyhb5Muad8eUYfpeXBF7Du8LJw VmhOqq8BSOVzXp6Ms/f2mueR8Tmb83F1lZr1Q/AjD0nfim1PO+rkcObi0sdeBPh+baHVvg/Xgn69 ANko9/hGqkad/f753R+ohl3BvvL9wJ3gp+p+ku9I9TDm4NO02K/LOnhPuPv8+duEdl8KmPQwoy5z f84g/giD+BnmrvL/SxpncKX2FOxKCvHUR9NYy60+/7WuRSZZjDYBPaaDVgq8U7QO1Ll677RuUD2j 9iB9+GPSZXi3FMO35Lrb7p1Wr9InGfEY5vixj6bx/ybmzrjvkcYZjjNze+3Ofv5f49/tviPt7gkK w4ZXIV6EvAlx0P1ArHLfwz4KwUbfknuJ6H7oLcZdskn/FexvK+z3M1SNOtWwXau0GRmv89trwfuu lX1p9qP5fmC7znaV/Vb2ScWr7rfZxrGf6Lf/Ba0PoD77+L6vwWUN0s4ehM//Ds4G/FB+o7Etknal AvZjs2d/lDzj/lht8ewFbEe5csSzSTL+e5yGnb6N+opno6T9+YF7AvqL1Bc9eyVgf5Rh1sM8ztmq K1IuUPf4dghnQnIANIHtfEZmfdzdkGcxD+elvSr37eAm1EOc3y3Sv9lNMT6D0DPv5Svh/h8A4+CN u+Sf5uS9fEK/DnOF+XC5eJuWYC/dJ87AxmyTb7dU4CwF77y5iKr4vtb75Ptiy11vEenj8/rwW0+u E7+dqrEXj9GSD78JtIdpA+7OBvgfpXxvYZ4ugEt3yU4Pt3Luji76PO41vnMPSr8izr4Dv8XYb+B+ wN667Afd9d6be8fJdwbWuCmQpDoxgT04S21o91OgHcD0zsLjnD3O8D7TH6Rl7MuwRB77BIsg/wz+ Am74vAewG2envfjtn8k3HOZl7i0Eu1CHst36i8i/jrfSIPyiUxSRvoorx3CAwZz0MZwvv0o2/ETz ttEteoR6ScdVABtD23BPfFd9gwKknuqIDWqlTmmZydKuqDYHtZBTG4uGM4ZWTjmgUhhhM+gEQoYK Tn65/VTaGoT4uid2eWKHJzrS1lkobqK0W9DKneoFJmc7JaVmjmVxkNMRe3vaygS1CLrEehH6rCft trQsbuVWIrTBy3UeXefVavGym3zlxnQ0k0A6BizQA06CGaCj9xHslQjlgQs0mWK9LOgF/WCKdWVr xelwpkYzUGLIsRsUBfVAUJcWxNgHZBjWijErxdjPxXRUK4LvVGLTk9HTaEQ462RPhVO3XEq79iFT Ftj3LTSHNaH20YMURYZiV9XIErJbWvzI6gYv4ixNmpOZEiwpuwCqRpoC50DWcmqXmzPnkVbELIUV hXPFB45Rib+J2064wrQyhvgntQGVBsQpKgCVusXfKAtUqJ+0kyv4R+KkU1JmGtCfphjIAUH9CBWZ tgDrTzsVVdz8u3Y4IutN2qmVXsQxFphtmUrxB/TnN+JNilNUXIVcDHkRchHkBfFrmif7edwJG2YO /3sZ6i+LPfQQin8kniYT8idiH9VItct2mfefy3btUjNTIl4Re6XKbvE1Wgn5pNhpm9HYkDjO+1Hc cIIh7t8N25hvDov3YfIrofU2tKqj4WGxCzfALjmSQSc4z8xnSsUghjmIaYmijwodlaEl3rTREP73 qshRFcpGxHM0H/KEeN6eHy0MiX9Itb9zK/jfMewYFs68MrOQCcJSYYeIW5jxW/Jvf3UeaDAp84A4 QCmgYlKvIXaNDyPc9RRoA90gC44CnUjcRMlN6NTD1PSItygPjiKuock9NmbwtIwkas3T4lmxFzNh DGHuFOTuc4Jl3LO9dnmFVNvLB7x5WIzhMhxDm5YY5xPZPQT3nIeSdxbUcIVLdrAUU/eMtxao+DSv wbDIwX3nmXhOzsDAOSSx/8W3ZGXXKY2YWax+B5LdCHvBKJgGGtQ6MIYO6gQC6m1OWdgMD8H558qf scvS0WGxEUPfKGdroz1/iezzBj+ihe2axeY5jlAS1szUyjTdro+2D4nN2D9bxRb7iSj63m6jXa64 xWloNFNDYouciy12NO5l2xWfkJH1dtDbV2udkgj35FGpWGcXl8nsOv9IiqVOZbUZxT5tlKNNsy3F fRMDKZBDDi+G6Rjl2P1PCFOOyKQu0A8GgIY1NqFuYo1NmpI5YbEaw11NLhBY29U0A2BqxAo4JCsw fyvoPJgCAZnbBVTkp/CHLoR5oKLFeqQNhBboAjnQDwpgBhTRCB5nLlDRhyTKk+hVkiaBhrVahn4s Q1m5iNFtXDdRyqp9VqOSpaySVbMiq2UDWSMbKbZW3b/MtHZwsJyDWgRruoI9wVxQpIJWsC0ojGAs qA66BbuoMQ1hleuN6Sutf2z9V6soX5PX80XqSKZUidAkmAaCRhQDKQMpw9ovRpomm6abxEjrZOt0 qxiZmJyYnhAjycnkdFJYrTWN5ppOpVvJKr2KFlXqlWZlq6J1im6RFb1Ci4p60Yy9oHWFekK5kEiF rFBbSBihWEjNh/pDA6FCaDQUGNAL+qg+pc/ogTa9S+/Rc3pe79f1aFF9UXORpWszmbV4CSrUj3AA qJRDmJcxQ5YUEI7KdF6muxD2yLSFsE3G4ghTHANxtHUFejmEecB6nI4jTHEaxGHdLyOvB2EeqOpl a+GSVMJKqEYillApocwklNHEVEIdSBQSaiHTqI7LXo6jl+Oyl+OoOS7/PY52EQNx9HZM6o1Bb0zq jUGPYx+X14WwR8YshG0yFkeY4pg6ZsfXhDPV6hG02Inw38RXbWwcxRmemUtyGzsbO05krrnYc75z jssuDpWJa0Pq9d35Lm11rEPstNwRN3GMvLETK8Tc2RL8iHClqEUR/UGqgk2bQJFKRArszqFk8wGy VBVBq0j+wy/axBVBfLSq+iGoCm3dZ2aPGNT86p/Oed5ndp5n3ved8e3tu2fQr6OH8NbyDOlDf0hd calgz8Cm2Xz19jvwwGfzIonfSEA8gNYAtiiofmVz54FMA0riM+jX0UNEXqGYhltcLS+wOZGT2jnR G8A9d13PdOMpKlOZQxk0h1R3w55Rozth+9ToFaVpuHntwi6p0THYZ2+uO6BGHPbztSE2j88cRg3s Ucw+mq5npLkZJVXTBq3JZ5fERBP32asi1QioBiAkZDayEM5ep39S9mVlzyj7I2XvV7YhXZ/Q/5HQ f5XQX0jomTqU9O2Y/rOyHyp7OL2+Xf+gXX+jXX++Xf9Zu36ZvkviINrSm+P6e3H9d3H9Qlx/Ma6f iuvDcX1PXL83Ll2lSIzorEVaul/ZLenbYvo/Y/rvY/pvYvqbMf25mF6K6ffEIKd/xfNUpz9R9ill uy7s0PkOvWWHfonhl4nuEw1k7WXG6D6ih+qEYXE/tFYBaxP2VsAWYWcAUWEPAjYL+2HARmGf4pm1 rIF6KFY4W089TeI6YcyCrg9AE8Z+wGph3M19+m9hJACfCacF8KlwWgGfCGcH4GMJV+jfiMPghv5F OKfhnn5EUtItfR8vk+eAvrD7oL4QRKevEotuxbRA1SdlvxAGkqNnhZECvCCMdsDPA3heGBzwnHC2 A04L5xTgp8K5AZgXqUnpb46klJ+n8b4gsSzsKOgpYUsPx4R9J+AhYXcBjgjrKmBCWDfk0kPUo/hm U4cYKtODwjFAH6ht5Lskpehh0qU8f0PY8kh2SScZneZrG8nRflnz0Sz1lJe0ML4KmSWMJKA3OLmv C8cE9IgUzph2i9RpnNzXagG2yf/PFdqONKSjhDDOQcSFsw3QKpw8ICpXIqmNtahNxFJJbRCGVDUK I8Zfp/XEUR7rSJLOn+f/gt/PLJ9+R/BP075GBf97CnCe/9Ee5X+wfVS8/CPcwufO8+uQXrMwTNfz 3xo3+DtOnP/agCId5W8Z2/kvk49wP3WZV+1W7iEx1xnlrzjKw8tJLBP8bMpnFKufde7lTxsmfyrp yxyehPj7MgYcnTAe4d9LzvJpfBUq9uO8bLTwY6n9/HBKBrqNTxiDfBwbOYQ1Y84hftA4xUe6VMb7 jat8qEvtoeCoHX3LUsQ3nUG+CxmA6JMEMtiJ72Unlm7vuizPCJVKf/Uq/3b3FYanMH0M/eH09vBr 4ePh0fDecBbPm9vDW8Nt4dbwJq1Ja9TWa+u0Ok3T1mirNKYRjbBN/vJS2pQvcJvwAghYs0raVWrc yKRlwfsdoxrDi5a7MVRghaGs220W/PDyoNtjFlztvn1Fj9IflmjBXXiQFEZj7idDCZ/W7XnAXZ3I UrepQAp7sxGIXfYDn5K9RZ8uyxUnom5Tf/EiofSOE09EJe468USpRJpn+iJ9TdaGu3flbmFGajaf M1daxDS/dNXi/rgwVHRfbCm5nXKw3FIquNuGYsPFi2ySHc7nLrIjEkrFi3ScTeYH5Twdz5Ug26lk xGJHICO2BMjYMLGkDPPDX5BRD9M5z7IC0W7qSRFumt1K9EAg6v+iKHSS9itRf+ikEp0OAhrIAwHT EiBbPUkMFdBYPalkESnzkkl4cpJS4nUmIfCSnYres0KnAvqlgH5J0j6lK3xXMsg2RZIqQpKloDH/ j20s+z8sotXemaPF/FgiP5LIj6GPuCdnxiPuY6OxmHd0RhIxN5QcGX1wXOLBMXcmMZZzjyZyMa+3 eAu6KOneRM4jxfzeoldMj+VEb7o3nziYK1UHZnumvhTr8ZuxemZv4WxWOuuRsQambkFPSXpAxpqS saZkrIH0gIpVGMzSwn1FTyPZUv9wgFVWX4e7ZSTaVso2Nx6z1K2zsy1yPHppFaFnSb1Zctclsq6O LqmOTEdGUrilJbUe0w01KnJ8Z1v0Ej1boxoxvSGRJZVIfiKHvzJapTKNhjMul4OzjgRExcwrHoIK RhXVoMRY9rKarfEVMr3STDPQkrLZX/RsOx+ZyEVRxFdl3W2WysQ0g4CmSRATu1aFfrMq9OvXNN/1 tv2e/bEdWlAV/iL6kqrwF1DdL6IvocJvDS1Yi9aSFVqwF+0laK8tXlu6FlroWOxY6gh11zKQoUoU Ga58ps3ytJw2qdqt2rdMBEljIHf9+TGUFVFRB4MWzKulJhyZN5ebK4NyQE6rJcFseeU7DEK6r0yb /91qs/gJ/s8AYt3XbQ0KZW5kc3RyZWFtDWVuZG9iag0zNjA2IDAgb2JqPDwvTGVuZ3RoIDMzMDYw L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDU4MTg4Pj5zdHJlYW0NCkiJbFZ9VFPnHf797s29 N1+Qm4TkJjFAEkgIxEr4SAAT4EqqAhatqNWiaBkgOEVBqVg7FW2tH0VbXdW2++hsN9eJq5sBDaCT nbl52FnduuMB/9i6qdS61RxPj8CsmmRvou6fNTnv5/34Pe/z/N7nvYAAoIBuoMG9YFFu/j2+63sA H+4lsy81bu60MLKPl5LxbQDu6Or2ljasGzoMcLIbgPm0Zd0rq6/OVbxD7j0P8HJKa3ND02hQngTw q+fJnLeVTCTnKUfIOP6+zNa2zi1vKS9/QsanALIOrtvQ2CBZmyknz/6FjN9ta9jSrlpDxwCu+cn9 lvUNbc2XFq56HeBHrSReavvG5vb6ddv15PoKAHkYKDSTeTMDBD0H5X0U3me5ELVa1AIjuU+DnJPc RzBKWeY+RYewOij78G8GFz/lj/jn8xP+mogfykmff0SqPLdVbVXbSYVmCTyy0MOPRAYegkUyDAy8 HRth9zFrSRwVpMN08MOVvrJun4cNxT4Xk/M9hcWiIrlwWrxyh2LDQdJqSSvqSEfQGqYJbkOxhAaG QoWhRB7CvLN8iYR5psRCuqLKU5KVVCYaPWWCYMoIzAxhztn8QA59Q4Qh3AMWyMHqPg5viFQI9wQt XCCV3HFGF0gKxbpFpclcaEnCJGNpxXKDiyyr3lUTmYoYTRGDKcxPPWnJzPzZzc/eckF5TTgSLo8X fzlZNNa7Ej/EDLTm63UpVIbN4SnUCDaOpXQp+oL8Iq/GU+jA+DWW/faL7L4Hq1cx7z+8t3L/xL7m noeH87Irv+vPcVnmdvno5xp6Np1b3PTmN98vcDzb4XO6bXM3ljBrH6xijh/dOhideG9LP/KurIro tW3eWWkVmPV6cUWk/ti2jaNb3ukcQG12Znn0r68UVVgDmPNyaSCu9Xdi15m/EzVyiQ6VcC1YR+CH 8LRoY6hShLPTc0vBbS51SlS2OTlcLjWd1QCiqmiBjdYM0e+BDpQoigZZmSpQptOpZNXdvtLCasI9 +pQnREUIdwa5E5acEHb0Oxe6NSfmhNDeX7rQbA8UnsdqcFNSMNMnz8xcmR5CqagQ5xtE8gKDsWrz AHogIYKrJjwRnohMhfnJiS/4SeMUkYGU8aci+Gt4Iso4P14e1pTk+jVCiZoUPoz8JCTquDJo1bEs x3JxngsS3Gc9UaDIa3eQxluQUIXTCF6iQpbdWxRvM2ws0YZj2YRC3iIHJfHgkWXr5zXO6tq/ZPYz /jdWvNQze8PI1v7fH2tEN8OMHlvdderzyjU/cBTE4F1P1Zziyib5kd+ePL5zbkej2EVddigr1729 ZKSqtmru4kWV548F9y5rcQTMf7rTsWTtpcro6MhQu8FCfzrLV9sgVm8/ZFtypvKz9u0/c81pwgoA hJ5oNb2fOQg8+M9xUkStTK2Js6yCE0S32UFG7pOF8IV+VYAxqisGKP4xiSRTx/lImL8F5eUJPjhH lsPDF2lQYBMJiDttXYXOI+fwfcPAy4cHo3X8zU/27seKGBajM2PfyauRj6fOA8as0WoqPRE/cE5G 4qtlWvW3xBflqoCKSWcoxkTg3f7183EUU/X/B6NIL+h1PEdhljeR/5hj6yrIPhKKtiRgMK9qbxAY 0QvR6OXotfT9v7hKvUhgEB7scECyXPI74rcB0cGOcfXyMYUCpNmyMWDGJPU4BtIxVpHNwNgOCimj 8oOpxzu6ZoIY1DjkThAgE2Hez5NOntuutnqs6gK1VWdVU/qoCr+uxXvRpAN4rxa/jqpqo8SIMfZV NIY89EEK5IpKSEm5W56MO5IxWT2InSCh+s9BmcKoa5t8zPid8TDk1neE+ZE8N5dIpyxHnPT/pZpu Xm4mK3HTnM+ZXd6z+7qt0GnXqKRumVrvKqvIf/FsPlmnF7dSzRgjO9UchNcoDNHqswxllLQdjEcZ r+HJWiKESs5aRDVnRx5kY2z3bvLc7Ni/CNYg4SdtgOzzQ2dYBbHtzn6ZUfkUYBjKyZNFCTCJreA9 6fL5c3J8vqAvXpMSX/VQ7DqdRBSnYY5oa4Et9M+BpokJZFN0CkXFu8SJ6XowMVhPgA3iHcLGkwhE 83gYYo97mBmuPdsuJUQn/kgnRdhlVIw5+GAR80sACrbGbtP3mFbQQCb0iPM9ep+lkq3mqtIWpD9n WSzUWZr0TcL6tPXpay2bVZv0ncL29Fctu/S7hQOWI/pDwo8tH+l+qj8u9KadtgxQfboz+j7hQtpF S6b2G3KqhbBFNMmTjL3dcXe323q76T/T/6Dv0jGaoU2OQUxFPTzN0ESWENDE2RNoE05OrOOJXWiK vIKNpbinpq3VqAsd1KXu07s2r2zxL9h1elnLT9a8NrNrx8x5dWKpa1Pt7jqmdfTLP0SbjnV50kZv f/ElJvesKFwe/efN6NhnrS3OdchgLyo2rCGqbSNSLSUsTIM/iibOhC9QLdRmqpO+kMRIQcoLKKgk UhXZYMVBKYfsLAUWk9PahB8BTyWDE4xkbMIIObR5FdIgdfIq1S2EFCRH9yBOgIlOEmXTpgEj5ZSA Q7ST7GMTpQimq1AVorNEBY9mMocCmuWDlBNvElZcvN/l8rv4YXRN1Y/7J/0JPcnm2ZM8w7WNv+SK 260B+Mmw6xE+ttzhx3WcvnroQIzbp0Ay1Jv4a596K5dlp5dGf2MuWCmPRJJrTTk6q+22jqIdVlNR Ei5kWh9+0DjdnsXZ7ZRCkzaji7ZXKVK0GU5l5krClYVwNUy4SoV+0fqW9A3FD6VH5aekvcqL0kHl FekVg/wu/W/JV/q7gkShTL1AODISfrrAjMWiLpUWDBI9Q0TU0hqWFiR6CSpCFCUqZb0qxmi4RTJf qbxICeTD6D/wX76rBLip64q+5S/6+l8r2iVLlmR5kbyBtxopWMEOaYIJDOOkcUAtZALYYGOMsUkh EDbXAcoaKGELiwkkdiYGjB3L9pimIQkkJUw70+k0mbbQmg4d4nGbOm6BSvR+ySydztSy5n29r/l6 77xzzz3HiTjsRimEnNfbXP14HI8m2TJrGGzBMOChjYXKYsOAA5bBgP/ckW+QNoa1V85xpLzqxbCg oSLjonaGQZHqyfkogiNudxGa9ACI4qQoyDQD71BcUkA+jkUIc3rWhsU75nkLLq3ceNaVv/FSPIqr 5i41Z/rwJYxXb67Z3KbduOvc+hdnNu/5Q/yPFaWyMlZAJZ0AXHLR1SgygHGaoXOURXLqc1alr8vZ mXMo5x3le5aunAEywPcoo5aLOeofoh9hssjQbCAsETRSFuWoiaYZjuZ05AzlfGfkGYPBQAz9dCc8 fqwbY7WnnwLbcN15u0ocxAeQkhCkgI9qNjAIQJmpCrHY3RvW4Twd1l3Eb6N8pAT6iVQDamHuznNh 1yBIRh66TOcj2UZGxkCMx0Etx2RVGoNeLjfzkeGIjFVjI26MBHDRI94UP9BQ04SVmtBVs5NAm4Yv pePSb1e/8MrTK37gK2xf2LJ365mapbvvbVv/ZKDAZ7Np183wvdQ8u4PcTPEtq6ydvWS7uGr1jrr5 HeWBE43r7m3NdmZ6pyjYGeZftSz4WQTUKQyY3mQrkRKp8HPhgFrEa0WsIQqpABUzJWKTso1t476g X1OlIArSImWzkqlS4sVKzIKp7TZbCxPmNgQXWCJgqBXgX3kFFTmVREQOsexfOBH2ISoF4a4kGiRB IYkKQSlKKp6hIK8atTCA34KFSKS9hyoULAKyHgsrlZlKxHCZrIoOkDNwmxDSjQQluOK7vaKAkMCy fTSzR4BHC0I/oK8guEdSqSRRHKBZSIDniWGRU2eKWs7MqZWXo/j2f5X8WGDNdWzJg7MAiwXTOC+w 5u8wEUhcaeV7MPwNBiiDgCwNAe0I0slGLBa6maiGNkVugAWdaMu1yHKhgT8QhkBgZWNjBM4W4wLe S72T3CWYYje9GY+dTDtV++bSuMlP8/bGongPW/nvLa/F9+G6n9K6eDz2E+D4M3Aev4Hz8KCPwg2c R1/KwNvNB1Lz+VDqHHYuN4dfyL7Mvcw3Mo1cE7+J2cRt4fcwe7jjTDvXw0RTTesZrHBYHBX8Se47 jnVbTNSpxyRNYbG7PUbKMHc9yODxIA8kDcapZ6jHoyYUpJSx9+G6D9UqvdXr7FQMEgH61eVE99CO Q+sYlkOBHIQAAX1SDWSZlPcvo5KYKk0YVFkcGxFEBuzm3bxsgwxcosk8oDJMTXA5g2jxJ7nx2pkn X9q+ZP/zq1oWBTML04uezLQZUxqHFh3ZxFa+c8Y2s/nX22+8lR3KduamFRS5ReHGhXVnv68GVmy8 f4spBEUwAF6/6FHoLXpikflYaS51esylHmMxLTBOp9ONSx1rHJvEDdZdrr3iPush5ynapTph6nRe oN18j2nQccloUtjNRoudVjDVOgJoGM1GG5NKCeL68OHu1FQJTOCSXsTa7kgqiFbusJgnlAlEI7gE Isj6KlzDGNvSzJ2aQYKQFzpv6AF20HzHIpFk5wX4YjoAKoFYQQGSTRSIAMAF0mnkEJ8UAJQMUaik GCf7sT5p2pnCzvjQj+sqXu+O//L8yTND+KmumjjdVTej6bNVc71lbE1GZvz+ldy+I6PxD0aPXsW7 sLMiM3Yifu3asrV49u9bNphlJb0FuOUnqv5UFDEQRafNKWT7kiMjj94nEp/DKrgoJVNBPZUsw/Th o2GJEgOlhKFKgpSJfbOczB5Qxn7ougKu6XUpsdIqMoP4HvipdMTStRewC7zqIJSpRPRJXMYiIZDE pCUBbsnMGtYDfx6yCieQSSRPyDg4A7s9HO/FO0h7TDGHHIwPtS4MZ7GVnrtDPuZ43jxwcc9B7fwV 2GAG5uajT6LIB1So1ZbyumVSq7nVyljZqarSjGdUz2ZU4VfwCrY5bW3+Ztxq2ZzW6t+WfUw8rDrk OJy+3/92foe209Ge9p6vK/8sHpQGVf3ai47b2ak+iwQ71SSGgPOOng3c4VTuTqTRaoimH449E58M i0lOWCfndtJ+/C2yw5yqzLjAuMF43cgYbVNAix6asth4EoPY+AQ/dBOtVt47FBE2PTKxJY/HueKH Kc78KMbBFOleUP2v3varZ25Vl312YHfvm5/XrW6KVC9P8afsP9i2fOWReeSfNb3z2v/x6ZbGrxbV 75zR+vPTDcsvaH3v1i9uXlFdXlo1PO12W33r8YaqKFRYEDAdSWDqQx9FkRsQnWUutUNxMZ7yoqnM kPi5lfJOi8XkpEF2JrvY9ZqlxbXNvslz1HLYvs/zPvu+2KHrtHQ6TnsG2B6X/nnZsnEWmyWF87IM Asd3+EOvF6Xc0bByhYX1SGXrbNBf1xO9LUODXZikQrV1X5ewBGzraYAis4KvPTgBoZx7IiORJJb/ t8BkJpnlTltcwiUBRQkoCQJnkqyuZKUVB5dUtv226okK/4HjuKTrWMdgfOhcLY7tWPZ0y8cNVelh S6rJ/+xXu536L7eO4hdGj38RXxX/01NZpBo7b9S/Gu/986trzUnnP0KsdBskFTMqiSIOsgripT4Y 9InIcl5o0sAAhDG6jMRotSyfM7ElYMUDm/5YiKGPXeNufwgSTSjU4Z8azIJMQ7cF/YmpYCw76M8K ypOwhrT4feKgb8Aa3KjivOTm4OfDAuLdo69bsXViFQ455mlIT1glTdOYXCZisnoeruWbYXk1eRFY TgLKxxdR/L/Zj+Nxb3JpwfjB2ik8zWEUoQz/tJnTLfX0jWBAvhcI3jsUKk81aIQCUWfwT5teVL6x UP89GTMf/pqZT5ugmnlU2INhJkL76KGwmmUi8GjOBmu3KvqjuCh5/CHteAjlhWbFQuMjIW1ocv4k SLryy8eU3Lsiv2nT3LG58JxPIe11ssugU+SirrCOt/J2s/1Lxe/sLJut1hb+h+xyDW7iOsPwnl3J uln3XUva3SNbe5Fk72pX2LJlOQ5a45KQgO20KQRiBCUJl2kaMHUgLZAAQwIe3GkapgQaSBlKYgok KcUIhIGSNk3/dIbSlpZJfoR26hIIl5Kpmz9gueesDANkNPbZPVqvd/Z7vvd7X6o0cX7Y588I5hrA 62dGnA5nzlg+tX5SS+227KfecwwJlkjdfGpJbNBhqbNBeq8zx1KI25UGI3bXO2wLdJiHPZCCbNr/ saczVALGsEoMoStWGK54t672qKQa0ffcfX6kfsgfjo2PViIasoiXkN/Gs9TMGKb8ocEgtrQQdzwi 7vW7JZg015aq++BYFvcsAAG1tm/u7OZoLC2KUw799K3Talv51JreyeKArvUlIM7Ld/a8INGQfiQk aI31c3/y/op50+ZcPFi+gCr10EOoUgQ5sZsgLN8x35wM3jA2UgxRYwlTMbvgFKskW7UIdDEv9ogL xRXiK+KPxbfEk+LndV/Vuawxq2iV0rEmIS1Nh9OF2cIL8DlhibSaXiX8UjjP/C12Qfy7FIwLaTrN TIGWekLldF6HloQRacvEjWBbJiiLAVoSRZSfhDpnwAWdMBYrkZzxuBCLQugAdujgGQ7yIsOIMYGO xQQxIDKBaCUaSjIti8GgQyAoyPNOp8NOCX6BFAgxxtCSJRBPM4DB887VlmFK1LTj4iuCEeFw8c09 oURNLRJ4h5jcIUpgmuEGhq8t4wU66EHWrkR1F+ODokDUjVBPU72myxwrKGOK8pWijF1SCljOUUEL OE6hTx5bKAwrnnR27B89yEBa0EH43oyJftuv3T2zeXztNquvvd3W3m6aTMQGgSPoSkCZM6CmCcXQ pkYzh2ZjlYlgJtMW035aapfavcGOLtf4F65QRz30uZy+8rqtejjT7iqvcD2+so9q2Fd+Ccy2Pn9r Z08kyUBelvmgWtv/3sl8NlynkbJMFXZausvD41cIauLPiIkTyEHECJXIgl3GahsKmmRATeflfLon 3Zv5btPapr7cj9LbnW8n96TfcX5Qfyg9bCk6T8ln0sE56u8tpJBNpdQgS8Mg4AgI1FQqynI0y3KO ZknXgg0ayGoCMnyaLryOaiYEARm0C1k1xbYmOdbncCRSjSVq/XAejYYRMI1IUOuLVYY/gCPJh8O+ MFpBqJhTT6f+xZWo6YYnwOJKHmY/ZM+xFIsuKvqb0yxgS6D/WKuDDbGtzhHQD5g7OQG3p1JQOufP PUGw6Ja8P4//ajgewuuG4WTYPD+WQueGP4dbVZkHukbNZlaUritjK69EcGLAd0ORAxtkIpzPo53C +HWf+cGGx6opDxbf5jPLXJh5OPnkzMOrvvn03COZiFya+Ly1dR4x87CCNqeizaKUFJNCshXtggJ6 TqM6LTC5RiGWS6Af83EKIBtrrLknUiInHjMpackGK4oSnLQOSFvAPYe6B4yuObPwwJm1Ly7b1/+t D8pedzef9IeT/63NdvlPdcBzf1w3ILWWf/G9h3d/uX2oTrMm5FkDs1adTmk7exeXloT9Mun28/EB qnlZg6yMnyWLA0v7q2/1ek7tXbuVwj5068Q/rXuRsiSI1w1J8nW6On3zq5a6XnSudr0U3ex707ef OEYcrXYPBf4QIKu8gCyBLsNhl7bZmxJ1FFMig8f9z4UdBO5iKnqEHEBCO+1IYgB361E6R4x5ECBG gDcenZnhDTq3hwf84uTilyvSi0s0riD9HUWtOT6ab79+zTc6JY2jWwFQYkKjsNraJr1VtqnKIgoS duUSDjF4y7p3sWSxSjOWdw5vPrToiUulwU8K+vLy2MmhCWLzDbDnr8+ubQmHpQbr8+XHlrcvmJ54 5uXRU7/9+Oq6jb96d/D2G5+Bd27qNK0jjf2IIKz7UD+xRIq4eILgJy4bTX5EzlPcDxNrlMFEMVrl pj3QjeiEgOP5KM3QNM2ImlvVAOm201qSoX31I9R6oqqCaNUICBE68vCOYK5PBzp3nh+hAMFQ048G vDSgMfWagw7R2teoX2kiTyPE0X3oSdTxargQ67QRztEP8l5AYtd1pQI6cvOI7Ds+/j6uTUePiKyz BBjaQ1oeQNEKTNlC71bKtlQ8GVCrwa9BEDh+3tt/o/zFufHfuXu4ZBBKN/nMLNBV/jTGBNi2t4F7 zppt/7jQjBh8pfzlrtdu7Tj2lExW+2HDeiqzKJtoiN92fJ/zRa2ODqMAHjl39d+Iv4m/oLfuRW89 Cw4YQ0bkaIR8LbI98m6E2sJvTrzJ70jt5/anTlqKgSJ/POVcyq/mNxOU1Ut7H4tQTQaHPDCTiwhB ZirLAa+XAF6fj7CpHs9CO7RBCQ0oLZPN/kaHWtUMklxkhVXcq6HQTRZyFhWosgJVwueLoiElSXJW U0nN4/UyKhnSoF1qTcqSr+qAzRADed0GbPwBzgiFMxwi+zh8NMNt07alcEKrYfnMntR/UmSKzZEH UdMe9B4gfubDpZbNUktAwte56FBGQlXbgM9NwZNCUkXw2u4TPKVSfakieFKpQoE0SQFeseBJCIJ7 ABi7NHYJOxila+y2oozqBWX0DgvXsd61fx2Ignb9GuH7H7hvMb+pHJrTbsvdIKhMjjzUmWYzUiIm Ji6KlfHXVNm8HycxGzMvSyCHKpI7dq0fWKPKg8mA+PAzGzcFI/5v/OCjqwV5w63L7m4uGeDkG3xz F1NNnf22bGOFjvT7Vmr88pN9ZXqqqmQi5XyHwNKerYfKWxBYAb5+E9X4bCauyOUTWm2zpIUDmKiz iKh5iCgdzCgygtc/dQp++ZuQn7F6GM+O+P74aUvRfzxuAx4PAVC9ES9uN+alBoZgTWKZri9KwsQd XhgvDRmLDOSoBGXC643CKA1hVNdkUnN7PIxM1jB2mE5GIWKFsBk28k+2izbSlthGxNNxI/5EvC9u jbNTiPNeTEQUjcHqgBfWQh1SGyCAmIS0A/3ntBMd/p/xKo9x4jrj82bWxxsbjz32+p7xeOzxjNe7 NmN7D4Njz0I5sxxVlpCgOIKwgCKaJlRkA7QJ25CbAkp6pZVoWjV/BCVpYXdZlqQglG4qJWqrKGqp 1Es0jUqksII/olRI2PR7Y3tZjki15PfNjI+x3/e7vhPX5gGhCQOh2X6h1X6hLQIC9F+4zfR2rYHW 75prffmrWk/N6/PtnX8eOv/kjM1tOmAmc1PDm/1uJpsbnU61O202+qc/H9/zRDV1SOO+/ujkqNS/ 01mHDoc1b0S5LIQLQ86O6EjKsaqkHbR01C+u3tvgy+pdSxs7Hkkqmk0xVSM9xuhbB8IKrzSOVbQl a9wsuNXh6xcsvwe36qN+awx5wU6SC0q+kr5K38Rvj+3Guxfs7RrNPOP8UWyKOonf6fwre17zROJR IRLmQzAQ5GkH7/GIctwnezg5HgmHcwpHx2ianmZow2krFF7pyzGuEQVHiIu1zKzvBepdEPIBygFO xqXhrmniZult/dseMG2MuJj7S+JihGvlS/X/1EjmKD9vz2ZchD4kdtwiwhRR4daGSozV4+PJFntN qhDW2EhMsDFWmCeSNBgebPSc5b23LYXffrXxwftH3/swf/+mrZ3hrgejDrrIrlke8qRGXnyjdr7x 5f4f/OPpifdffjznDyWi4H4b7k4+9OPG3y82PjnbuMTHUG1lJukVVBXJ6cjTjWOL1V8gfOA4uutv 1Y0LvYFuwqQPKcr6JDBpENK+kw/KnLeSJgsHg9kE1CoZ0A7DgU/2laaUi3n6OfakbyrM3FMdZUfT zDD32FIaxSWJpuTBwQRmEeuB+SEkhYVQl54RuvAitGhwsbAI0zBEBPmAEEwnNCFdyg8IENd5UaJ9 8OHBRELU8z5dzyNKjidygAMquKhUgmGC7kqnQ6GgXZeWaLSU1938oBNIRtNeSkIvUgk4zjPLKJ7S QbMLfUXdUHqJHExkskWzammzwuzYq5NoOqYf18/pH+kX9Cu6VQdCGuwSLAX0gKQvMfn5qMlPIGhL qskDaHpSN/xK1fwqDJqtGyJPzkzm6i3mNl/lxKo+xoXMq6eAxvpYsGT+FIf5iXNTvLeit2ndehB2 z37x6WyGDC/A63NzcwxZzTDbGmZc7WHGdYdh5pa1dodLtpbizxDiwwO1/+Bpirv+z3F3ifQcigPK CW8z38bnBMCWsjVRe7M+xL9KMFrvR1fpb22NhopDLC07l8kLA3H5stg74qhfcYFm8OHUvvrBbwvF EXv90oJ1ICLh1BUh1LvGSQccS6WcX0zSl9G6h/qIViiI64znRq/9YXt3SjWVhI+qB9BrjS0j2bkL 6e8yhZFi6+2+ePc+wPo5imJWAtZF9P1JJHMlP8G2AdimYpxEbwj8xDsRYcYkRGNGoDGP+KBX4FEI oqCHdQueYCgkYtaHMct7aBrZcUxjsTv4GwBiCEDI0l4Yizgcwzm8Hx/BFgxdx9Dt8UwvKacKvdhI qUVybAS03jF8Dn+EL+Ar8E7AAjbAxjBxihjGARwzM4N3XmYAZzYbRRzD6MQG76hiw+eExb8AloCr itvQxASa5GxC8pJqQhS3IGpeB4SaP00tNT/UmahigljcQmmrVsyaMM/HDAxQxobmM1894bsJvvNQ XJ/nTHOAvQNOazfCam1XJqPcGTstqPnRVUf9Y9dwpLsznrgkhgk0nA4j1pNTPpdC/YppKGJuL5Pf XgwnvWbXV++/9sddsVDCC71/5/q/OjZD71Vq9jRFwZ9yuqvqdLN2kC0YdnsqFsqiBjuCyaPCUeVd xbYvdsD+qpPRkgPJh2NMXJalIELIQgvIDfokqwJlsVpFSQYBkwMRz3EHqFKk4MCSpsmS2/KUVZ5G yw3W+rEkbZYekxhpmlluOFzY90rwLZfBlVzkvlx0UXGdC7lCmhSQNLZ8mlndanpreCLb+UUNzX7q nhf2yjDTlm7Z21qb366mp9cIXlC8uYU24jIwVYHDwHzamrYqdH9zs1V6Ne137BjOvqXnl/770O7v 3F3sKYXjKSm7deOgrP8wXt5iGVLQqtfqbx67f8/hnUPl9X2qJKZcnXL3pqceeZumd0VTC62wzx9A MvsT7HMFnT9NZUm67a9mCdIcpSyhm7KAq+yh9nKPZ5/N/jJnuaf73vL32J/lX178BvUr9gw76f2M Y/lMy3wMskFrI4mi1WUTrAExKATUHshtA5WSMGBBHYLF7+4U/KmYIqT6c31CP4WQ6OJ8LhdXoahE NufLUiibc+UqFLIYsDIpbpr5mpHJstmUheNc2Wyux90D04EY88FzoL9fVVN0wO+3Wi12sarF3O5p BhleXjQUtciJMTEnMhfEKyItmr5RxWJArLI72omOBLqmkopN0okt0oktJxBBE0SyHT6zNOXV5M1s psWZG6I/J/b2GfsMBQEjE3TPUnyghODZDh7/rxPcvppxH37sZE52lyjCBbFcRUT7RXJKiptYQDt+ wlhAAIX8/gKhajPxozvpfuIGdxFcJABrpx36MFq/aXSzo34WLyux9nxj9tn4wDfddXM4ANW/HCms 9jlRna3GMpr6MPpks8grKRaN4xVbCtwkw9SvvrRGUWzFuBj1rUW/blS/oaS0eaL/YEnrMi1iyTON 19HOlV3hTl62KIpTldmXSOI5S1EdOUCohrBRwN6gRvMb/EdSB9WD2uvUKWoqYlM1ZAeSm/LvwS3l t2Of3Y4TkjaNrEZcyiIwAWTX1ATV0WVPa9jupo5RmluTNEab6QqdAUfAZiyxg6SnsT1gT5vhYuaG optAsTeBYjeTSpBUc/KzjzUnPzMWNDN/k/2k91SVCMDtCjB/Nce5GoktMI/6KqHp65+Ne0qdLWYR 6xuH2rxFLX5z+2TSLrlt8+bYZ74K48Gb17yu9ZEuXyxxWewf8rBOOm2vrQ3z6c8jEU/5wJHhSjG6 IgztcPBCdg9T2r4w1YUUJZmOHLr25weSQT+XjPSJT/SQTpyhKNsIdEKnoxMhGiHC9jI42r1ok0jz sr1XWBFZLtwX3SjsoCbjfxH+K7Bq9HcCvV14TpgSmJSAemRQbWohLCI5OmGllw7fZ6hsdyEfEXQn iiK4udiBxB7mf5RXaWwU1x1/b2b2nN317LzZmfXszt673l3v4b1wTZx4EOY0BAgQgrEdIDhQQ+SQ CAMxxk65g0RVlxbFgIQIpCEldRsfGAdwW0FpPzWkfCFIFSjQlg+oSomitthL3xsb44IaqdJq/jPz 5tDO/3f9KxS7ECpTIkyFkkFKxEhnKM2gqrmxK/h35Yodf1iS6bUk71K/n0niK2kTo9BIFhQUSeCb ebNd4cNeMiVipSFTIqQUHArMHtklyLIL/4mg2yW43a5kIhH0egSv18Mj5I6Ew4riNmYATVGAUtyQ lr1yNuqSPV4Oo+JUv4wTgEy0YubP8jKBglPJa8ee6drxp0KBFOwe9rxP7pRPyLR8kToIcvg7LgQJ rEWsV+Xsea9qsea9Ew/wTjyQVNWOn+TdmZUlryR7s+bqyZDLjWn0xv7yOOs+yaDQTsA2RZL+S5YY rDy6qRKENck5dQL97u1KTYDKSQQlkabE7cS9VwJ4A8iGIBMrDmyECPod+sdJgKARqw1BJIYrDNKT AqSBFEaw1lAHOmgE6zYhf6XvoeiKvOQ0jV0xuxZEvZnErdF70c5/eKdtYIszWNdrCV8Qlvmrl5h1 Cx5eYGrDBoP1xdbRU3XlZYISDovcyvdp/uGvmEWj5zeGwyRcZkPb6AcBpyFMEHz10W29EyM4Bteq WwxI4qPCNH56ZDaYxc9xbKC2U6ec7DLU5ux30rsgZHmLwiohj6LEwngEMlMmxewWXYqbgElwCAKk BAeBEOIFBAHiw6FQUCThxxFjWbOZIMcoIJOI4lEeOUQOptEQ/YIqCGqlu0ZQs6U1qvCm0CWcEBhh iE72mcD7IeJTrEguEMkFIgETItH3132xZF6rSkiraqlcqBEXiZ3iD8VeUSfujJuQJEpIjE8RLjIV TQIFh5Lyb/E+LN6ZOrbUPONf/yc+xnncD30mWx6UY5yARhxnIJyiThNTRfBp/xnvfx384Ct3fo7F ysJ+S60/Lfn8xd+Eis9/7co0mIsvYwWLCUoIWstWNrG48Tdoee20MNEpbbTY8vAks220b3Xu8TSh JHbSvdVJGvecAu88uq27pNsIOBAAvxjwBXDUlkiymYt38qXT3dMDtaVz3XWBZdQK21JhuaNeafI0 O1rcLd429I57h3ePcEg5oj+Mjrl7lH7HiHLR4zLYjIiy5wAt54wmaYjuVO0WVaiyqA0FizpnXd7S HPSRs05G9c+oYfAkizcNBYasMWppgRmC0uCbIRhqbnCWc43fas25x5F6j6TF+5hpm0mfshhKAsXg JIijID8tJAWIKWtZEH88Hn9d+ut9n7eNFTd8efxPzeeK0Ne1buRCXUP3kVW9r2492a3buOVu+5dF /+jBOxsvwbf/tVd97fbgrauHbta/cQCeGdp/DVCP/oj99Z+YE27ssHm1VE+J1Bz//vBh/9HwacOH vkHDgN+sN8M4QdyrpdPzRmfM/5x/tm5FtD38AfVz/6B12H8pzIo4lNgDJdwLStRsVqJRlhexHQPJ rQA7iz05yrIeUcLckMxGxRtJAWPO67UDircbzUpQjEUlkQsO052AgVJfPHqdHcaOLFGon+8SoTik mbIoieOm/O4TU27UXFkcd2VxwpXFifgmqk6NOgN8lajaJ7MbmXmwRy+899iiq4hq1vBV6fskp/Oa T/8P3JO0Xm2wVWti2FgONjdCP4noetylsklwZyesuQyRVo3TwABVSvzi893F0SNNP9oUmfa6eewu 27K04la0as3vNs96o695x85anNsHfrD+t9sDxUO74764Phyed5pmDqaDKd3YJ0p9/5rmNjtB9Zri Yt1FjOowqIQh9cW8OFM3s3I7d5Dr4c5wFzljDBZAAVZlplfOSs3LLKpc7l7qWxZbHl+Sasiuyq2L r0615NuiO/J7Yoeyh6NHM4Px4eyFnKtA6JEg9DDhne0cNLOOz6ATxyJI135Kf8UP0Z4+G5s2D9Hd qslwzlYSyXloiYR0IZ0CJghESZGCAApAcgIoDcFj5wAoJNgzAXEYPyeBWWGVMRdkwgW5+XsFjScB wpMA4UkArwXIWkCdWQhoPKmCVc/w5B6eruykXyRWl+NOQXsVcNbcv4vZM/YNtsaxu9wdSDIVliLc J9Co05FRiiHEkbRe4Y7oDWUwQhXyAOQ0pgEGPUMwakWx+Hw+uxxKG1qPzvOvL/7t+Iojf20IJhIS 7Ll0GZrg8auHr71V/Hex/Rjh3qruI/W/bNp2stt7jbXULKznDu8K5MzIBWtlKJ+4Ca9DuO3utr8U ow90sx+TcdN78ONz+77AfX10DbPxJGZjBGTge2qHUTSVVcfnggXx+eX1oAW0g63e7cmf6nuSH8fP SyPxkZT9Q32/gdK7RfeBJE2XZTKMBVkVC8uYFVYWShU5EsDTVoZhPEgQEBL8gYCHtAdAP4ylU3Is BSGQqYjFwrLAGPBDwCRQNiogLkHY6CGESubJ8NPn9oxX5MSVdCYHc5nrDCGqQKEBpPJsDRoaZyKp qglTEaklpS8gchvLk6rxEs1wVpFzg3wVwrzUlvFb0MRbtCX8li4EEWF+Fhsbyj4dxydMbcLaxjmt YeQJr5+koQlu85MRXAtB3+lt+7jqjssTXuan9WXjaeap0clQOc5+A8LKZoAEN+Nkp5feWLB4i6SI a01jD9j5cgz5gveddbMtcPjPl//Qu7ti9UZ27BU1e/b3HR2+BPVjyBVfX1wZd/LGcJi22JX0Vjr3 UjKlwvBHB3bdUIpvd7+iD1M3TSOHWtuMuHvA9ug28zJWgOfgcnXPnsS7aarJ2mRrKmmxttpaS1q5 DmunrbOknetKdqWOWY/bjpVwURC35pPLkuv965I7jO22t1IHjHvje5NHLT22Hu4nuY/AJ5ZeW2/J We506kz6PLxkuWAb4fpSg+lvUh4xtYRdbFlqXZVcltbrBUmYb5lrm8/tTulLktYUY4gqWBtUc3Sd I/h3v99BU5/BFACgCp+0G3L5PDBx5bz5rK+iooKqwJcOBPcHfPsxxf9DeLUGN3Gd0b27euxqpX1p 9dZqtStLsiTrZUvYsoW1QIcAJjGPiYEGhenglkdweWSgkNaESSbBEANtUlomPAT9kUybtBSDBwPJ dJrSH23pj2bS6Ux/dMgMTaadeNrpkHZasOh3V3JJ0mYqee537+p6be0595zvLJ5WtdsaqbU6HVwu B0IlXI2QnizltZp2SKO04MLMm5KRK0u3yAk0MIHwLzaI26CFsPMqbCQMX5m4jhYQVbTg0rgfUwRO PsQxYfZuBmcyTJj2uo6pgLkx+5EwiwtMcKDAcO9BdWI32u1z97SFoFxKJvC7XAIJAQbAG8tDDxVr YY23EZgENjBqrCt2bpduv3js+Qk1f2tzOPfea33d6pp+Gycq6XBiq245//zW59aizPqxWweqW/ck gwOaiv6xvHDkzQvbvtC39jejxdUbjv+Stek+kooUm4PV+IFXn1m19Nnm+xee2PLT7d4MvwrwP0EQ 1m5QCg1ljBiFz54LLHjahcz4I7GQfKzUBBmd0EgB2RC6QdGEg9BwKBErmkAUiF342VG0IYQEB7hz KxIxYUcIVNuQCVJ7GxGkwy3RQb0zJLDvSmbSASjNmsm1aizVqpFoqRV5/MHSs8FG8CJEnhkyclVn gr6g7thyjVpBtA9vC4pMBqfdoAHZwYxMvkrrfpK5vCq5B4O4A2579mwGH2mALFOr3ocQWK1W5106 84zw1zry5zN4dhsmfZmbCCCdq3zyOINh45ZKM1EDlGLIhPdhOEExLP4x1GWx7Uy4s/qxp5p3e4zV OefcFBt8LK3k0yiweu+J9eG4dWXz1PDg8nj4/hd/nEoU4/GAuOGb1M+qe7YBLr+HjPE84NKN1l4j 1Ad/uMy7B63YUcdgcjJ2xTntuuG1rLWuUZ92vRCz0Dk6X5EGkhYmnEmSyEYqKBQNKyEi260QpoDb GCaSzsrpdDaq6zFJliVJDgWDINskNxpneEHsiFmltNTTmU3Lgj4hGSC7kinUgUFcDZdYKUiGtEqi BAlJb1GPEQxodhqeeaCcNrHrLJk1kzWrIRX7S9E0Su/vYdI+yQf3BsOvXdr5MFK0EERwkupmAv1U AJ39TJ6Yz5ufK7WtAGGIsp8RSxIeZEmPWrgAgQ9lBkcKhHMnxs/OkRAs2yY9SLb7LIgYGD2KI+EM lkvz8pxETnIhu36orLwUtzuvfHfzmZ0bY/uzC+ssusiuXNKtvvLIwb9cuvUvllZfDFeetq6Mk8qK 0Wb0UKfRe+D1ocMf7kPnTue1vDUeV4Z2NJmP/3T2w5MDS7p2oF+P5uMpGyRBAvLFL8xzWDcMgiEc DpGW6ZBNs3lEQyClPnGhZyBQiVa0ZcJKcVz8hvu4eMJzVj7jedvDfVkdjZJnxB+Jb4kUJNsYBiGq l3CdUsrmMhgyl5dz/WY1utJlhncoTDAaUoI0sit0QPQrAV4QTF8XRAKJghDTorKmRWce7DMkgdCi wUCAYWhSI5i8iMQZ8uiUcFC7Tg3CF1g8TWDGYBk1BGjweSIA4nCIsBABnZmhVl96xz/vt+Cyf797 p07MJ8bMYctnIuP/g5jZLD4nfk+cEi1EfYPZQ2NRhpfZxsNxmYJHNWMW3GtcknHTvgF7sLWVJmOA NO7R7BQCE25Db8OXEOrdRS9Z1uEgfey6RW4Hu4oUR7x8ruZEpxxFpXds35xFtWwbiWSrEBz1lHfL /d+R7+7Nqb5QpyUet/DB7Rfu/Q1O8D8fvG8/BogW0W1DtHUhl4XlXSLn5mVbzubCWIDYmp0Qy5fw 2hBhglyooDv5EmfAwGAA2TKNP5xly24DNsh4oCOMykT5uCNrzVmL+TjtyXmKw9qwPpwczgxnn1Sf zB7gvq4fdR+Vz7nPyd/OTGXEWnZYHY5StWQtU+uianotXktQNbUWrWlULpsrkL5wnsupFC+rMilz bkUWaEQ7GYUWPMgT8iqeZLZTSdqRTbHziXyCTKjQEqqRSCyXlXO5bCgSieQLcj6i5gucyxUrFuRi seB0uUxCuTjgiNNV4EJhJaJmWSKZSHg8skzTdrKIe/4CFwmpWVseNlFEzww1MpWbyM+QE1PFCZNT bCAFnFLBbALd19F+0wZMOj06e3f2jujrgR9gVLXNKfyGQ48b+3HBehMY5m9N6PnJ/JU21+r/Tbb6 p0tbPVoKgl/Ebixeu4k2qTCFEiajPsknGwkX/nMFUw7F3Ah59toXj7DoPvuVIW4Itiweo8k4u0nz aw4KbvrDpR2Ffhq97Civ6YuOzq2Lf3VunWrZvijWXyWBdkMvz3VQIZnrq9phxbPFAbG5pnmcnHxq JBLOQNyzdA12vHrvA0vw3gfQ5T34Grj8LHCxhjYawSOW05Y3LJTfOyKMaa/3TPdYaZr29vqpMvaX pXxlkREolAw8wP/r83n9fqvP5+/sTKZSXpvNageXK5eZzs4UfK/e3iSygtvwXkHhc+W8kmuBNINC xuZKTSE4xqVwmj+qaEQWZVNdSrayoDPus9kWGTDx2ayEXgZr8qZkrzdl7U0mY36rDH+xt5wK+L2M lV5kwBTP7IQe/34sr+ey4FnQ9ukaz9HX0Z/JAFDBhB43YdUqyt+9Yyo+wgO2j8PceMs+QFoefvK5 wH/8P7hgF+gqXT0s0OM3uZvmpDVW6Zst/alDOkQmwsjt9UXIdocPTQKFTJ952PQjKjFvNXDZ3d6W SFp09Cv2S98ab57fzCX8heUr2LmP2DUdoeCm5jt1iY1wjziaC9nHFwy/hI7uKC5/woH+6FySD/g3 /vZgXnSHVoDvcBteaJ5qniyNLe1XKYgAYTka3oQeb/5kU0QSI26aicdpNT+JJtHhK2uBJ2LM61/f nHrv4KMhj88lUaBbM8CVEeBKAY1fI3LAiJ+7Ky7Ek07KaXfSvJN38ZyLh1tQk/ZJetI1yfMN1CAb VMPWsDfos44G23A2XA2uwb/idnUb4AW0/oPoa9kb5GV5Omc7Tb1BnWeoI+go9Z0ctQxtQ2MkRfOg M8F/813tsU3cd/z3uzv77LPPPj/Oz9iJz/bdJQ6xk9gOzsvHUwRIwitQSFMYDRkgaBvohhiPUbUs Ajo6oFlbVpF2Yt2DVYUEqGlHCwX+QJq0bkKbqLqXlE3QyWJSodrWxdn3d3Y2mLRZufve2Xfxz/d5 fD/fCPQiNVUbUnWT0RuSEpVDSsQhIEYKqILDEY5I0JEkO0YoKtjdgmBHqRRCYSnqhliDcCpqx0xT YyqKaVaS/KoC/hLwm1BTgTp2UTA7fiWZy7NBK8wG1Lc0c6RRlYRIpJF7D+/Ecjlb4qQeEzGMgdfx FGx/9id9ertqb/fDDDjDINNIpV/pBw+zLPEQwf7/vtzRxtPwiwb+HVDwjuEEfthHiG2QydHzyOhY 4RHxGSAS9XNMDSY2cfgnpk5vLJpcWzo/GPeG5B5u6oa1r2qWR4rtOqbMWc7hB9YneE9ViPol3vJt xRMCHpjM9pq6PaVs6dz+VHUNZ8XxOGV1hht2AVNu7SUuwxrYuqraJ4mb3CstZJylk4hGAc1K1SIU MGA/k88QQ54UvkDJ7iL8kEgmwji//C0TLS1chcARUtN36Kv0ISSjDL6t+cw1pkgGv4BfqBvFrwZP 1L3a8NPmiwlLiniQ1+rOn/acbqSydYtrKKvkz1htkpq2kc9ycJD39nrXe+mOFLZqcGrV/JlLntvy HZnGFMMgj8cbh+5i5T1KskmOe5hGsb45JBfoUc2FlJgkIVZFDFMtym5RlJOF6U8nws58skA3aHwg IFjErCqLAn/YehnPQwxFIxHWT78rvy1qcJ1IupEtGk8jURBTIv0d6I6F6QPjKzPiZWoU1dPPIScK kaiVTofItV5ZSYcOrMyMhe6FqFBTVvSKWa7pWnmKKSeihJ5byE3L1Dy5aQJGFr36KuditFztlfdh IaFyONfrOZJvy6+13XfvJwagNd2H2eWLYkKoTDxCMTETpROQ08i0OokdOZhgHTn4A1/MYeHmiE5n CN3CdWJsAwicbYfub2jJ2bqVS862Ll/32IcoM30LpWFTp+8gZfrObHhBvErgAZCd7nVkGGrx6rMs 5OgWoKh+5GzJNjd5vC2sBI1Rz956+qKvXvPQnMnKi8ocacHxzkTCIz7/VO/Srq0fntg51LFcjN3Q Fg2Nza/ffuDMXPrQ1Lp+3ixYzUKo37d5e6K2cdmSM/Mbd28dw1/ZukpbvKOqva80PjK/981f/7Fv KeFelnDPcBR5UQwbNKE/iE0cZs3L0RrD+1WMTB5kVThNKrS9QNphwDga8/mQd4HtM9WT8nb7eBwJ YBtCKoJ3fdW8zc3ztkgsnIsoDMtPBmIWCx9XbbwQLtDPaXYW8H6J/QVLVbOY3ej7GZDIi2OIhy+q S+lpb1zN6EXWC/l6vhxzAukr/Mf8X3maL+C2C3Hey8e5AlV9rkKYmal3sjgFRnF3Bt5iMV/G11TG Fzt1RJ25B8XEP/EDwLO9fR9BdJhACZDSWYKE6KaYqKTg8jArsRkaIMk6SUSWjCzVe2PDSz1PvVgo fTbyyhh4q+CdJSZqB5c+dvlIf+fAuGw4OtU9uPj4vjdLV8eHGe9uMcA7Wfkff2t5Dje9/vjm0YPQ T9rh2W8D3auY1xYizWvLq2TXgOpxQmlQO1EnbjV0Kp3qi9SRyCHlDHU6dqF6IiZUowAVYPyGgFKt Gg/K+BvKYeWtCO0xYDJcjjv0mXPcoxfQY2ZMfUelVECI9zsKmDkfinFsHBxjIijkoX6qSeFcXKEt 6Kb7Gb/CA0BJPs/38ut5xs5X8xQfqJMIdmEjfJQ39hrXG582MgeMbxjPGq8YPzYajP7axOpy6BxO dN/tEUqkFouT8PQTCUAAekIuJ9wcKAeCYaKYCCimARTzPgwld1CYKGUtGsbDgGG8Ig5nTMehIpBO qozEzGiabaGDm299/ejYGRw5sn2bXFVbXWtPcq5QZuOV+SueHex+5YlP9n3tjZHXsHqpf25nvaSG XTWz3BbR5j78zZMnh3Z1bwL+g0SZVcD/JGrDH2mn2DB2S3573gLGycFm0bLtaY7sLL50Jm3Rmprh tCmTDnIByxZui+X33O8sxrzYK64X+5qZ/9wmtaazma5wV1tfw0jmu/h77pPiW+giLnAXQufTExnb KoRljD/PYKsPLuXI9fpNHVo806FFY3BQlXG7xWhMll3bOMxZkiW5gD/XZLUhleyOuptzKTnYmo26 aRfRHo2SdLVLdrtccnOshs0Vpj8ZD+dyxLktPp/N4mpXZZeACjQ9Ib/jshBmcFlYZ9OptOUwB6fv ZmHl806luQKep3H0ZHIUuQQX5SobuOs9MPAscMAWBA4EYZFBLRRLB8tyDeozGrj6vSAO+ttdXlc7 1/TDR1UJ1js8OQW5ARgh3H/EfPPFh+VJqOIk5ktUWhEpUEfXqWnf9ZmZFlg0QDw4sQPvmDF4yJnY WPHO/22xrkqq1EVN5Iz0WxCzqvSjKoeZd0rLpEUnNKk+rBzbtWLJ0uEPXt/z1WyPvNHCWu1ixJsJ Ls7tL92b27AZ5Hn0y8ENYc7J+zaIg3tT9bkNe/+wum3k2VG8YmtffTN+PO5RA6LNwcandmo9pQ0f LOnFHxHf1UD7w6D9AIqjkpa1C5a4T/DFGWQSTJRzpWm5mVLNdfHZ5rbwIrbL1GVexPWb1gh98RPM 95kfuMaZi3FBIY+9Q86YpSpH3iQ5LXmT2WQ2BJHJLNagw0HNxHXywVAwGaSDQUs05mQNisVS02oX q0VKDCioiyKy9toAUtsBdVnepsE/GrNhm19OXPPNdODuv0/2AIrdRVBzvgghbyBRrKCEHETWlZiP BvRebQZjgaWYicE4uLypUllSzdZOcj4OtdyRAbEB14yevf8le9aoAFTZsuXeZ/evW3TwebH4m+Mv F7DnxNahuWt+/Mz1lwf27Mk0Dv0J726KrN3Xtin0l8LTo3j226vbVi59sqM24KhteW1BXfo2pLPS WGkhfRO0Pg8PXUI0LGfdrDxNnqGrL5E3at45/2K76mPbKM/4vb5LHNtn+3x3ubPj5M722b47f8RO 7LPjj8bXJG7TOIHSlBR3SUvHWL+rhsLaUNjExigtokyg8seglaqKoZWPQUo6s+4DTR0SAzQkpP2D NCYtKrAR8U+HhLSEPXe202qalPd97t7cvX51v+f3e34PP1LACLqqK2pWMtZ7fFIW02GqAuWrOgfD C8NFZauGs3BqTYuqk0GCqI4hSYd9pAY6qFPhMNaZObchnMSoc/6wzY1VVpeNvzK1Gi8bHy/1oV+P B0OyLOKW0RFCChOiZVQeAe8lyiwMeK35/m27Msauxm7imCKLVK5YGEg3LGuL/ICzYcF1Ks3oQNjX xkReHLMPftLi38251ZXVlXXCrTTPAIehltuuBxk+BwA9dR1auFMd1HVXub7Os5YFI+B7wUEshtP0 wwURKgsVi15mK6FQcmclaExVnWmbrTqC1EFWCbdYTfrJAGyuhWvTBeVMoy7lmxetmtvMgDY9DXNv uY9+9siWif0Ls7PlmJiJ+CPdlNXGxHdPBF0bXn/dNT2ST5RyE5fGJ2f7w6LcY3P6KoOjmn8cnx9Z q619euHTuzeGfUogFeI4xmW1dVhzB++P/cvy0gi/sX5ipF6fSkrpsI9KdbmsdkWbL/0TUuM98PFx YGcK24BNIrteeHb0In2ZeYW7NPra5jfoPwjXxCujdvoAdaC2QC3Ufl57tdbpcbvF4Ql2eHjC7Rme IIaD3mjhTFcDzywmMODZc7qYejcTTlirYa+b9rDjlhTRFU3nhoOkhM4R4wPs7/BBrBdLg0sm8AHd ppJF6ZC6sdj7W7BHIL2YClob01QjMd1RJUup6CMVqW9PvT/pNVR23tDYFcrwtl9Qq2BhDUTN0Qwm e2+uAPorwNwCX2ijP5A2mbtUCzm5itugaTu6qWHKoCvEFqaAaIuaZhXmoekyUDNgM3ADIM0QbaHN W03umvwetqDONvRG+xYl4n0vM0fn/3RAY8Nb/ngxm1n44ulHPrinEPf/sP+unxx57Ju/1O5NTtXH 55/bNardN6asBe+aLs/84pn3a4dKeG1fLvX43r2OQILysEFPMprVqtuenCp9T4vPCczmcFzZmes+ u+Ps34XA+a2z/zg59d3i9y+sPhR5cGgkPrxnSt7EkeDAVFDhV0ERcuhO/TC93TqjXlLx/Z37bQeF Q/KCbUE4GT0pd01jB6OWac1wBhoDAyFLLJ5IYAybq/bvVLR0bgpJSdSPYVaSFP0B1u8PYAkslxCT /Wwy2S8NENZkwu51+PNKwN+fpNgzDFTZK6Q1Emig8CIZ8RvlNWHBF3MfJw3PC1bXiIt8wQy9mrkK rsCMsawZdbqofZVESV/ezyd5f94++EST8m3hNrR7GSCHlDC7nZYCVMpQcDuaBRdywBuHiK374nbB PUW5Hr0O/Y6pA1Bqa28MgmPLgWN7MxAaglSAlNFtyEsW+mGAg/jbVYYdZkNNBagjRLfojt+qyC5L syIzTU1vppHVKqG8eWvVLPW1z65+MJfWex/mPQ6npzAkhhZ2hCIp6RjnY/siY3XvkzG//jzaIsVF OtLdcfY/GqLfGsmP7Fqbm+xy0c7EHYz2o4FUJHEC/awWZ71c7AHxk03THxInHulROnHZqL33fPu5 pb+DwxyYisK6zB8patwPihod12ktrvv82TqJfBLieLUa3KkoaXWKxI52NvAX9R7SqpBuUnWLQpAV hKDfIcSUoEDxZzgA9C237ShONtDmRfxedwNJv1YP0YLu1wQDtGIpK7TAM6JuAzQFXQw07xiGy6aF ZwSL4IsJvBCzH29heQtK43s7BKNCC7oTJmMzzmnGVo9bn1peXb5BtdA2sb7NWGFfr1BtcI1uZ87c conXSbbiNOEr8ICecbnkLvC6u9ASctDx26SZuQ3PtrFaB1RDf44VS6paKubfZRmnu7tQlMZmx4bV rO/HAdHPVTu4YkwtldRYce3Y6uhmF8VSyWl+32ZtIBKZQe8c6eV6HYARwlhg5mfAzAxa0tNkiC1o utOd1fRuTdMpze6wk16Hj9yG/dTzEmXN8xVtEz/DE/6IL9qTxFtlWUQyOGNFhMYACgqKsoRCDqYz UxhGdir2kAOoUKn8e8VD8wXTz6S+zBjBr8u4hSAQw7JekKmw7EGIkBXZo2CC6PS40k6ScKTJzFq8 gXr1bsXckvV6xXCUDYejiEAYYZTrQY/MejwykuGHSRlBAwanycBx4qyqxp1kp6rYhXM9csgRVyln jyacERvo7ave5XCDXY7+Hk9Brj6NKRYci6Nri4Mfq6Yy+LNqUxLMW3AqaiurzMJgL2qqL6vypvuG 3GmJwPLqja9BBlZX7qBuQGpglSnDi1TKbRlo0h/436wK68pglAcv1kobjFpBkFPmTL1n7aLKXeVT xvyo4Rpc1PXrdTOvzHxFKG/a7GhUkvJBa6dJdM4oF7fMuRzFrTiQv508lom15QeuDdGklJAcaMle O5y5PzDDBXIMw3r4bEk6/GA6xitzp/e+iCZ7OyISPwgCoO65MOlz2ih7NErI0Vrf5Phjf1UUT3Ta d3pHsISeP752nnhoj4/xBuySkVl3Avv3QGb1IVWfsGGIxkQk6j3admx771fiNzxhDzjSDt2x1UE4 +qrdO5XedB+kDHRYfbhId7M03e120ILSTVO3Hjxk/w26BluGdRKP0BiN3qE/oi10A5V0u2CjeVqw H59sqbNRq01LRQNwvKtCm3Iw6KvQusKad1ciXHOVkbphNQiruvGgTvmb/3f7Wm+5eFh1Np9e8hZo nWsbsLYNW1m++eXc/8oB4N3GdM4Qg7k4mjf1xWH8jt2YEOjAm1KhVfbR/yE9Wsdtz9plH+MCCSsI u7eWtGgmgNzBqMKnoD3aWWfdrEedEZ/QotlQ+Ch++ZjHK1ojgIT07ecdR8BlTVuq+uM+qBhDSVS3 fYfc7dzBzg7NFedKu8p3b9vH7OcOJBbIBe7hxInyafypxFPl06Pn8RdcL+TOj76MXnFezP9y6Ff/ 5btcg5u4rjh+766ktR5evbXa1WNXb8mSLFmWZOthe21skDAutmWTMcaQhFAoceLClLaBFEMGCHZD SUNJQgfGzvDoFDBuISHCpQ0zSWndmU6ZaacfOp1pP7hN6dSlH1zSTsdy7+46xgy0Gt29vlfSB5/z P+f8/pnp7HTuWv5y+/mODxpvZm8WfC+mdzXsbsd7wUB7by8+lj7e/m4HviOzP70ve6D9q4XzGUUQ +jKBdbH+kT65y12qdAr13BfsjZe6QHWWgMXWalUWgs5knV7fWkcQpbuAMNE0G4qjAo6rslk212zK 5ZpBAZQKbLHTVCx2+tXFQiGXy6pCfWhwNOc6izr3uEuY9rTJFy8LAqF9IZ5MPRv6QwgLlbHkzZEs nM7CrIDw5hzvSeV4mz05koO5bhVU+ZqncjPwDihg+PudU72zRQkLxM2TEjdW3G6gH4lHWjrWRMQj T8WSyZHigyJWpPtCVI4qUqG+R6Swar4IbWJ+YWF+SIdIcn5oD7pfRQ7LAhL/almhB/lyj1iFEXN5 HWJM0SDqJaJA79WDZ0h8SXrTVyN2yKMF3JrMerSnhf9Am9GK1JmRSRuQLkvSRi2jhtttXK11wUri opOQsIMwNKwCEOoJAmlYbTI8K0SC7AruMX7ekgLw9mvPNG3bnMom2qh159/q2VibM7zsVSpUKjqT cNGjm/2eWGiQxXC1RlsTG//6xo53rtgtOpcv/+MkvfU7t6xEkK3OKfGxStNE96uNHJ+o21iBdQfa W9qyrZUDoySpIoyRgjn4RiLuiX8bto5ojAaaJMOjf3rnb9jQ8y4bYw0sgX0Nld9ix/uMSotHI1RO AE3HKVQ5aXhSYrDoMoPxZ5chrCpmATbMFpP1EL3KXmcP9wo8EB1zXgpcCM5gM371Frgl+BHENys3 OzdzIvLudkrAq9hU05Ma9qO6eRx4wyLvRiXeRbY0AkF0wgMR3MoAsQp8wyAdZiNRUyQSjYQ/h95o 5CnQK+RzS8pWxk5fT81GBZsTRsMuIgo8In0obllxE2ZcZBmDI9IIjIg9EsHygwiMCBgc+R8YHO6a n5tbCD9Jwk/hYCTevXBZurrHaPj/wDASn2DA0NzDn8K9T3CSNA5XVId09snRH/1sS6LVsd+sU2r0 qRZ2qJSt9UXcX7EwRntg/eRAjE28fZPzMBqnX4HklIHUD9pS+Rcqg0Udaayu2WQ8mglE/fF98K3O GhNtjf7qvf4dF7G9eyiLS6bwIurNI83cQJqpBjSY4lurMCWuUOEXjNesk7brhuuWn1gVg9YB+qjx Detp4znrRQORNmbpdcYi/UzVJkOfkVBpNHqvmsDlcsorU5vK+GHeQBzqLCWJQ2tSJ4kJAiNohhSu A0CYIIBHnwF+TQrwCbScKQA4EAc8mARy8LEt/LEVZeihlKGu+1Kyuu4jmyq0GOEhNQsUWhMmE+Nn 8KLQipYSE2NrwG9MVOaOjU19H9qOHLlyabBw6rNniyc+w7rfrvzu6vQ3T8Hg1Wtrh7ZXBu9t2wnP I55aclbW4z9HUfCABCzxnf3whOacZkpzu1qeMXeCteRac6GmX7GD3Ee+wlwN3qq6HbpVM8uQa9zd YBOJx0HSzQMcVnvrEiQJLAwVt5hJU9zs6bCV4fd4MuiOe7qAF8b8ENhiZfwE7xbKIwhI4CFZxmZi GJvfq1KjX2kZyNQHbYwuMoMfBgQSdG2KEHQdkraAuPFmLkXwbGojAXmim/gyMUncIeTEDJ5DRBJ+ 3+bxlBn0tQ8TKYZ3GloY0Rfa0cHmSD5goI2uZyimXlXGsz/cJJXFclHs/4s1pptflFQbvi8Rwh4g msNVpmG5lQvFkHkKByLsy6PXNz5ZyRWRlvQPUMYCYg1Y6glXQzr9yCQYUeqacfGgIOBPO166MjBw sPLdvye64kULlexSVkKqoVbvIsVyjuTLzV9KDu/sbS3WDf+6Dh/786Evntjz+0rGYq9UNlAWVu/z yRpH8eGSyeYkAovG9dm9p3+xvbv/X5cE1qtBQWpC2Q6Bf/OtGOqRLrR6YD++VblV1Ru6jF/VXrZe ZJRHmdPMUhgfk52RYU6WhaDD9ddgKA66IGbiMBaDrlg1rC7DCd5t8ikUkAhC9CWW5VwmjnNxrCro 4nRxJa/sVuLKGYwHaCJcD81yQjZqqQzHJ5uSHB9JcbwXLTdayPhxvN2RBBwE3AT3EXePe8AtcQrU G49/EOaohEiLC8vpCYeRsxMp7lHLkrKDrsVRu7pdvS6M5Lq40JNQqo0+fGUUCm0o4F8Ze4+6kHj1 Ihx4c/pkT73L77ZGKZcMI6rUei2TKj1X46xRcGducVqTy9yI9zRWGBj+WnvA15aPOlmjoqqK5J8/ 21baSx3EXhquNWh0ShT9pXlE2p+i6MfBh7w3ASHltulaqtQyrVVt1mYD8qDaoz2D4zHYAjfCbcg3 laGMV9XeBXFC7g0RdBl5v6T5rpVSO7x6NTYO7kLeoG7phhDOktl73B+5f3D4KHcSxe8OJ+Mmq7L+ 08w4fdcqjoVkysrH0XK5k5PWO1bM+mrdDGyHLwBrWPdPoQQW0DhYGBpaRPUwN4/aTkt+bl56Dolq DgtE4fELKkUqpiwogKJpQZHyGOuRrBNC4GqxVBJFlxLODdinTT75rq7moqPutQ1TRwpbXYYo5Wvy KfZu3zCgs9+oPzHCMeROfdiBWvgvj+1vj7vy6W+9ye96z62phe3vHuxvDrrzv9mdeu6YHA/EkIL7 UAy3yw4DJ1TcAnI04PcgOuK1mQvyB9h/SLzfNg4eQtzryIJBEtdyDg4bRULCnIDUQpmcIIDD7rRB xu5wWuW0DFahnkXTMhl+CkxiUGFUo9HNWmhUpLSFDdIWHVbU4iyOLeEQH+bANKEdJ2cgBASCU43B wqczyTuWexbMIjobVonCwj7mbMIC1mktgpOx8HY9eqCuJJqIxYfzujlB0XNSrxG6jFwauSjmiyJZ IilTEjNmMqKK5fk81M1K3Iic5ZAwYOsJz1Nnq0doMpjpC+f0Z6/adWo6ZC25tvQ2/pftqo9t4rzD 9975+yu2z+f7TO4uts+O7di+2I7txLFfCBCSQJIBC6RtGj5W8SkYdFvVSkiszejwJEDdEKooKxpa 25WuLCGsHurEpLFMoZWqafunQqo2LVTrtqibRrtqa8ze9xy+pMl672f7fXUn3fN7nt/zlJJF5fWz joMvPWb6duMf1eXZKcnnDwV288cLWiHRfYjsj7Y9832sFnhC3kD9WgZn4bSth+8h/Xl9QN9S3hd8 lnku+BbzG+I/jP2rqS29++zUMLOFeIyhuokyQ6qxjhJ5yQ5KWjU2GpuKfcZ8HvysZA30lsu03aFF i6WeIGvOMmVai4p9qWx2xSslrGXCQlCUTJcDNF3mPE6R7kNuqUx7HTX7dgpHArH8UxrNUBpyfI6G TF6mR+kp+hT9Km2mUXqArmxEhCmQiihn/GLTLeFyBR03aoBp1mTOqJAPxXIZEYoXRErk++wiS7Po oY5nfm1g+EgkQFBeFWHIXzVugJiH60ywmQk34qSwZJxEseG+qcIZ4SFky0bkxEhilcJRAAGMAcWD o6lRh408gNuGYzhniVlJA71oZdBqQ+telkV8bAL/MO4I80fdlcUa7S48asIqZKFA3Xg76nb6Oja3 jW4uZKNJt3f4zds7UzC5VfE5mPiQPLwFdkfSsSejPKPum3l6VZA6vPzWd0J+n3yAPdqrJUPtxaEv Gp/8AerD50D+kOjytW0PfqOQSEe6v9f45XSIZlf/+bcfbsCdlESdVEOdpBH/haveASAGvfkYdKHl yU+Q26ifmz5UTR1SrzRIUsV2YLM7gMvtsXJWK1DCSOcYYJUVp+xP+6t+yo/mzjstUQ57Kixts/G8 oXCilv+Uu8uRCge5Y9xp7gPOzAkxuaYQgxredwXyVW1Um9KuaybtXSqESUwouBVSOaV5H2NAoTyK ZhG6+ZhyTDmtXEBSqmQUqFBKnZSuRLs+4jCxjZZYQgRf9C6NrPzeiKYPdgzlO0s8gjYNELiIqYeN TWKSjiB5QB8jlRmRypBKYxAZqYs0xDQJVJkWfTbPUW46oLqdk9lQHHqFkz8M3IxwG/gePkUNV4Y2 Hj438mVNvSLnY22isCaudK3NZtMbbtXZ35HPns/a0VsP3f2LeRi99QQ4BJ0cw4ukjbGLZBznoqjL XdkqbI4/JWyP/1Ewx5m0WA6uF6fEJ+IHxQPy3sSPo3MJp78Td3qmJ4cr8mOdzddkFNkoV9qamzDD SjkhvgAAR7TXIvMJTUOG0CqJIs9zTpIymS1mHy8mBEl2pp1VJ+VEKF41P9/iA746VYAucJuvcc8L iRpxW6iTJ6FDrEmR0fBUmAzXqfRs/LaEn4ZkFNfZRB4X2JLqzklQzWckKI1JlHQNoZqkijNNiFYQ QpZteXnJi9byJAKoyTskq1VDYpvXFcAWufSMhezfsg06XUACSaCJybiZmJwwgs6KBsyJiIIseomz vhJqvI+u+kpCe4tBygnk+BJoVALawPfeMDQQtlpIJNQAg2zAnI8E6SCLIufat/f0OUyFYCrcUWpp 27rvT4XIqsaupDXcEuKzrZ1ALvstJnCOOrHsf//K3nTQZw9FGDnRl811jn/3YuOTIjm3vAFc+vdu hbWE+19vvPZCO4nd3t13EeumEf7rgA3ucmOrYCWscaIPVAJEEKXLEBgSx8EJ/iL4Cf9m/I2+y1Xv ekRML7tLfVpd4N9TzfaQK74pRJl4QSDj8UQFVsowpraTgiDHYCAWg5U4Gp6+/OraunkC4XgGykyP w0FY8/OlaCqlOU1xvqLWXm3/oJ1sX3CTi2uvgQECorgrPB/D9rGVX6zA3uFcBbbmK5UBxQ3dp9yX 3Sa3sL6LH6iDAIZyBM3JjycRPDi3Io/y8RJS5CWMI8ZwedG4eO8sYVTvy6t3wWrzlm1IfL03DGGd BAmEDeYfnosPDOCK+6ODDw/QqEaRzbriZvBedwEhZ0AHduu8v2Nb6Gsa15rItkhhBoUHTq2Mb6IF NyMVoqHqjoJWVJnVrzzZV4qpXFJRwoLHRad/xFfM7NB6to06kcuFX57ObPU6Uqrm4e1eKXem8cao zKaG/N8aSVajoKPxz5Gu1mBETSqsV/uy+C/Pqm4yjJHd3lhHHUfIFgENHz+nA53rydt5ge/g+/jX yDnymjAXq3fNU/Omm/xNwT0oToh7RcqkZ9Jpc2uiTdAFnymTTnUmYpJoU3WzxYok1+mysaZ8rTgf IKzhhUS0rUWtg1/Bgu6DTn+uxSf7SF/M9U0WS+Np9gJLjrHH2J+xlMJm0H8UO9hTHLxeANXCaGGq QBXqVAi6Tbd17Hp07Hp0zFgWietp/YL+qU6N6cd0UtEzOtQpHUtr6Z60TjaJO4ntEfphWP1Forr8 d6yshidqrhLhx1fDGZlulJsuFRwBwSBL3xfZBxy0EEhnjdHYNKhNVNGHMlCNguF2wZ0sHyl8RXda PL3RTDhZOdB4/9bZl3JyepUWcNtom9lqaSkMbk8VPcXVTLedOtHz1A8agfWvbHhhTPH6nB46q3Z0 DcLR9xpPfHFpIi1Hod2ctpkd7UM7K+Rz59dYIgi/xtHGOhNhPknsIP4Ksz3R/SO/2HgzYhoZbZM1 TQJEtVIh1wwMyOMTgfHxiQpJypIWkCStf411BwGrBApF++dUtWrJ1EEYyr3hOLHZ6TnDha0tEqlV TJ3OcWlnbGJck7yjtZE66IeOgYKei3ReXvP7gWsgRIxTR6B3Z2DR2eP7285xVmLReUed+vrM1Xuu x3sHSebny4t3llB54GaahrSKOFdt8m5FQ+/RDlXO8DovItZ5UDbzlj2YixgaZFZIy0OkwohY2RXa ddPIrxrfKmRza+VcM4uh+agil5P9v0bXOINOgZcPFo5f3JwvwaSajwjhkIk0BZxQ36Tbp/fP+rT+ ToHfv+f64YN70u0qT4e8XHzs/FQfsB7YlG1d8PvsdDA5EHl8W19XIsefYiwu2lOh9MbArcbM9c7/ sV/uwVHdVRz/nvvIbkiabMiTJCQXsnkQyCabAAmvsDQhhEAwTwktwW6TTbJ5bR7LowygIEIpDKAC hVCZ0mIDAqWUUsHWgrUq0ooDSkuxA9QyBartUIYWpyT3evbuVsWp/mEddZy7v/nce37v8/ud7/3d u4nWhBTFPiI6KsVsks1ZZRuGkUr9jvgI+2/XNVZNHJUTE5EYbTPzF5Wr/73g8MHCKXFDIizJ9Ykr JqbnpIysoVtlcSHm8CAJEPT4N3H870clRTkWrrLToUw6lLHbti97oFQaVTKxZG+SeN/Mb9o3FYgF E1BUXOwYnmS1JghUWSFW8AdygpW/l602uz3ZURzlcBSDiiopuVpRKoMyM8ut6basrHRMCQk5HmuV w0uKHQmitUKymR0JVRnWhGKHZUJ7wQl+A9j4OLGjmI7CTkVHbjrIcUxcfLQq8pg5NeyYONoRXJXA j3aCo0oXx5p7xVH/4VXL1b/Xhu+h1OXhE8aHedl/0cjnH8G6QnSpyKwQvloC14BM+GMJ9d00QhTw +aPqf32aomLvkcr4/KG+ulg+lvPoi2QReY98xER1TfdC9d3t02aMTU1KiwkRBXOIpTCramx6e+uR qFHlk+OXf7BjVGHu6MykDHWHxRISGTducmr9V1kNeTFnFgzLsMTlVe+sL2JFTFfHq30T06y5KVGR USF8eprMGWWb3HSY9jhGjifTK5Y4wRJzd1JBfGhERFpV/KqCdHt6+izhBBXFD4u2B4cOsdQ/cx3+ X8s/hz4FxGf8SGnMs37kkcw25gwQFMesAEyrAfNzQPApICQRCD0A3HcRCB/K8HwRk4GhS5gBIPKA Hz4VdaIdfmJrgGF9QPweIDEeSGoHlFJgxIuA9SkgbReQwe0z9wJjcgHbbSCHx841A3mvAOPYp/yT wARmUh0whftO5XGmsf9F54Dpt7+Ykkw/pdyujNc2i+9zkoCvfAeofBmoZn9q2a+5hX7mbQce5HYL 5gMPbQacPG/Daj8uAWgqAZqfB9y81rYeoIPx8J+R7lCD/xV6mYVRBgYGBgYGBgYGBgYGBgYGBgYG BgYGBgYGBgYGBgYGBgYGBgYG/z4Qhmf5KsL3a9WvPtuEM5wj+H/jqCBgi0imjoAtsb0hYAexvT9g m9BMp7klScG+MQV7wCYUCjsDtoAw4e2ALXL5tYAtoVBMDdhBbDcEbPZH3I19UJCLHE4FbNWgBS6+ l8ODTsaLR9CllxRxrodt39XJ5W69hY1rpqGdk4IqLmvm/l706jkX313cehFfG7llDdd36KUK5vB9 sd7Kw2VOHknhWl+Nk/HqczRyG19dD9q4zIOmf8E/36id+oj+frWcc3PO55GCaraces4/cyeXZusj KPrYLbr/Cho4t5BrfX659da2fUpuTk6BUtPiUso9nR7vI10upcjT0+XpcXrdnk6bMq29XalyN7d4 e5UqV6+rZ5Gr0fbA7DnlteWja9wdrt45rsVVng5nZ0V11kyvs93dUF7z5ar1coUrFL1GcfcqTsXb 42x0dTh72hRP0z90VnF3Kl6uq+10e12NSrXX6eWRnJ2N2Z4excM1PUqDZ2Gnt8ft6rX9BwXzAGaz UMo5aOUY/Tfy8Yvnr9Kp4EBmYaYezHZu1cDta/Txmjls7bqEvtxY/83e/1ePjX7eifm0GTLMcp+c hzGUqt9ni0+iSRhKsiDIoizJwaJ0BUM0YEkR99FPwZryIoUtRRuQN6ollGcaQS85QCcu3+FBu+XZ 3ESBJG8E2E5mEsVuxAHau8x1H2oZ921Ditqi/V4s5PZbA/h/qdiLjRSC5ViF6SzyPTjNm9iFShzC ZNyktzCDT9NUDsEoODCIGHKihPI5txGx2mmueVC7IbzPJ/EOrMQtXvybvAk/51O3j/Jg5QfmDUzR mhEpX8B4rMFW7XcwSWPxfVzQ3tFUlOIpXKDJVC1+Qy7EXCzFMmygWMqkAlqGNPZhCX6Mk4Il+ChC OZhzOLB1LPIXJOI5ZRbQITovFvFMdVhP4+ikdoB3JJV7ZmEajRdGaz9CEjIxFpMwFd/CFmzHW2Sj KaJdOo5YXpMTxymMYmgkndCeQDKncsxnTzdgG36A1/E6JVONkC0+JO9Tr/N7zsMeLsd6nMfHNITm 0hLhmHhQnaq1ake017h3Ps9TjDL2ezke59X140WcxE94Ty7QcKqgx+kjySvnDq5Uz6pXtBjtY4Sz r7UsoU58Hes4NrvwKi7iKv5EEpkpgl4VcoSLYpi0S47VoK3VY57NR8pcnmMtHuV0nHv8jBTKoDzy 0ptCmBAutAsrhP3CH8V14mHxPemaVqTt1X7Ke36D34IpnNL4kVrMPq7EJo7dAX5/H8UxnMIHuInb vJOttJ4O01G6I0QJB4Xz0oB8Qb6pfU8bQAjvdirG6AdiHu/gDH6A57L3fRypX+JXeAef4TNKoAm0 gtbSY7SRttI2ukyfCmuEXwuXxG3iPvE58ZREUq7UKq+XrwRVmpzqNrVPm8Wri+Sxx7JuCnkPXazF XtbEE7yPz+OHOMG+3cFd3pdIXq2VJlEVLaFltJI20ZP0tlAqtAoeoUskcbiYIqaLj0rJ0n7prHRR XiqvV9PUeZoNPt0MYTVMYr/rOH2Nj4s2nmMpx3QHq/5ljtYvWLU3WM2f4C7PJnCcQyiaRlA6TedU y1GvowXkpBZaTk/TfrpIHwkWIU4YKWwStghPC+eEa2K3+F1xp3hE/I2oSpocIudymiXP4/Xul28F 1QatM91vetjUb35jMHPw1OAlNVSNVtPVanW1+pJWpy3SFmu7tX7toHZIOxn4ZtqC4awvhVM6Hyul mMWH7AL2vw3drMnHsBnf5tTPaziCF/AaK+4szuESLnN6H9c5sn/Q1/QJBnhNcZRCdtZLPs2nh6mJ umipnlbRdtpBf2a8WqCjOsrwPzP37i55wPIMSXjc5SYBkmwDpkASKGzJbgjmICSNuJvGunlBwKpU pJYop2nxWLgQoVRzpFBbTo+1J6jcTXkseEBsgQA9iIUij2oPyONUaQCpVFpCrt/c3YREz1F399v5 5///mfn/mW/mzt3CTPZbdpAdZ6fZWXaOXcT3U/ZPdpcP4UN5Hp/G/XwOn88reB1v4Mv4s/ynfAt/ g+/h+/hhrPIf+Vl+lXeLUViJgCgVXxVPYEZWiufENrFHvC/OiHPikriLuVGwRh5FVzKVImWxslq5 qE7APNWrS9VX8X3bkehY6tjheMvxruMjp8M5wVnqXOB8w9nutLBTdtAm7NI+HzDuTTaRP44oBXuH 72QvsRO8XenkA1mINQniXiUXHJ9H1/hakclmimdYOvZxC83lAnM4kL/C54Dd8lOBXZwPHlaqp5Xh 7BdE/IesEefNSfCnDD5raB9lWudoML1ofZ12sRTsqAZrM/ZCMytjB7GHFvOn+N+ULuEGQy+J8+DN Nez9h1mr412q5jlg2yP0Ko2gQqznh7SSaVxeADaLNVhpD6VStvKkijOc3Rbt1MZb+Vq+0zrGiT7G uVelzGGExwWp2bgzX6dfI7bj/DRfy3YpDraNzUcMo4QL/OigDP4KNYgVTOHN/BPlHJ3nhbxK5LLb ymQhaAHWaTWF2HXmol+yVn6XeegnrBnZX2XX+VU8yj5hFr8vNvBGdpR1sBE8h80Wk6ibX2K1iCaD bqgpzMWnYR85wKtrvE0sYlvotPq2+JMyT+wmhR1g03iX0LifzRMFVidlOu6K5O4zVjH5uWVtUhLv 38TsPEXnrUPCq9QoX7y3695JnsI2iW+oQet29yp1NZ9Ji9S/Oh+hlbwYJ8RJPIt2UDa7ydMw72Oh KcJMpSgb793j5TSa32J36Bm2AbsjA5lU4uTYgfeJN+Gr4tk0C0+Bz/l2nJrzxAqcM7vpENj+fZzt Q3kdnjONrII4nhKK/Tx4GWz4u7IEF4hmrP9+PE23Qxqj/rzbh/ebb9JC7MUP2DrsulJeqARxWXge 33FEvkcrfbNmPjJjelFhwbQpD+d/YfKkvIe8uTnZEyeMz8rM0Md5tLFjRo9KT0sdmTJi+LChQwa7 Bw1MTkpMGOByOlRFcEa5Ab0krJlZYVPJ0ktLvbKu10BR00cRNnHvNUv6+5ha2HbT+nv64Lno3zx9 MU9frydzazNohjdXC+iaecKva1FWVR6E3OLXQ5rZacvzbHmjLSdD9njQQAuMbPRrJgtrAbPk6UYj EPaju0hiQrFe3JDgzaVIQiLEREhmir4swlJmMlvgKYGiCCdXMoIy03R/wEzV/TICU2QGaurNBeXB gD/d4wl5c01WXKfXmqTPNgfl2C5UbA9jOopNpz2MtkRmQ+u0SO5BY33UTbXhnKR6vb6mOmiKmpAc Y3AOxvWbKU1XRj6oovMhxcEX+lrThREYuUSTVcN4QTNfKw/2tXrkfyiEPtCWZ5aEjRIMvV5O4sg8 BCLDl6nEkmrQA1ITXqqZA/TZeqOxNIz1SDNMqljpaU9L8+21LlJaQDMqg7rHnJWuh2r8oyLDyKhY +VaqT0vtb/HmRtyDY7MZGTgoLiQl9xUaem22ZLtLqayidzqZjEifCxaYWp2GSII6EimQfw0FZNQV wA2fEEMrsx7LsMQcUBw23EVSL9ubaqZb14w7hGXXOz/ur6mJaxyZ7jskRUmOXn7B3iObOTlmdrbk hbMYC4kYZ9r1Kd7cp6P8hr7MraHA9NGCIJqFivIw5x6PXNV1UR/VomI2lwdjdY1q09vJl5cTMnlY Wg72WIZ/WVqaeyy9zcM66LvTvnUPN11Zvb9B7hFDA41FJhvxX8wNMXvZY3pZeVVQCxjh+NyWVfar xewFvba4ZA4tDop0Hpd4urCtYGJ1r7OsBJNMJRM/h83k+qjTBSraGqaVmO5waew/lODx/J+NotYt 2couHjSLh2kW5fSvT+9X7xdekiEQsJLFyyqrDCOhn60Ex45hlOhaiRE2aqJWc62uuXVjL+6AprEs EO5Z0ai1b126WbI+hCQaWRHYyml2RGdryiM+tuaxquBeN26+ayqD7Zzx4vDsUCQDtuBeDQetreW9 WlnTZI3KGJjezl22KX2vj6jZtiq2wq7XRRnZOlePjlFdlMd0bluHj5fi72Rq0olQ65UzXxs0444r 1WVfFV4fG90vy8ORz452qffXJ7S5JuGWMAD+jOLtnJ7uAH0loahL/XxBQhve0Zx97y0D/uIoZKOk xHvQRi+LapalEL0ELHS00UZHIdWy3SwZtvW8zfIoxMapi+gAJ+s6dFPRLsALrd/AvwlYBWiAH/AB c4HngI+ALwHT0aYJyEAfrcBRWUJ/xFlNNcplayvwnrqQDLXDegfyKeD3agf9CPXjGP+gaLH2qQut Y8py64CjzdoPuQP2JvidRCn7eA/9DVSW0wbULyiXGSGPz6D/LnRRtOsSoymZF9IFMdrKF2EqUMi6 ydtYI9pNAqaKFqmj8Sh9vLB7C+zHUJ+INkHUX4N+GOT56F+XfsAM+IxB6UXf2ei3E/ZKqYdvLvLR EXcUqIatQ+RTC8+nTpFvLVYqaVg875/JvGXOPTnZ8cdi+g+gX9m3ry9i8T3Ag9j+J/6MmN5H+W1g MnLp4ifoV0oePalQ9x7HMFon4TyLdW9jm4EkpZ5SnaOtHyPGUnUnTUFd4gmgCu1vK1utU+If5IMt x9FKm6Av5ZPBsSnUzr9HVxyZ9Djy9WI8VfIE87bR5kK9PW8c5RjlqnUIsqxnOkezhPg8bZVz42wh L9pPxVg3EEenspwZwArE1g68KOPB+HmY8zDWfQ9b2L0d/QwG974DPIS8VsVgXQaHT0H3KPzGYHc9 Gx/nVJ/ylOReX8TXpwcXemDPfRtuqm10BPgUsWQBvwNWod0HKPOgRxysAlw8Av98yVfw4laMm1aH 5Ab4/gfop8nY7RzAb8mx2L5hTXwRvQ58C/iBg2hbHM/Dx94vkrMyznjfnZJbkjM9ZZwbh/l2vB/I PCWv4qW99z6k8XYMyP1ftFdrcFXVFV7n7HPOvQQEFJtYIg+BJKKkvKZCYjKEOOEVEKgkQBqQUrSU iAF51gqiQCl1IEQJAoEOjwA2UcYGTUOVEEASOjYwVoPjAxxbVJChUoqB0nBXv7XvOZdwQlA77Y9v 1r777sfa+6z9rW9JbEUs3p3EvrZn8KbFFtFwiVlZM2JrNR+kyHuUNxGxrj/yPsEb+7Q9Q9lurKd4 1ruLiF3FFfhvkRNDm63+iP1KvIEEilYXwEEncIczaYS8Y6uINprL6fbAWeqNbzkaa23w2fWCQL0x A+tV4z5rrDraALveqje7WfWGbZfxGeucUW2XmYul3dz64Y0VK2j633ft/29gHrfLUKuU8Zd2PbNV T89LlgicNfoAXT2L/nJgCXBP8F5jfTDPqAxkUXvEzUUg30qjZDsNMVdNg6zvaf6OQ3+WQ4gHgzKt 39Ico9q4RWUZ8U4ZPaay8Eaxl3mclgpkfdhZkTgKx1qyZ5vFkmu9ePXZI8L5wrue1W8PvOraCdf/ 5hrJDcLPkh+EowXheOVtkbh8Hjnko2vx6YvTmCbx+YKZTH39cem3kluE3yW3YP/J2H8z1toh59f8 CI4TjhSew5sf5Y3328j8UmMf+OEPmofrKMd714C889P4b6TLI+Bhek3zYT5NcrJpohpAozQfDaPJ 9jHqqnOQm1Otct6luQzvyculOo/Wc0Ekj3biC2E+48Oabw7wXnmfOm8if9pbjA72nyhW88ocelO/ Q3mDlykZe2Wpl8G5jbwAfX1VKrgX/ervlKP/e5+6qAWYZ/FayYlqJsXp/Pg+56tBNEjPXc5p1mXk 7Z1S1YbX02Ng7SLEJLSAM4UOaC7IkRihth4fy7cP5PEbgcl80JlGNfYYnGcqfYqz1Ok7qOQafQ8y N4YT5S4C43iNauAQxvxZQ+bk8V59H7ijpnehc7NoCqzp5FORvg+Zs5S+CE7gUwJ7Os13rmAf7GWn Ipekc5WdzoWaWx3kuF/gnF2Q29pQqsR9YDaz6sJHvTysqihOLeIddiyX4O56uv0JwvuiSURviIaw d0vu50o95x3otChKE1gJiMs8elSVACuonV0CLVLJy7RWqKe7lcWlahH0TVifiEbI0u8ln3fa5Zqb e2ofsIe8fXyPQ+DSbHDJ4MBz/JJlUj/Qyg+JeDTwCJDh/j7o4lAYxrHwGENk5TjzEp1DOxfx+jCR egp9A0QHqne5Xj3Nh81CXqzG0z51lN8x76T9ZhB+vMVX1Ls00fiKatQSOqCGQzfNolp1hE+pQ3zS bE0jzBTerH5PeWop16knaLR6HOutocPqRT6vVnOBKkKMfk0H1du83BpI+63WWOsk1Ri/omLzH1Ts jKT22G+wXn8JFWD9aI2liBPMawrtq4fmPk8146iN62/Odf6Kr56fno+ef6uRy1z/5Nyyrp6HMdYw GoE7/BiIC9vQWHyTHOF1zVkZ4J4gOGgSpeD/jkRXLwCvoV2IsQ3AKbQXAr9B+9fAv4FtwOMYdzH8 3agLfg+1OtJCl2fyMf5e9D0GYN7Vv+B3Z7QHol0HfJ+o8QvY2cAgtP8FoL/RdpEFtMMcjGPZq6/b 9xXGbwI+RHsr7EPhvsY9aN/i2j8Ca4HFQB+tX3265P9gb5iPvq315aG+/pzynWzGt7LX5x73+3+T dXNLbjPr3oN3jib+3DTneRbxU9UUwq3Cb8Krwm3Cp8InEQtO1bwm+QREELb8iXCp8JlwqfCZvdTN +wXgiFUU6/mFt/Wq1KvqPuAkLZRazc6kJM3taHsWXN3f1RwDRcM6qTKG4nVNV0lB7Pe5aqD7rb+F 6nRtuR01Yltd34328qJb442QnOVk0Ao7O1Qn+UzXHo9iznTcwyisK3Wf1ubUAfohWnKm2Q3rJPHk sMZFDp5DdcibTyJPf2htphNWtHwDV9c+xJOAEzj/K8B5rNNVlSNX3Mp7zHXQIT/gzsZG2moOoq1G iKLAmxujkvlQ8BQfCnSihCBxlfMyV1ngluDnXBso4FonSdeusd73xZX902s30SSisWZGNJd75ma6 CP7BrxmSJ5ru680LrMW3quXBnr76pjfmxtpdN4i5G9YLzeqC6+uH96wL0BN38fCIVhyCmvEz1ANj aUzkjn2+eHvhXva09CbdNzJFrdTarY+L+zD/VvRXuPUT7hnxu49itQ6SXP4zPqr2ix4KbcH91AnU 18i/x2iC2kXz3DP01Ho2iVpr/ojXdeAQHX9J5Fh5NAx+pLjojjp1md6vHZ/WPv4UgEaysrFuJ/64 CcqARvMTSgAKkWNq1HGgE79kZoa2aFiI68zQEdzdJb0XygSrJ/TIWeivVXQbYqODWGXTQLk7DXx/ oEqNoADwFEBqJeoO3JWahfX3kyNntO6Qc4Q2Yew+1Vm/xURvjtOGEpxcIArn+CVyZBFqlU40zj4W KrZyUZd1BDrREPUB4iIDdS1gjOXfGbWwtZQqMIdSGmLiGTOKgkYF6pBcIx46uBwoDOtm44RGIr0N /BU1XQIQB7wlMEvNQFg3G9PxjrYjBicCDDTgLn5iJhn90X/Jxc4mCAJKtTVsczyVGjHw6VXKNtOh bbGPak/r/MD4qWGg/iil3dYcY541ntb58IAfmCu2tx/oFxvnh9vf0Q/0i033A/3pN/CjpXEt+dFS f7wf6I//H/jR0rrd/UB/95v4l+kH+jO/gx8t3XMPP9Df4yZ+POgH+h/0+wENtRFYCR0FvcanwVdP wEJbUyzsVdhWQEFYx/GM8Bg9bgxwDzAXwO9QNbD9GvhJ9L+C9rnr+69izRA0Or8HOwDYCcCH0HPo gwbk+zHmCn73AkSnQQuGxrvz2gBRaEOvhnoDIeAzIAaQOYXh/fR82ftOrIf/6RH3fOfRlrpiQ9h3 hm4MXYbNxZw7rp1B34nUF6vw23H9xvlpSBgMbcl5wDyAgR8DU4C57h3lYM5Rdx34wguAB8K8wMV4 q4NVI/gQntox9LpzG00Ta/XQnNvFepqUmyMSwZVboOF7SV2qXuddVjcapTahfzNVWInQ0xl8FXnp krUD4xPoRacP9M9i3g7e7qfRgDzWD1xfTPN1jugG7q6gNrKH1Q68WUgp4NMSzbNJ+D+Jt0oOk7pT 51TkglbR0BUxVAx+mwt/EgLl0C/TUH++wAVWNq8LJkC/pHGN8wHPtaN5WatnuDpwOzi7gbORrxLt LfSRdZlmRfJfrkHWbOrl2eAJ6J1YaMl0+pG1ie6W/Zz5kjtDAyJ7u1oLdc4buMv5wG58i2mkc2wj 6onGkeKzzn3QaFKfhjUTd4ZPFchTpfAnBH9KIlqRaT5qthTnAvL6FeoZ7MaH7RXg82xajb2Sw3vy ReTpNZIj9fqp8N/VkM4y3M/DZHhW9IZPl7a383ivWsQ7wrqU3/T0aWSNUt5nx3KJNcyo8+saT0dF NIWrVb093PMc1Rb50zv/NevTHanUWa2gdvZU+lR0RzPr+XQF3zYP91dJQ0UTOD+nofY22AH0pZ1I z1r/Yb3ag6Oqzvh3z7m7eRAIhtBAEJYEdvMqSbg3kBiaYSMShGoRhyIKbYYqjGLLSzqlpkwIjxbQ DK9SfGDD0GqdAA3uCiQkBKiCpWhDpiOKpUBB2qkDREGQ0mFPf9+5d0MSMPzR7s7v/u4978d3vvP7 MukzaPClMcWqwRNQr7M+86zFnKDX2MY8c+iDmCdoCPYP8Zba4O7TetI6UU0BP+icf/Uz52xEQkiD 7jagutU1JzakU45vibCfOOiUudkEPoH0IPg94A/OeabJqAdfFtmId/gdA2eafuMi7MB4AOjJaR3W uVVr+s6c5toar+M7PP8u3LPLt7xz7KY1IX9Th/Q/46zVtOvhqJ68I6ua6DfsaiW01MJ2PRvV0V0Y WrQZ+X06s5rocERpW4Mdd+Woru7M6t/ut/w6/dpBT7fcilE0d9LXnVnFtevru/Gt2GaNMx8agfk8 Dk7BfK520e2ZLsvb9Pw5g7A+8KEUZvbWEubG83fYjQ2b2tnV5e3avjNXYY7neVxcV5fj+Pa+yGum jb66A9sd4BkHvz9O28XmjtD6/g7wbKNq4BXvR1QJNESZY8Xu4F1D1cD6mEaqBBo68DGGjgscjOnw 3g65gFYyzF9TJdDQgY9pOHHGbUCfR4Cr0f68VzDeKxjvduj/buAZReu8R1HewTGOP7qDdx36WUfn Yvahn32ocxX9XNV8jBFd9/a1dNclOr/oeNv7d9v9n/fxuvpPd7jbvvy/5t3d2DvCiW2o1OXD4ITO Y+Z1w7gTIYYSqRV7eQ1oZf+E8uccGAUdbOdbLpxv9luAPE4XgFaUHeii4DY7+EjN1XC/+SwyvNIw vRJ9bqNN6O9tB8bTd1yfK4bJvsl7FXyEBjDcmGyf2UZ72b9ruL4vdr5qhS94nP0o+5pYUs044zvM gzTrluZzgPn0wFnfgvx3HX9HGfBJQZd3mxPUOQbmexOIYJxDgQJAABuBZCANeT8EIy40atx1j0da m8xVbwC/xTvuQ7KBp3G37XZ1Mmtp1sOpTnp0XJH4qO+V+WqtuU6tZd0gx0CDvIY9v0cdZkArMHAH UZyMoWy5Dd+W+sR8H+iBMnwW/ojy2S42wYdOoZFyBdIvuShDnTagkJJlPD0gL9ByaLjZnsW0BGu7 R36fXoRveFEWqi9EqzopcaObs9ReOQx1hmNsEsxtXKP1cqtqkpPpSfOX9KScRqvkE8BxoFRjDTTc KfFXdUOk0CrRQG/Ky7RMWtAfK2k5bGO1vEIr5AcoE6IdrEdkBdJT6LKMGEXmC8bDMh96JopMWiEy aLaoQFv96RfAz41PaREwT4ynEVAH00SQ5sopNEdkA+OpQiTTAvAyYJEYoz4xptJLYiraeYHWwS+u ECW0WpygZ0QZSeNjWiJGoex8Wiwy1HW0F29cV2fFVPUvUQLNXaYWGB+rM+AjYr46iTLf88SpD81l tM+8Ad3xY9wvm+k980v1qXmUmsyv1ArkIc65WQtg728exP5eMp8zVsvp0NPY+FggymIbADa+66Tp d0QfhHT+sb3zfY+9Lve0wEd7oOditbbczHmos4B1AvA63724r015nmagFcRBEba/ZEdrq6M4nwXt Z4jrVkNf+7jLSD3KIKZTPcU89Rd8b9O6Sp+NyKs4bz3wnmwiVkMfvxenVQ33hXPTou9XxFNY30x5 SNV6XlHviIA6zOdN2/UFyjKzcLai7R2PvGo2OroH9bfzWeZ0XXagStXttka28H2PO7reaR+az0EG 6zF9J/jUTNbU+r6rVm+Ib0fe1eegWu1guxGpsINUyhOPUgXbivGU+hVQJ1YifSpVY5+fBTYADzpQ m9y0HOMQ+s6hmcACka1mwK7mAgWwp+dhhxVY2eFoazPsykBbs8UPdJu1wDLYVpXRRlOAx8QAZnUZ 9RDfqkkA9G7k7+At8BvPi8cw1/7wOeOhS8rUUbyf0RrT0bl9eI/gTy7e7V67kwbopAfucn/ftfxi KmINiLHNMj9E7OjqYqz1XvapnlrWxdomWS/2hS/eirzpiFGTOU5lRrsTo/bm6rX6KMOnjEIfKdGY C+vTDOwCTgIbnXVT8KkRxBH0CPvRmF40GDZwitt2dfMIfQ7Yn56jhxxtB38a1ea3tLbWhBwn4kz9 SY6Fff6IJqDd2QDOK2UA8ejvd+hnjtbt69UBvm8862kO0t5H3r3gs8BXwN+AfwCHgBvAefc9hPWa wesS1auen6q3UHeZpxn6e6GjZ70zaQhsYacsoZ8Yu2kr8DnqvMzA/VJlVBjxaiE7BaK483QZJ3kp eXBme1Mesc84AaszSbw1mUoTZBPlA0FgC7AT8OD6bgyPHWsF68E5uZpDmVlWg85IDVhLSvvIRqoB 6oAWgLV4I/kAIRtFHRbEh8INoW8M0LXqQ/ff776MLHJewtnDrNOl8bKe2gAh62UDZTq1wpm51uel iUjADOQeMgAJz+eTzXI/5ehC+0NDs60GuVtWhYp9iaUpMky9ZQgbHKJHgHnAGcCL0YXpNNAGKMCk JPlm6OwqX7OsMZ6F3/TJl2hDrBFM8FWalR5RKSqlKG8UO8lQB4yUUP9ZVr06EJ6ZOgvjXmI8xwn7 5HIjhQcEsVMXGm4H60G5msJYJ82BDIfT/A7fO1hzaIhTur+9pQnrtBM4I+p2yaBMy0JHl8PFgRKr SS7lPxXH0i5f0D/dHlSPeU5/CgUuhf25djI+eWOeaZZVWKPV+tmL0/Ks3pw3aZqVwPydSVY687iH rV7cRJkdDwrGBcZZSf4xU3WhkGVznVC2ncRFC0uspEY0WEK2+jLY119i9/OPmGb19gcKLK8/205A //UqEhzqH2YnFOfZ1sv+Wv9e/xG/6fGPRK5VZPUvziouKpb9/Clo8O1Mf5HfbJJV/Cd/LAV7+xJ9 PHjfIp/o4cu3Masvwj497SX8Jx8K9fUVlsfUxYhyb51XpG9H+bjteej4ZDB+uy/dSh+S8yhPqTKU ZWtK50WpDA0ajNb+uWdQjm0NwmKwpVXufmiiZQW+aZfGq0uyku7DxK6Dc8CfoUqxPRg1w6PLrEHM ecVWEreUa+tPWKluP2Cb/Dl+QgEzFlJTmt0PFEwYaKcH8i0rPWAXof/rwfgAOo8LDEizVjejK0NW 8p8CmFiur9DnzfOO9soaUSf2ixZh1sg6uV+2SHMuSq2R0ifz5Gg5UZZLT2LpCHERm1uOZw1wGpC4 oi7SaGCu/qqDDRk0EU+0iGOeh+do/TaarVjnlHfJ4fNhyJAMiYv478QfrQRTCw3KN4KGMAyKMwTU RkoK/EjSPbHB0h6iQgyhAupplOhnoX7+l9Vqi22jiKIzG8e7eUzjOElx68azyToLZJvAYkNSSuJH 7BRpVUjqFHlLG8K7oRUKdVypIml4RYJKLR8gKhWIBAIpykI1XtqyKRUgIfEXCfHHD0IQIj77hcQj MndmrQYQgh9G3ntm7jn33tnR1Y6j6Z1J8mqSvJQkR5PETpKJJLk3SXYnyS1JkglJdyIVEbjUwOLf hf1C2DFhd6d3quS6Sj5VyesqOaWSp1TysEoeUklOJRmCh/EgImhI2NuF7eQWb15q2d+CGj7Dm2g/ InUVONoORKUOV09ST2p39RSA4sY+oZkdUhDFFAxsPTwOPIEa1iEa4H4MNzN8BfBvSMMPAF509V7q 4Q99cHjOTAdeRjqPwu+jGO4BfA85Yv0uMgW+U8O3Xe04hL3FIdOA34S/KlAECiREkZOu3g/0cdc8 QTOt+BjU5O6jKC5keWgRjqlamObGlug13IViEl+iS/opugnxPS79NeEp2KW/xD3JcelPuodh9SNw F1y6bsIq3UR/MNfp9+Yr9Gvdk/AV+pW+Rtd6vAAIPzaF8KIuknwQAyfol8xJel5foq/5uc/EhehF OEwn3UZfgFcqa+t0BtI8pp2gk36qI5rYwcENsSrAfgDuTwjnfTpP3Eb3mU/SUd2hI+YaHdYm6d0U /Ffonvg6HdBErX5NhPfG4OVgJ7dqDr3ZdOjBgWv4SyTjM/AY6X55QX5GnpafkC05LQ/Kd8l9crfc JbcrYSWkbFOalUZFUYJKQJEUpLR71e/SBr8G24MhDsEAtwExD0ncSv4tKWFFgvuctdVZklXIsgHD 8uTqATZoWKxh7MFiBeNzNrbY548i6xGV/VzQPNw4fojVa1nMwhayJrIREDPpZQ+jiaKHqzxiMcrC I0W4xHB68WyUo7141rbR9pOpSCo83LpnNPcPZqpmja0RMf46Ip3sDatQZCudNruDT6qdtsX2FdTD xVVpXno2n1uV5jjYxVU8Ks3nD3A/Hs3ZN2TQUHMgg6ae82ULKMZl0N0LQjbpyyhEg6yHA5ctIypk FC9zGbQZ11Ucms9VKBWawAxyhMYJzPiaHqHZ+JOmPoQ2hGajPiTK3SQk8ThIzDiXVLrjIKjEuwU9 vkVrPj3v0/OCfnqLTvj0ik+vAG38T+Px7H8p8tOFLLbGihUFZe2Rwz5uD80Miz5ovTz0XPQq3lX3 DWoybNaoZVmTlkWpVMQI3YNvOxJsZkHwyfBw+d6uyOno1QCCI+fyZnCTGtWX6ctwCtqZU9vA3VKj Iqf3dkGR5RoVAncrFIE+7i9AXx7Ls94pAC1no0h+Oge/GpRglMvlUmm2zAcE6AWLDY0fKlZ0Pc92 TOVsIx+Zzs3+y/sji/VCUIoHyXKepSGoVDJEnGGU/Qnk5tO/j1nfJ6TIKN3wY563xLMYGI7Uq377 UWyXuHUvG4mIbiRWq9frnq+EE1xs4xLfH8RDNj9HSeQtwWcA/TEAN6CuGg0KZW5kc3RyZWFtDWVu ZG9iag0zNjEwIDAgb2JqPDwvU3VidHlwZS9YTUwvTGVuZ3RoIDEwNDMxMy9UeXBlL01ldGFkYXRh Pj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03 MDIiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAg ICAgICAgICB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAg ICAgIHhtbG5zOnhhcFRQZz0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3QvcGcvIgogICAg ICAgICAgICB4bWxuczp4YXBHSW1nPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvZy9pbWcv Ij4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMTItMDUtMTZUMTE6Mjc6NTgtMDQ6MDA8L3hh cDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDEyLTA4LTA3VDEzOjQz OjM4LTA0OjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+MjAx Mi0wOC0wN1QxMzo0MzozOC0wNDowMDwveGFwOk1vZGlmeURhdGU+CiAgICAgICAgIDx4YXA6Q3Jl YXRvclRvb2w+QWRvYmUgSW5EZXNpZ24gQ1M1LjUgKDcuNSk8L3hhcDpDcmVhdG9yVG9vbD4KICAg ICAgICAgPHhhcDpQYWdlSW5mbz4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAg IDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8eGFw VFBnOlBhZ2VOdW1iZXI+MTwveGFwVFBnOlBhZ2VOdW1iZXI+CiAgICAgICAgICAgICAgICAgIDx4 YXBHSW1nOmZvcm1hdD5KUEVHPC94YXBHSW1nOmZvcm1hdD4KICAgICAgICAgICAgICAgICAgPHhh cEdJbWc6d2lkdGg+MjU2PC94YXBHSW1nOndpZHRoPgogICAgICAgICAgICAgICAgICA8eGFwR0lt ZzpoZWlnaHQ+MjU2PC94YXBHSW1nOmhlaWdodD4KICAgICAgICAgICAgICAgICAgPHhhcEdJbWc6 aW1hZ2U+LzlqLzRBQVFTa1pKUmdBQkFnRUFTQUJJQUFELzdRQXNVR2h2ZEc5emFHOXdJRE11TUFB NFFrbE5BKzBBQUFBQUFCQUFTQUFBQUFFQSYjeEE7QVFCSUFBQUFBUUFCLys0QUUwRmtiMkpsQUdT QUFBQUFBUVVBQWdBRC85c0FoQUFNQ0FnSUNBZ01DQWdNRUFzTEN4QVVEZzBORGhRWSYjeEE7RWhN VEV4SVlGQklVRkJRVUVoUVVHeDRlSGhzVUpDY25KeWNrTWpVMU5USTdPenM3T3pzN096czdBUTBM Q3hBT0VDSVlHQ0l5S0NFbyYjeEE7TWpzeU1qSXlPenM3T3pzN096czdPenM3T3pzN096dEFRRUJB UUR0QVFFQkFRRUJBUUVCQVFFQkFRRUJBUUVCQVFFRC93QUFSQ0FFQSYjeEE7QU1ZREFSRUFBaEVC QXhFQi84UUJRZ0FBQVFVQkFRRUJBUUVBQUFBQUFBQUFBd0FCQWdRRkJnY0lDUW9MQVFBQkJRRUJB UUVCQVFBQSYjeEE7QUFBQUFBQUJBQUlEQkFVR0J3Z0pDZ3NRQUFFRUFRTUNCQUlGQndZSUJRTU1N d0VBQWhFREJDRVNNUVZCVVdFVEluR0JNZ1lVa2FHeCYjeEE7UWlNa0ZWTEJZak0wY29MUlF3Y2xr bFB3NGZGamN6VVdvcktESmtTVFZHUkZ3cU4wTmhmU1ZlSmw4ck9FdzlOMTQvTkdKNVNraGJTViYj eEE7eE5UazlLVzF4ZFhsOVZabWRvYVdwcmJHMXViMk4wZFhaM2VIbDZlM3g5Zm45eEVBQWdJQkFn UUVBd1FGQmdjSEJnSTdBUUFDRVFNaCYjeEE7TVJJRVFWRmhjU0lUQlRLQmtSU2hzVUlqd1ZMUjhE TWtZdUZ5Z3BKRFV4VmpjelR4SlFZV29yS0RCeVkxd3RKRWsxU2pGMlJGVlRaMCYjeEE7WmVMeXM0 VEQwM1hqODBhVXBJVzBsY1RVNVBTbHRjWFY1ZlZXWm5hR2xxYTJ4dGJtOWljM1IxZG5kNGVYcDdm SDErZjMvOW9BREFNQiYjeEE7QUFJUkF4RUFQd0R6MW8wR2lzVXcyeTA4RWFSYW9iNEpVcTE5amZC R2xXdUtnZXlWSXRmMFI1SlVxMS9SSGdFYVZhL29qd1NwRnIrayYjeEE7UEJHbFd1Sy9KTGhWYSt5 ZXcrNUxoVmF2U0hnRXVGVnE5SWVBU3BGcmVpUEFKY0tyWDlFZUFSNFZXdjZROEI5eVhDcTFlaVBE OEV1RiYjeEE7VnE5SHlDWENtMWVsNUQ3a3VGRnE5RWVINEpjS3JYOUVlSDRKY0tyVjZJOEV1Rk5x OUFlQVE0Vld0Nkk4QWx3cXRZMGlSeHovQUFTcCYjeEE7VnNHTUVEWHNnQWtsbjZSUEdxTkl0UW9K N0pVcTJYMmQzZ1VlRkZxOUVqeFI0Vld6YlU1SVJLclp0cjhVN2dSYVFWTjdvKzJxMWVpMyYjeEE7 c0VmYlZ4SzlBZGdqN2FPSmNVSHdSOXBYRXY2SGtsN1N1SlF4aWVBajdTdUprTU54OFV2YVZ4TC9B R1IzZ1VmYUNMVjltSTdKZTJGVyYjeEE7cjBTUHpVdmJDclY2VHYzQ2x3S3RiMFhmdUZMZ1ZhdlFm KzdDWHRxdGI3Tzhka3ZiVmEzb1A4RVBiVmF2UWQzQ1h0cDRsL1FTOXRYRSYjeEE7c2FmbzZkLzRG QTQxY1NHdkc5b2xoNDhWR0lGSktRWXJEeTF3K1lUaGpSeE14alZnOHZUaGpDdUpJM0hhZUMvN3Y5 aWNJSU1tZjJZZSYjeEE7SitZLzJJOElSYTR4Q2ZENTZJOElWYVJ1RjRodnljRWFDclROd2FlNE0r UmxEUlRKdlQ2VDJkOHAvdVNRbEhUYSt3ZWZsL3NTNGxhcyYjeEE7aDAzU2RqeWx4S3RpL0IyQUVz TFFkQVhFQ1NoeGdKRnNoMDYzOXdqN2tlSUpYT0JkMmo1a0ljWVVzTUcvdkErQkNYRUZNbTREejlK MCYjeEE7Zk1KY1NMU3Q2ZVAzcCtmK3hMalV6K3d0QS8xL3VRNGtVd2RnL3V4OHdVZU5OSW5ZVG02 dTJnZVBINVV1TlN3dzl3a0VSeE1oTGpDdCYjeEE7VnowOFRCTUh3a0pjWVZxcjlsejJkL3I4a3VO VmxHN3BvYVlMZzBuVUFuVkxqQ2tic0U3bWlSRTg2K0JSSlZZZUxibTN0ZHZGenArTyYjeEE7bjNj TEpHU1lOMjN1Q05iSjZ1c1pUTjI1d3NKRUFrTkcwK09qVkpIbXNnV0hEQXFiMW5xTGZvMy9BSHNi L2NsOTZ5OTAremo3TVg5ViYjeEE7ejdmcDVEdjdNTi82bUV5V2ZKTGNwR0tBNklyY2k2MDdyclhP STQzT09uNHBrcEdXNVhpSUd5N01uSlkwdFpkWTBFeVFIdTUrOUlUSSYjeEE7NnE0UXpibVpySGIy MzJ6L0FGM0grS0l5U0hWWEFEMFpqcXVleVl5WGp4OXlQdlpPNVI3Y2V5eitvWmx4M1B5TENmSjVI L1VrSnB5VCYjeEE7TzVTSVJIUk4rMmVxa3RQMnV5V0NHd1IzOGZINW8rOVB1ajJvZGtUOC9Qc1lX UHliWE5jU1NDOTJzL05OT1NSNnBFQU9pRjlsbHJXcyYjeEE7c2U1N1dDR2h6aVEzNFNVTEthYmxQ WE9yNHpQVHB5bmh2ZzROZjVmbmh5ZkhOT094V25IRTlFdytzM1d3STlkaDBpVFZYUHgraW5mZSYj eEE7Y25kYjdFT3l3K3N2WE5ybW5KQjNpSjlOZ0k4MmtOQ0gzakozVDdNT3lIOXNkVjI3ZnRkMGYx eW0rN1B1dTl1UFpydXljcDlwdmRmWSYjeEE7YlAzOTdwKytVM2lOcDRRbHhPcmRSd0hUaVpMMkVt UzBuZTAvRnI1Q2RISktPeFJMR0piaHN2OEFyTDE1N2k0NWpteUloald0RWVRRCYjeEE7ZnhUdmZt ZXEwWVlEbzU5K1JrWlR5L0l0ZmE0OGx6aWY0cGhrVHV1RVFFY3VBZ09kQTdTWVN0VkxFdm1kN3A4 ZHhuOHFWcXBzMTlWNiYjeEE7blVJcnlyUjhYRjMvQUZVcDR5ekhWYWNjVDBhOTE5OTlodHV0ZTk1 L09jNGtwcGtTZFVnQUwvYXNyL1QyY2JmcHU0OE9VdUlxb1BRWSYjeEE7Mk5oM3RhWDR4QWphWWFB U1hBd1hRMTBLaktjZ2QyN0dNVDBiQTZQZ1cxTmY3R05MbzNXVmdpSmlRNTJ3YmRFMzNwZ3J2YWlS c2laaSYjeEE7OUNZSUxXdkJEaVhob08walJvT25FNjhvOGVROVZ2REFkRjhicGZUYjd6WTZ5dXFz TkJMalFXanRPMW9KSk92Z2lja2hvZ1FpVHN6LyYjeEE7QUdkaDRkam40dDczQ3ZWNUZiNEFkNHlP RURsbExvdTRJeDZyVVY5S3RjMTJWWVdWZTFzTlk0dS9sZTV6UUJxa1RNZEZBUU81Ym9iMCYjeEE7 Sm9manRiU1hWenRmNk1seEh0RU8yeDNtVkdQY092N1YzNnZaSGswZE94WFRiRzRNM1F5c08zVDlH Q0J5WVNqS2NsU2pFSThTem9GdSYjeEE7U0xNcXU0QWF2YTltNXJ5MFNYT2NHekhialJPbDdvQzBl MlMzS3NiNnQ1UHJQeDZIWGJaT3dnQjRHbXJXYk9HL2Y1SUU1QldxUU1aSyYjeEE7Tm5VdnFwUzAw V1lXSzV3M0VteXM3Z2RZSDBCcktIQm5QVXBFc1FYT1AwR3lwZ2JSakgyaDROYlFYRUV5QTh0MGJ6 QlE0c29PNVRXTyYjeEE7dGdoZGpmVjVyRHZ4L293SFdWRU9iNW1OcWR4NXU2M2h4S3E2WDlXY2w1 ZFhhS2hJaGppMGlEcE03UWZ3U09YTUFyZ3hFdWt6cFAxVSYjeEE7STJnVXVjREVNc2JMejRNbHNS OFZGTEp6RnI0d3hVbmQwRHBWVlllN0NaVzF4ZG8reW9rNmFURWlOTkUwNU0zZGNJNHV5bWZWdm92 cSYjeEE7KzBZajJ1QmRVM2V3N3ZJZTBlUGRIM2N2ZFhCajdNbTlBNkZlL3dDenNmVlVRR3NEU0di Wk11ZDdtZ2x5UXlaQnVveGdSb0d2K3hlZyYjeEE7VkM1NG9vdHRyZVFLWGtBQVFTRHEwVDhFdmV5 bnFhVDdlTWRBeHljYnBiRFhaVlZpT2RaVzAxNHJ3SE45eDEvazl1ZEVZVHlkU1ZwaiYjeEE7QTdC ampmVjNwTnJYTnVaUjZqaUh1REF6OUd6bjJRZGRFSjh6a2lSdlM4WUlFYmFzN2VoZEx6YlcwWWVM VFZVMXJtNzl6WEY4RVFkUSYjeEE7MzVoTDd4S0l1emFQWWllalgvNXE0ZGRMblhuSExnSW12YVFY TkhiYzRINWZGTysrU0owdFgzV05NLzhBbTcweDFkVnp6UzZrd2J0dCYjeEE7SWJhMXJSRTd0NUNS NXFRTkMwZmQ0bHBEb25RM1h1dzIzVWx6QkxpNG5UUWU1cm8yN1pjTzZrOS9MdzhWRlo3T1BpcDF1 ay9WSEtkZyYjeEE7MTVXT3cwMzFEZUhYVmxyak1iZG9EaWVKN0tQSm1zbTlrd2pHTmE2dHV2NnM5 V3ltTXJkbFVVMVZOaXIxRzdaMU80YWdtQWZGTWpsaCYjeEE7cVYweElmMkk3ZnE1MWdUZ1ZtbXlr TmtiTE5nY2Z6ZzRQSEpSR1RIeGI2b3FmRDRPYm1mVnpyR1JlTitFeDdXKzRuMVdUMkVDSE4xMCYj eEE7NFVzTXNRTkNzbGprZHdoeS9xMWxWVitwYjA4TnNJbjAyUHMzQ1ptRzZ6b0pSR2NBMWFEZ0ox QWFMOFBEeDlUaTVOV1V3N1hGei9ZeSYjeEE7UU51dXdnUjMzY0tUakpHN0h3VnVIWHc4YkY2aTcw N01hL2ExN1E0NGoydmdnYXVKYklMZnlKa1RSM1htRmgwTE9nZE5wejZXZXY2bSYjeEE7TThiRzdI Nzd2VmdsZ3NyamMzNzlZVWM1bUkwWkk0NHkzNk9kWjBMbzFPYlhqRFBzWmErNXpTNXptTmExcmZj Q1hPSEU4RkdHYWN4cyYjeEE7RVR3eGpyYlJmWjB6MWE4VTVRMk9JUHE3bXViQUJFV3dCeDVKNUVx dW1NQ08xdHJDdHdiZlNvc3V1ektiSG4xS1BRTGcxclFmMGpIcyYjeEE7OXlCc2EwdWpXMXA3VzRt UGJWVFRtMFcxTmw0cXlMVzBtb1AvQUtwYnU5cDRtVTBEaTFwZVpjT2x0N28zU2NMMS90VDhyN1Bi akhkVyYjeEE7YmdMR3ZjZFlhS3JEd0U3MHlHcHBpSmxFNkMwaGIwekR5YnM3SzZqUmxNc0VQcWRV K3NQYzJDR05PMzI4Y29IRUtvRk1jcEIxRG11NiYjeEE7bmgzWTdMd1F5ejFIV3V4dHRmdGlBQTZ5 VG9mT0UwUUkwWEdRSnRGYjlZT25rQnRPSTF6eTBzSTlwcWNRZHpYQjB5ZGZCUEdBYmxIdSYjeEE7 a0Z4dW9kUUZ0d0F4cW1WN2lSVzEyMTBramMxeDNTTmVGTERHQU4xa3BFblpXTmpXWm85ZHJIVmdC ek5teXdrTjBCRzhlMlEzVUpTSSYjeEE7anBhb2dub2lmaTJNeXhqNW1NNXNEY0JZWEE3UUozZTRz N2FwMSttd1VWcnNueDZzSnR0Z0xCWXdoeDIxM3RidGlDQy8zV0g1YytDaiYjeEE7a1pFZjJMeFFj OTNvTXJKcmI3M3ZsdE93dWUwZk53N2VTbUFKWWlhVmMxMlBrUVNHMENadElPNlkzbGdZU1BjMG1J U2pVb3FrZUVwYyYjeEE7UHFXSGlNUDdReHZ0b2E3MjFqZlZNeWR4ZnUvQ0VwWXpJNmFLamtBR3Vx Zklxb3F4blo3Qy9wTExRMTlkVDRzc0xiTjQzTjk0Y1oyeCYjeEE7d21Sc3lyNWw4cUVidmhjSTNQ OEF0RGJQWHM5T1A1NzAvd0E3YnQralB5Vm5oRmJOWGkxM2ZYdW01bDRGYnN5NGdWaXQxendTMW9x SSYjeEE7MjZOWlk3M0U2LzNMR2xoaHhhalIwZU1jSGkyT3I5VHdmZjhBczZ6ZTVvSmJXMXJwM2pV a0Z6bXQxRHRWTExIaU93V3dsUHEwVzVyeiYjeEE7YzIwTXVzb2NkbGRaTlRTWStsK2thLzU2cXVJ WTlpMkFaZ2FJUjFhdXU5MzJvZW5qdkJiVUhFRjdYSGcrMlFmbVFrTUVlbGxQSExxMCYjeEE7ZXIv V3ZwOUdVV3R5M2l5Z2JIVnNidkpjUGFSdWNOdTM1cWJIeWs1YTE5cFdTendqMWFsSDFzZGRsWldW ajRyTXFzTUc2bXd0WldKMCYjeEE7M3UzbVhFOTRVLzNjUUlzc0p6Y1lJRGR3ZXJkWXY2Ylk3QmJq WUpmRlo5T3ByZzZST2pvSkRpVDRSb21tY2NabzZwR0tjeGJWeWI4TCYjeEE7cDNWSDJWM2t2ckxI QVVOZUR2Mnc3YjZzZm5EbjdrN2g0Z0tXY1JpZlVHcDFUcldIMUM5OWpXQ3JKdmFROG12MUhpQUND MzZMVy9KTCYjeEE7SGlNZkpHU2R0ZS9Hd1BRYlFXVkJ2c3NEMmV5d3RqM0F5WHh1N2FSS2R4UzRy VFE0YWJkblRMdWdHdk1xeHhodnVyZFpSYmRrQ3d1ciYjeEE7SWlOckRwTzdWQ1FsTUM5bG9NUWRI QWE5OTFweVJXMHZwYnVmYTRiNUlQMHZjN1h3QVUxQUNsZ3M2cE1iSXlyOHFtcXV6SXR5cjNpQyYj eEE7NXdyWUNUdEd1L3R3bEtJQTZVZ1M4M1Vyb3RvTHFzakVkWlk1NDNlbzhXdGJHaGREYk5Tb1pF ZEN5UjE2T3prZEdvRmhmMHU1aHgzTiYjeEE7WUhlczNhNXdjd3ZMeVFBUGE2Tk9WWDk4RFFzM3R5 T3RPVlgwZkQ5YXI5cTU5VklFTmlsamk0RUVnRDJqYVBqQ205NGtla2ZhdEdQWCYjeEE7VXBPcTVQ UzhUYlIwZkdaVllRSE15TXBvc0x3SjFEU1hiZU8rcU9PTXBheUpXeW1JbWdBNFYzVWV0UHhXK25r a08zRjFncUlZMFRyTCYjeEE7dHZpUEFLZU9MRnhiTU1zMlNuUGIxQzkrU2NwMXpiSGtiUzEyOXdj MXcya0QybU5QRlNuR0twWkhJYnRuWGo1d3BjNTIyaGxoa1BKYSYjeEE7MXhBM1Fmb2t3Z1pSSjdw NEoxMlMxTTZUUTQzNWZWSHZ0RUJyY2VveWVKOTd4QWhOa2NoMEVOUEZNZmJHcGxyNE5abHRUbjc3 YXJjaSYjeEE7cDBsb2ZjUWRUdEx6SGNsUzBRR0lrRXRpckt4ZlZGZUhROTNxV05nMk9hOSs2dlha NzlJVEpSTldTdWhMb0FtRnRHVFkrdXdoMW9yYyYjeEE7NnZmTDNWbHBuMHBmcHhycHA4MHpoSURK dWRXczdQYUttUGRhemNXa00yMUQwcEE5MjRIWGRyMkVKNHhzWEVIb01SdUV6SHRvc2E5MSYjeEE7 YjJOWUhQYzV6dXhjOFE5b2E2UnB5bXl3WmVsTGhueFZyYWVyRStySnhOdVJYbE95SUlMcTN0cllm RDJsdG4rMU85aklqMzhmaWlwWiYjeEE7aDBWZWkwbllHeTBsb2M0UEoxNDJhUW81Y3JrSnRranpj QWh2cW91QXJmdmZVeHdlMEZ4RUVpTEliSkh3MVRvOHRranRTMDh6ak85byYjeEE7ZjJSMGZhMW9G c2dsMjV3YVFKSTAyeWQyZzdsTzl2UDRJT2JCNHM2K2s5R1ppR28rbys3Y1hDemllSWFScU52eVFP TG1ESzlLVDcrRSYjeEE7RHEyZW1VNFhUckd1YmtaQmJCOVJyVHREcDdRSGZtOWxIbDViTGtHMFY4 T2F4UTd0M0k2b3kyc3ZycHFiY3gwMU5mdmVOUHpqWTZkWSYjeEE7N2JFWWNsS0t6SnpZa2xzNnpo c290dHhjT3R1Ymt1THIzYmZiRDJsamhXN2Y3ZWYzVXBjcGtsTFdxVERtb1JIVzJyaTUzVHNkaEw4 QSYjeEE7M1gyZ3R1dXNlSGtqY0h0ZEQ1QmRwOEVzbktacERRaE1PYnhST3hhdVZkWG5abnJYMERh WGIzT2Yra2R1N2tORDJ0RW94NVRKR082eSYjeEE7Zk5RSjBDZk11d1E5aDZZTFdWdDJ2RlZ6V09E SHNHaGI3eU9mTDcwMGNuazZxaHpkRFZyMjlVNjNzUDJlNXRWdTBNM1Yxc1lDSm4zQSYjeEE7ZjZs UCs1QW5VS1BObXRHcG1ONmhhNHVaazMyeTNRUGUxZzNFZTZSVzNqZDVwOE9WRWVnV3k1dVI2bEN6 cHQ5Z0RyY2owWFRKRE56eCYjeEE7R21nRG9pSVRqaWtOZ2dab25jbGhaMGF2MUo5V3kxcE9wSjJG MnBtUkpIQ1Foa3JZSU9USGZWVlhSY05sZSt5czNYQnN3NSsxaGZQOSYjeEE7b2tSOEVqREtUMHBR eVl3RXVUMHVoZ29mMDMydUFCdlpkbzNjUDNTd0dXNm5RcFJ4NU5lSlh1d0d3WEhUR2JMSCtxVzJP cExXMXNZMSYjeEE7dFllVC9KSTA4Tk9VRGlucFFYeHp3MUpQMk5mcWZTblpsMWRsQmZGZFRLejY3 OXppV3QxNG1CS2RqeFNpTlZtWE5HWjZ0VDlnM2g3aSYjeEE7M2J0T2pRNHpBNzlsSnd5WStPS1lk SXVGMVZnWldCWEc3VTZ4NENVMDQ1VXU5Mk5yV2RIeVBYYzVteHpIT2t1Y0FIZjV1by9GSVFsUyYj eEE7RGtpU3V6cFdaWDdRUVdPUDZTQ0d1SUgwWWR0Y1VqaktmY2l3ZDBmS0JheHJ2MFoxYzB4OU9D TkI0UWx3U1Y3a2ZvK3hZZjhBaSs2RCYjeEE7YmlVV3Vka2JuMXNjWWVJa3RCL2NUK0lyT0FKdi9H NjZCKzlrZjU3Zi9JSmNSVndCWC9qZGRBL2V5UDhBUGIvNUJMaUt1QUsvOGJybyYjeEE7SDcyUi9u dC84Z2x4RlhBRmYrTjEwRDk3SS96Mi93RGtFdUlxNEFyL0FNYnJvSDcyUi9udC93RElKY1JWd0JY L0FJM1hRUDNzai9QYiYjeEE7L3dDUVM0aXJnQ3YvQUJ1dWdmdlpIK2UzL3dBZ2x4RlhBRmYrTjEw RDk3SS96Mi8rUVM0aXJnQ3YvRzY2Qis5a2Y1N2YvSUpjUlZ3QiYjeEE7WC9qZGRBL2V5UDhBUGIv NUJMaUt1QUsvOGJyb0g3MlIvbnQvOGdseEZYQUZmK04xMEQ5N0kvejIvd0RrRXVJcTRBci9BTWJy b0g3MiYjeEE7Ui9udC93RElKY1JWd0JYL0FJM1hRUDNzai9QYi93Q1FTNGlyZ0N2L0FCdXVnZnZa SCtlMy93QWdseEZYQUZmK04xMEQ5N0kvejIvKyYjeEE7UVM0aXJnRHpOUDFiNmZaVXg3bld5NW9K aHc3aitxbHhGYlNRZlZmcHNqZFpZMEV4TG50YVBtWE5BUzR5cW5Mek1YcERkemNEMW50WSYjeEE7 WU9YZTcwNlNSMnJhS2k5M3gwU0JrVi9BT3JRR0c5M3VydXFjUDZ0alIvbmFwOUZid2gyY1BvblRN M0hZUzkrTGtIUWVvOXI2TEQrNiYjeEE7MjFyRzdDZkJ3UUlJUlFYSFF1bnR0ZGo1QXZwdXJNUHJj UklQK2J3aFpRbC81dDlPblI5ditjUC9BQ0tIRVZJMy9WM0FENnh1dDFkSCYjeEE7SS9kZC9KUzRp cDlLNmY4QThuNDMvRTEvOVNFMWxiQ1NsSktVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktVa3BTU2xK S1VrcFNTbmdxciYjeEE7UlhpMXVPcDJOQUhpWVNMR0JiYXc4VDE2amt1YXk2NXcvUmVxQzVyUjRo dllmaWt5RFJ0M1YyRWt1QU02RVFZKzdWRUtMUnY2WlhhNSYjeEE7cnFhbTBXdWRCdlpBYUIvd3Ra RVBiK0tkeFVpcmFqOEo3WFdNYldLcjJhWFVEV3Q0SW1XK1RocUZJQ3NJUXcvTXBHSnVMOGlpdDF2 VCYjeEE7ckhhdWRYWDdyY1I3dVR0SHVZbVRGRlE5UVpZbVdMNld1SGNKcEMwRkk5M3ZyL3JIL3FY SUplNTZmL3lmamY4QUUxLzlTRUdWc0pLVSYjeEE7a3BTU2xKS1VrcFNTbEpLVWtwU1NsSktVa3BT U2xKS1VrcFNTbEpLZk45NWVNZkhtQTlqUWY3VUJLdFZrZG03bjlRdjZiamk3R2NQZCYjeEE7Y0s0 Y05BMDZRUHVTbG9MWHgxTGwyZlhiTnFzREgwTnNqd21VMk0xeGkyTVg2N055Ylc0enNZaDFoREJE dUNma25jYTNoZFRNYy8xQiYjeEE7ZkFIMmN0ckRwMWN4L00vMUh4Q2tqMld5ZWUrc1dhM0FEOHJF ZnR0b2ZYbVU3Unc0ZlRhaWZWR2lnYUZoMHpKcnVzc2RWcFhZZlVhUCYjeEE7RGZySDNwbzJXUzBM ZmVmZFdKL08vd0MrdVFVK2dkUC9BT1Q4Yi9pYS93RHFRbXN6WVNVcEpTa2xLU1VwSlNrbEtTVXBK U2tsS1NVcCYjeEE7SlNrbEtTVXBKU2tsS1NVK2FWaDNxWXpoK2ExcC93QTBpZnlvOVZrZG5iWmpt NFBiWTBlbUhIY1hBT0VlUU1vcFEzOUg2WTRGejZxWCYjeEE7eHFRR1E0L0poYWxTWE56T2w5UHhB TXJIcEpzcGFMbU1ZNXdKMWdOQWVsd2pzcXlsdXpiTW5wTjk5MVpvYzRDV0V6RU9BNVRodXRlSiYj eEE7NnYxTzNJeDhsMTVHNmJkclFJOXU3YXpSSzlFdC93Q3F3ZU1aazlxMmlVSTdMSjd1Njl4M01I ZmQvd0I5Y2t0ZlJlbi9BUEorTi94TiYjeEE7Zi9VaE1aMndrcHhIL1dLMzBtdXB4USt4L1VMdW1z WTYzYUM2b1hROHU5TXh1TlhFYVNwaGhGNzlMWXZkMDI2MDBydnJqbTQyRmJtNSYjeEE7UFRXTWJW a1c0c055ZHhObERMM3Yvd0FBTkpwajVwNDVlSmxRUGpzc1BNRUN5SFN6dXM1TkE2ZXpEeFc1RjNV WjJNZmI2UWJ0ck54OSYjeEE7M3B2N0R3VWNjWU4yZG1TV1FpcUc3bk0rdVZsZURqOVJ6OEVZOUda WGJaUTVsM3FTNnRvZXlzL29tUTUvdUErQ2VlV3VSQU96SDk0OSYjeEE7SUpHN3BaL1dMOEtqQ0J4 bW5Mem5DdHRMN1F4akg3RFk1cnJpdy91d1BicVZIREdKRTY2Qmtsa01RTk5TMTMvV1BMM2JhT20y MnVwcCYjeEE7cXZ6S3QwVzFDNHVBWXlzTmR2ZDdDWTBUaGhIV1hrdE9ZOWtUL3JmVzIvcUZMY1lu N0JaVFhXNHZqMWhaY01heHc5bW14L3hueVJITCYjeEE7NkRYZi9mUWVZMU9temQ2aDFiT3grcFZk TTZmaHN5ckxLSDVCTDd2UkRXc2Mxbitpc25WNFRJWTRtTmswdm5PUWxRQ3VxOWF1d01tciYjeEE7 Q3hzWDdWa1cxV1g3UFVGY3RxTFE1dGN0ZHZmN3RHbzQ4WWtMSnBVOGhpYUFjKzM2NlYwbnF6WDRq bXU2V0s5alMvVzQyRnJkdjBEdCYjeEE7SWM5bzc4cDQ1YStIWGRZZVlyaTAyWjEvVyt0K1RpNDMy WS9yV0UzTWMvZklZOTliNzIwSDJha3RyT3Y0SUhsOUNiNjBvY3hxQlhTMCYjeEE7WC9PN3FJeC9Y L1pqQ1RoZnRJTkdUcDluQWwwbjBOSDZpR3hyNDZJL2Q0MzgzV3RrZS9LdHVsN3U5MDdJeWN2RHJ5 Y3FsdVBaWU4zcCYjeEE7dGY2b0RUcTMzYkdkdkpRekFCb00wQ1NMTFpUVnlrbFBtdnBlcGpWUnkw QncrN1VJM3F4aDB1aTVicm1PeGJYbHRrUTF4L09IaVBORiYjeEE7YzZOajZtKzJ4dXJkQzV6Q1Fm bUVWTFY3YkszZlJjMmZiQTAvRUpLZVIrdEhWY2ZwK01hZ0NIMzJTUjRpdUlBSG1VZGxidkIyMldk USYjeEE7eVBUUHVMM0EybjRhaHFZVDBYYmF2YTlJeC9zMk0xcEVPSTFUMkFteTNubjNNL3JmOTlj Z3A5SDZmL3lmamY4QUUxLzlTRXhuYkNTbiYjeEE7bnF1ZzlRYm5NRDdLZnNWWFVMT3B0Y0M3MWk2 d1dmb3kzYnRnR3c2N3ZrcHpsancrTlV3REZMaThMdEIxTDZyOVF6T2wzWVZWbElzcyYjeEE7ejhy TEJjNXdic3lHWkRXQXd3Kzc5S0pUb1o0eGxmZ0FpZUdVbzE0a3R2SDZiMXF6SjZaYm5qRll6cHJu L3dBeFpZOHVhNmw5UDU5VCYjeEE7TlpjRXd6Z0JLcjFYQ0V5UmRhTUdmVjNJL1lYUytsMm1sOXVC ZmozV2trbGhiUy9jL2JMSmt0a2FoRTVoeHlsM1VNUjRJanNrNmwwRyYjeEE7KzJ0d3hIaktiZFp2 dnhlbzJQdHBjMkhnQmhjTERYdGM2UnNqaENHVURmOEFCVThSTzM0dFdyNnY5Y3dHYk9uNWRaZmZp NCtOa1gybCYjeEE7d2V4Mk9YKyt2MnZCbHI0Z3B4eXdsdU9xMFlweDJQUm9XL1VucTdNZkhPTmwx MjVHMGpLYmU0aXVUZlZsL29peW5kRzloK2tuam1ZVyYjeEE7Ykg4cXBZZVdsUW8veTNidlVlaGRZ NnBtVVoyZGlkT3lEVlUrazBXVzJtc2JuTWMxNFBvVFB0STRUWVpZUUJBSlh6eFRtUVNBM1ByRiYj eEE7MGJQNnd4bGRKeHl3MXZZNXQ0TTFXTzI3Y2lsN1dGMjVrSFNRQ21ZY2tZTHN1T1UzTnY4QXFa bVg1djJwMTlaQnlMYmJKTHQxakhWMCYjeEE7ZWx1OW5JdHAzRlNEbVFJMVN3OHVTYlEwL1VucVl4 YTMzWmJSbVZXWThNWTc5QWFxS21ZK3BOTy9kczNlV3Z6UlBNeHZiUkE1YVZiNiYjeEE7dHVqNm8z WW1LK2pFRkZSeU9rdXdjamFYQVB5aTBBV21HYWpWMnZQa21ubUFUWi9ldjZMaGdJR243dGZWNlRG cWRSalUwdmd1cnJhdyYjeEE7a2NTMEFhS3ZJMldlSW9KVUVxU1UrWWpxT0ZTMFUyV2hyNndHdUVI UnpkQ09FNHhZMEYrYmhGM3E0K1FHUG1TQ0hiU2ZIUWFGQUFoTiYjeEE7cnMrdHZVTWNSN0wyampj VHUrOEp5ckRXenZyZjFuSkJxb1pYVHVHamdTVDk4UUVrMkhrcjhIcVdiZTY3THRHNXhPb2tuL09L YWVJcCYjeEE7c0IxdWxkUHc4TU5kWTV1OEQ1QkdNYVdTa1M3Yk0zRGFJOVVmY2Y3azVaUzcrb1lj cy9TajZYZ2ZCM2trbW4xRHAvOEF5ZmpmOFRYLyYjeEE7QU5TRkd6TmhKVDUzMW5yUFZjZkk2N2lW WlZ6VGZhUmlFUGNEVU1WcmI3dlRNKzJXTzdLL2p4eElpYTgvcTBjbVNRTWhmOGc2ZlJCZCYjeEE7 MUxOeVdaVCtwdjhBMHByYmZWa09iajF0OUN0MjF3OVlIZExqdzN1RkZscU1SVmZ5TEpqdVJOMjFL dnRMY1BwYjNaSFVzazVlWGwxMyYjeEE7VjBaTmh0YzJnNURhd3d2dFlCRzBFNjlrODFjdEJvQjA4 bG91bzZuVW5xbCsxWmxYWFJXeXpPcll6THdhUWI3aStwbGRsRmJuMDNNOSYjeEE7UjgyUFBlRHJy S0hDRERwc2Z6VHhFVDY3aHM5ZHZ5NnN6ck9aVGxYMXY2YlJpVzQ5YkxYQ3JjOTFtOE9xbmE3ZHRB MUNiaUFJaUszdCYjeEE7ZGxKQmtiMnBwWkdWbGpENjVsQi9VUmJUZG1OcXlCZTc3TXdNdExXdGEz MVpCQTQ5cWVJaTRqVHA1ckRJMUk2OVc3MHE3cURQckJqMCYjeEE7R3pNYjArMzdVN0habU9mNmpt dHJ4Wkx4YjdpQTh1MjdreklJKzJkcjAyK3ErQmw3ZzNyWGY2SXM1L1VNdXUvSnJ6Y2ltKzNxcnVt cyYjeEE7YlhZNXJHVkYzb05oallHNGZUM2NveDRRUUsvUnRFdUk2MytsVG5aUFV1dmZaTUxyVnVS YlcrekljWDBWMk85TTFkUHFkNm8yZ3g3MyYjeEE7MVBKK1NrRU1kbU5meUxHWnpvU3YrUVkvdFRx T1ptWkZweU15ekh5dW9ZNW9weGJYTWY2RDI1NGEydjhBU01BM0NwcnVRbHdSaUJvTiYjeEE7djRL NDVTSjFPLzhBRm4xbnF2VWVtMlp3cXV6S2NiN0hUUzFsOXJuVzFYV2kyeGp5NFBkRGo2SmJJUGNJ WThjWlZ0ZHB5VGxHOTluUyYjeEE7ZmpabU8vcmpNVFB5Qlppdm9weHZ0T1UvWUJheWw3MjdyWEZv ZTR1TFd1N0VxTVNCNGJHL2d2TVNPS2orTHNmVnUzZXpMcGMvS0Q2YiYjeEE7UTErTm11OVN5a2xq WGJSYnVmdmE2ZHdNcUxNTnR2b3k0VHZ2OVhaVVRLcEpUNEZiMVFYOVV5OGV3TlpZTDdRM3djQTUz SG1uY1JXOCYjeEE7QWRMRXduV01GdVQ3R3VFc2EzNlJIanJNQkxpS0RFSkRpWTdTUVM3VHpIOXlO bzRVT1hRMmxyTGFpWE1lZHV2SWNQZ2taRUpFUVVndyYjeEE7NldVT3lzcXowYVdDWFBjWUEvQkxp S3VFT2QrMmVoZXB0bkoyVEhxYkJIM2MvZ2h4SzRIVnB3OExJcWJkajJtMnQrclhOSUlQNEpjUiYj eEE7VndzWDlQckZqR3k3VW5YVHdQa2x4RlhDSDEvcC93RHlmamY4VFgvMUlUVjdZU1U4M2wyL1Uw NVdWWGw2WE1PUzY4dWJlQnVzcGEzSiYjeEE7RFh4dExqUzBlMXBud1ZpSXpVSzhPMzBZSkhGWnZ4 VDI0djFhNkl3ZGZ0TDhkaExYK29MTHkwbDdReHBOUWNRZEkvTlRSTEprOVA4QSYjeEE7Qkpqamg2 a2VWVjlVeXgvVDd5V2pwVmpYdWF4OTdYVnZ6WGUwaDliZzUyODI5aVFKN0l4T1hmdit4RWhpMjdm dFNZbGYxWXlNcCtCaiYjeEE7RXZ2Yll5NGh6cnZkWmliYTJ1Ylk4dzhzMmdHQ2ZOQ1J5Z1dmNVdt SXhrMFA1VXo2cGkvVnRuVWFyK3BpTXJKTEEwRjFwWTcwbk5GWiYjeEE7c1l3K25BZThBRndpU2xD V1RoOU95Wnh4OFd1NkRxblRmcXIwNXo3T29NdGIrMEhXNzJNZmsyQ3h6d2JMZjBkVG5BZHp3akNl V1czVCYjeEE7eVd6aGlqdjE4MXMvUCtxWFY4bWhtWGEreXluYTJxMnY3Uld4djJsdGJtZzNVN0dl OGJlWEpRaGxnRFg3T2lwU3hUSXY5cW1YZlUrbiYjeEE7SnV6bU9IcTRJTnRqajZ6bS9veDZEcld0 TXRzY1BvbDdRVDVwRVppSzdxQnhBMzJVY242by9ZcW5FbjBhTGI2MlZsdC9xTnN2YTgzZyYjeEE7 MUVlcHEyeHgxRUFGS3N2RXE4Vk1NakYrcGpUajR0a0QxVzR6cVRYWmVBR3NGbFdNNDIxdWhzaXh3 QmNSUG1pSlp0VDUvd0JxakhEbyYjeEE7RjhtajZuVi9iZWxaWHVMVzQ3Y3l0N3IzdUEzajdQNzVj ZnBYZGozMTBTaWMya2g0MG9qRnJFdHZxbG4xY3duWk5QVTRCNmcxdG1TMiYjeEE7TExKYldHMXRz ZHNEdGdHMGU3VDcweUF5U3F1aTZaeHh1K3FiRjZIMC9GeUtNdkNsb3JGcCttNncyRzRWamM5NzN1 TG9GZWtvU3l5SSYjeEE7SUtZNDRnZ2gwMUd5S1NVL1BkR0MzTytzdDdiMjdxYXJyYnJQTU1lZHJm bTRnSks2UFc1bExzZkVPZG1QOUZqdUhIa3orNmliUUhBdiYjeEE7K3NmVDMwWFVVNHR0ZVZXM2ZV OTdnNFBBUHUzd2RORXJWVG5WOWF5clFHUDI3ZDI0Q0NJSSsveFNKVUF4NjMxaS9xTEthQ0dzb3Ax ZCYjeEE7V0hmU2Q0NmVYQ1JLZ0tZNG1GVjFFTlowK3U2Nnh4aHVNd1M4YVR5R3VrSUVycWIvQUV5 bnFmUkxXWFpGTnRHSGxQRlZqYm03U3l6aCYjeEE7cm5OUDNUM1NRUTlMWTMzMVJXZDBrRnZhWWNp aDlQNmYvd0FuNDMvRTEvOEFVaEJMWVNVOGJuZEN6ODZqcmxsaGVLYThqSnlNYkZiVSYjeEE7ZDkx cHhSVXg3WHo3bSs0Z0FONTdxM0hMR0pqOVB6YXNzVXBDWDEvSlhVUm5mV0NqcC9TY1RDdVl5bXQ3 c2s1MVZ1UFZ1Rlhvc0FlYSYjeEE7blNac0pHblpLSERqSmtUOWlwOFdRQ0lIMnVRM3B2V3I2M2RR T0hrTnZmYmhZMlF4MWJ3NTlkYk1ZdXNBalVOc3grZk1xWGpnTkw3LyYjeEE7QUxXTGdtZGE3ZnNk ekJ2eU9rNTc3SFl1VFhnc2RkNnRWakJZeW15NjlqR094YnRyQzV0bTdjNXZaUXlBbkhmWCtXN05F bUV0dFA1YiYjeEE7TWZyVFQxS3pxOVdWVGlXWlAySmxkbUhVeW92cnVjWEUzTnVlMzZPM2F4elow a0pZREhncTk5MVp4TGl1dG03bjFkVnpuOUJ2b0pweSYjeEE7UnZmZGM2aHptMU9kanZEaSt0eFp0 a21CdVBLWkF4angvd0F1cTZRbExoL2wwY2cvVi9PNmVNMm5GT1JiaTQrVDArTWYwd1c1TGEyNCYj eEE7NGUrUXpmN1NDVHRNYUtYM1l5cTk2UDAzWXZhTWJyYlJCbGRONmxiMGl2QmJoM2kzcG1EbFk5 enZUZEZ0bHI2dGdxSUh2bllYYVNuUiYjeEE7bkVUdTl5RVNoSXdxdGdYWHY2WmxkSjZyUjF2STlU cVQ3SFhqSyt6MG5RdnFxcnEyMHROaGlLb0prOHFJVEU0bUkwWlRBd2tKSFZvNCYjeEE7M1QrcWRO R0JUVmkzaks5REVydGhvdHhybXRlUzlsOHRpdDFJUHRkdVQ1VGpLOWROZk5ZSVNqV211am45UndP dkYvN1grd3ZjelB5ciYjeEE7RFl5dGxqOGh0UXVwc3I5U3IwL2FBM0ZFYTkreWZDZVA1YjJIOHZ6 V1RqUDVxM1A4dnlkanJOK1JtWkI2aDA3RXo2TWc0enFhclBRYyYjeEE7V1hPRGlmcytSUmJYb3oz U0hramsrQ2l4Z1JGRWpkbHlFeU5nRjZ5bmVLbWVvME5kdEc1cmVBWTFBVlk3dGdiTTBFcVNVK0Zk UGVHWiYjeEE7M1dMbWF1WllSSHdmWTc4clVSdWc3TmZyZjFrNjExL0hweDg1MVZsT0tIRmpLMkNy c0pKZ3dVa3ZPZ0d4MGpVbUkrSjBDU25wUHE3OSYjeEE7VE9yZFp5TmpoOW14YS81M0kwZEd1cmF4 K2M3OEFoYVE5M2lmNHZQcTloZ0d5bjdXOEdmVXZKZFA5alJvKzVEVlRzVmROdzhWZ1pSVSYjeEE7 eXRvNGF4b2FQd1JwVnRENno0OWVSMHdzZXplTGJSVllTWU94NE81dzAxYzB0RGg4RWdFRXZPV1hX L3N1cTcvRGxwcW4vaFlkVlA4QSYjeEE7bklxZlQrbk5zL1orSDcrS21GMmc5dzJjSUtiQlpZUThD d2d1UHRNRDJpQjk2U2w0ZHYzYnZiRWJZNytNcEtXRExBR0EyRWxwOXhnZSYjeEE7NFFmdVNVb3Nz SWVCWVFYSDJtQjdSQSs5SlNuVjczZStITTBPd2dFYmdkd2Q4b1N0U2d5d0JnTmhKYWZjWUh1RUg3 a2xLTExDSGdXRSYjeEE7Rng5cGdlMFFQdlNVdkR0KzdkN1lqYkhmeGxKU3daWUF3R3drdFB1TUQz Q0Q5eVNsRmxoRHdMQ0M0KzB3UGFJSDNwS1hoMi9kdTlzUiYjeEE7dGp2NHlrcGlHV0JyQWJKTGZw bUFOMmgrNUpTbk1zTFhodGtGeGxwZ0hhSUdubWtwSWtwU1NsSktmRE1MWlYxVE95eERhN2NoMkxZ ZSYjeEE7UGZ1TDJINXdRaXJvMSt0WW5VOHk5ODFid1pEYmF0clpudFlKYWdxMS9xOTlWYjhycVZG VnJnWFR1TFc2Z0J2MG5rNmNkdk5JcTNldiYjeEE7K3BYMVM2bmk5UmYxN3JucTQ3Nk45ZUpqdXMz YVBMcExneHhHMEE2RHVkVWt2WlBFamNkQjJDU2tMMzFqVHVQbVVsUE9mVy9ybUhnWSYjeEE7VEs3 TEFMYmI2L1RxYVJ2TzA3aWR2eWlmTkpUemxtWTM5blYyZm0vYWkveTIrdTRwSTZ2cnZULytUOGIv QUltdi9xUWtwc0pLY1BNNiYjeEE7amwxOVYrek52RlZQcVI3dGpkTmxMbzNPWS91OHFobHp6R2Jo dWhmN0I0T2hpNWZHY0hGdzJhOGU1OFdPTjFITnM2UFprK3Y2bCsrbyYjeEE7QXMyRnpkNzJOSTIr bTBBbWU4b1k4K1E0REs5ZE8zOEU1T1h4eDVnUjRmVHIzN2ViRDl1NTlWWWFXTmVXMVBlNTd4QjNO ZFlOUTF6ZSYjeEE7TmdCZ2NvZmZNa1J0MC9pdSs1WXBIZnFQMk03ZXU1YkdrdGJVNkd2SU1PaDRh YjRlMzMvUi9SQ2ZpakxuSmdkUDVYL0JiSGtZRTllbiYjeEE7MDIwL0g4SFE2YmRrMlB5cThwN1h2 cXUyZ05HMkFXc1BjblRWV2VYbE1tUWtkaTF1WWhDSWlZamNONVR0ZFNTbEpLVWtwU1NsSktVayYj eEE7cFNTbEpLVWtwOFA2VzF0dVgxR2x3RG0vYm52SU9zdzJ6c2ltT3poNGZXK3F1cCt4dHM5UzVo aXZjMFBjOERUWUNmenZCQkQ2djlUdiYjeEE7cTY3cE9INithVFpuNVFEc2g1TTdSK2JVM3liUGJ1 aHVuWnRmV1ByMk4wT2tQc0pzc3ZjRzAwQWdUdEh1andIaWtod0gvWG5JdkcybiYjeEE7RmJXVHB1 ZTdkcjhBR28wcTNsZXBmV2Y2MVkrVlBVTEE3SE13eWtlblc0ZVR4THArSlNwVGtPeUtNMjZNVEUz WjFyOXpYbnRQYzZuaiYjeEE7bVVsUFFQdzJmWVdkTzNlME05TGQ1N1hlNzc5VWxQc2ZULzhBay9H LzRtdi9BS2tKS2JDU25LeXV2TnhjeXpETkpjV1dWTUIzUklzRSYjeEE7ay9SL05rS3BrNXdRbVkx Mi9GdVl1Uk04WW5mUS9nekhYc01pZHRtcnpYRUNkME5JSDB1KzcrOU8rK1E4VnYzSEozSGRqbjU0 OVIvVCYjeEE7N3NjV050aGpmMGtidDdtTUc3YUNXZ2wrbmZRb1pzMnBnWTcrS2NHRFFURXR2RHor MWRuV1Rhd3Zyb0lpbXU4RjcydGJ0ZVMwa25XQSYjeEE7MlBqNUpEbXVJYURvQ284cHdtakxxUnMz c2E0NUdQWGVXR3MyTkR0anVSSW1GWXh5NDRndGZKRGdtUmV5Vk9XS1NVcEpTa2xLU1VwSiYjeEE7 U2tsS1NVcEpTa2xQaDJFWFluV2NzUGxqWDVMbmJpSUVmcEFlZmlqU2hJVW4rcEhSK20wZFVzNngx YTZxb1V2UDJXbDVBSmVlYkNQSyYjeEE7ZEVwQW9CRDZMWjlZK2gwMUVqTXFkQUpPMHlkUEFCRGhL ZUlQazNYT3A5UzY3MWwzVkxhbnNZdzdjZW9nK3lzSFFmRThsR2lpdzNBNCYjeEE7Ykd1Ym9TQVk3 aEtpcXczMlpOTmxQNlF0bDJqbU9najdpbFJWWVlWL1pLWjlFVnNubllBMmZ1U29xc01YVzE3Mkhj T2ZIeUtWRlZoOSYjeEE7ZzZmL0FNbjQzL0UxL3dEVWhCTFlTVTFiZW1ZTjFwdnRxM1dPSWNYUzdr Ykk3LzhBQmhSUzVmSEtWa2EveS9nelI1bkpHUENEcC9MKyYjeEE7S0ozUnNRR29VdEZiSzdXM3Vi cTR1Y3dRMEF1ZG9FdzhyRFN1aHRlT2JucmV0aWtyK21ZZGxsbHIyTzMya0Y1RDNpUzJOcGdPZ0VS cCYjeEE7Q2VlWGdTVDM4U3Nqek9TSUF2YndDbjlNd2JHZW02cjI3RzF3MXptKzJzN21qMmtjRXBI bDhaRlY0S2p6T1NKdS9IN1d3eGphMkJqWiYjeEE7aG9nYmlYSDczRWxTQVVLWXBHemJKRkNrbEtT VXBKU2tsS1NVcEpTa2xLU1VwSlQ1eC96Um96UDF0MlE5cHY4QTBwYUdnZ0YvdWpueiYjeEE7VlNY UG1KSXBqNFYvK1pHTi93QnluLzVvL3ZRLzBoTDkxUENzUHFWaUV3TXQvd0Rtais5SDcvTDkxWEN5 L3dDWStOLzNLZjhBNW8vdiYjeEE7US8waEw5MVhDci9tUGpmOXluLzVvL3ZTL3dCSVM3SzRWZjhB TWZHLzdsUC9BTTBmM3BmNlFQN3F1RlgvQURIeHYrNVQvd0ROSDk2WCYjeEE7K2tKZnVxNFdEL3FU amgxWSsxUDFkSDBSKzY0K1BrbC9wQ1g3cXVGOUE2Zi9BTW40My9FMS93RFVoWEY3WVNVcEpTa2xL U1VwSlNrbCYjeEE7S1NVcEpTa2xLU1VwSlNrbEtTVXBKU2tsS1NVOHRpdkRNR2x4NEZUUCtwQ3g1 aTVueldoZzYxMXBrR1IrN3hBODArTVFFcDhGaGR1YyYjeEE7MXVrcTFHSUlTNG4xMDZrZW45S3Nz cmNhckhXTVkxdzBJUEovSW54d2dxSWVYd1ByejFXaUEreHVRMGRuOC9lbXk1V0pROW45WHZyQiYj eEE7WDEybXgyejByS2pEbVRPaDdoVk0ySTR5cDFsRXBIWjlPcit1ZitwZWlGTzMwLzhBNVB4ditK ci9BT3BDMlV0aEpTa2xLU1VwSlNrbCYjeEE7S1NVcEpTa2xLU1VwSlNrbEtTVXBKU2tsS1NVcEpU eHU4akV4bXlXajAyNmorcUZrbjV5dENpZHRRc2VRUUJvUjQrYWRFWEpMczlOeSYjeEE7Y2R0RFlF eUorNVg0bGM4cjllTDhUT2RqNHBJSTkxcng1blFma1QxRjRxL29XTTR6VVN3K0xTaWhOOVc4KzNv M1dtWTdYNzVmNmI1NyYjeEE7Z3FMTmo0d2g5RXI2dmp1Y0dXZzFtWThRcU11WGxGTkpiTXpHSXJ0 RmcyZzdqNUF0ZUV6Z0tIb2VuLzhBSitOL3hOZi9BRklXdWxzSiYjeEE7S1VrcFNTbEpLVWtwU1Ns SktVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktlTXJHL0Z4ejRWczUrQVdRVDY1TFFqeUFYVEFEZHg3 ZVhLbCYjeEE7eGlpbHRPc3R4OGYya1R0Z1I1cXdDdUQ1VDladXFYWGRidWRVOGh0VVZ0aitTckVk bHJWbzY3bFY2UDhBZjU5MFZPMTlTNnNiTCt0TiYjeEE7R1RtdURhNmk3SWVYY1MwZTM4VTIwaDYy bkh4dW9Qc3ljYS8welplWVpNd0R4cDVKcStrVjlHWFRaanNmWXo5UFk3WThlUWU4ejVleCYjeEE7 S2dpbjBQcC8vSitOL3dBVFgvMUlVcTFzSktVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktVa3BTU2xK S1VrcFNTbEpLZUhwZEdOVC94YiYjeEE7ZnlCWXVRMU0rYXdMQzFqN0FJQVVzTWdJWEkrcmRRWmlZ bDFwT2xUQzc1eHArS21nYktyZkpySG0yeDFqOVM4bHgrYXVLV1l4cm5DQiYjeEE7eHFsYW5vK2dZ MUZWRDhxL2w3aHRIOGxuKzFRem5yU2cyUmloclRaVGErdXowM085cC9PZTZRZ01oU21kWGxPZTJ1 M0pjZHRrVW53OSYjeEE7amc1djRsSDNGVyt1OVA4QStUOGIvaWEvK3BDc3FiQ1NsSktVa3BTU2xK S1VrcFNTbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbmhLOCYjeEE7akVHTld4OTliWHRZME9hWHRC QkExQkVySHlZcG1SMEt4cnZmalNTM0lxL3oyLzNwbnM1UDNTbXc0M1dLZnRPTytsdDdITmRxUUhq VyYjeEE7UG1yR0VUaWRpaTNrN3VrNVRTZGpRNGVSQ3V4bDRKdHQ5TjZJOXhtOHRaUFl1QVRNa3ow QlFTN282TlVXQm95S1dnZHQ3Ung4MVg0NSYjeEE7MzhwUnFpUFNzeGgvUlpkQkdtam50N0g0b2lS L2RQMkp0dkhBcUdPQTdKcE54TXRPOXVoZ21lVXk4bC9LYVRiNmYwLy9BSlB4ditKciYjeEE7L3dD cEMwMXpZU1VwSlNrbEtTVXBKU2tsS1NVcEpTa2xLU1VwSlNrbEtTVXBKU2tsS1NVK0c1RjR0eTdu dUd6Zlk1M2pFa255UzkydSYjeEE7akFaTWZ6OW9uYWVISWU5NExmYzBibVgweS9DTlgyalFYTkQy a2E2RkQzL0JSbVIwUU9wQnRGVlRpL2NRR2tpSkorWlI5L3dSN25nbSYjeEE7ZmdqSHR1b3pMRFRa U1BvaHU2WGVIMGg5Nlh2K0Nqa283SUtxWE9hMis4R3JHYzhzTjBiZ0NCTVJvcE1VaE0wdTRrVlJG akxMSG5ZeCYjeEE7Z08xeEVoemhIdEhuQ25HSHhYS2VDS1dXbjZUbkdLeHp0RGQyNCtVRkwyZkZW NnZ0dlQvK1Q4Yi9BSW12L3FRcXJNMkVsS1NVcEpTayYjeEE7bEtTVXBKU2tsS1NVcEpTa2xLU1Vw SlNrbEtTVXBKU2tsUGhiR0YrV2EzNnRlOGpkNFNWRExxMVpHblE2dDA0ZE16QlJWWUxCdERnUiYj eEE7NW9hb2tLTklzakt2eXRucXZKOU51eG9QQUhnZ0JTM1ZObVY0bEdMaTNZMWszdUJOcmZBZzZK QldpTEhkWGRuc3Y2b1hHcXd6WTQ4ayYjeEE7ZVJSVjV0YTYzSnlLTGNUSDNQeEtIbTRnRDZJbmFI T1V1R2hKZkZhelpiYjlsdzk3OFN2YmM4SGtRMEN3clIzMFh4T2k0dHFPUTYreiYjeEE7MURqdGNL SzNDTndZWkJhZit0eWplcWRYMm5wLy9KK04vd0FUWC8xSVdlekw1bVZYaDBQdXRKYTFvRUVEY1M0 a05hMER1WEVnQWQwbCYjeEE7RnpzWDZ3VUhlN09JbzlTeUttaVhocmRyUkQzdGJzM2JwbUNRUEZW NWM1aEJxMnhIa3M4aGRPdUNIQU9hUVFkUVJ3UXJBTnRjaWwwbCYjeEE7S1NVcEpTa2xLU1VwSlNr bEtTVXBKU2tsS1NVcEpTa2xQaGdZOFhPY3pzNC9sVU10MnJLbVZ0anJYN3JTZHc3b0JhQlRwMnY2 Y09qMSYjeEE7TjJrNVFmN2lPNFRlcWJGZUxSR05kYlErK3RoZlZYRzUzaEtOMGlsODdxQnlzVEd4 ZGdBeGdRQ05DWlJBU0NXR2N5N3BEZlNvdUQyNSYjeEE7dERUWnQ1MnUxMm43ay9IcVVoQTAwL1pz ZG1HNTMycTB1cnVid0NIRUJvSHg3clNpZlN2RE8ycjFMS2NHdW9zdXFCcXNiT3I3U1hORyYjeEE7 bmo3a1R1RkR1KzFkUC81UHh2OEFpYS8rcENvTTdtL1dRZm9LZ2ZVSHZjV2x1clM4MVdzYTEzdWtj NmFmU2hSOHhaeFNyc3k4dFF6UiYjeEE7dnU0UFVjNjNJeE1hdjJ0cWEzMnRacHdHZ2dnSDk0Rll1 Zk1ad2lPanVjdmdqQ2NqMWQzbzlsdFhUY1Y5dHNOYUNYVnVjeHZzYzRociYjeEE7anZCZDhQY0Zx OGpmc0MzSStJVjc4cWRVWldQQkxyR05MZnBndWI3Zkk2K2FzMDFiWDlaa2wyNXV3TkIzU0kxSkhQ Q1JJQVVBU2RHTiYjeEE7bHQ1YzBZekdXQ2ZlWFAyeDhJYTZVZ1FWRUVLOVRLQmwxYkEyZFR2UEhj L1JTMFZxb1hYTmYrbll5dXZnUDN5UzRtQUlMVy9sU0pBVSYjeEE7QVNrOVZrZ1RxZU9QOWU2SEVF OEpaVDVJb1ZKOENrcGRKU2tsS1NVcEpTa2xQa0gxZmZpVTlSZTdOaDFYdUd2WStLZ25WNnRXd0ph dCYjeEE7TEtkUS9MczlNUXd2TzM0VG9nQm9pMDl1RmtVME11Y3dobG4wU2VDZ0phb3BqWG41RkdK ZGgxbmF5K04rbmduSzFESEZ4Y1c3Q3k3OCYjeEE7bXpaYlMwR29EODR6cWtTbTNPQXVCYmw3VFl5 bHdPN2thR1FDblJPcVJTN1hqUHpjbkxMbTRwaDk3QTNqY05kZ1YzRHF2WEdUWlhqdSYjeEE7c2V3 bTY2eHRsZDVKa0ZtN2RCODVVMW1sVnErNGRQOEErVDhiL2lhLytwQ29zN0xLeHFzcWwxTnpkN1hp QzBrZ2NnenB3UkVnOGhKVCYjeEE7a1Y5QWRWZTB1ZFhrME1mRG0yMUZ0amdZMUw2N0dWdWd4L2cr M2lvVHl1RW0rRm1qemVlSXJpZFE0cjNEM0d1WURmNXNqMmo4MzZhbSYjeEE7R2pDYkt6c1BjSEg5 RnZkQTNHc25RYTYrL3dBVWJSVElVUDJtc2tDV2dibXRnVEpPZzNmeFRaQ3hTNkI0VGJGK0pZOXdk NnBiRFNCRyYjeEE7NGFuZy9UMWlPNmpPSWs3c295Z0RiK1gyS0dFOEc0K3BCdUpNdEJHMGxqYTlQ ZC9KbEQyanJydi9BQXBYdkRUVGIrTnMzWTczMWVrOSYjeEE7NGtQYS9jQVJvMXdjSjkzT25LY2Na TWF0YU1nRXJBV09LNHUzN3dIOTNORWQyRS9uSDl4RDJ6M1Q3b3FxWXV4TEhrRjFzUTJJYUhORSYj eEE7L3ZRSHBIRVQxU01vSFQrWDJMbkZzZ3RGbWhBRFlCbHBCbmNDU2Z1alZJNHozUU1vN05nQUFB RGdLVmlYU1VwSlNrbEtTVStIYlhDeCYjeEE7NWJQMGorVlF5M2FwV2E0aC91RW9JSWRmTDZ2YmxZ Tk9JMkFLdS9jcG9CMktESWtVeHcrblU1V0RrNU4xb1krbHU1cmZGSzlWRFVGeSYjeEE7ZlNzZVhD a0Y0R3BBMTBUclRvdTNxRDZPblg5T2FBRzN1YTl4UElMZkJFYnAxYWR0ZUtNZkdkVTgvYUxDNFhN N05nKzM3MWF4THJiTiYjeEE7dEhVckxhT2l1WVRaUzV3WlZIQmVOeC9JckpWWTNmWmVuOVF3QmdZ d09UU0NLYTVIcU4vZEhtcVRZYkg3UTZmL0FOeWFmKzNHL3dCNiYjeEE7U2xmdERwLy9BSEpwL3dD M0cvM3BLViswT24vOXlhZiszRy8zcEtWKzBPbi9BUGNtbi90eHY5NlNsZnREcC84QTNKcC83Y2Iv QUhwSyYjeEE7ViswT24vOEFjbW4vQUxjYi9la3BYN1E2Zi8zSnAvN2NiL2VrcFg3UTZmOEE5eWFm KzNHLzNwS1YrME9uL3dEY21uL3R4djhBZWtwWCYjeEE7N1E2Zi93QnlhZjhBdHh2OTZTbGZ0RHAv L2Ntbi90eHY5NlNsZnREcC93RDNKcC83Y2IvZWtwWDdRNmYvQU55YWYrM0cvd0I2U2xmdCYjeEE7 RHAvL0FISnAvd0MzRy8zcEtWKzBPbi85eWFmKzNHLzNwS1YrME9uL0FQY21uL3R4djk2U255ejZ1 L3M5K1RlTTl6UTJIYlM0aUpsViYjeEE7OGdCT3JXRmNXcmtYWFVldThOY0kzR05lMHBBR2tBR20w N0VjM0ZibGFlbTdRR1VMMVJSYS93Qm9MR2xnY0lQSWxPcEhDbjZYMVd2cCYjeEE7ajduN1d1TnRa cmcrYVJDUllROUx4c1BPc3ZibTNOcURLM1BZNlJxNGNCRXAyY3NWUGVMTHFQYzJtQzgvdXlZQ254 a2hjbVoxYTl0eiYjeEE7OHB6eWNod0FiWVRxQ05KQitHaXRlN3BhZUYvLzJRPT08L3hhcEdJbWc6 aW1hZ2U+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHhhcFRQZzpQYWdlTnVt YmVyPjI8L3hhcFRQZzpQYWdlTnVtYmVyPgogICAgICAgICAgICAgICAgICA8eGFwR0ltZzpmb3Jt YXQ+SlBFRzwveGFwR0ltZzpmb3JtYXQ+CiAgICAgICAgICAgICAgICAgIDx4YXBHSW1nOndpZHRo PjI1NjwveGFwR0ltZzp3aWR0aD4KICAgICAgICAgICAgICAgICAgPHhhcEdJbWc6aGVpZ2h0PjI1 NjwveGFwR0ltZzpoZWlnaHQ+CiAgICAgICAgICAgICAgICAgIDx4YXBHSW1nOmltYWdlPi85ai80 QUFRU2taSlJnQUJBZ0VBU0FCSUFBRC83UUFzVUdodmRHOXphRzl3SURNdU1BQTRRa2xOQSswQUFB QUFBQkFBU0FBQUFBRUEmI3hBO0FRQklBQUFBQVFBQi8rNEFFMEZrYjJKbEFHU0FBQUFBQVFVQUFn QUQvOXNBaEFBTUNBZ0lDQWdNQ0FnTUVBc0xDeEFVRGcwTkRoUVkmI3hBO0VoTVRFeElZRkJJVUZC UVVFaFFVR3g0ZUhoc1VKQ2NuSnlja01qVTFOVEk3T3pzN096czdPenM3QVEwTEN4QU9FQ0lZR0NJ eUtDRW8mI3hBO01qc3lNakl5T3pzN096czdPenM3T3pzN096czdPenRBUUVCQVFEdEFRRUJBUUVC QVFFQkFRRUJBUUVCQVFFQkFRRUQvd0FBUkNBRUEmI3hBO0FNWURBUkVBQWhFQkF4RUIvOFFCUWdB QUFRVUJBUUVCQVFFQUFBQUFBQUFBQXdBQkFnUUZCZ2NJQ1FvTEFRQUJCUUVCQVFFQkFRQUEmI3hB O0FBQUFBQUFCQUFJREJBVUdCd2dKQ2dzUUFBRUVBUU1DQkFJRkJ3WUlCUU1NTXdFQUFoRURCQ0VT TVFWQlVXRVRJbkdCTWdZVWthR3gmI3hBO1FpTWtGVkxCWWpNMGNvTFJRd2Nsa2xQdzRmRmpjelVX b3JLREprU1RWR1JGd3FOME5oZlNWZUpsOHJPRXc5TjE0L05HSjVTa2hiU1YmI3hBO3hOVGs5S1cx eGRYbDlWWm1kb2FXcHJiRzF1YjJOMGRYWjNlSGw2ZTN4OWZuOXhFQUFnSUJBZ1FFQXdRRkJnY0hC Z0k3QVFBQ0VRTWgmI3hBO01SSUVRVkZoY1NJVEJUS0JrUlNoc1VJandWTFI4RE1rWXVGeWdwSkRV eFZqY3pUeEpRWVdvcktEQnlZMXd0SkVrMVNqRjJSRlZUWjAmI3hBO1plTHlzNFREMDNYajgwYVVw SVcwbGNUVTVQU2x0Y1hWNWZWV1puYUdscWEyeHRibTlpYzNSMWRuZDRlWHA3ZkgxK2YzLzlvQURB TUImI3hBO0FBSVJBeEVBUHdEMFBEeE9tMWROb3R1b29hMXRMQzV6bU5nZTBha3doS1FpTEtZeE1q UVkrdjhBVnp4eFB1Wi9jb3Z2T0g5NE0zM1QmI3hBO04rNlZldjhBVnp4eFB1Wi9jbDk1dy92Qlgz VE4rNlZldjlYUEhFKzVuOXlYM25EKzhGZmRNMzdwVjYvMWM4Y1Q3bWYzSmZlY1A3d1YmI3hBOzkw emZ1bHNVNDNTY2hucTBVNDlqQ1kzTlkwalQ1S1NFNHpGZ3NVNFNnYWtLU2ZzL3AvOEEzR3AvN2Ji L0FISnkxWDdQNmY4QTl4cWYmI3hBOysyMi8zSktWK3orbi93RGNhbi90dHY4QWNrcFg3UDZmL3dC eHFmOEF0dHY5eVNsZnMvcC8vY2FuL3R0djl5U2xmcy9wL3dEM0dwLzcmI3hBO2JiL2NrcFg3UDZm L0FOeHFmKzIyL3dCeVNsZnMvcC8vQUhHcC93QzIyLzNKS1YreituLzl4cWYrMjIvM0pLVit6K24v QVBjYW4vdHQmI3hBO3Y5eVNsZnMvcC84QTNHcC83YmIvQUhKS1YreituLzhBY2FuL0FMYmIvY2tw WDdQNmYvM0dwLzdiYi9ja3BYN1A2ZjhBOXhxZisyMi8mI3hBOzNKS1YreituL3dEY2FuL3R0djhB Y2twWDdQNmYvd0J4cWY4QXR0djl5U2xmcy9wLy9jYW4vdHR2OXlTbGZzL3Avd0QzR3AvN2JiL2Mm I3hBO2twcjVQVDhBWFlzWTFPdHhuOUczL1JXK1NTa09YLzRtdi9RVm4vVXRVSE4vek12SnNjbi9B RDhmTjR0Yys5SXBKU2tsS1NVOW45VnYmI3hBOytTVy8xMy9sVzM4Ty9tUTRIeFArZkxycTQwbEpL VWtwU1NsSktVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktVa3BTU2xKS1VrcHI1UDgmI3hBOzlpZjhj ZjhBejFja3BvNWYvaWEvOUJXZjlTMVFjMy9NeThteHlmOEFQeDgzaTF6NzBpa2xLU1VwSlQyZjFX LzVKYi9YZitWYmZ3NysmI3hBO1pEZ2ZFLzU4cjVHYjBabDlqTHVvK2xZMXhEMmV1VzdUNGJaMFZ4 cEkvd0JvZEIvOHRmOEEyWlAvQUpKSzFVcjlvZEIvOHRmL0FHWlAmI3hBOy9ra3JWU3YyaDBIL0FN dGYvWmsvK1NTdFZLL2FIUWYvQUMxLzltVC9BT1NTdFZLL2FIUWYvTFgvQU5tVC93Q1NTdFZLL2FI UWYvTFgmI3hBOy93Qm1ULzVKSzFVcjlvZEIvd0RMWC8yWlAva2tyVlN2MmgwSC93QXRmL1prL3dE a2tyVlRjeDhmRnlxbTM0MlZkYlUrZHIyWE9JTUcmI3hBO0RCbnhDVnFwSit6MmY2Zkkvd0MzWGYz cFdxbGZzOW4rbnlQKzNYZjNwV3FsZnM5bitueVArM1hmM3BXcWw2OEp0Ync4VzNPMjZ3NngmI3hB O3hCK0lKU1UyVWxLU1VwSlNrbE5mSi9uc1Qvamovd0NlcmtsTkhMLzhUWC9vS3ovcVdxRG0vd0Na bDVOamsvNStQbThXdWZla1VrcFMmI3hBO1NsSktleitxMy9KTGY2Ny9BTXEyL2gzOHlIQStKL3o1 Y1BxYi9xVU9vWkF6YTdqa2VvNzFTM2ZHNmRZaHl1TkpyZXA5UVA4QVIzL2YmI3hBO1ovNUpKU3ZV K29IK2p2OEF2cy84a2twWHFmVUQvUjMvQUgyZitTU1VyMVBxQi9vNy92cy84a2twWHFmVUQvUjMv ZlovNUpKU3ZVK28mI3hBO0granYrK3ovQU1ra3BYcWZVRC9SMy9mWi93Q1NTVXIxUHFCL283L3Zz LzhBSkpLZFhCK3RmMVk2ZGlzdzhRMnNwcm5hMHNjWTNFdU8mI3hBO3BQaVVsSi8rZkhRZjM3Zisy eWtwWC9Qam9QNzl2L2JaU1VyL0FKOGRCL2Z0L3dDMnlrcDBPbGRjd09zK3I5aGM1M283ZCs1dTM2 ZTYmI3hBO1ArcFNVNkNTbEpLVWtwU1NtdmsvejJKL3h4Lzg5WEpLYU9YL0FPSnIvd0JCV2Y4QVV0 VUhOL3pNdkpzY24vUHg4M2kxejcwaWtsS1MmI3hBO1VwSlQyZjFXL3dDU1cvMTMvbFczOE8vbVE0 SHhQK2ZMamRTek05bWZrTXI2emgwTkZqZzJwOWJTNWduNkxpYVhhL05YR2sxdnQvVXYmI3hBOy9M N0Ivd0MybWY4QXBCSlN2dC9Vdi9MN0IvN2FaLzZRU1VyN2YxTC9BTXZzSC90cG4vcEJKU3Z0L1V2 L0FDK3dmKzJtZitrRWxLKzMmI3hBOzlTLzh2c0gvQUxhWi93Q2tFbEsrMzlTLzh2c0gvdHBuL3BC SlN2dC9VdjhBeSt3ZisybWYra0VsSyszOVMvOEFMN0IvN2FaLzZRU1UmI3hBO3I3ZjFML3krd2Y4 QXRwbi9BS1FTVXI3ZjFML3krd2YrMm1mK2tFbEsrMzlTL3dETDdCLzdhWi82UVNVcjdmMUwvd0F2 c0gvdHBuL3AmI3hBO0JKVHBkRGQxckt5ZzluVmNiS3g2bk5PUlhUVzBFZzdvRWlsdmg0cEtlblNV cEpTa2xLU1UxOG4rZXhQK09QOEE1NnVTVTBjdi93QVQmI3hBO1gvb0t6L3FXcURtLzVtWGsyT1Qv QUorUG04V3VmZWtVa3BTU2xKS2V6K3EzL0pMZjY3L3lyYitIZnpJY0Q0bi9BRDVjYnFWR2U3UHkm I3hBO0RYMDdwZHJUWTdhKzR0OVJ3bmwvNllhL0pYR2sxdnMvVXY4QXlyNlA5N2YvQUV1a3BYMmZx WC9sWDBmNzIvOEFwZEpTdnMvVXYvS3YmI3hBO28vM3Qvd0RTNlNsZlorcGYrVmZSL3ZiL0FPbDBs Syt6OVMvOHErai9BSHQvOUxwS1Y5bjZsLzVWOUgrOXYvcGRKU3ZzL1V2L0FDcjYmI3hBO1A5N2Yv UzZTbGZaK3BmOEFsWDBmNzIvK2wwbEsrejlTL3dES3ZvLzN0LzhBUzZTbGZaK3BmK1ZmUi92Yi93 Q2wwbEsrejlTLzhxK2omI3hBOy9lMy9BTkxwS1Y5bjZsLzVWOUgrOXY4QTZYU1U3MzFhWlpXeTha R1BoNHRyaUliaGtlNXJlN29lL2d1U1U3YVNsSktVa3BTU212ay8mI3hBO3oySi94eC84OVhKS2FP WC9BT0pyL3dCQldmOEFVdFVITi96TXZKc2NuL1B4ODNpMXo3MGlrbEtTVXBKVDJmMVcvd0NTVy8x My9sVzMmI3hBOzhPL21RNEh4UCtmTHpmVnNTcC9VOHB4NkZtWkJOcmo2ekgyQnI5ZnBOQW9jSVB4 VnhwTlQ3RlYvODd1ZC93QnVXZjhBdk9rcFgyS3ImI3hBOy93Q2QzTy83Y3MvOTUwbEsreFZmL083 bmY5dVdmKzg2U2xmWXF2OEE1M2M3L3R5ei93QjUwbEsreFZmL0FEdTUzL2Jsbi92T2twWDImI3hB O0tyLzUzYzcvQUxjcy93RGVkSlN2c1ZYL0FNN3VkLzI1Wi83enBLVjlpcS8rZDNPLzdjcy85NTBs Syt4VmYvTzduZjhBYmxuL0FMenAmI3hBO0tWOWlxLzhBbmR6diszTFAvZWRKU3ZzVlgvenU1My9i bG4vdk9rcFgyS3IvQU9kM08vN2NzLzhBZWRKVDB2MVY2VmkwTWQxRm1GZGcmI3hBO1h1M1VtcTV6 bkhaTEhUN21NNUk4RWxQUXBLVWtwU1NsSkthK1QvUFluL0hIL3dBOVhKS2FPWC80bXY4QTBGWi8x TFZCemY4QU15OG0mI3hBO3h5ZjgvSHplTFhQdlNLU1VwSlNrbFBaL1ZiL2tsdjhBWGY4QWxXMzhP L21RNEh4UCtmTHpmVnN6cHJPcDVUTGVwZFFxZUxYQjFkWDAmI3hBO0dtZUcvcEJvcmpTYW4yN3BQ L2xyMVA4QTEvNjRrcFgyN3BQL0FKYTlULzEvNjRrcFgyN3BQL2xyMVA4QTEvNjRrcFgyN3BQL0FK YTkmI3hBO1QvMS82NGtwWDI3cFAvbHIxUDhBMS82NGtwWDI3cFAvQUphOVQvMS82NGtwWDI3cFAv bHIxUDhBMS82NGtwWDI3cFAvQUphOVQvMS8mI3hBOzY0a3BYMjdwUC9scjFQOEExLzY0a3BYMjdw UC9BSmE5VC8xLzY0a3BYMjdwUC9scjFQOEExLzY0a3BYMjdwUC9BSmE5VC8xLzY0a3AmI3hBO3U5 RnkrbXY2cmpNcTZqMUM1NWY3YTd2b09NSFIzdktTbnVVbEtTVXBKU2tsTmZKL25zVC9BSTQvK2Vy a2xOSEwvd0RFMS82Q3MvNmwmI3hBO3FnNXYrWmw1TmprLzUrUG04V3VmZWtVa3BTU2xKS2V6K3Ez L0FDUzMrdS84cTIvaDM4eUhBK0ovejVjYnFYVWNxdlB5SzJkZXJ4MnQmI3hBO3NjQlNhaVN6WDZN K21lRmNhVFcvYW1aLzg4bFgvYkovOUpwS1YrMU16LzU1S3Y4QXRrLytrMGxLL2FtWi93RFBKVi8y eWY4QTBta3AmI3hBO1g3VXpQL25rcS83WlAvcE5KU3YycG1mL0FEeVZmOXNuL3dCSnBLVisxTXov QU9lU3IvdGsvd0RwTkpTdjJwbWYvUEpWL3dCc24vMG0mI3hBO2twWDdVelAvQUo1S3YrMlQvd0Nr MGxLL2FtWi84OGxYL2JKLzlKcEtWKzFNei81NUt2OEF0ay8razBsSy9hbVovd0RQSlYvMnlmOEEm I3hBOzBta3BMalpYVTh5OW1OamZXR3V5MnpSclJTUk1DZTlZOEVsUFc0VmVSVGkxVlpkbnJYTmJG bGdFYmo0d2twT2twU1NsSktVa3ByNVAmI3hBOzg5aWY4Y2YvQUQxY2twbzVmL2lhL3dEUVZuL1V0 VUhOL3dBekx5YkhKL3o4Zk40dGMrOUlwSlNrbEtTVTluOVZ2K1NXL3dCZC93Q1YmI3hBO2Jmdzcr WkRnZkUvNTh1Wm05UDZ4a1p1UlppNEhUTHF6WTdhK3l0cm5uWDg4L3ZlS3VOSkQreVByQi81V2RK LzdaYWtwWDdJK3NIL2wmI3hBO1owbi9BTFpha3BYN0krc0gvbFowbi90bHFTbGZzajZ3ZitWblNm OEF0bHFTbGZzajZ3ZitWblNmKzJXcEtWK3lQckIvNVdkSi93QzImI3hBO1dwS1YreVByQi81V2RK LzdaYWtwMzhib3ZUVGoxSEs2ZmlDL1kzMVEybG0zZkEzUjdlSlNVay9ZblJ2KzRHTC9BTnNzL3dE SXBLVismI3hBO3hPamY5d01YL3Rsbi9rVWxLL1luUnY4QXVCaS85c3MvOGlrcG5WMHJwbVBZMjZq RG9xc2I5RjdLbU5jTzJoRFVsTnBKU2tsS1NVcEomI3hBO1NrbE5mSi9uc1QvamovNTZ1U1UwY3Y4 QThUWC9BS0NzL3dDcGFvT2IvbVplVFk1UCtmajV2RnJuM3BGSktVa3BTU25zL3F0L3lTMysmI3hB O3UvOEFLdHY0ZC9NaHdQaWY4K1dyYjFMck9EazVGT0YwZDFsUnRlOFdDdys4dU9yOVFZbFhHa3gv YjMxay93REtSMy9ibi9tS1NsZnQmI3hBOzc2eWYrVWp2KzNQL0FERkpTdjI5OVpQL0FDa2Qvd0J1 ZitZcEtWKzN2ckovNVNPLzdjLzh4U1VyOXZmV1QveWtkLzI1L3dDWXBLVismI3hBOzN2ckovd0NV anY4QXR6L3pGSlN2Mjk5WlAvS1IzL2JuL21LU2xmdDc2eWYrVWp2KzNQOEF6RkpTdjI5OVpQOEF5 a2QvMjUvNWlrcFgmI3hBOzdlK3NuL2xJNy90ei93QXhTVXI5dmZXVC93QXBIZjhBYm4vbUtTbGZ0 NzZ5ZitVanYrM1AvTVVsTnZwblZPczVlVUtjM3Byc1NyYVQmI3hBOzZwZnUxSEFpQWtwMkVsS1NV cEpTa2xOZkovbnNUL2pqL3dDZXJrbE5ITC84VFgvb0t6L3FXcURtL3dDWmw1TmprLzUrUG04V3Vm ZWsmI3hBO1VrcFNTbEpLZXorcTMvSkxmNjcvQU1xMi9oMzh5SEErSi96NWVaNnVlaS90VEs5ZHZV elo2cnQvcE9yMlRQNXN0bUZjYVRUbm9IN3YmI3hBO1Z2OEFPci84aWtwVTlBL2Q2dC9uVi84QWtV bEtub0g3dlZ2ODZ2OEE4aWtwVTlBL2Q2dC9uVi8rUlNVcWVnZnU5Vy96cS84QXlLU2wmI3hBO1Qw RDkzcTMrZFgvNUZKU3A2Qis3MWIvT3IvOEFJcEtWUFFQM2VyZjUxZjhBNUZKU3A2Qis3MWIvQURx Ly9JcEtWUFFQM2VyZjUxZi8mI3hBO0FKRkpTcDZCKzcxYi9Pci9BUElwS1ZQUVAzZXJmNTFmL2tV bE8xOVZzM3BsR2Y4QVpNT3ZPTDhvUVhaUllXdDlOcm4vQUpvSEtTbnImI3hBOzBsS1NVcEpTa2xO ZkovbnNUL2pqL3dDZXJrbE5ITC84VFgvb0t6L3FXcURtL3dDWmw1TmprLzUrUG04V3VmZWtVa3BT U2xKS2V6K3EmI3hBOzMvSkxmNjcvQU1xMi9oMzh5SEErSi96NWNEcW1XR2RSeVcvODRiTWFMSEQw QlZjUXpYNk10MDBWeHBOWDdhMy9BT2VlMy90bTlKU3YmI3hBO3RyZi9BSjU3ZisyYjBsSysydC8r ZWUzL0FMWnZTVXI3YTMvNTU3ZisyYjBsSysydC93RG5udC83WnZTVXI3YTMvd0NlZTMvdG05SlMm I3hBO3Z0cmYvbm50L3dDMmIwbEsrMnQvK2VlMy90bTlKU3Z0cmY4QTU1N2YrMmIwbEsrMnQvOEFu bnQvN1p2U1VyN2EzLzU1N2Y4QXRtOUomI3hBO1N2dHJmL25udC83WnZTVTdIMWM2dGgxNUQ4Vzdx N3VvMjVKWTJscnE3VzdTM2RPcnhHc3BLZW9TVXBKU2tsS1NVMThuK2V4UCtPUC8mI3hBO0FKNnVT VTBjdi94TmYrZ3JQK3Bhb09iL0FKbVhrMk9UL240K2J4YTU5NlJTU2xKS1VrcDdQNnJmOGt0L3J2 OEF5cmIrSGZ6SWNENG4mI3hBOy9QbHh1cFB6Qm41QVpmMGRyZlVkQXZOZnFBVCtmSW1WY2FUVzM1 My9BSEk2Rjk5WC9rVWxLMzUzL2Nqb1gzMWYrUlNVcmZuZjl5T2gmI3hBO2ZmVi81RkpTdCtkLzNJ NkY5OVgvQUpGSlN0K2Qvd0J5T2hmZlYvNUZKU3QrZC8zSTZGOTlYL2tVbEszNTMvY2pvWDMxZitS U1VyZm4mI3hBO2Y5eU9oZmZWL3dDUlNVcmZuZjhBY2pvWDMxZitSU1VyZm5mOXlPaGZmVi81RkpT dCtkLzNJNkY5OVgva1VsSzM1My9jam9YMzFmOEEmI3hBO2tVbE9qMFhHNnJibDFaSi9abHVNeHhG ajhSckM0R09BNXJlZFFrcDZoSlNrbEtTVXBKVFh5ZjU3RS80NC93RG5xNUpUUnkvL0FCTmYmI3hB OytnclArcGFvT2IvbVplVFk1UDhBbjQrYnhhNTk2UlNTbEpLVWtwN1A2cmY4a3QvcnYvS3R2NGQv TWh3UGlmOEFQbHh1cGRPeXJNL0kmI3hBO3NaMEd2SWE2eHhGeHRJTDlmcFI2ZzVWeHBOYjlsNW4v QU03ZFgvYngvd0RTaVNsZnN2TS8rZHVyL3Q0LytsRWxLL1plWi84QU8zVi8mI3hBOzI4Zi9BRW9r cFg3THpQOEE1MjZ2KzNqL0FPbEVsSy9aZVovODdkWC9BRzhmL1NpU2xmc3ZNLzhBbmJxLzdlUC9B S1VTVXI5bDVuL3omI3hBO3QxZjl2SC8wb2twWDdMelAvbmJxL3dDM2ovNlVTVXI5bDVuL0FNN2RY L2J4L3dEU2lTbGZzdk0vK2R1ci90NC8rbEVsSy9aZVovOEEmI3hBO08zVi8yOGYvQUVva3BYN0x6 UDhBNTI2diszai9BT2xFbFBUL0FGZnhmc3ZUZzEySTNBZTk3bnZvYTR1QVAwWmtsM0lhRWxPa2tw U1MmI3hBO2xKS1VrcHI1UDg5aWY4Y2YvUFZ5U21qbC93RGlhLzhBUVZuL0FGTFZCemY4ekx5YkhK L3o4Zk40dGMrOUlwSlNrbEtTVTluOVZ2OEEmI3hBO2tsdjlkLzVWdC9EdjVrT0I4VC9ueWd5L3Fa MGpOeWJjdTQzZXBjNHZkdGVBSlBoN1ZjYVNML21IMFB4di93QThmK1FTVXIvbUgwUHgmI3hBO3Yv engvd0NRU1VyL0FKaDlEOGIvQVBQSC9rRWxLLzVoOUQ4Yi93RFBIL2tFbEsvNWg5RDhiLzhBUEgv a0VsSy81aDlEOGIvODhmOEEmI3hBO2tFbEsvd0NZZlEvRy93RHp4LzVCSlN2K1lmUS9HLzhBengv NUJKVE9qNms5R3g3Njc2emR2cWMxN1plSWxwa2ZtcEtlZ1NVcEpTa2wmI3hBO0tTVXBKU2tsS1NV cEpUWHlmNTdFL3dDT1AvbnE1SlRSeS84QXhOZitnclArcGFvT2IvbVplVFk1UCtmajV2RnJuM3BG SktVa3BTU24mI3hBO3MvcXQvd0FrdC9ydi9LdHY0ZC9NaHdQaWY4K1VlVmQ5Ym01Tmd3Nk1OMUFj ZlNOaGR1TGUyNkxCcXJqU1JldjlkLzhBdVBnZmUvOEEmI3hBOzlLSktVYi9ydDJ4OEg3My9BUHBS SlN2WCt1Ly9BSEh3UHZmL0FPbEVsSzlmNjcvOXg4RDczLzhBcFJKU3ZYK3Uvd0QzSHdQdmYvNlUm I3hBO1NVcjEvcnYvQU54OEQ3My9BUHBSSlN2WCt1Ly9BSEh3UHZmL0FPbEVsT2gwcXpyYi9WL2JO ZEZjYmZTK3prbWZwYnQyNXp2SkpUb0omI3hBO0tVa3BTU2xKS1VrcFNTbEpLVWtwU1NtdmsvejJK L3h4L3dEUFZ5U21qbC8rSnIvMEZaLzFMVkJ6Zjh6THliSEovd0EvSHplTFhQdlMmI3hBO0tTVXBK U2tsUFovVmIva2x2OWQvNVZ0L0R2NWtPQjhUL255NjZ1TkpTU2xKS1VrcFNTbEpLVWtwU1NsSktV a3BTU2xKS1VrcFNTbEomI3hBO0tVa3BTU2xKS2ErVC9QWW4vSEgvQU05WEpLYU9YLzRtdi9RVm4v VXRVSE4vek12SnNjbi9BRDhmTjR0Yys5SXBKU2tsS1NVOW45VnYmI3hBOytTVy8xMy9sVzM4Ty9t UTRIeFArZkxycTQwbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktVa3BTU2xKS1Vr cHI1UDgmI3hBOzlpZjhjZjhBejFja3BvNWYvaWEvOUJXZjlTMVFjMy9NeThteHlmOEFQeDgzaTF6 NzBpa2xLU1VwSlQyZjFXLzVKYi9YZitWYmZ3NysmI3hBO1pEZ2ZFLzU4dXVyalNVa3BTU2xKS1Vr cFNTbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbEpLVWtwU1NtdmsvejJKL3h4L3dEUFZ5U20mI3hB O2psLytKci8wRlovMUxWQnpmOHpMeWJISi93QS9IemVMWFB2U0tTVXBKU2tsUFovVmIva2x2OWQv NVZ0L0R2NWtPQjhUL255NjZ1TkomI3hBO1NTbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbEpLVWtw U1NsSktVa3BTU2xKS2ErVC9QWW4vSEgvQU05WEpLYU9YLzRtdi9RVm4vVXQmI3hBO1VITi96TXZK c2NuL0FEOGZONHRjKzlJcEpTa2xLU1U5bjlWditTVy8xMy9sVzM4Ty9tUTRIeFArZkxycTQwbEpL VWtwU1NsSktVa3AmI3hBO1NTbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbEpLVWtwcjVQODlpZjhj ZjhBejFja3BvNWYvaWEvOUJXZjlTMVFjMy9NeThteHlmOEEmI3hBO1B4ODNpMXo3MGlrbEtTVXBK VDJmMVcvNUpiL1hmK1ZiZnc3K1pEZ2ZFLzU4dXVyalNVa3BTU2xKS1VrcFNTbEpLVWtwU1NsSktV a3AmI3hBO1NTbEpLVWtwU1NsSktVa3BTU212ay96MkoveHgvd0RQVnlTbWpsLytKci8wRlovMUxW QnpmOHpMeWJISi93QS9IemVMWFB2U0tTVXAmI3hBO0pTa2xQWi9WYi9rbHY5ZC81VnQvRHY1a09C OFQvbnk0M1V1bzVWZWZrVnM2OVhqdGJZNENrMUVsbXYwWjlNOEs0MG10KzFNei93Q2UmI3hBO1Ny L3RrLzhBcE5KU3YycG1mL1BKVi8yeWYvU2FTbGZ0VE0vK2VTci9BTFpQL3BOSlN2MnBtZjhBenlW Zjlzbi9BTkpwS1YrMU16LzUmI3hBOzVLdisyVC82VFNVOWgwNjMxc0RIdDlVWkJkVzJiZ0lEeUJE blJBNUtTbXlrcFNTbEpLVWtwU1NsSktVa3BTU2xKS1VrcFNTbXZrL3omI3hBOzJKL3h4LzhBUFZ5 U21qbC8rSnIvQU5CV2Y5UzFRYzMvQURNdkpzY24vUHg4M2kxejcwaWtsS1NVcEpUMmYxVy81SmIv QUYzL0FKVnQmI3hBOy9EdjVrT0I4VC9ueTQzVW1aaHo4Z3NvNk81dnFPZzNpdjFDSi9Qa3pLdU5K cmJNNy91UDBMN3F2L0pKS1haUjFHeDRycnhlaHZjNHcmI3hBOzFyVzFFaytRQlNVMlAyUjlZUDhB eXM2VC93QnN0U1VyOWtmV0QveXM2VC8yeTFKU1hHNlIxazVGUXl1bWRMRkc5dnFsdExOMnlSdWom I3hBO3poSlQxRlZWVk5iYXFXTnJyWUlheGdEV2dlUUNTbWFTbEpLVWtwU1NsSktVa3BTU2xKS1Vr cFNTbEpLYStUL1BZbi9ISC96MWNrcG8mI3hBOzVmOEE0bXYvQUVGWi93QlMxUWMzL015OG14eWY4 L0h6ZUxYUHZTS1NVcEpTa2xQWi9WYi9BSkpiL1hmK1ZiZnc3K1pEZ2ZFLzU4dUImI3hBOzFURUQr bzVMditiMW1UTmpqNjR0dUFmcjlLRzZhcTQwbXI5aWIvOEFPeGIvQU52WHBLU1k5Tm1MZlhrNC93 QldiV1cxT0QyTzlXNHcmI3hBO1J4b1pDU25XL3dDY24xaS84bzdmdmQvNlRTVXIvbko5WXY4QXlq dCs5My9wTkpTditjbjFpLzhBS08zNzNmOEFwTkpUMHJTUzBFaUMmI3hBO1FDUjRKS1hTVXBKU2ts S1NVcEpTa2xLU1VwSlNrbEtTVXBKVFh5ZjU3RS80NC84QW5xNUpUUnkvL0UxLzZDcy82bHFnNXY4 QW1aZVQmI3hBO1k1UCtmajV2RnJuM3BGSktVa3BTU25zL3F0L3lTMyt1L3dES3R2NGQvTWh3UGlm OCtYWFZ4cEtTVXBKU2tsS1NVcEpTa2xLU1VwSlMmI3hBO2tsS1NVcEpTa2xLU1VwSlNrbEtTVXBK VFh5ZjU3RS80NC84QW5xNUpUUnkvL0UxLzZDcy82bHFnNXY4QW1aZVRZNVArZmo1dkZybjMmI3hB O3BGSktVa3BTU25zL3F0L3lTMyt1L3dES3R2NGQvTWh3UGlmOCtYWFZ4cEtTVXBKU2tsS1NVcEpT a2xLU1VwSlNrbEtTVXBKU2tsS1MmI3hBO1VwSlNrbEtTVXBKVFh5ZjU3RS80NC84QW5xNUpUUnkv L0UxLzZDcy82bHFnNXY4QW1aZVRZNVArZmo1dkZybjNwRkpLVWtwU1Nucy8mI3hBO3F0L3lTMyt1 L3dES3R2NGQvTWh3UGlmOCtYVmU5ckFTNHhBTHZrT1ZjYVRKSlNrbEtTVXBKU2tsS1NVcEpTa2xL U1VwSlNrbEtTVXAmI3hBO0pTa2xLU1VwSlNrbE5mSi9uc1QvQUk0LytlcmtsTkhML3dERTEvNkNz LzZscWc1ditabDVOamsvNStQbThXdWZla1VrcFNTbEpLZXkmI3hBOytxNWpwRFNCTVBmb08vM3Ji K0hmekljRDRuL1BsRDFmSnN1eW1ZRG5taWh3bDdpU0pJRzk3WGVucVExc2FUN3QydWcxbXo1ZUNn T3ImI3hBO0R5K0QzTEoySFR6UjlQNjljT3BIQnlIL0FHaXB6eXhsdTBOZFBBMGJ5UHhWYkR6Y3Zk NFNiRGN6OGpIMmVPSW85bm9LM2l4b2VBUUQmI3hBO3FOd0xUOXgxSHpWOXpGeVFOVHAyKzlKU3pu c1lKZTROQjBCSmhKVEg3UmpuaTFuK2NFbE1nOXBKYUNDUnlBVWxNa2xLU1VwSlNrbEsmI3hBO1NV cEpTa2xLU1VwSlNrbEtTVTE4bitleFArT1AvbnE1SlRSeS93RHhOZjhBb0t6L0FLbHFnNXYrWmw1 TmprLzUrUG04V3VmZWtVa3AmI3hBO1NTbEpLZXorcSt2U1dnL3Z2L0t0djRkL01od1BpZjhBUGxI MWZvd3Z0R1hqTWFMQnJZMGV6Y0dHUTRPSTI3eHVQUFBqcEtzWnNNY28mI3hBO290ZkJubGhsWTY3 b2VsZElGZGxtWGRSYzI5cmkxdGIvQUV3V2s3VDZudHVlMC9TMDE3ZUtodzhuSEhQaUp0c1orZmxs aHdnVTZYMmEmI3hBO3hyeVdlcXd2UHVjellKSWgyNTN1NzdkdkN0dEZJRzJEZHZGa0Y5Wkc4Z3Qr bVBvdzV4N0lLWVcwWFdBaDFZc0V1Z1dBUGJxNXUzMmwmI3hBOytzQ2ZCUmVzZnkvdFovMVozL2wr Qy9vMlBCQm9yQUxZSUxXa2NPM0Q2UTBPaU56UldNTW5VVE5yS1JYY1hRWEFORGkyWjVhNFNEOFUm I3hBO1R4RUlIQ0NvRExiWVg3TnpURU5KRWdickovT2pqYW0rc0grWGl1UHRrZnk4RndjMlQ3R2dl N3RNNnUyNitwNFFqYy81Zjc2S3gveS8mI3hBOzNrakhYbXdCekExc0dlSkVhQ0lKNWxFR1ZyU0ln Sms5WXBKU2tsS1NVcEpTa2xLU1VwSlRYeWY1N0UvNDQvOEFucTVKVFJydjZkbDkmI3hBO0hxeFg1 VlRCWlF4cEllMlI3UjVwbVhHTWtESHV2eFpEam1KZG5OLzV2OUcvOHNXLzV6UDcxUi8wWEQ5NHVo L3BhZjdvVi96ZjZOLzUmI3hBO1l0L3ptZjNwZjZMaCs4VmY2V24rNkZmODMramYrV0xmODVuOTZY K2k0ZnZGWCtscC91aFgvTi9vMy9saTMvT1ovZWwvb3VIN3hWL3AmI3hBO2FmN29kYnBydW05TnhS aXN6S25nRXVsejJBNi9OWE1HRVlZY0lhWE1aem1ueEVOazUvVG5BdGRrMGtIUWd2YkJIM3FWaFgv YUhULysmI3hBOzVOUC9BRzQzKzlKU3YyaDAvd0Q3azAvOXVOL3ZTVXI5b2RQUE9UVC9BTnVOL3ZT VXI5b2RQLzdrMC84QWJqZjcwbEsvYUhUL0FQdVQmI3hBO1QvMjQzKzlKU3YyaDAvOEE3azAvOXVO L3ZTVXI5b2RQL3dDNU5QOEEyNDMrOUpTdjJoMC8vdVRUL3dCdU4vdlNVcjlvZFA4QSs1TlAmI3hB Oy9iamY3MGxLL2FIVC93RHVUVC8yNDMrOUpTdjJoMC8vQUxrMC93RGJqZjcwbEsvYUhULys1TlAv QUc0Mys5SlN2MmgwL3dEN2swLzkmI3hBO3VOL3ZTVXI5b2RQL0FPNU5QL2JqZjcwbEsvYUhULzhB dVRUL0FOdU4vdlNVcjlvZFAvN2swLzhBYmpmNzBsSy9hSFQvQVB1VFQvMjQmI3hBOzMrOUpUWHll b1lCdXhZeWFkTGpQNlJ2K2l0ODBsUDhBLzlrPTwveGFwR0ltZzppbWFnZT4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC94YXA6UGFnZUlu Zm8+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wL21tLyIKICAgICAgICAgICAgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIKICAgICAgICAgICAgeG1sbnM6c3RSZWY9Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiPgogICAgICAgICA8eGFw TU06SW5zdGFuY2VJRD51dWlkOmViYTZjMmU5LTk5YjctNGYxOC04NDYwLWY4ZjBjNDE4MjE1NTwv eGFwTU06SW5zdGFuY2VJRD4KICAgICAgICAgPHhhcE1NOkRvY3VtZW50SUQ+eG1wLmRpZDo5QTE0 OTM2QjYwMjM2ODExODA4M0JENzVDMkU0NjcwRTwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAg PHhhcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD54bXAuZGlkOjAxODAxMTc0MDcyMDY4MTE5OERCODY2 RkQ5MEYwRjNCPC94YXBNTTpPcmlnaW5hbERvY3VtZW50SUQ+CiAgICAgICAgIDx4YXBNTTpSZW5k aXRpb25DbGFzcz5wcm9vZjpwZGY8L3hhcE1NOlJlbmRpdGlvbkNsYXNzPgogICAgICAgICA8eGFw TU06SGlzdG9yeT4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGkg cmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9u PmNyZWF0ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNl SUQ+eG1wLmlpZDowMTgwMTE3NDA3MjA2ODExOThEQjg2NkZEOTBGMEYzQjwvc3RFdnQ6aW5zdGFu Y2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAwOS0wNC0wMVQxMToxMTozMi0w NDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+ QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICA8 L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowMjgwMTE3NDA3MjA2ODEx OThEQjg2NkZEOTBGMEYzQjwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OndoZW4+MjAwOS0wNC0wMVQxMToyMTo1OS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpz b2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vPC9zdEV2dDpj aGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSBy ZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+ c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+ eG1wLmlpZDowMzgwMTE3NDA3MjA2ODExOThEQjg2NkZEOTBGMEYzQjwvc3RFdnQ6aW5zdGFuY2VJ RD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAwOS0wNC0wMVQxMToyMTo1OS0wNDow MDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRv YmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6Y2hhbmdlZD4vbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwv cmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA0ODAxMTc0MDcyMDY4MTE5 OERCODY2RkQ5MEYwRjNCPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6d2hlbj4yMDA5LTA0LTAxVDExOjIyOjI1LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA2LjA8L3N0RXZ0OnNv ZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNo YW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5z YXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54 bXAuaWlkOjA1ODAxMTc0MDcyMDY4MTE5OERCODY2RkQ5MEYwRjNCPC9zdEV2dDppbnN0YW5jZUlE PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDA5LTA0LTAxVDExOjIzOjAyLTA0OjAw PC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9i ZSBJbkRlc2lnbiA2LjA8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA2ODAxMTc0MDcyMDY4MTE5OERCODY2RkQ5 MEYwRjNCPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4y MDA5LTA0LTAxVDExOjI5OjExLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA2LjA8L3N0RXZ0OnNvZnR3YXJlQWdl bnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAg ICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5 cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RF dnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA3 ODAxMTc0MDcyMDY4MTE5OERCODY2RkQ5MEYwRjNCPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDA5LTA0LTAxVDExOjMwOjIxLTA0OjAwPC9zdEV2dDp3 aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2ln biA2LjA8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFu Z2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAg ICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA4ODAxMTc0MDcyMDY4MTE5OERCODY2RkQ5MEYwRjNCPC9z dEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDA5LTA0LTAx VDExOjMxOjMxLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29m dHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA2LjA8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi88L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAg ICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291 cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9u PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjA5ODAxMTc0MDcy MDY4MTE5OERCODY2RkQ5MEYwRjNCPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6d2hlbj4yMDA5LTA0LTAxVDExOjMzOjI2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA2LjA8L3N0 RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi9tZXRh ZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6MEE4MDExNzQwNzIwNjgxMTk4REI4NjZGRDkwRjBGM0I8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDQtMDFU MTE6MzM6MjYtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6Rjc3RjExNzQwNzIw NjgxMTkyQjA5NjQ2NDI2REE1MkU8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMDktMDQtMDFUMTE6MzQ6NTUtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RF dnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0 aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5j ZUlEPnhtcC5paWQ6NzQxMTdGRjMyMDA3MTE2ODhENjdEMDIzMThFNjYzQUQ8L3N0RXZ0Omluc3Rh bmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMDhUMTQ6MjE6MDIt MDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50 PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmNoYW5nZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo3NDExN0ZGNDIwMDcx MTY4OEQ2N0QwMjMxOEU2NjNBRDwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAwOS0wNS0wOFQxNDoyMTowMi0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRh ZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6NzQxMTdGRjUyMDA3MTE2ODhENjdEMDIzMThFNjYzQUQ8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMDhU MTQ6NDU6MTUtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MzRDQ0JBQzYyMDFF MTE2ODhENjdEMDIzMThFNjYzQUQ8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMDktMDUtMDhUMTQ6NTE6NDktMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RF dnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0 aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5j ZUlEPnhtcC5paWQ6RUJGNzNGQjYyMERFMTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0RXZ0Omluc3Rh bmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMTNUMTM6MjQ6MjEt MDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50 PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmNoYW5nZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpFQkY3M0ZCNzIwREUx MTY4QkJGRkM3NEZDODdBRDIwMTwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAwOS0wNS0xM1QxMzoyNDoyMS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRh ZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6RUJGNzNGQjgyMERFMTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMTNU MTM6MzU6MzQtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6RUJGNzNGQjkyMERF MTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMDktMDUtMTNUMTM6Mzc6MjMtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDpFQkY3M0ZCQTIwREUxMTY4QkJGRkM3NEZDODdBRDIwMTwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAwOS0wNS0xM1Qx MzozNzoyMy0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NDI4 NzFEOEUyMEY2MTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMTNUMTQ6MDg6MTQtMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6NDI4NzFEOTAyMEY2MTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMDktMDUtMTNU MTQ6MTA6MDYtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NDI4NzFEOTEyMEY2 MTE2OEJCRkZDNzRGQzg3QUQyMDE8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMDktMDUtMTNUMTQ6MTA6MjEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDYuMDwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDo0Mjg3MUQ5MjIwRjYxMTY4QkJGRkM3NEZDODdBRDIwMTwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAwOS0wNS0xM1Qx NDoxMDoyMi0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpGNzdGMTE3NDA3MjA2 ODExQTIwMEI3QkUxNUJFQ0YxQzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAxMC0wMy0zMFQxNDoxMjozNi0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vPC9zdEV2 dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjps aSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rp b24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNl SUQ+eG1wLmlpZDpGNzdGMTE3NDA3MjA2ODExQjlFN0JEOEUxNzcxMEVGNTwvc3RFdnQ6aW5zdGFu Y2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMC0wMy0zMVQxMDoyOToxOC0w NDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+ QWRvYmUgSW5EZXNpZ24gNi4wPC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6Y2hhbmdlZD4vbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAg IDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNl Ij4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkY4N0YxMTc0MDcyMDY4 MTFCOUU3QkQ4RTE3NzEwRUY1PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6d2hlbj4yMDEwLTAzLTMxVDEwOjI5OjE4LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA2LjA8L3N0RXZ0 OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDpGRTdGMTE3NDA3MjA2ODExODA4M0ExNzA0QzRCMUU5Qzwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wNi0yN1Qx NTo1OToyMC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6RkY3 RjExNzQwNzIwNjgxMTgwODNBMTcwNEM0QjFFOUM8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDYtMjdUMTU6NTk6MjAtMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAg ICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowMDgwMTE3NDA3MjA2ODExODA4M0ExNzA0QzRC MUU5Qzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAx MS0wNi0yN1QxNTo1OTozNS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50 PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hh bmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRm OnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNh dmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnht cC5paWQ6QkExOUU3N0MwNzIwNjgxMTgwODNBMTcwNEM0QjFFOUM8L3N0RXZ0Omluc3RhbmNlSUQ+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDYtMjdUMTU6NTk6MzUtMDQ6MDA8 L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2Jl IEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OmNoYW5nZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3Jk ZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpDMjE5RTc3QzA3MjA2ODExODA4 M0ExNzA0QzRCMUU5Qzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OndoZW4+MjAxMS0wNi0yN1QxNjowMTozMi0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0 d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwv c3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxy ZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0 YW5jZUlEPnhtcC5paWQ6MEEyNTQyNTYwODIwNjgxMTgwODNBMTcwNEM0QjFFOUM8L3N0RXZ0Omlu c3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDYtMjdUMTY6MDU6 NDAtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFn ZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAg ICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJl c291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0 aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkRGMzVBOTY5 MEIyMDY4MTE4MDgzQTE3MDRDNEIxRTlDPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6d2hlbj4yMDExLTA2LTI3VDE2OjI3OjQxLTA0OjAwPC9zdEV2dDp3aGVuPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8 L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87 L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAg ICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpFNjM1QTk2OTBCMjA2ODExODA4M0ExNzA0QzRCMUU5 Qzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0w Ni0yN1QxNjoyODoxOC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50Pgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdl ZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBh cnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVk PC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5p aWQ6MEVCM0FEQTEwQjIwNjgxMTgwODNBMTcwNEM0QjFFOUM8L3N0RXZ0Omluc3RhbmNlSUQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDYtMjdUMTY6Mjk6MTUtMDQ6MDA8L3N0 RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIElu RGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRm OmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjBGQjNBREExMEIyMDY4MTE4MDgz QTE3MDRDNEIxRTlDPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 d2hlbj4yMDExLTA2LTI3VDE2OjU4OjU5LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3 YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9z dEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJk ZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDph Y3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3Rh bmNlSUQ+eG1wLmlpZDowNjgwMTE3NDA3MjA2ODExOEMxNEFCN0RCMUU4QThBQTwvc3RFdnQ6aW5z dGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wNi0yOVQxMjo0NTo0 OS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdl bnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAg ICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVz b3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rp b24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MDE4MDExNzQw NzIwNjgxMThDMTRDMkYwNkJFNzcyNDA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDFUMTI6NDQ6NDgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwv c3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+L21l dGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAg ICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowNzgwMTE3NDA3MjA2ODExOEMxNEMyRjA2QkU3NzI0MDwv c3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0w MVQxMjo0NDo0OC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNv ZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4K ICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNl VHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9z dEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6 MDg4MDExNzQwNzIwNjgxMThDMTRDMkYwNkJFNzcyNDA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDFUMTI6NDY6MjctMDQ6MDA8L3N0RXZ0 OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVz aWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNo YW5nZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4K ICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo5Nzc2MTRBRjA3MjA2ODExOEMxNEMyRjA2 QkU3NzI0MDwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+ MjAxMS0wOC0wMVQxMjo0NjoyNy0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFn ZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6 Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkg cmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9u PnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlE PnhtcC5paWQ6OUU3NjE0QUYwNzIwNjgxMThDMTRDMkYwNkJFNzcyNDA8L3N0RXZ0Omluc3RhbmNl SUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDFUMTM6MTk6MDctMDQ6 MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFk b2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAg IDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNl Ij4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkYwRjAyM0ZCMjMyMDY4 MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjE3OjU3LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0 OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDo2NzdGQkZGQjJFMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1Qx MzoyMTozOC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MUFB QkM5MDUyRjIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6MjE6NTUtMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjIyQUJDOTA1MkYyMDY4MTE4MDgzQzFBMkU5 QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4y MDExLTA4LTAzVDEzOjIyOjM2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdl bnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpj aGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSBy ZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+ c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+ eG1wLmlpZDo5NUUwQ0UyMjJGMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJ RD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzoyMjo0My0wNDow MDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRv YmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAg PC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2Ui PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NTY1NjQxNjcyRjIwNjgx MTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6MjQ6MzgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6 c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRh dGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAg ICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 aW5zdGFuY2VJRD54bXAuaWlkOjQ5QThFRjc1MkYyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2 dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEz OjI1OjAzLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdh cmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAg ICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBl PSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0 OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo0QUE4 RUY3NTJGMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzoyNToxNC0wNDowMDwvc3RFdnQ6d2hl bj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24g Ny41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdl ZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NEJBOEVGNzUyRjIwNjgxMTgwODNDMUEyRTlB N0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIw MTEtMDgtMDNUMTM6MjU6MTgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2Vu dD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNo YW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5z YXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54 bXAuaWlkOjk0N0UxNENDMkYyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlE PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjI3OjI3LTA0OjAw PC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9i ZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8 L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo5NTdFMTRDQzJGMjA2ODEx ODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzoyNzozNy0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpz b2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0 YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAg IDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpp bnN0YW5jZUlEPnhtcC5paWQ6NTdCMDk3RkMyRjIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0 Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6 Mjg6NDktMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2Fy ZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAg ICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9 IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6 YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjAxQTU2 OTI0MzAyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjI5OjU2LTA0OjAwPC9zdEV2dDp3aGVu PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3 LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2Vk Pi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAg ICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpGRjRCMkYzRTMwMjA2ODExODA4M0MxQTJFOUE3 QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAx MS0wOC0wM1QxMzozMDozOS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50 PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hh bmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRm OnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNh dmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnht cC5paWQ6M0U2OENENEEzMDIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6MzEtMDQ6MDA8L3N0 RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIElu RGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRm OmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjcyNEEwNDZFMzAyMDY4MTE4MDgz QzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 d2hlbj4yMDExLTA4LTAzVDEzOjMxOjU5LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3 YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9z dEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJk ZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDph Y3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3Rh bmNlSUQ+eG1wLmlpZDpEOEM1ODhBMDMwMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5z dGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzozMzoy NC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdl bnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAg ICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVz b3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rp b24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6Q0U2NEIwQUUz MDIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6MzM6NDgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwv c3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzsv bWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAg ICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjc2REIwQkMzMzAyMDY4MTE4MDgzQzFBMkU5QTdDMEU3 PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4 LTAzVDEzOjM0OjIyLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2Vk PgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFy c2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8 L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlp ZDo3N0RCMEJDMzMwMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzozNTowNC0wNDowMDwvc3RF dnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5E ZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6 bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NzhEQjBCQzMzMDIwNjgxMTgwODND MUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3 aGVuPjIwMTEtMDgtMDNUMTM6MzU6MjEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdh cmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0 RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRm OmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFj dGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFu Y2VJRD54bXAuaWlkOkRCRjk3QTBBMzEyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0 YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjM2OjIy LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2Vu dD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAg ICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNv dXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlv bj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpDOUIwMTgyOTMx MjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzozNzoxMy0wNDowMDwvc3RFdnQ6d2hlbj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9z dEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9t ZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAg ICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MTUyOTk4MzIzMTIwNjgxMTgwODNDMUEyRTlBN0MwRTc8 L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgt MDNUMTM6Mzc6MjktMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpz b2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+ CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJz ZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwv c3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlk OkJBNEM0RDRFMzEyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjM4OjE1LTA0OjAwPC9zdEV2 dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRl c2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpj aGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjps aT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpCQjRDNEQ0RTMxMjA2ODExODA4M0Mx QTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Ondo ZW4+MjAxMS0wOC0wM1QxMzozODozMC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2Fy ZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RF dnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0 aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5j ZUlEPnhtcC5paWQ6NjVCODA5NkMzMTIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3Rh bmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6Mzk6MDUt MDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50 PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAg ICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291 cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9u PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkVFQjlFRkI3MzEy MDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjQxOjEzLTA0OjAwPC9zdEV2dDp3aGVuPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0 RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21l dGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAg ICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpDRkJCQTZCQzMxMjA2ODExODA4M0MxQTJFOUE3QzBFNzwv c3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0w M1QxMzo0MToyMS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNv ZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4K ICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNl VHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9z dEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6 RDBCQkE2QkMzMTIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6NDE6MzAtMDQ6MDA8L3N0RXZ0 OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVz aWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNo YW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxp PgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjgxNzhCRUQwMzEyMDY4MTE4MDgzQzFB MkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hl bj4yMDExLTA4LTAzVDEzOjQxOjU0LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJl QWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2 dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjps aSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rp b24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNl SUQ+eG1wLmlpZDo4Mjc4QkVEMDMxMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFu Y2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzo0MjozNy0w NDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+ QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NDJFMzlBMjIzMjIw NjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTM6NDQ6MTItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0 YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAg ICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6aW5zdGFuY2VJRD54bXAuaWlkOjQzRTM5QTIyMzIyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9z dEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAz VDEzOjQ1OjMwLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29m dHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgog ICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VU eXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0 RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDoz MzNBQjI1RTMyMjA2ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzo0NTo1Mi0wNDowMDwvc3RFdnQ6 d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNp Z24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hh bmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+ CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MzQzQUIyNUUzMjIwNjgxMTgwODNDMUEy RTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVu PjIwMTEtMDgtMDNUMTM6NDY6MjEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVB Z2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0 OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxp IHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlv bj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJ RD54bXAuaWlkOkNFQUE2N0E5MzIyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5j ZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDEzOjQ3OjU4LTA0 OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5B ZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDoyNjRDRThCQjMyMjA2 ODExODA4M0MxQTJFOUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAxMS0wOC0wM1QxMzo0ODoyOS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRh ZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6ODBDREE5RUUzNjIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNU MTQ6MTg6MzItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAg ICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5 cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RF dnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjU3 MkM3MjA5MzcyMDY4MTE4MDgzQzFBMkU5QTdDMEU3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTAzVDE0OjE5OjE3LTA0OjAwPC9zdEV2dDp3 aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2ln biA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFu Z2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4K ICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo2OTI3QjAwRjM3MjA2ODExODA4M0MxQTJF OUE3QzBFNzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+ MjAxMS0wOC0wM1QxNDoxOToyOC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFn ZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6 Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkg cmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9u PnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlE PnhtcC5paWQ6NzRFNDBBMzMzNzIwNjgxMTgwODNDMUEyRTlBN0MwRTc8L3N0RXZ0Omluc3RhbmNl SUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDNUMTQ6MjA6MjctMDQ6 MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFk b2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAg IDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNl Ij4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkJFQzYxMjc0MDcyMDY4 MTE4QzE0QzAzMEEyRjVEM0Q3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6d2hlbj4yMDExLTA4LTA1VDA4OjEzOjE0LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0 OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDpCRkM2MTI3NDA3MjA2ODExOEMxNEMwMzBBMkY1RDNENzwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wNVQw ODoxNjoxMC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6QzJC NjE0NDMxQzIwNjgxMThDMTRDMDMwQTJGNUQzRDc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDVUMTA6NDI6MTItMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkRCQzM2QTkxMUMyMDY4MTE4QzE0QzAzMEEy RjVEM0Q3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4y MDExLTA4LTA1VDEwOjQ0OjIzLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdl bnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpj aGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSBy ZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+ c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+ eG1wLmlpZDo5RUYzNTU5NzFDMjA2ODExOEMxNEMwMzBBMkY1RDNENzwvc3RFdnQ6aW5zdGFuY2VJ RD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wNVQxMDo0NDozMy0wNDow MDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRv YmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAg PC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2Ui PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6OUZGMzU1OTcxQzIwNjgx MThDMTRDMDMwQTJGNUQzRDc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDp3aGVuPjIwMTEtMDgtMDVUMTA6NDU6MTItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6 c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRh dGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAg ICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 aW5zdGFuY2VJRD54bXAuaWlkOkZDMjZDN0VDMUMyMDY4MTE4QzE0QzAzMEEyRjVEM0Q3PC9zdEV2 dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTA1VDEw OjQ2OjU2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdh cmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAg ICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBl PSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0 OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo3NDgx MEUyMTFEMjA2ODExOEMxNEMwMzBBMkY1RDNENzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0wNVQxMDo0ODoyNC0wNDowMDwvc3RFdnQ6d2hl bj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24g Ny41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdl ZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6NzU4MTBFMjExRDIwNjgxMThDMTRDMDMwQTJG NUQzRDc8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIw MTEtMDgtMDVUMTA6NDg6NTEtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2Vu dD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNo YW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5z YXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54 bXAuaWlkOjc2ODEwRTIxMUQyMDY4MTE4QzE0QzAzMEEyRjVEM0Q3PC9zdEV2dDppbnN0YW5jZUlE PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTA1VDEwOjQ4OjU5LTA0OjAw PC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9i ZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8 L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDowN0VCN0UzQTFEMjA2ODEx OEMxNEMwMzBBMkY1RDNENzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OndoZW4+MjAxMS0wOC0wNVQxMDo0OTowNy0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpz b2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0 YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAg IDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpp bnN0YW5jZUlEPnhtcC5paWQ6NUU3RTY5M0YxRDIwNjgxMThDMTRDMDMwQTJGNUQzRDc8L3N0RXZ0 Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDVUMTA6 NDk6MTUtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2Fy ZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAg ICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9 IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6 YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkVCQjhD OEQwMUUyMDY4MTE4QzE0QzAzMEEyRjVEM0Q3PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4LTA1VDExOjAwOjI5LTA0OjAwPC9zdEV2dDp3aGVu PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3 LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2Vk Pi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAg ICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpDNzgzMDBBRjIxMjA2ODExOEMxNEMwMzBBMkY1 RDNENzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAx MS0wOC0wNVQxMToyMS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50Pgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdl ZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBh cnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVk PC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5p aWQ6MDI4MDExNzQwNzIwNjgxMThDMTRFREQzMEE1MzdFNTM8L3N0RXZ0Omluc3RhbmNlSUQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDhUMTQ6Mjg6NTQtMDQ6MDA8L3N0 RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIElu RGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OmNoYW5nZWQ+L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjps aT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo4MUQ1MURBMjFEMjA2ODExOEMxNEVE RDMwQTUzN0U1Mzwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Ondo ZW4+MjAxMS0wOC0wOFQxNDoyODo1NC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2Fy ZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RF dnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6 bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0 aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5j ZUlEPnhtcC5paWQ6NTBGNDhBQkMyMjIwNjgxMThDMTRFREQzMEE1MzdFNTM8L3N0RXZ0Omluc3Rh bmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDhUMTU6MDU6MjYt MDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50 PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAg ICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291 cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9u PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjUyNUIzRTkwMkUy MDY4MTE4QzE0RUREMzBBNTM3RTUzPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6d2hlbj4yMDExLTA4LTA4VDE2OjMwOjA1LTA0OjAwPC9zdEV2dDp3aGVuPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0 RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21l dGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAg ICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpGMUM2MUYzNzJGMjA2ODExOEMxNEVERDMwQTUzN0U1Mzwv c3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0w OFQxNjozNDo0NS0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNv ZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4K ICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNl VHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9z dEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6 ODE3MjdDQ0EzMTIwNjgxMThDMTRFREQzMEE1MzdFNTM8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDhUMTY6NTM6MTEtMDQ6MDA8L3N0RXZ0 OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVz aWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNo YW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxp PgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjgyNzI3Q0NBMzEyMDY4MTE4QzE0RURE MzBBNTM3RTUzPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hl bj4yMDExLTA4LTA4VDE2OjU2OjUxLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJl QWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi9tZXRhZGF0YTwvc3RFdnQ6 Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkg cmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9u PnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlE PnhtcC5paWQ6NUMyNzcwNEQzMjIwNjgxMThDMTRFREQzMEE1MzdFNTM8L3N0RXZ0Omluc3RhbmNl SUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMDhUMTY6NTY6NTEtMDQ6 MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFk b2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAg IDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNl Ij4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjU2Q0IxMzc0MDcyMDY4 MTE4QzE0RTU5ODgxMDAwODQ4PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6d2hlbj4yMDExLTA4LTEwVDEwOjA5OjE4LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0 OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDoxRjZDQzQzNzA4MjA2ODExOEMxNEU1OTg4MTAwMDg0ODwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0xMFQx MDoxNDo0Ni0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6QzRF Qzk2MkUxMTIwNjgxMThDMTRFNTk4ODEwMDA4NDg8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMTBUMTE6MTg6NTYtMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjE2MUNCRjE4MzUyMDY4MTE4QzE0RTU5ODgx MDAwODQ4PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4y MDExLTA4LTEwVDE1OjM2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFu Z2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6 cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2 ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1w LmlpZDpBNkE1NDY3RDM5MjA2ODExOEMxNEU1OTg4MTAwMDg0ODwvc3RFdnQ6aW5zdGFuY2VJRD4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0xMFQxNjowNzoyNi0wNDowMDwv c3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUg SW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RF dnQ6Y2hhbmdlZD4vbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRm OmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkE4NjY0QTdEMzkyMDY4MTE4QzE0 RTU5ODgxMDAwODQ4PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 d2hlbj4yMDExLTA4LTEwVDE2OjA3OjI2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3 YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9z dEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJk ZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDph Y3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3Rh bmNlSUQ+eG1wLmlpZDpBOTY2NEE3RDM5MjA2ODExOEMxNEU1OTg4MTAwMDg0ODwvc3RFdnQ6aW5z dGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0xMFQxNjoxOTow Ny0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdl bnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAg ICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVz b3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rp b24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6REU4QkFBNTIz MzIwNjgxMTgwODNDNTdFQTVENDQ4RTg8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDp3aGVuPjIwMTEtMDgtMTFUMTY6MzU6MDctMDQ6MDA8L3N0RXZ0OndoZW4+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwv c3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzsv bWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAg ICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOkJGN0JFNEEyMzQyMDY4MTE4MDgzQzU3RUE1RDQ0OEU4 PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA4 LTExVDE2OjQ0OjMxLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2Vk PgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFy c2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8 L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlp ZDo1QzZCMTM3NDA3MjA2ODExODA4M0VGMjAwRDJCMkE0MTwvc3RFdnQ6aW5zdGFuY2VJRD4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOC0xOFQxMzoyMjo1MS0wNDowMDwvc3RF dnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5E ZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6 bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6OEZEQzk1OUEwNzIwNjgxMTgwODNF RjIwMEQyQjJBNDE8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3 aGVuPjIwMTEtMDgtMThUMTM6MjM6NTYtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdh cmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0 RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRm OmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFj dGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFu Y2VJRD54bXAuaWlkOjAxODAxMTc0MDcyMDY4MTE4MDgzRkJBMjQ4RkU4ODkwPC9zdEV2dDppbnN0 YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA5LTE5VDEyOjU5OjEx LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2Vu dD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDpjaGFuZ2VkPi9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MDkwRjE0NzQwNzIw NjgxMTgwODNGQkEyNDhGRTg4OTA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMTEtMDktMTlUMTI6NTk6MTItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0 YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAg ICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6aW5zdGFuY2VJRD54bXAuaWlkOkQ0NEI5QzY0MTAyMDY4MTE4MDgzRkJBMjQ4RkU4ODkwPC9z dEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA5LTE5 VDE0OjAzOjExLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29m dHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgog ICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VU eXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0 RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDow MTM4MzQ4RDEwMjA2ODExODA4M0ZCQTI0OEZFODg5MDwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMS0wOS0xOVQxNDowNDoxOS0wNDowMDwvc3RFdnQ6 d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNp Z24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hh bmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+ CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MjJDNzVDQjYxMDIwNjgxMTgwODNGQkEy NDhGRTg4OTA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVu PjIwMTEtMDktMTlUMTQ6MDU6MjgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVB Z2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0 OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxp IHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlv bj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJ RD54bXAuaWlkOjE0Q0M0RDZBMjIyMDY4MTE4MDgzRkJBMjQ4RkU4ODkwPC9zdEV2dDppbnN0YW5j ZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA5LTE5VDE2OjEyOjExLTA0 OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5B ZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAg ICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJj ZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo4N0M0NjdBQTIyMjA2 ODExODA4M0ZCQTI0OEZFODg5MDwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OndoZW4+MjAxMS0wOS0xOVQxNjoxMzo1OC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2 dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRh ZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAg ICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDppbnN0YW5jZUlEPnhtcC5paWQ6RDRDNTU5Q0IyMjIwNjgxMTgwODNGQkEyNDhGRTg4OTA8L3N0 RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTEtMDktMTlU MTY6MTQ6NTMtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0 d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAg ICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5 cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RF dnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjM2 QTVBOEQ5MjIyMDY4MTE4MDgzRkJBMjQ4RkU4ODkwPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTA5LTE5VDE2OjE1OjE3LTA0OjAwPC9zdEV2dDp3 aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2ln biA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFu Z2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4K ICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpFRDdGMTE3NDA3MjA2ODExODcxRkRENEQ1 MEIxNTUyMTwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+ MjAxMS0xMi0zMFQxNTowNzoyOC0wNTowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAg PHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFn ZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vbWV0YWRhdGE8L3N0RXZ0OmNo YW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJk ZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5z YXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54 bXAuaWlkOjI1NkExNTc0MDcyMDY4MTE4NzFGREQ0RDUwQjE1NTIxPC9zdEV2dDppbnN0YW5jZUlE PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDExLTEyLTMwVDE1OjA3OjI4LTA1OjAw PC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9i ZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8 L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDo4RkZERjQwNDA4MjA2ODEx ODcxRkUyMURBMkY0RUEyMDwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OndoZW4+MjAxMi0wNC0wMlQxMDozOTozOC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpz b2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0 YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAg IDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpp bnN0YW5jZUlEPnhtcC5paWQ6MDhDNTE5NTYwQzIwNjgxMTg3MUZGMkM5MDJFRDJDN0U8L3N0RXZ0 Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTItMDUtMDRUMTQ6 MjE6NDgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2Fy ZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAg ICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9 IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6 YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjEyQzUx OTU2MEMyMDY4MTE4NzFGRjJDOTAyRUQyQzdFPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6d2hlbj4yMDEyLTA1LTA0VDE0OjUwOjA2LTA0OjAwPC9zdEV2dDp3aGVu PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3 LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2Vk Pi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAg ICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlpZDpBOEQ3MTk3NDA3MjA2ODExOEMxNEMyQkNGNEI0 OTczMjwvc3RFdnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAx Mi0wNS0wN1QwOToyMToxNy0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50 PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hh bmdlZD4KICAgICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRm OnBhcnNlVHlwZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNh dmVkPC9zdEV2dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnht cC5paWQ6MTc1QzlGQUY0MDIwNjgxMTgwODNCRDc1QzJFNDY3MEU8L3N0RXZ0Omluc3RhbmNlSUQ+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTItMDUtMTBUMTY6NDk6MjAtMDQ6MDA8 L3N0RXZ0OndoZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2Jl IEluRGVzaWduIDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0 RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwv cmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAg ICAgICAgICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjFFQzYxOTc0MDcyMDY4MTE4 MDgzQTg2Rjc4NEU2NDUwPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6d2hlbj4yMDEyLTA1LTE0VDA5OjM5OjQ5LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNv ZnR3YXJlQWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRh PC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAg PHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omlu c3RhbmNlSUQ+eG1wLmlpZDoxNUFFNjMyMzA5MjA2ODExODA4M0E4NkY3ODRFNjQ1MDwvc3RFdnQ6 aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMi0wNS0xNFQwOTo1 MTo1My0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJl QWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAg ICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0i UmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDph Y3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6REU1MEZD MzQwOTIwNjgxMTgwODNBODZGNzg0RTY0NTA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDp3aGVuPjIwMTItMDUtMTRUMDk6NTI6MjItMDQ6MDA8L3N0RXZ0OndoZW4+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcu NTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+ LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAg ICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAg ICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjYyMDVCMTZEMTMyMDY4MTE4MDgzQTg2Rjc4NEU2 NDUwPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDEy LTA1LTE0VDExOjA1OjMyLTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RF dnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFu Z2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6 cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2 ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1w LmlpZDo1NzNFOTI5NDIwMjA2ODExODA4M0E4NkY3ODRFNjQ1MDwvc3RFdnQ6aW5zdGFuY2VJRD4K ICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMi0wNS0xNFQxMjozOTo0MS0wNDowMDwv c3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUg SW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RF dnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAgICAgPC9y ZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgog ICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6M0E0RUIxNjUyMTIwNjgxMTgw ODNBODZGNzg0RTY0NTA8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2 dDp3aGVuPjIwMTItMDUtMTRUMTI6NDU6MzItMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RFdnQ6c29m dHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+LzsvbWV0YWRhdGE8 L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAgICAgICAgICA8 cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6aW5z dGFuY2VJRD54bXAuaWlkOjc5MzRDQUMwMEMyMTY4MTE4MDgzQkQ3NUMyRTQ2NzBFPC9zdEV2dDpp bnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDEyLTA1LTE0VDE1OjQy OjE2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6c29mdHdhcmVB Z2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAgICAgICAgICAg ICAgICAgIDxzdEV2dDpjaGFuZ2VkPi9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAg ICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVz b3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rp b24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MjZGNzBGRjg1 QjIzNjgxMTgwODNCRDc1QzJFNDY3MEU8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAg ICAgIDxzdEV2dDp3aGVuPjIwMTItMDUtMTRUMTU6NDI6MTYtMDQ6MDA8L3N0RXZ0OndoZW4+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwv c3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+Lzsv bWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgogICAgICAg ICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAgICAgICAg ICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjdCODJGNkIwNUQyMzY4MTE4MDgzQkQ3NUMyRTQ2NzBF PC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4yMDEyLTA1 LTE0VDE1OjU0OjM2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdlbnQ+CiAg ICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpjaGFuZ2Vk PgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaSByZGY6cGFy c2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rpb24+c2F2ZWQ8 L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNlSUQ+eG1wLmlp ZDo3QzgyRjZCMDVEMjM2ODExODA4M0JENzVDMkU0NjcwRTwvc3RFdnQ6aW5zdGFuY2VJRD4KICAg ICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMi0wNS0xNFQxNTo1Nzo1NC0wNDowMDwvc3RF dnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+QWRvYmUgSW5E ZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAgICA8c3RFdnQ6 Y2hhbmdlZD4vbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxp PgogICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg ICAgICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAg ICAgICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjY5QjcwNzI3NUUyMzY4MTE4MDgzQkQ3 NUMyRTQ2NzBFPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hl bj4yMDEyLTA1LTE0VDE1OjU3OjU0LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJl QWdlbnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2 dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjps aSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDphY3Rp b24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0Omluc3RhbmNl SUQ+eG1wLmlpZDo2QUI3MDcyNzVFMjM2ODExODA4M0JENzVDMkU0NjcwRTwvc3RFdnQ6aW5zdGFu Y2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMi0wNS0xNFQxNjowNDo1MS0w NDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3YXJlQWdlbnQ+ QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAgICAgICAgICAg ICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAgICAgICAgICAg ICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlwZT0iUmVzb3Vy Y2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2dDphY3Rpb24+ CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MzEzRjYwNUI2MDIz NjgxMTgwODNCRDc1QzJFNDY3MEU8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAgICAgICAgICAg IDxzdEV2dDp3aGVuPjIwMTItMDUtMTRUMTY6MTQ6MDgtMDQ6MDA8L3N0RXZ0OndoZW4+CiAgICAg ICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWduIDcuNTwvc3RF dnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5nZWQ+L21ldGFk YXRhPC9zdEV2dDpjaGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAg ICAgPHJkZjpsaSByZGY6cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgICAgICAgIDxz dEV2dDphY3Rpb24+c2F2ZWQ8L3N0RXZ0OmFjdGlvbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0 Omluc3RhbmNlSUQ+eG1wLmlpZDo5QTE0OTM2QjYwMjM2ODExODA4M0JENzVDMkU0NjcwRTwvc3RF dnQ6aW5zdGFuY2VJRD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OndoZW4+MjAxMi0wNS0xNFQx NjoxNDowOC0wNDowMDwvc3RFdnQ6d2hlbj4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OnNvZnR3 YXJlQWdlbnQ+QWRvYmUgSW5EZXNpZ24gNy41PC9zdEV2dDpzb2Z0d2FyZUFnZW50PgogICAgICAg ICAgICAgICAgICA8c3RFdnQ6Y2hhbmdlZD4vOy9tZXRhZGF0YTwvc3RFdnQ6Y2hhbmdlZD4KICAg ICAgICAgICAgICAgPC9yZGY6bGk+CiAgICAgICAgICAgICAgIDxyZGY6bGkgcmRmOnBhcnNlVHlw ZT0iUmVzb3VyY2UiPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6YWN0aW9uPnNhdmVkPC9zdEV2 dDphY3Rpb24+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDppbnN0YW5jZUlEPnhtcC5paWQ6MDA4 MDExNzQwNzIwNjgxMTgyMkFCNjlDQTI5MEM2OTk8L3N0RXZ0Omluc3RhbmNlSUQ+CiAgICAgICAg ICAgICAgICAgIDxzdEV2dDp3aGVuPjIwMTItMDUtMTVUMTc6NTM6NDEtMDQ6MDA8L3N0RXZ0Ondo ZW4+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpzb2Z0d2FyZUFnZW50PkFkb2JlIEluRGVzaWdu IDcuNTwvc3RFdnQ6c29mdHdhcmVBZ2VudD4KICAgICAgICAgICAgICAgICAgPHN0RXZ0OmNoYW5n ZWQ+LzsvbWV0YWRhdGE8L3N0RXZ0OmNoYW5nZWQ+CiAgICAgICAgICAgICAgIDwvcmRmOmxpPgog ICAgICAgICAgICAgICA8cmRmOmxpIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAgICAg ICAgICAgICAgPHN0RXZ0OmFjdGlvbj5zYXZlZDwvc3RFdnQ6YWN0aW9uPgogICAgICAgICAgICAg ICAgICA8c3RFdnQ6aW5zdGFuY2VJRD54bXAuaWlkOjBBODAxMTc0MDcyMDY4MTE4MDgzRDBDN0ZE MDM3QTcxPC9zdEV2dDppbnN0YW5jZUlEPgogICAgICAgICAgICAgICAgICA8c3RFdnQ6d2hlbj4y MDEyLTA1LTE2VDExOjIzOjU2LTA0OjAwPC9zdEV2dDp3aGVuPgogICAgICAgICAgICAgICAgICA8 c3RFdnQ6c29mdHdhcmVBZ2VudD5BZG9iZSBJbkRlc2lnbiA3LjU8L3N0RXZ0OnNvZnR3YXJlQWdl bnQ+CiAgICAgICAgICAgICAgICAgIDxzdEV2dDpjaGFuZ2VkPi87L21ldGFkYXRhPC9zdEV2dDpj aGFuZ2VkPgogICAgICAgICAgICAgICA8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgog ICAgICAgICA8L3hhcE1NOkhpc3Rvcnk+CiAgICAgICAgIDx4YXBNTTpEZXJpdmVkRnJvbSByZGY6 cGFyc2VUeXBlPSJSZXNvdXJjZSI+CiAgICAgICAgICAgIDxzdFJlZjppbnN0YW5jZUlEPnhtcC5p aWQ6MzEzRjYwNUI2MDIzNjgxMTgwODNCRDc1QzJFNDY3MEU8L3N0UmVmOmluc3RhbmNlSUQ+CiAg ICAgICAgICAgIDxzdFJlZjpkb2N1bWVudElEPnhtcC5kaWQ6NjlCNzA3Mjc1RTIzNjgxMTgwODNC RDc1QzJFNDY3MEU8L3N0UmVmOmRvY3VtZW50SUQ+CiAgICAgICAgICAgIDxzdFJlZjpvcmlnaW5h bERvY3VtZW50SUQ+eG1wLmRpZDowMTgwMTE3NDA3MjA2ODExOThEQjg2NkZEOTBGMEYzQjwvc3RS ZWY6b3JpZ2luYWxEb2N1bWVudElEPgogICAgICAgICAgICA8c3RSZWY6cmVuZGl0aW9uQ2xhc3M+ ZGVmYXVsdDwvc3RSZWY6cmVuZGl0aW9uQ2xhc3M+CiAgICAgICAgIDwveGFwTU06RGVyaXZlZEZy b20+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIgogICAgICAgICAgICB4bWxuczppZFByaXY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veG1w L0luRGVzaWduL3ByaXZhdGUiPgogICAgICAgICA8aWRQcml2OkRvY0NoYW5nZUNvdW50PjM3MDI8 L2lkUHJpdjpEb2NDaGFuZ2VDb3VudD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRp b24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFkb2JlIFBERiBMaWJy YXJ5IDkuOTwvcGRmOlByb2R1Y2VyPgogICAgICAgICA8cGRmOlRyYXBwZWQ+RmFsc2U8L3BkZjpU cmFwcGVkPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6RkExPSJodHRwOi8vbnMuSW5zaWRlclNvZnR3 YXJlLmNvbS9mb250bGlzdC8xLjAvIj4KICAgICAgICAgPEZBMTpQb3N0c2NyaXB0TmFtZT4KICAg ICAgICAgICAgPHJkZjpCYWc+CiAgICAgICAgICAgICAgIDxyZGY6bGk+Q2hhcGFycmFsUHJvLUJv bGQ8L3JkZjpsaT4KICAgICAgICAgICAgICAgPHJkZjpsaT5DaGFwYXJyYWxQcm8tUmVndWxhcjwv cmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpPk9mZmljaW5hU2VyaWYtQm9vazwvcmRmOmxp PgogICAgICAgICAgICA8L3JkZjpCYWc+CiAgICAgICAgIDwvRkExOlBvc3RzY3JpcHROYW1lPgog ICAgICAgICA8RkExOlByb2ZpbGVCbG9iPgogICAgICAgICAgICA8cmRmOkJhZz4KICAgICAgICAg ICAgICAgPHJkZjpsaT5BQUFEcEFBQUFBTEwyVDdNQUFBQUFISnpibVlBQUFPVUNFU2hRZ0FBQUEx bGJXRnVnQUFBcGpNR20yQUFBQUFBQW04U0FBQUFBQkVDYndBTkFRRUFBQUFBQWg0QUJBSUJBQUFB QUFJR0FCd0RBUUFBQUFBQ2J3QVNCQUVBQUFBQUFTNEFPZ1VCQUFBQUFBSVJBQkVHQVFBQUFBQUNn UUFOQ1FFQUFBQUFBbFlBR1FzQkFBQUFBQUlpQUJvQkF3QUJCQWtCbUFBSUFnTUFBUVFKQVdnQU9B TURBQUVFQ1FGK0FDSUVBd0FCQkFrQXVnQjBCUU1BQVFRSkFYNEFJZ1lEQUFFRUNRR2dBRFFJQXdB QkJBa0NQQUFhQ1FNQUFRUUpBZFFBTWdzREFBRUVDUUJXQUdVQWNnQnpBR2tBYndCdUFDQUFNZ0F1 QURBQU5BQTBBRHNBVUFCVEFDQUFNZ0F1QURBQU1BQXdBRHNBYUFCdkFIUUFZd0J2QUc0QWRnQWdB REVBTGdBd0FDNEFOUUEzQURzQWJRQmhBR3NBWlFCdkFIUUFaZ0F1QUd3QWFRQmlBRElBTGdBd0FD NEFNZ0F4QURnQU9RQTFWbVZ5YzJsdmJpQXlMakEwTkR0UVV5QXlMakF3TUR0b2IzUmpiMjUySURF dU1DNDFOenR0WVd0bGIzUm1MbXhwWWpJdU1DNHlNVGc1TlFBeUFDNEFNQUEwQURRQU93QkJBRVFB UWdCRkFEc0FRd0JvQUdFQWNBQmhBSElBY2dCaEFHd0FVQUJ5QUc4QUxRQkNBRzhBYkFCa0FFRUFa QUJ2QUdJQVpRQWdBRk1BZVFCekFIUUFaUUJ0QUhNQUlBQkpBRzRBWXdCdkFISUFjQUJ2QUhJQVlR QjBBR1VBWkFCb0FIUUFkQUJ3QURvQUx3QXZBSGNBZHdCM0FDNEFZUUJrQUc4QVlnQmxBQzRBWXdC dkFHMEFMd0IwQUhrQWNBQmxNaTR3TkRRN1FVUkNSVHREYUdGd1lYSnlZV3hRY204dFFtOXNaQUJE QUdnQVlRQndBR0VBY2dCeUFHRUFiQUFnQUZBQWNnQnZBRU1BWVFCeUFHOEFiQUFnQUZRQWR3QnZB RzBBWWdCc0FIbG9kSFJ3T2k4dmQzZDNMbUZrYjJKbExtTnZiUzkwZVhCbFEyaGhjR0Z5Y21Gc0lG QnlieUJDYjJ4a1EyRnliMndnVkhkdmJXSnNlUUFBWm5sc1p3QUFBQVVBQVZlTitxNXloUUFBQUFB Z2VIUnRBQUFBQlFBQURHQ3oydkYvQUFBQUFIaHRabVlBQUFBRkFBQUNGbkNyc05rQUFBQUFJQ0J0 WWdBQUFBVUFBQUFBLy8vLy93QUFBQUIwYm1adUFBQUFCUUFBQUFELy8vLy9BQUFBQUNCamJtVUFB QUFHQUFBT1J2L1RCQUVBQUFBQUFBRC8vMjVsY25BQUFBQUZBQUFJVzBCWGdXSUFBQUFBZVdGc1lR QUFBQVVBQUh6d1Y0cUh1Z0FBQUFCdWNtVnJBQUFBQlFBQUFBRC8vLy8vQUFBQUFHNXlhMllBQUFB RkFBQlhpRStjMEdZQUFBQUFlV0ZzZHdBQUFBVUFBQUFJQzFQSTJnQUFBQUFnZEcxbUFBQUFBMDlV VkU4PTwvcmRmOmxpPgogICAgICAgICAgICAgICA8cmRmOmxpPkFBQURxQUFBQUFMTDJUN01BQUFB QUhKemJtWUFBQU9ZT3ZkckJRQUFBQTFsYldGdWdBQUFwMFJUT2tvQUFBQUFBbmdOQUFBQUFCRUNl QUFOQVFFQUFBQUFBaVFBQndJQkFBQUFBQUlNQUI4REFRQUFBQUFDZUFBTkJBRUFBQUFBQVd3QU9n VUJBQUFBQUFJWEFCUUdBUUFBQUFBQ2hRQU5DUUVBQUFBQUFsOEFHUXNCQUFBQUFBSXJBQm9CQXdB QkJBa0JYZ0FPQWdNQUFRUUpBUzRBUGdNREFBRUVDUUZFQUNnRUF3QUJCQWtBdWdCMEJRTUFBUVFK QVVRQUtBWURBQUVFQ1FHbUFEUUlBd0FCQkFrQ1JRQWFDUU1BQVFRSkFkb0FNZ3NEQUFFRUNRQldB R1VBY2dCekFHa0Fid0J1QUNBQU1nQXVBREFBTkFBMEFEc0FVQUJUQUNBQU1nQXVBREFBTUFBd0FE c0FhQUJ2QUhRQVl3QnZBRzRBZGdBZ0FERUFMZ0F3QUM0QU5RQTNBRHNBYlFCaEFHc0FaUUJ2QUhR QVpnQXVBR3dBYVFCaUFESUFMZ0F3QUM0QU1nQXhBRGdBT1FBMUFESUFMZ0F3QURRQU5BQTdBRUVB UkFCQ0FFVUFPd0JEQUdnQVlRQndBR0VBY2dCeUFHRUFiQUJRQUhJQWJ3QXRBRklBWlFCbkFIVUFi QUJoQUhKV1pYSnphVzl1SURJdU1EUTBPMUJUSURJdU1EQXdPMmh2ZEdOdmJuWWdNUzR3TGpVM08y MWhhMlZ2ZEdZdWJHbGlNaTR3TGpJeE9EazFBRUVBWkFCdkFHSUFaUUFnQUZNQWVRQnpBSFFBWlFC dEFITUFJQUJKQUc0QVl3QnZBSElBY0FCdkFISUFZUUIwQUdVQVpBQm9BSFFBZEFCd0FEb0FMd0F2 QUhjQWR3QjNBQzRBWVFCa0FHOEFZZ0JsQUM0QVl3QnZBRzBBTHdCMEFIa0FjQUJsTWk0d05EUTdR VVJDUlR0RGFHRndZWEp5WVd4UWNtOHRVbVZuZFd4aGNnQkRBR2dBWVFCd0FHRUFjZ0J5QUdFQWJB QWdBRkFBY2dCdkFFTUFZUUJ5QUc4QWJBQWdBRlFBZHdCdkFHMEFZZ0JzQUhsb2RIUndPaTh2ZDNk M0xtRmtiMkpsTG1OdmJTOTBlWEJsUTJoaGNHRnljbUZzSUZCeWIwTmhjbTlzSUZSM2IyMWliSGtB QUdaNWJHY0FBQUFGQUFGV0ErQ0tmdmNBQUFBQUlIaDBiUUFBQUFVQUFBeGlBbWZ5andBQUFBQjRi V1ptQUFBQUJRQUFBaGFlcTdoMEFBQUFBQ0FnYldJQUFBQUZBQUFBQVAvLy8vOEFBQUFBZEc1bWJn QUFBQVVBQUFBQS8vLy8vd0FBQUFBZ1kyNWxBQUFBQmdBQURrYi8wd1FCQUFBQUFBQUEvLzl1WlhK d0FBQUFCUUFBQ0Y0UmFBdjZBQUFBQUhsaGJHRUFBQUFGQUFCOXhLSHdZMTRBQUFBQWJuSmxhd0FB QUFVQUFBQUEvLy8vL3dBQUFBQnVjbXRtQUFBQUJRQUFhY0R1TmllR0FBQUFBSGxoYkhjQUFBQUZB QUFBQ0F0VHlOb0FBQUFBSUhSdFpnQUFBQU5QVkZSUDwvcmRmOmxpPgogICAgICAgICAgICAgICA8 cmRmOmxpLz4KICAgICAgICAgICAgPC9yZGY6QmFnPgogICAgICAgICA8L0ZBMTpQcm9maWxlQmxv Yj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFj a2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag14cmVmDQowIDM2MTcNCjAwMDAwMDAwMDMg NjU1MzUgZg0KMDAwMDAwODUyNiAwMDAwMCBuDQowMDAwMDA4NjUyIDAwMDAwIG4NCjAwMDAwMDAw MDQgMDAwMDAgZg0KMDAwMDAwMDAwNiAwMDAwMCBmDQowMDAwMDA5MDQ5IDAwMDAwIG4NCjAwMDAw MDAwMDcgMDAwMDAgZg0KMDAwMDAwMDAwOCAwMDAwMCBmDQowMDAwMDAwMDA5IDAwMDAwIGYNCjAw MDAwMDAwMTAgMDAwMDAgZg0KMDAwMDAwMDAxMSAwMDAwMCBmDQowMDAwMDAwMDEyIDAwMDAwIGYN CjAwMDAwMDAwMTQgMDAwMDAgZg0KMDAwMDAwOTYwMyAwMDAwMCBuDQowMDAwMDAwMDE2IDAwMDAw IGYNCjAwMDAwMDk5ODEgMDAwMDAgbg0KMDAwMDAwMDAxOCAwMDAwMCBmDQowMDAwMDEwMzU5IDAw MDAwIG4NCjAwMDAwMDAwMjAgMDAwMDAgZg0KMDAwMDAxMDczNyAwMDAwMCBuDQowMDAwMDAwMDIy IDAwMDAwIGYNCjAwMDAwMTExMTUgMDAwMDAgbg0KMDAwMDAwMDAyNCAwMDAwMCBmDQowMDAwMDEx NDkzIDAwMDAwIG4NCjAwMDAwMDAwMjUgMDAwMDAgZg0KMDAwMDAwMDAzMCAwMDAwMCBmDQowMDAw MDExODg1IDAwMDAwIG4NCjAwMDAwMTE5NjQgMDAwMDAgbg0KMDAwMDAxMjI1MSAwMDAwMCBuDQow MDAwMDEyMzE5IDAwMDAwIG4NCjAwMDAwMDAwMzEgMDAwMDAgZg0KMDAwMDAwMDAzMyAwMDAwMCBm DQowMDAwMDEyNTg3IDAwMDAwIG4NCjAwMDAwMDAwMzUgMDAwMDAgZg0KMDAwMDAxMjk2NSAwMDAw MCBuDQowMDAwMDAwMDM3IDAwMDAwIGYNCjAwMDAwMTMzNDMgMDAwMDAgbg0KMDAwMDAwMDAzOSAw MDAwMCBmDQowMDAwMDEzNzIxIDAwMDAwIG4NCjAwMDAwMDAwNDEgMDAwMDAgZg0KMDAwMDAxNDA4 NiAwMDAwMCBuDQowMDAwMDAwMDU0IDAwMDAwIGYNCjAwMDAwMTQ0NTEgMDAwMDAgbg0KMDAwMDAx NDkwMSAwMDAwMCBuDQowMDAwMDI3NDM0IDAwMDAwIG4NCjAwMDAwMzI2NDAgMDAwMDAgbg0KMDAw MDAzMzEwOCAwMDAwMCBuDQowMDAwMDMzNjU4IDAwMDAwIG4NCjAwMDAwMzUwMTcgMDAwMDAgbg0K MDAwMDAzNTMxNiAwMDAwMCBuDQowMDAwMDM1NjUzIDAwMDAwIG4NCjAwMDAwMzc4NzkgMDAwMDAg bg0KMDAwMDAzODE4NyAwMDAwMCBuDQowMDAwMDM4NTUzIDAwMDAwIG4NCjAwMDAwMDAwNTUgMDAw MDAgZg0KMDAwMDAwMDA1NiAwMDAwMCBmDQowMDAwMDAwMDU3IDAwMDAwIGYNCjAwMDAwMDAwNTkg MDAwMDAgZg0KMDAwMDA1Njc2NyAwMDAwMCBuDQowMDAwMDAwMDYxIDAwMDAwIGYNCjAwMDAwNTcw NDggMDAwMDAgbg0KMDAwMDAwMDA2MiAwMDAwMCBmDQowMDAwMDAwMDY0IDAwMDAwIGYNCjAwMDAw NTcxNTggMDAwMDAgbg0KMDAwMDAwMDA2NyAwMDAwMCBmDQowMDAwMDU3MjM3IDAwMDAwIG4NCjAw MDAwNTc3NDQgMDAwMDAgbg0KMDAwMDAwMDA2OCAwMDAwMCBmDQowMDAwMDAwMDcwIDAwMDAwIGYN CjAwMDAwNTc5OTUgMDAwMDAgbg0KMDAwMDAwMDA3MSAwMDAwMCBmDQowMDAwMDAwMDcyIDAwMDAw IGYNCjAwMDAwMDAwNzMgMDAwMDAgZg0KMDAwMDAwMDA3NCAwMDAwMCBmDQowMDAwMDAwMDc1IDAw MDAwIGYNCjAwMDAwMDAwNzYgMDAwMDAgZg0KMDAwMDAwMDA3NyAwMDAwMCBmDQowMDAwMDAwMDc4 IDAwMDAwIGYNCjAwMDAwMDAwNzkgMDAwMDAgZg0KMDAwMDAwMDA4MCAwMDAwMCBmDQowMDAwMDAw MDgyIDAwMDAwIGYNCjAwMDAwNTgwNjMgMDAwMDAgbg0KMDAwMDAwMDA4NCAwMDAwMCBmDQowMDAw MDU4MzU0IDAwMDAwIG4NCjAwMDAwMDAwODUgMDAwMDAgZg0KMDAwMDAwMDA4OCAwMDAwMCBmDQow MDAwMDU4ODU3IDAwMDAwIG4NCjAwMDAwNTg5MzYgMDAwMDAgbg0KMDAwMDAwMDA4OSAwMDAwMCBm DQowMDAwMDAwMDkwIDAwMDAwIGYNCjAwMDAwMDAxMDYgMDAwMDAgZg0KMDAwMDA1OTAwNCAwMDAw MCBuDQowMDAwMDU5NTEzIDAwMDAwIG4NCjAwMDAwNTk4ODAgMDAwMDAgbg0KMDAwMDA2MDIzMCAw MDAwMCBuDQowMDAwMDYwMjk3IDAwMDAwIG4NCjAwMDAwNjAzNTggMDAwMDAgbg0KMDAwMDA2MDQw OSAwMDAwMCBuDQowMDAwMDYwODExIDAwMDAwIG4NCjAwMDAwNjExODcgMDAwMDAgbg0KMDAwMDA2 MTU4OSAwMDAwMCBuDQowMDAwMDYxOTY2IDAwMDAwIG4NCjAwMDAwNjIzNjkgMDAwMDAgbg0KMDAw MDA2Mjc0NiAwMDAwMCBuDQowMDAwMDk2MDczIDAwMDAwIG4NCjAwMDAwOTY0NzYgMDAwMDAgbg0K MDAwMDAwMDEwNyAwMDAwMCBmDQowMDAwMDAwMTA4IDAwMDAwIGYNCjAwMDAwMDAxMDkgMDAwMDAg Zg0KMDAwMDAwMDExMCAwMDAwMCBmDQowMDAwMDAwMTExIDAwMDAwIGYNCjAwMDAwMDAxMTIgMDAw MDAgZg0KMDAwMDAwMDExMyAwMDAwMCBmDQowMDAwMDAwMTE4IDAwMDAwIGYNCjAwMDAwOTY4NTMg MDAwMDAgbg0KMDAwMDA5NjkyNCAwMDAwMCBuDQowMDAwMDk2OTkzIDAwMDAwIG4NCjAwMDAwOTcx MjIgMDAwMDAgbg0KMDAwMDAwMDgyOSAwMDAwMCBmDQowMDAwMDk3MjE4IDAwMDAwIG4NCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDk3Mzk0IDAwMDAwIG4NCjAw MDAwOTc1MDAgMDAwMDAgbg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYN CjAwMDAwMDAxMjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1 IGYNCjAwMDAwMDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1 NTM1IGYNCjAwMDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMz IDY1NTM1IGYNCjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAw MTM2IDY1NTM1IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAw MDAwMTM5IDY1NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQow MDAwMDAwMTQyIDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBm DQowMDAwMDAwMTQ1IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0NyA2NTUz NSBmDQowMDAwMDAwMTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAwMDAwMDE1MCA2 NTUzNSBmDQowMDAwMDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUgZg0KMDAwMDAwMDE1 MyA2NTUzNSBmDQowMDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1MzUgZg0KMDAwMDAw MDE1NiA2NTUzNSBmDQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTggNjU1MzUgZg0KMDAw MDAwMDE1OSA2NTUzNSBmDQowMDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAxNjEgNjU1MzUgZg0K MDAwMDAwMDE2MiA2NTUzNSBmDQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUg Zg0KMDAwMDAwMDE2NSA2NTUzNSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1 MzUgZg0KMDAwMDAwMDE2OCA2NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAg NjU1MzUgZg0KMDAwMDAwMDE3MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAx NzMgNjU1MzUgZg0KMDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAw MDAxNzYgNjU1MzUgZg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAw MDAwMDAxNzkgNjU1MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYN CjAwMDAwMDAxODIgNjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1 IGYNCjAwMDAwMDAxODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1 NTM1IGYNCjAwMDAwMDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkw IDY1NTM1IGYNCjAwMDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAw MTkzIDY1NTM1IGYNCjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQowMDAw MDAwMTk2IDY1NTM1IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUzNSBmDQow MDAwMDAwMTk5IDY1NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIwMSA2NTUzNSBm DQowMDAwMDAwMjAyIDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAwMDAwMDIwNCA2NTUz NSBmDQowMDAwMDAwMjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0KMDAwMDAwMDIwNyA2 NTUzNSBmDQowMDAwMDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUgZg0KMDAwMDA5ODk5 MSAwMDAwMCBuDQowMDAwMDAwMjEwIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1MzUgZg0KMDAwMDAw MDIxMyA2NTUzNSBmDQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUgNjU1MzUgZg0KMDAw MDAwMDIxNiA2NTUzNSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAyMTggNjU1MzUgZg0K MDAwMDAwMDIxOSA2NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAwMDAyMjEgNjU1MzUg Zg0KMDAwMDAwMDIyMiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAwMDAwMDAyMjQgNjU1 MzUgZg0KMDAwMDAwMDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYNCjAwMDAwMDAyMjcg NjU1MzUgZg0KMDAwMDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1IGYNCjAwMDAwMDAy MzAgNjU1MzUgZg0KMDAwMDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1NTM1IGYNCjAwMDAw MDAyMzMgNjU1MzUgZg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1IDY1NTM1IGYNCjAw MDAwMDAyMzYgNjU1MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAwMjM4IDY1NTM1IGYN CjAwMDAwMDAyMzkgNjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAwMDAwMjQxIDY1NTM1 IGYNCjAwMDAwMDAyNDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQowMDAwMDAwMjQ0IDY1 NTM1IGYNCjAwMDAwMDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBmDQowMDAwMDAwMjQ3 IDY1NTM1IGYNCjAwMDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUzNSBmDQowMDAwMDAw MjUwIDY1NTM1IGYNCjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2NTUzNSBmDQowMDAw MDAwMjUzIDY1NTM1IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1NSA2NTUzNSBmDQow MDAwMDAwMjU2IDY1NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAwMDAwMDI1OCA2NTUzNSBm DQowMDAwMDAwMjU5IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUgZg0KMDAwMDAwMDI2MSA2NTUz NSBmDQowMDAwMDAwMjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMgNjU1MzUgZg0KMDAwMDAwMDI2NCA2 NTUzNSBmDQowMDAwMDAwMjY1IDY1NTM1IGYNCjAwMDAwMDAyNjYgNjU1MzUgZg0KMDAwMDAwMDI2 NyA2NTUzNSBmDQowMDAwMDAwMjY4IDY1NTM1IGYNCjAwMDAwMDAyNjkgNjU1MzUgZg0KMDAwMDAw MDI3MCA2NTUzNSBmDQowMDAwMDAwMjcxIDY1NTM1IGYNCjAwMDAwMDAyNzIgNjU1MzUgZg0KMDAw MDAwMDI3MyA2NTUzNSBmDQowMDAwMDAwMjc0IDY1NTM1IGYNCjAwMDAwMDAyNzUgNjU1MzUgZg0K MDAwMDAwMDI3NiA2NTUzNSBmDQowMDAwMDAwMjc3IDY1NTM1IGYNCjAwMDAwMDAyNzggNjU1MzUg Zg0KMDAwMDAwMDI3OSA2NTUzNSBmDQowMDAwMDAwMjgwIDY1NTM1IGYNCjAwMDAwOTkwNTEgMDAw MDAgbg0KMDAwMDAwMDI4MSA2NTUzNSBmDQowMDAwMDk5MDkwIDAwMDAwIG4NCjAwMDAwMDAyODMg NjU1MzUgZg0KMDAwMDAwMDI4NSA2NTUzNSBmDQowMDAwMDAwMjg2IDY1NTM1IGYNCjAwMDAwMDAy ODcgNjU1MzUgZg0KMDAwMDAwMDI4OCA2NTUzNSBmDQowMDAwMDAwMjg5IDY1NTM1IGYNCjAwMDAw MDAyOTAgNjU1MzUgZg0KMDAwMDAwMDI5MSA2NTUzNSBmDQowMDAwMDAwMjkyIDY1NTM1IGYNCjAw MDAwMDAyOTMgNjU1MzUgZg0KMDAwMDAwMDI5NCA2NTUzNSBmDQowMDAwMDAwMjk1IDY1NTM1IGYN CjAwMDAwMDAyOTYgNjU1MzUgZg0KMDAwMDAwMDI5NyA2NTUzNSBmDQowMDAwMDAwMjk4IDY1NTM1 IGYNCjAwMDAwMDAyOTkgNjU1MzUgZg0KMDAwMDAwMDMwMCA2NTUzNSBmDQowMDAwMDAwMzAxIDY1 NTM1IGYNCjAwMDAwMDAzMDIgNjU1MzUgZg0KMDAwMDAwMDMwMyA2NTUzNSBmDQowMDAwMDAwMzA0 IDY1NTM1IGYNCjAwMDAwMDAzMDUgNjU1MzUgZg0KMDAwMDAwMDMwNiA2NTUzNSBmDQowMDAwMDAw MzA3IDY1NTM1IGYNCjAwMDAwMDAzMDggNjU1MzUgZg0KMDAwMDAwMDMwOSA2NTUzNSBmDQowMDAw MDAwMzEwIDY1NTM1IGYNCjAwMDAwMDAzMTEgNjU1MzUgZg0KMDAwMDAwMDMxMiA2NTUzNSBmDQow MDAwMDAwMzEzIDY1NTM1IGYNCjAwMDAwMDAzMTQgNjU1MzUgZg0KMDAwMDAwMDMxNSA2NTUzNSBm DQowMDAwMDAwMzE2IDY1NTM1IGYNCjAwMDAwMDAzMTcgNjU1MzUgZg0KMDAwMDAwMDMxOCA2NTUz NSBmDQowMDAwMDAwMzE5IDY1NTM1IGYNCjAwMDAwMDAzMjAgNjU1MzUgZg0KMDAwMDAwMDMyMSA2 NTUzNSBmDQowMDAwMDAwMzIyIDY1NTM1IGYNCjAwMDAwMDAzMjMgNjU1MzUgZg0KMDAwMDAwMDMy NCA2NTUzNSBmDQowMDAwMDAwMzI1IDY1NTM1IGYNCjAwMDAwMDAzMjYgNjU1MzUgZg0KMDAwMDAw MDMyNyA2NTUzNSBmDQowMDAwMDAwMzI4IDY1NTM1IGYNCjAwMDAwMDAzMjkgNjU1MzUgZg0KMDAw MDAwMDMzMCA2NTUzNSBmDQowMDAwMDAwMzMxIDY1NTM1IGYNCjAwMDAwMDAzMzIgNjU1MzUgZg0K MDAwMDAwMDMzMyA2NTUzNSBmDQowMDAwMDAwMzM0IDY1NTM1IGYNCjAwMDAwMDAzMzUgNjU1MzUg Zg0KMDAwMDAwMDMzNiA2NTUzNSBmDQowMDAwMDAwMzM3IDY1NTM1IGYNCjAwMDAwMDAzMzggNjU1 MzUgZg0KMDAwMDAwMDMzOSA2NTUzNSBmDQowMDAwMDAwMzQwIDY1NTM1IGYNCjAwMDAwMDAzNDEg NjU1MzUgZg0KMDAwMDAwMDM0MiA2NTUzNSBmDQowMDAwMDAwMzQzIDY1NTM1IGYNCjAwMDAwMDAz NDQgNjU1MzUgZg0KMDAwMDAwMDM0NSA2NTUzNSBmDQowMDAwMDAwMzQ2IDY1NTM1IGYNCjAwMDAw MDAzNDcgNjU1MzUgZg0KMDAwMDAwMDM0OCA2NTUzNSBmDQowMDAwMDAwMzQ5IDY1NTM1IGYNCjAw MDAwMDAzNTAgNjU1MzUgZg0KMDAwMDAwMDM1MSA2NTUzNSBmDQowMDAwMDAwMzUyIDY1NTM1IGYN CjAwMDAwMDAzNTMgNjU1MzUgZg0KMDAwMDAwMDM1NCA2NTUzNSBmDQowMDAwMDAwMzU1IDY1NTM1 IGYNCjAwMDAwMDAzNTYgNjU1MzUgZg0KMDAwMDAwMDM1NyA2NTUzNSBmDQowMDAwMDAwMzU4IDY1 NTM1IGYNCjAwMDAwMDAzNTkgNjU1MzUgZg0KMDAwMDAwMDM2MCA2NTUzNSBmDQowMDAwMDAwMzYx IDY1NTM1IGYNCjAwMDAwMDAzNjIgNjU1MzUgZg0KMDAwMDAwMDM2MyA2NTUzNSBmDQowMDAwMDAw MzY0IDY1NTM1IGYNCjAwMDAwMDAzNjUgNjU1MzUgZg0KMDAwMDAwMDM2NiA2NTUzNSBmDQowMDAw MDAwMzY3IDY1NTM1IGYNCjAwMDAwMDAzNjggNjU1MzUgZg0KMDAwMDAwMDM2OSA2NTUzNSBmDQow MDAwMDAwMzcwIDY1NTM1IGYNCjAwMDAwMDAzNzEgNjU1MzUgZg0KMDAwMDAwMDM3MiA2NTUzNSBm DQowMDAwMDAwMzczIDY1NTM1IGYNCjAwMDAwMDAzNzQgNjU1MzUgZg0KMDAwMDAwMDM3NSA2NTUz NSBmDQowMDAwMDAwMzc2IDY1NTM1IGYNCjAwMDAwMDAzNzcgNjU1MzUgZg0KMDAwMDAwMDM3OCA2 NTUzNSBmDQowMDAwMDAwMzc5IDY1NTM1IGYNCjAwMDAwMDAzODAgNjU1MzUgZg0KMDAwMDAwMDM4 MSA2NTUzNSBmDQowMDAwMDAwMzgyIDY1NTM1IGYNCjAwMDAwMDAzODMgNjU1MzUgZg0KMDAwMDAw MDM4NCA2NTUzNSBmDQowMDAwMDAwMzg1IDY1NTM1IGYNCjAwMDAwMDAzODYgNjU1MzUgZg0KMDAw MDAwMDM4NyA2NTUzNSBmDQowMDAwMDAwMzg4IDY1NTM1IGYNCjAwMDAwMDAzODkgNjU1MzUgZg0K MDAwMDAwMDM5MCA2NTUzNSBmDQowMDAwMDAwMzkxIDY1NTM1IGYNCjAwMDAwMDAzOTIgNjU1MzUg Zg0KMDAwMDAwMDM5MyA2NTUzNSBmDQowMDAwMDAwMzk0IDY1NTM1IGYNCjAwMDAwMDAzOTUgNjU1 MzUgZg0KMDAwMDAwMDM5NiA2NTUzNSBmDQowMDAwMDAwMzk3IDY1NTM1IGYNCjAwMDAwMDAzOTgg NjU1MzUgZg0KMDAwMDAwMDM5OSA2NTUzNSBmDQowMDAwMDAwNDAwIDY1NTM1IGYNCjAwMDAwMDA0 MDEgNjU1MzUgZg0KMDAwMDAwMDQwMiA2NTUzNSBmDQowMDAwMDAwNDAzIDY1NTM1IGYNCjAwMDAw MDA0MDQgNjU1MzUgZg0KMDAwMDAwMDQwNSA2NTUzNSBmDQowMDAwMDAwNDA2IDY1NTM1IGYNCjAw MDAwMDA0MDcgNjU1MzUgZg0KMDAwMDAwMDQwOCA2NTUzNSBmDQowMDAwMDAwNDA5IDY1NTM1IGYN CjAwMDAwMDA0MTAgNjU1MzUgZg0KMDAwMDAwMDQxMSA2NTUzNSBmDQowMDAwMDAwNDEyIDY1NTM1 IGYNCjAwMDAwMDA0MTMgNjU1MzUgZg0KMDAwMDAwMDQxNCA2NTUzNSBmDQowMDAwMDAwNDE1IDY1 NTM1IGYNCjAwMDAwMDA0MTYgNjU1MzUgZg0KMDAwMDAwMDQxNyA2NTUzNSBmDQowMDAwMDAwNDE4 IDY1NTM1IGYNCjAwMDAwMDA0MTkgNjU1MzUgZg0KMDAwMDAwMDQyMCA2NTUzNSBmDQowMDAwMDAw NDIxIDY1NTM1IGYNCjAwMDAwMDA0MjIgNjU1MzUgZg0KMDAwMDAwMDQyMyA2NTUzNSBmDQowMDAw MDAwNDI0IDY1NTM1IGYNCjAwMDAwMDA0MjUgNjU1MzUgZg0KMDAwMDAwMDQyNiA2NTUzNSBmDQow MDAwMDAwNDI3IDY1NTM1IGYNCjAwMDAwMDA0MjggNjU1MzUgZg0KMDAwMDAwMDQyOSA2NTUzNSBm DQowMDAwMDAwNDMwIDY1NTM1IGYNCjAwMDAwMDA0MzEgNjU1MzUgZg0KMDAwMDAwMDQzMiA2NTUz NSBmDQowMDAwMDAwNDMzIDY1NTM1IGYNCjAwMDAwMDA0MzQgNjU1MzUgZg0KMDAwMDAwMDQzNSA2 NTUzNSBmDQowMDAwMDAwNDM2IDY1NTM1IGYNCjAwMDAwMDA0MzcgNjU1MzUgZg0KMDAwMDAwMDQz OCA2NTUzNSBmDQowMDAwMDAwNDM5IDY1NTM1IGYNCjAwMDAwMDA0NDAgNjU1MzUgZg0KMDAwMDAw MDQ0MSA2NTUzNSBmDQowMDAwMDAwNDQyIDY1NTM1IGYNCjAwMDAwMDA0NDMgNjU1MzUgZg0KMDAw MDAwMDQ0NCA2NTUzNSBmDQowMDAwMDAwNDQ1IDY1NTM1IGYNCjAwMDAwMDA0NDYgNjU1MzUgZg0K MDAwMDAwMDQ0NyA2NTUzNSBmDQowMDAwMDAwNDQ4IDY1NTM1IGYNCjAwMDAwMDA0NDkgNjU1MzUg Zg0KMDAwMDAwMDQ1MCA2NTUzNSBmDQowMDAwMDAwNDUxIDY1NTM1IGYNCjAwMDAwMDA0NTIgNjU1 MzUgZg0KMDAwMDAwMDQ1MyA2NTUzNSBmDQowMDAwMDAwNDU0IDY1NTM1IGYNCjAwMDAwMDA0NTUg NjU1MzUgZg0KMDAwMDAwMDQ1NiA2NTUzNSBmDQowMDAwMDAwNDU3IDY1NTM1IGYNCjAwMDAwMDA0 NTggNjU1MzUgZg0KMDAwMDAwMDQ1OSA2NTUzNSBmDQowMDAwMDAwNDYwIDY1NTM1IGYNCjAwMDAw MDA0NjEgNjU1MzUgZg0KMDAwMDAwMDQ2MiA2NTUzNSBmDQowMDAwMDAwNDYzIDY1NTM1IGYNCjAw MDAwMDA0NjQgNjU1MzUgZg0KMDAwMDAwMDQ2NSA2NTUzNSBmDQowMDAwMDAwNDY2IDY1NTM1IGYN CjAwMDAwMDA0NjcgNjU1MzUgZg0KMDAwMDAwMDQ2OCA2NTUzNSBmDQowMDAwMDAwNDY5IDY1NTM1 IGYNCjAwMDAwMDA0NzAgNjU1MzUgZg0KMDAwMDAwMDQ3MSA2NTUzNSBmDQowMDAwMDAwNDcyIDY1 NTM1IGYNCjAwMDAwMDA0NzMgNjU1MzUgZg0KMDAwMDAwMDQ3NCA2NTUzNSBmDQowMDAwMDAwNDc1 IDY1NTM1IGYNCjAwMDAwMDA0NzYgNjU1MzUgZg0KMDAwMDAwMDQ3NyA2NTUzNSBmDQowMDAwMDAw NDc4IDY1NTM1IGYNCjAwMDAwMDA0NzkgNjU1MzUgZg0KMDAwMDAwMDQ4MCA2NTUzNSBmDQowMDAw MDAwNDgxIDY1NTM1IGYNCjAwMDAwMDA0ODIgNjU1MzUgZg0KMDAwMDAwMDQ4MyA2NTUzNSBmDQow MDAwMDAwNDg0IDY1NTM1IGYNCjAwMDAwMDA0ODUgNjU1MzUgZg0KMDAwMDAwMDQ4NiA2NTUzNSBm DQowMDAwMDAwNDg3IDY1NTM1IGYNCjAwMDAwMDA0ODggNjU1MzUgZg0KMDAwMDAwMDQ4OSA2NTUz NSBmDQowMDAwMDAwNDkwIDY1NTM1IGYNCjAwMDAwMDA0OTEgNjU1MzUgZg0KMDAwMDAwMDQ5MiA2 NTUzNSBmDQowMDAwMDAwNDkzIDY1NTM1IGYNCjAwMDAwMDA0OTQgNjU1MzUgZg0KMDAwMDAwMDQ5 NSA2NTUzNSBmDQowMDAwMDAwNDk2IDY1NTM1IGYNCjAwMDAwMDA0OTcgNjU1MzUgZg0KMDAwMDAw MDQ5OCA2NTUzNSBmDQowMDAwMDAwNDk5IDY1NTM1IGYNCjAwMDAwMDA1MDAgNjU1MzUgZg0KMDAw MDAwMDUwMSA2NTUzNSBmDQowMDAwMDAwNTAyIDY1NTM1IGYNCjAwMDAwMDA1MDMgNjU1MzUgZg0K MDAwMDAwMDUwNCA2NTUzNSBmDQowMDAwMDAwNTA1IDY1NTM1IGYNCjAwMDAwMDA1MDYgNjU1MzUg Zg0KMDAwMDAwMDUwNyA2NTUzNSBmDQowMDAwMDk5MTI5IDAwMDAwIG4NCjAwMDAwOTkyNDIgMDAw MDAgbg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTExIDY1NTM1IGYNCjAwMDAwOTk2MDcg MDAwMDAgbg0KMDAwMDAwMDUxMiA2NTUzNSBmDQowMDAwMDAwNTE0IDY1NTM1IGYNCjAwMDAwMDA1 MTUgNjU1MzUgZg0KMDAwMDAwMDUxNiA2NTUzNSBmDQowMDAwMDAwNTE3IDY1NTM1IGYNCjAwMDAw MDA1MTggNjU1MzUgZg0KMDAwMDAwMDUxOSA2NTUzNSBmDQowMDAwMDAwNTIwIDY1NTM1IGYNCjAw MDAwMDA1MjEgNjU1MzUgZg0KMDAwMDAwMDUyMiA2NTUzNSBmDQowMDAwMDAwNTIzIDY1NTM1IGYN CjAwMDAwMDA1MjQgNjU1MzUgZg0KMDAwMDAwMDUyNSA2NTUzNSBmDQowMDAwMDk5OTczIDAwMDAw IG4NCjAwMDAwMDA1MjYgNjU1MzUgZg0KMDAwMDAwMDUyOCA2NTUzNSBmDQowMDAwMDAwNTI5IDY1 NTM1IGYNCjAwMDAwMDA1MzAgNjU1MzUgZg0KMDAwMDAwMDUzMSA2NTUzNSBmDQowMDAwMDAwNTMy IDY1NTM1IGYNCjAwMDAwMDA1MzMgNjU1MzUgZg0KMDAwMDAwMDUzNCA2NTUzNSBmDQowMDAwMDAw NTM1IDY1NTM1IGYNCjAwMDAwMDA1MzYgNjU1MzUgZg0KMDAwMDAwMDUzNyA2NTUzNSBmDQowMDAw MDAwNTM4IDY1NTM1IGYNCjAwMDAwMDA1MzkgNjU1MzUgZg0KMDAwMDAwMDU0MCA2NTUzNSBmDQow MDAwMDAwNTQxIDY1NTM1IGYNCjAwMDAwMDA1NDIgNjU1MzUgZg0KMDAwMDAwMDU0MyA2NTUzNSBm DQowMDAwMDAwNTQ0IDY1NTM1IGYNCjAwMDAwMDA1NDUgNjU1MzUgZg0KMDAwMDAwMDU0NiA2NTUz NSBmDQowMDAwMDAwNTQ3IDY1NTM1IGYNCjAwMDAwMDA1NDggNjU1MzUgZg0KMDAwMDAwMDU0OSA2 NTUzNSBmDQowMDAwMDAwNTUwIDY1NTM1IGYNCjAwMDAwMDA1NTEgNjU1MzUgZg0KMDAwMDAwMDU1 MiA2NTUzNSBmDQowMDAwMDAwNTUzIDY1NTM1IGYNCjAwMDAwMDA1NTQgNjU1MzUgZg0KMDAwMDAw MDU1NSA2NTUzNSBmDQowMDAwMDAwNTU2IDY1NTM1IGYNCjAwMDAwMDA1NTcgNjU1MzUgZg0KMDAw MDAwMDU1OCA2NTUzNSBmDQowMDAwMDAwNTU5IDY1NTM1IGYNCjAwMDAwMDA1NjAgNjU1MzUgZg0K MDAwMDAwMDU2MSA2NTUzNSBmDQowMDAwMDAwNTYyIDY1NTM1IGYNCjAwMDAwMDA1NjMgNjU1MzUg Zg0KMDAwMDAwMDU2NCA2NTUzNSBmDQowMDAwMDAwNTY1IDY1NTM1IGYNCjAwMDAwMDA1NjYgNjU1 MzUgZg0KMDAwMDAwMDU2NyA2NTUzNSBmDQowMDAwMDAwNTY4IDY1NTM1IGYNCjAwMDAwMDA1Njkg NjU1MzUgZg0KMDAwMDAwMDU3MCA2NTUzNSBmDQowMDAwMDAwNTcxIDY1NTM1IGYNCjAwMDAwMDA1 NzIgNjU1MzUgZg0KMDAwMDAwMDU3MyA2NTUzNSBmDQowMDAwMDAwNTc0IDY1NTM1IGYNCjAwMDAw MDA1NzUgNjU1MzUgZg0KMDAwMDAwMDU3NiA2NTUzNSBmDQowMDAwMDAwNTc3IDY1NTM1IGYNCjAw MDAwMDA1NzggNjU1MzUgZg0KMDAwMDAwMDU3OSA2NTUzNSBmDQowMDAwMDAwNTgwIDY1NTM1IGYN CjAwMDAwMDA1ODEgNjU1MzUgZg0KMDAwMDAwMDU4MiA2NTUzNSBmDQowMDAwMDAwNTgzIDY1NTM1 IGYNCjAwMDAwMDA1ODQgNjU1MzUgZg0KMDAwMDAwMDU4NSA2NTUzNSBmDQowMDAwMDAwNTg2IDY1 NTM1IGYNCjAwMDAwMDA1ODcgNjU1MzUgZg0KMDAwMDAwMDU4OCA2NTUzNSBmDQowMDAwMDAwNTg5 IDY1NTM1IGYNCjAwMDAwMDA1OTAgNjU1MzUgZg0KMDAwMDAwMDU5MSA2NTUzNSBmDQowMDAwMDAw NTkyIDY1NTM1IGYNCjAwMDAwMDA1OTMgNjU1MzUgZg0KMDAwMDAwMDU5NCA2NTUzNSBmDQowMDAw MDAwNTk1IDY1NTM1IGYNCjAwMDAwMDA1OTYgNjU1MzUgZg0KMDAwMDEwMDAzMyAwMDAwMCBuDQow MDAwMDAwNTk3IDY1NTM1IGYNCjAwMDAxMDAwNzIgMDAwMDAgbg0KMDAwMDAwMDU5OSA2NTUzNSBm DQowMDAwMDAwNjAxIDY1NTM1IGYNCjAwMDAwMDA2MDIgNjU1MzUgZg0KMDAwMDAwMDYwMyA2NTUz NSBmDQowMDAwMDAwNjA0IDY1NTM1IGYNCjAwMDAwMDA2MDUgNjU1MzUgZg0KMDAwMDAwMDYwNiA2 NTUzNSBmDQowMDAwMDAwNjA3IDY1NTM1IGYNCjAwMDAwMDA2MDggNjU1MzUgZg0KMDAwMDAwMDYw OSA2NTUzNSBmDQowMDAwMDAwNjEwIDY1NTM1IGYNCjAwMDAwMDA2MTEgNjU1MzUgZg0KMDAwMDAw MDYxMiA2NTUzNSBmDQowMDAwMDAwNjEzIDY1NTM1IGYNCjAwMDAwMDA2MTQgNjU1MzUgZg0KMDAw MDAwMDYxNSA2NTUzNSBmDQowMDAwMDAwNjE2IDY1NTM1IGYNCjAwMDAwMDA2MTcgNjU1MzUgZg0K MDAwMDAwMDYxOCA2NTUzNSBmDQowMDAwMDAwNjE5IDY1NTM1IGYNCjAwMDAwMDA2MjAgNjU1MzUg Zg0KMDAwMDAwMDYyMSA2NTUzNSBmDQowMDAwMDAwNjIyIDY1NTM1IGYNCjAwMDAwMDA2MjMgNjU1 MzUgZg0KMDAwMDAwMDYyNCA2NTUzNSBmDQowMDAwMDAwNjI1IDY1NTM1IGYNCjAwMDAwMDA2MjYg NjU1MzUgZg0KMDAwMDAwMDYyNyA2NTUzNSBmDQowMDAwMDAwNjI4IDY1NTM1IGYNCjAwMDAwMDA2 MjkgNjU1MzUgZg0KMDAwMDAwMDYzMCA2NTUzNSBmDQowMDAwMDAwNjMxIDY1NTM1IGYNCjAwMDAw MDA2MzIgNjU1MzUgZg0KMDAwMDAwMDYzMyA2NTUzNSBmDQowMDAwMDAwNjM0IDY1NTM1IGYNCjAw MDAwMDA2MzUgNjU1MzUgZg0KMDAwMDAwMDYzNiA2NTUzNSBmDQowMDAwMDAwNjM3IDY1NTM1IGYN CjAwMDAwMDA2MzggNjU1MzUgZg0KMDAwMDAwMDYzOSA2NTUzNSBmDQowMDAwMDAwNjQwIDY1NTM1 IGYNCjAwMDAwMDA2NDEgNjU1MzUgZg0KMDAwMDAwMDY0MiA2NTUzNSBmDQowMDAwMDAwNjQzIDY1 NTM1IGYNCjAwMDAwMDA2NDQgNjU1MzUgZg0KMDAwMDAwMDY0NSA2NTUzNSBmDQowMDAwMDAwNjQ2 IDY1NTM1IGYNCjAwMDAwMDA2NDcgNjU1MzUgZg0KMDAwMDAwMDY0OCA2NTUzNSBmDQowMDAwMDAw NjQ5IDY1NTM1IGYNCjAwMDAwMDA2NTAgNjU1MzUgZg0KMDAwMDAwMDY1MSA2NTUzNSBmDQowMDAw MDAwNjUyIDY1NTM1IGYNCjAwMDAwMDA2NTMgNjU1MzUgZg0KMDAwMDAwMDY1NCA2NTUzNSBmDQow MDAwMDAwNjU1IDY1NTM1IGYNCjAwMDAwMDA2NTYgNjU1MzUgZg0KMDAwMDAwMDY1NyA2NTUzNSBm DQowMDAwMDAwNjU4IDY1NTM1IGYNCjAwMDAwMDA2NTkgNjU1MzUgZg0KMDAwMDAwMDY2MCA2NTUz NSBmDQowMDAwMDAwNjYxIDY1NTM1IGYNCjAwMDAwMDA2NjIgNjU1MzUgZg0KMDAwMDAwMDY2MyA2 NTUzNSBmDQowMDAwMDAwNjY0IDY1NTM1IGYNCjAwMDAwMDA2NjUgNjU1MzUgZg0KMDAwMDAwMDY2 NiA2NTUzNSBmDQowMDAwMDAwNjY3IDY1NTM1IGYNCjAwMDAwMDA2NjggNjU1MzUgZg0KMDAwMDAw MDY2OSA2NTUzNSBmDQowMDAwMDAwNjcwIDY1NTM1IGYNCjAwMDAwMDA2NzEgNjU1MzUgZg0KMDAw MDAwMDY3MiA2NTUzNSBmDQowMDAwMDAwNjczIDY1NTM1IGYNCjAwMDAwMDA2NzQgNjU1MzUgZg0K MDAwMDAwMDY3NSA2NTUzNSBmDQowMDAwMDAwNjc2IDY1NTM1IGYNCjAwMDAwMDA2NzcgNjU1MzUg Zg0KMDAwMDAwMDY3OCA2NTUzNSBmDQowMDAwMDAwNjc5IDY1NTM1IGYNCjAwMDAwMDA2ODAgNjU1 MzUgZg0KMDAwMDAwMDY4MSA2NTUzNSBmDQowMDAwMDAwNjgyIDY1NTM1IGYNCjAwMDAwMDA2ODMg NjU1MzUgZg0KMDAwMDAwMDY4NCA2NTUzNSBmDQowMDAwMDAwNjg1IDY1NTM1IGYNCjAwMDAwMDA2 ODYgNjU1MzUgZg0KMDAwMDAwMDY4NyA2NTUzNSBmDQowMDAwMDAwNjg4IDY1NTM1IGYNCjAwMDAw MDA2ODkgNjU1MzUgZg0KMDAwMDAwMDY5MCA2NTUzNSBmDQowMDAwMDAwNjkxIDY1NTM1IGYNCjAw MDAwMDA2OTIgNjU1MzUgZg0KMDAwMDAwMDY5MyA2NTUzNSBmDQowMDAwMDAwNjk0IDY1NTM1IGYN CjAwMDAwMDA2OTUgNjU1MzUgZg0KMDAwMDAwMDY5NiA2NTUzNSBmDQowMDAwMDAwNjk3IDY1NTM1 IGYNCjAwMDAwMDA2OTggNjU1MzUgZg0KMDAwMDAwMDY5OSA2NTUzNSBmDQowMDAwMDAwNzAwIDY1 NTM1IGYNCjAwMDAwMDA3MDEgNjU1MzUgZg0KMDAwMDAwMDcwMiA2NTUzNSBmDQowMDAwMDAwNzAz IDY1NTM1IGYNCjAwMDAwMDA3MDQgNjU1MzUgZg0KMDAwMDAwMDcwNSA2NTUzNSBmDQowMDAwMDAw NzA2IDY1NTM1IGYNCjAwMDAwMDA3MDcgNjU1MzUgZg0KMDAwMDAwMDcwOCA2NTUzNSBmDQowMDAw MDAwNzA5IDY1NTM1IGYNCjAwMDAwMDA3MTAgNjU1MzUgZg0KMDAwMDAwMDcxMSA2NTUzNSBmDQow MDAwMDAwNzEyIDY1NTM1IGYNCjAwMDAwMDA3MTMgNjU1MzUgZg0KMDAwMDAwMDcxNCA2NTUzNSBm DQowMDAwMDAwNzE1IDY1NTM1IGYNCjAwMDAwMDA3MTYgNjU1MzUgZg0KMDAwMDAwMDcxNyA2NTUz NSBmDQowMDAwMDAwNzE4IDY1NTM1IGYNCjAwMDAwMDA3MTkgNjU1MzUgZg0KMDAwMDAwMDcyMCA2 NTUzNSBmDQowMDAwMDAwNzIxIDY1NTM1IGYNCjAwMDAwMDA3MjIgNjU1MzUgZg0KMDAwMDAwMDcy MyA2NTUzNSBmDQowMDAwMDAwNzI0IDY1NTM1IGYNCjAwMDAwMDA3MjUgNjU1MzUgZg0KMDAwMDAw MDcyNiA2NTUzNSBmDQowMDAwMDAwNzI3IDY1NTM1IGYNCjAwMDAwMDA3MjggNjU1MzUgZg0KMDAw MDAwMDcyOSA2NTUzNSBmDQowMDAwMDAwNzMwIDY1NTM1IGYNCjAwMDAwMDA3MzEgNjU1MzUgZg0K MDAwMDAwMDczMiA2NTUzNSBmDQowMDAwMDAwNzMzIDY1NTM1IGYNCjAwMDAwMDA3MzQgNjU1MzUg Zg0KMDAwMDAwMDczNSA2NTUzNSBmDQowMDAwMDAwNzM2IDY1NTM1IGYNCjAwMDAwMDA3MzcgNjU1 MzUgZg0KMDAwMDAwMDczOCA2NTUzNSBmDQowMDAwMDAwNzM5IDY1NTM1IGYNCjAwMDAwMDA3NDAg NjU1MzUgZg0KMDAwMDAwMDc0MSA2NTUzNSBmDQowMDAwMDAwNzQyIDY1NTM1IGYNCjAwMDAwMDA3 NDMgNjU1MzUgZg0KMDAwMDAwMDc0NCA2NTUzNSBmDQowMDAwMDAwNzQ1IDY1NTM1IGYNCjAwMDAw MDA3NDYgNjU1MzUgZg0KMDAwMDAwMDc0NyA2NTUzNSBmDQowMDAwMDAwNzQ4IDY1NTM1IGYNCjAw MDAwMDA3NDkgNjU1MzUgZg0KMDAwMDAwMDc1MCA2NTUzNSBmDQowMDAwMDAwNzUxIDY1NTM1IGYN CjAwMDAwMDA3NTIgNjU1MzUgZg0KMDAwMDAwMDc1MyA2NTUzNSBmDQowMDAwMDAwNzU0IDY1NTM1 IGYNCjAwMDAwMDA3NTUgNjU1MzUgZg0KMDAwMDAwMDc1NiA2NTUzNSBmDQowMDAwMDAwNzU3IDY1 NTM1IGYNCjAwMDAwMDA3NTggNjU1MzUgZg0KMDAwMDAwMDc1OSA2NTUzNSBmDQowMDAwMDAwNzYw IDY1NTM1IGYNCjAwMDAwMDA3NjEgNjU1MzUgZg0KMDAwMDAwMDc2MiA2NTUzNSBmDQowMDAwMDAw NzYzIDY1NTM1IGYNCjAwMDAwMDA3NjQgNjU1MzUgZg0KMDAwMDAwMDc2NSA2NTUzNSBmDQowMDAw MDAwNzY2IDY1NTM1IGYNCjAwMDAwMDA3NjcgNjU1MzUgZg0KMDAwMDAwMDc2OCA2NTUzNSBmDQow MDAwMDAwNzY5IDY1NTM1IGYNCjAwMDAwMDA3NzAgNjU1MzUgZg0KMDAwMDAwMDc3MSA2NTUzNSBm DQowMDAwMDAwNzcyIDY1NTM1IGYNCjAwMDAwMDA3NzMgNjU1MzUgZg0KMDAwMDAwMDc3NCA2NTUz NSBmDQowMDAwMDAwNzc1IDY1NTM1IGYNCjAwMDAwMDA3NzYgNjU1MzUgZg0KMDAwMDAwMDc3NyA2 NTUzNSBmDQowMDAwMDAwNzc4IDY1NTM1IGYNCjAwMDAwMDA3NzkgNjU1MzUgZg0KMDAwMDAwMDc4 MCA2NTUzNSBmDQowMDAwMDAwNzgxIDY1NTM1IGYNCjAwMDAwMDA3ODIgNjU1MzUgZg0KMDAwMDAw MDc4MyA2NTUzNSBmDQowMDAwMDAwNzg0IDY1NTM1IGYNCjAwMDAwMDA3ODUgNjU1MzUgZg0KMDAw MDAwMDc4NiA2NTUzNSBmDQowMDAwMDAwNzg3IDY1NTM1IGYNCjAwMDAwMDA3ODggNjU1MzUgZg0K MDAwMDAwMDc4OSA2NTUzNSBmDQowMDAwMDAwNzkwIDY1NTM1IGYNCjAwMDAwMDA3OTEgNjU1MzUg Zg0KMDAwMDAwMDc5MiA2NTUzNSBmDQowMDAwMDAwNzkzIDY1NTM1IGYNCjAwMDAwMDA3OTQgNjU1 MzUgZg0KMDAwMDAwMDc5NSA2NTUzNSBmDQowMDAwMDAwNzk2IDY1NTM1IGYNCjAwMDAwMDA3OTcg NjU1MzUgZg0KMDAwMDAwMDc5OCA2NTUzNSBmDQowMDAwMDAwNzk5IDY1NTM1IGYNCjAwMDAwMDA4 MDAgNjU1MzUgZg0KMDAwMDAwMDgwMSA2NTUzNSBmDQowMDAwMDAwODAyIDY1NTM1IGYNCjAwMDAw MDA4MDMgNjU1MzUgZg0KMDAwMDAwMDgwNCA2NTUzNSBmDQowMDAwMDAwODA1IDY1NTM1IGYNCjAw MDAwMDA4MDYgNjU1MzUgZg0KMDAwMDAwMDgwNyA2NTUzNSBmDQowMDAwMDAwODA4IDY1NTM1IGYN CjAwMDAwMDA4MDkgNjU1MzUgZg0KMDAwMDAwMDgxMCA2NTUzNSBmDQowMDAwMDAwODExIDY1NTM1 IGYNCjAwMDAwMDA4MTIgNjU1MzUgZg0KMDAwMDAwMDgxMyA2NTUzNSBmDQowMDAwMDAwODE0IDY1 NTM1IGYNCjAwMDAwMDA4MTUgNjU1MzUgZg0KMDAwMDAwMDgxNiA2NTUzNSBmDQowMDAwMDAwODE3 IDY1NTM1IGYNCjAwMDAwMDA4MTggNjU1MzUgZg0KMDAwMDAwMDgxOSA2NTUzNSBmDQowMDAwMDAw ODIwIDY1NTM1IGYNCjAwMDAwMDA4MjEgNjU1MzUgZg0KMDAwMDEwMDExMSAwMDAwMCBuDQowMDAw MTAwMjI0IDAwMDAwIG4NCjAwMDAxMDA1OTEgMDAwMDAgbg0KMDAwMDAwMDgyMiA2NTUzNSBmDQow MDAwMDAwODI2IDY1NTM1IGYNCjAwMDAxMDA4NjggMDAwMDAgbg0KMDAwMDAwMDg2NyAwMDAwMCBm DQowMDAwMTAxMjM1IDAwMDAwIG4NCjAwMDAxMDE0MDEgMDAwMDAgbg0KMDAwMDEwMjAwNiAwMDAw MCBuDQowMDAwMTAyMzQ1IDAwMDAwIG4NCjAwMDAxMDI1MzYgMDAwMDAgbg0KMDAwMDEwMjU3MiAw MDAwMCBuDQowMDAwMTAyNjA4IDAwMDAwIG4NCjAwMDAxMDI3OTMgMDAwMDAgbg0KMDAwMDEwMjk3 NCAwMDAwMCBuDQowMDAwMTAzMDg3IDAwMDAwIG4NCjAwMDAxMDUwOTAgMDAwMDAgbg0KMDAwMDEw NzA0NyAwMDAwMCBuDQowMDAwMTA4NjUxIDAwMDAwIG4NCjAwMDAxMTAxOTAgMDAwMDAgbg0KMDAw MDExMTc5NSAwMDAwMCBuDQowMDAwMTEzMDc2IDAwMDAwIG4NCjAwMDAxMTM0ODYgMDAwMDAgbg0K MDAwMDExMzgzNyAwMDAwMCBuDQowMDAwMTE0MjYwIDAwMDAwIG4NCjAwMDAxMTQzNDMgMDAwMDAg bg0KMDAwMDExNTg3NyAwMDAwMCBuDQowMDAwMTE3NTM5IDAwMDAwIG4NCjAwMDAxMTk0MDAgMDAw MDAgbg0KMDAwMDExOTc2MCAwMDAwMCBuDQowMDAwMTM0NzMwIDAwMDAwIG4NCjAwMDAxMzU1MDQg MDAwMDAgbg0KMDAwMDE0NzIyNCAwMDAwMCBuDQowMDAwMTY2ODIyIDAwMDAwIG4NCjAwMDAyNTI5 OTcgMDAwMDAgbg0KMDAwMDI1MzA3NCAwMDAwMCBuDQowMDAwMjY2NTc5IDAwMDAwIG4NCjAwMDAy NjY5NjEgMDAwMDAgbg0KMDAwMDI2ODM0NiAwMDAwMCBuDQowMDAwMjY4Njk1IDAwMDAwIG4NCjAw MDAyNjkwODAgMDAwMDAgbg0KMDAwMDI4NzI5NSAwMDAwMCBuDQowMDAwMjg3NDE4IDAwMDAwIG4N CjAwMDAwMDA4NjggMDAwMDAgZg0KMDAwMDAwMDg2OSAwMDAwMCBmDQowMDAwMDAwODcwIDAwMDAw IGYNCjAwMDAwMDA4NzEgMDAwMDAgZg0KMDAwMDAwMDg3MiAwMDAwMCBmDQowMDAwMDAwODczIDAw MDAwIGYNCjAwMDAwMDA4NzQgMDAwMDAgZg0KMDAwMDAwMDg3NSAwMDAwMCBmDQowMDAwMDAwODc2 IDAwMDAwIGYNCjAwMDAwMDA4NzcgMDAwMDAgZg0KMDAwMDAwMDg3OCAwMDAwMCBmDQowMDAwMDAw ODc5IDAwMDAwIGYNCjAwMDAwMDA4ODAgMDAwMDAgZg0KMDAwMDAwMDg4MSAwMDAwMCBmDQowMDAw MDAwODgyIDAwMDAwIGYNCjAwMDAwMDA4ODMgMDAwMDAgZg0KMDAwMDAwMDg4NCAwMDAwMCBmDQow MDAwMDAwODg1IDAwMDAwIGYNCjAwMDAwMDA4ODYgMDAwMDAgZg0KMDAwMDAwMDg4NyAwMDAwMCBm DQowMDAwMDAwODg4IDAwMDAwIGYNCjAwMDAwMDA4ODkgMDAwMDAgZg0KMDAwMDAwMDg5MCAwMDAw MCBmDQowMDAwMDAwODkxIDAwMDAwIGYNCjAwMDAwMDA4OTIgMDAwMDAgZg0KMDAwMDAwMDg5MyAw MDAwMCBmDQowMDAwMDAwODk0IDAwMDAwIGYNCjAwMDAwMDA4OTUgMDAwMDAgZg0KMDAwMDAwMDg5 NiAwMDAwMCBmDQowMDAwMDAwODk3IDAwMDAwIGYNCjAwMDAwMDA4OTggMDAwMDAgZg0KMDAwMDAw MDg5OSAwMDAwMCBmDQowMDAwMDAwOTAwIDAwMDAwIGYNCjAwMDAwMDA5MDEgMDAwMDAgZg0KMDAw MDAwMDkwMiAwMDAwMCBmDQowMDAwMDAwOTAzIDAwMDAwIGYNCjAwMDAwMDA5MDQgMDAwMDAgZg0K MDAwMDAwMDkwNSAwMDAwMCBmDQowMDAwMDAwOTA2IDAwMDAwIGYNCjAwMDAwMDA5MDcgMDAwMDAg Zg0KMDAwMDAwMDkwOCAwMDAwMCBmDQowMDAwMDAwOTA5IDAwMDAwIGYNCjAwMDAwMDA5MTAgMDAw MDAgZg0KMDAwMDAwMDkxMSAwMDAwMCBmDQowMDAwMDAwOTEyIDAwMDAwIGYNCjAwMDAwMDA5MTMg MDAwMDAgZg0KMDAwMDAwMDkxNCAwMDAwMCBmDQowMDAwMDAwOTE1IDAwMDAwIGYNCjAwMDAwMDA5 MTYgMDAwMDAgZg0KMDAwMDAwMDkxNyAwMDAwMCBmDQowMDAwMDAwOTE4IDAwMDAwIGYNCjAwMDAw MDA5MTkgMDAwMDAgZg0KMDAwMDAwMDkyMCAwMDAwMCBmDQowMDAwMDAwOTIxIDAwMDAwIGYNCjAw MDAwMDA5MjIgMDAwMDAgZg0KMDAwMDAwMDkyMyAwMDAwMCBmDQowMDAwMDAwOTI0IDAwMDAwIGYN CjAwMDAwMDA5MjUgMDAwMDAgZg0KMDAwMDAwMDkyNiAwMDAwMCBmDQowMDAwMDAwOTI3IDAwMDAw IGYNCjAwMDAwMDA5MjggMDAwMDAgZg0KMDAwMDAwMDkyOSAwMDAwMCBmDQowMDAwMDAwOTMwIDAw MDAwIGYNCjAwMDAwMDA5MzEgMDAwMDAgZg0KMDAwMDAwMDkzMiAwMDAwMCBmDQowMDAwMDAwOTMz IDAwMDAwIGYNCjAwMDAwMDA5MzQgMDAwMDAgZg0KMDAwMDAwMDkzNSAwMDAwMCBmDQowMDAwMDAw OTM2IDAwMDAwIGYNCjAwMDAwMDA5MzcgMDAwMDAgZg0KMDAwMDAwMDkzOCAwMDAwMCBmDQowMDAw MDAwOTM5IDAwMDAwIGYNCjAwMDAwMDA5NDAgMDAwMDAgZg0KMDAwMDAwMDk0MSAwMDAwMCBmDQow MDAwMDAwOTQyIDAwMDAwIGYNCjAwMDAwMDA5NDMgMDAwMDAgZg0KMDAwMDAwMDk0NCAwMDAwMCBm DQowMDAwMDAwOTQ1IDAwMDAwIGYNCjAwMDAwMDA5NDYgMDAwMDAgZg0KMDAwMDAwMDk0NyAwMDAw MCBmDQowMDAwMDAwOTQ4IDAwMDAwIGYNCjAwMDAwMDA5NDkgMDAwMDAgZg0KMDAwMDAwMDk1MCAw MDAwMCBmDQowMDAwMDAwOTUxIDAwMDAwIGYNCjAwMDAwMDA5NTIgMDAwMDAgZg0KMDAwMDAwMDk1 MyAwMDAwMCBmDQowMDAwMDAwOTU0IDAwMDAwIGYNCjAwMDAwMDA5NTUgMDAwMDAgZg0KMDAwMDAw MDk1NiAwMDAwMCBmDQowMDAwMDAwOTU3IDAwMDAwIGYNCjAwMDAwMDA5NTggMDAwMDAgZg0KMDAw MDAwMDk1OSAwMDAwMCBmDQowMDAwMDAwOTYwIDAwMDAwIGYNCjAwMDAwMDA5NjEgMDAwMDAgZg0K MDAwMDAwMDk2MiAwMDAwMCBmDQowMDAwMDAwOTYzIDAwMDAwIGYNCjAwMDAwMDA5NjQgMDAwMDAg Zg0KMDAwMDAwMDk2NSAwMDAwMCBmDQowMDAwMDAwOTY2IDAwMDAwIGYNCjAwMDAwMDA5NjcgMDAw MDAgZg0KMDAwMDAwMDk2OCAwMDAwMCBmDQowMDAwMDAwOTY5IDAwMDAwIGYNCjAwMDAwMDA5NzAg MDAwMDAgZg0KMDAwMDAwMDk3MSAwMDAwMCBmDQowMDAwMDAwOTcyIDAwMDAwIGYNCjAwMDAwMDA5 NzMgMDAwMDAgZg0KMDAwMDAwMDk3NCAwMDAwMCBmDQowMDAwMDAwOTc1IDAwMDAwIGYNCjAwMDAw MDA5NzYgMDAwMDAgZg0KMDAwMDAwMDk3NyAwMDAwMCBmDQowMDAwMDAwOTc4IDAwMDAwIGYNCjAw MDAwMDA5NzkgMDAwMDAgZg0KMDAwMDAwMDk4MCAwMDAwMCBmDQowMDAwMDAwOTgxIDAwMDAwIGYN CjAwMDAwMDA5ODIgMDAwMDAgZg0KMDAwMDAwMDk4MyAwMDAwMCBmDQowMDAwMDAwOTg0IDAwMDAw IGYNCjAwMDAwMDA5ODUgMDAwMDAgZg0KMDAwMDAwMDk4NiAwMDAwMCBmDQowMDAwMDAwOTg3IDAw MDAwIGYNCjAwMDAwMDA5ODggMDAwMDAgZg0KMDAwMDAwMDk4OSAwMDAwMCBmDQowMDAwMDAwOTkw IDAwMDAwIGYNCjAwMDAwMDA5OTEgMDAwMDAgZg0KMDAwMDAwMDk5MiAwMDAwMCBmDQowMDAwMDAw OTkzIDAwMDAwIGYNCjAwMDAwMDA5OTQgMDAwMDAgZg0KMDAwMDAwMDk5NSAwMDAwMCBmDQowMDAw MDAwOTk2IDAwMDAwIGYNCjAwMDAwMDA5OTcgMDAwMDAgZg0KMDAwMDAwMDk5OCAwMDAwMCBmDQow MDAwMDAwOTk5IDAwMDAwIGYNCjAwMDAwMDEwMDAgMDAwMDAgZg0KMDAwMDAwMTAwMSAwMDAwMCBm DQowMDAwMDAxMDAyIDAwMDAwIGYNCjAwMDAwMDEwMDMgMDAwMDAgZg0KMDAwMDAwMTAwNCAwMDAw MCBmDQowMDAwMDAxMDA1IDAwMDAwIGYNCjAwMDAwMDEwMDYgMDAwMDAgZg0KMDAwMDAwMTAwNyAw MDAwMCBmDQowMDAwMDAxMDA4IDAwMDAwIGYNCjAwMDAwMDEwMDkgMDAwMDAgZg0KMDAwMDAwMTAx MCAwMDAwMCBmDQowMDAwMDAxMDExIDAwMDAwIGYNCjAwMDAwMDEwMTIgMDAwMDAgZg0KMDAwMDAw MTAxMyAwMDAwMCBmDQowMDAwMDAxMDE0IDAwMDAwIGYNCjAwMDAwMDEwMTUgMDAwMDAgZg0KMDAw MDAwMTAxNiAwMDAwMCBmDQowMDAwMDAxMDE3IDAwMDAwIGYNCjAwMDAwMDEwMTggMDAwMDAgZg0K MDAwMDAwMTAxOSAwMDAwMCBmDQowMDAwMDAxMDIwIDAwMDAwIGYNCjAwMDAwMDEwMjEgMDAwMDAg Zg0KMDAwMDAwMTAyMiAwMDAwMCBmDQowMDAwMDAxMDIzIDAwMDAwIGYNCjAwMDAwMDEwMjQgMDAw MDAgZg0KMDAwMDAwMTAyNSAwMDAwMCBmDQowMDAwMDAxMDI2IDAwMDAwIGYNCjAwMDAwMDEwMjcg MDAwMDAgZg0KMDAwMDAwMTAyOCAwMDAwMCBmDQowMDAwMDAxMDI5IDAwMDAwIGYNCjAwMDAwMDEw MzAgMDAwMDAgZg0KMDAwMDAwMTAzMSAwMDAwMCBmDQowMDAwMDAxMDMyIDAwMDAwIGYNCjAwMDAw MDEwMzMgMDAwMDAgZg0KMDAwMDAwMTAzNCAwMDAwMCBmDQowMDAwMDAxMDM1IDAwMDAwIGYNCjAw MDAwMDEwMzYgMDAwMDAgZg0KMDAwMDAwMTAzNyAwMDAwMCBmDQowMDAwMDAxMDM4IDAwMDAwIGYN CjAwMDAwMDEwMzkgMDAwMDAgZg0KMDAwMDAwMTA0MCAwMDAwMCBmDQowMDAwMDAxMDQxIDAwMDAw IGYNCjAwMDAwMDEwNDIgMDAwMDAgZg0KMDAwMDAwMTA0MyAwMDAwMCBmDQowMDAwMDAxMDQ0IDAw MDAwIGYNCjAwMDAwMDEwNDUgMDAwMDAgZg0KMDAwMDAwMTA0NiAwMDAwMCBmDQowMDAwMDAxMDQ3 IDAwMDAwIGYNCjAwMDAwMDEwNDggMDAwMDAgZg0KMDAwMDAwMTA0OSAwMDAwMCBmDQowMDAwMDAx MDUwIDAwMDAwIGYNCjAwMDAwMDEwNTEgMDAwMDAgZg0KMDAwMDAwMTA1MiAwMDAwMCBmDQowMDAw MDAxMDUzIDAwMDAwIGYNCjAwMDAwMDEwNTQgMDAwMDAgZg0KMDAwMDAwMTA1NSAwMDAwMCBmDQow MDAwMDAxMDU2IDAwMDAwIGYNCjAwMDAwMDEwNTcgMDAwMDAgZg0KMDAwMDAwMTA1OCAwMDAwMCBm DQowMDAwMDAxMDU5IDAwMDAwIGYNCjAwMDAwMDEwNjAgMDAwMDAgZg0KMDAwMDAwMTA2MSAwMDAw MCBmDQowMDAwMDAxMDYyIDAwMDAwIGYNCjAwMDAwMDEwNjMgMDAwMDAgZg0KMDAwMDAwMTA2NCAw MDAwMCBmDQowMDAwMDAxMDY1IDAwMDAwIGYNCjAwMDAwMDEwNjYgMDAwMDAgZg0KMDAwMDAwMTA2 NyAwMDAwMCBmDQowMDAwMDAxMDY4IDAwMDAwIGYNCjAwMDAwMDEwNjkgMDAwMDAgZg0KMDAwMDAw MTA3MCAwMDAwMCBmDQowMDAwMDAxMDcxIDAwMDAwIGYNCjAwMDAwMDEwNzIgMDAwMDAgZg0KMDAw MDAwMTA3MyAwMDAwMCBmDQowMDAwMDAxMDc0IDAwMDAwIGYNCjAwMDAwMDEwNzUgMDAwMDAgZg0K MDAwMDAwMTA3NiAwMDAwMCBmDQowMDAwMDAxMDc3IDAwMDAwIGYNCjAwMDAwMDEwNzggMDAwMDAg Zg0KMDAwMDAwMTA3OSAwMDAwMCBmDQowMDAwMDAxMDgwIDAwMDAwIGYNCjAwMDAwMDEwODEgMDAw MDAgZg0KMDAwMDAwMTA4MiAwMDAwMCBmDQowMDAwMDAxMDgzIDAwMDAwIGYNCjAwMDAwMDEwODQg MDAwMDAgZg0KMDAwMDAwMTA4NSAwMDAwMCBmDQowMDAwMDAxMDg2IDAwMDAwIGYNCjAwMDAwMDEw ODcgMDAwMDAgZg0KMDAwMDAwMTA4OCAwMDAwMCBmDQowMDAwMDAxMDg5IDAwMDAwIGYNCjAwMDAw MDEwOTAgMDAwMDAgZg0KMDAwMDAwMTA5MSAwMDAwMCBmDQowMDAwMDAxMDkyIDAwMDAwIGYNCjAw MDAwMDEwOTMgMDAwMDAgZg0KMDAwMDAwMTA5NCAwMDAwMCBmDQowMDAwMDAxMDk1IDAwMDAwIGYN CjAwMDAwMDEwOTYgMDAwMDAgZg0KMDAwMDAwMTA5NyAwMDAwMCBmDQowMDAwMDAxMDk4IDAwMDAw IGYNCjAwMDAwMDEwOTkgMDAwMDAgZg0KMDAwMDAwMTEwMCAwMDAwMCBmDQowMDAwMDAxMTAxIDAw MDAwIGYNCjAwMDAwMDExMDIgMDAwMDAgZg0KMDAwMDAwMTEwMyAwMDAwMCBmDQowMDAwMDAxMTA0 IDAwMDAwIGYNCjAwMDAwMDExMDUgMDAwMDAgZg0KMDAwMDAwMTEwNiAwMDAwMCBmDQowMDAwMDAx MTA3IDAwMDAwIGYNCjAwMDAwMDExMDggMDAwMDAgZg0KMDAwMDAwMTEwOSAwMDAwMCBmDQowMDAw MDAxMTEwIDAwMDAwIGYNCjAwMDAwMDExMTEgMDAwMDAgZg0KMDAwMDAwMTExMiAwMDAwMCBmDQow MDAwMDAxMTEzIDAwMDAwIGYNCjAwMDAwMDExMTQgMDAwMDAgZg0KMDAwMDAwMTExNSAwMDAwMCBm DQowMDAwMDAxMTE2IDAwMDAwIGYNCjAwMDAwMDExMTcgMDAwMDAgZg0KMDAwMDAwMTExOCAwMDAw MCBmDQowMDAwMDAxMTE5IDAwMDAwIGYNCjAwMDAwMDExMjAgMDAwMDAgZg0KMDAwMDAwMTEyMSAw MDAwMCBmDQowMDAwMDAxMTIyIDAwMDAwIGYNCjAwMDAwMDExMjMgMDAwMDAgZg0KMDAwMDAwMTEy NCAwMDAwMCBmDQowMDAwMDAxMTI1IDAwMDAwIGYNCjAwMDAwMDExMjYgMDAwMDAgZg0KMDAwMDAw MTEyNyAwMDAwMCBmDQowMDAwMDAxMTI4IDAwMDAwIGYNCjAwMDAwMDExMjkgMDAwMDAgZg0KMDAw MDAwMTEzMCAwMDAwMCBmDQowMDAwMDAxMTMxIDAwMDAwIGYNCjAwMDAwMDExMzIgMDAwMDAgZg0K MDAwMDAwMTEzMyAwMDAwMCBmDQowMDAwMDAxMTM0IDAwMDAwIGYNCjAwMDAwMDExMzUgMDAwMDAg Zg0KMDAwMDAwMTEzNiAwMDAwMCBmDQowMDAwMDAxMTM3IDAwMDAwIGYNCjAwMDAwMDExMzggMDAw MDAgZg0KMDAwMDAwMTEzOSAwMDAwMCBmDQowMDAwMDAxMTQwIDAwMDAwIGYNCjAwMDAwMDExNDEg MDAwMDAgZg0KMDAwMDAwMTE0MiAwMDAwMCBmDQowMDAwMDAxMTQzIDAwMDAwIGYNCjAwMDAwMDEx NDQgMDAwMDAgZg0KMDAwMDAwMTE0NSAwMDAwMCBmDQowMDAwMDAxMTQ2IDAwMDAwIGYNCjAwMDAw MDExNDcgMDAwMDAgZg0KMDAwMDAwMTE0OCAwMDAwMCBmDQowMDAwMDAxMTQ5IDAwMDAwIGYNCjAw MDAwMDExNTAgMDAwMDAgZg0KMDAwMDAwMTE1MSAwMDAwMCBmDQowMDAwMDAxMTUyIDAwMDAwIGYN CjAwMDAwMDExNTMgMDAwMDAgZg0KMDAwMDAwMTE1NCAwMDAwMCBmDQowMDAwMDAxMTU1IDAwMDAw IGYNCjAwMDAwMDExNTYgMDAwMDAgZg0KMDAwMDAwMTE1NyAwMDAwMCBmDQowMDAwMDAxMTU4IDAw MDAwIGYNCjAwMDAwMDExNTkgMDAwMDAgZg0KMDAwMDAwMTE2MCAwMDAwMCBmDQowMDAwMDAxMTYx IDAwMDAwIGYNCjAwMDAwMDExNjIgMDAwMDAgZg0KMDAwMDAwMTE2MyAwMDAwMCBmDQowMDAwMDAx MTY0IDAwMDAwIGYNCjAwMDAwMDExNjUgMDAwMDAgZg0KMDAwMDAwMTE2NiAwMDAwMCBmDQowMDAw MDAxMTY3IDAwMDAwIGYNCjAwMDAwMDExNjggMDAwMDAgZg0KMDAwMDAwMTE2OSAwMDAwMCBmDQow MDAwMDAxMTcwIDAwMDAwIGYNCjAwMDAwMDExNzEgMDAwMDAgZg0KMDAwMDAwMTE3MiAwMDAwMCBm DQowMDAwMDAxMTczIDAwMDAwIGYNCjAwMDAwMDExNzQgMDAwMDAgZg0KMDAwMDAwMTE3NSAwMDAw MCBmDQowMDAwMDAxMTc2IDAwMDAwIGYNCjAwMDAwMDExNzcgMDAwMDAgZg0KMDAwMDAwMTE3OCAw MDAwMCBmDQowMDAwMDAxMTc5IDAwMDAwIGYNCjAwMDAwMDExODAgMDAwMDAgZg0KMDAwMDAwMTE4 MSAwMDAwMCBmDQowMDAwMDAxMTgyIDAwMDAwIGYNCjAwMDAwMDExODMgMDAwMDAgZg0KMDAwMDAw MTE4NCAwMDAwMCBmDQowMDAwMDAxMTg1IDAwMDAwIGYNCjAwMDAwMDExODYgMDAwMDAgZg0KMDAw MDAwMTE4NyAwMDAwMCBmDQowMDAwMDAxMTg4IDAwMDAwIGYNCjAwMDAwMDExODkgMDAwMDAgZg0K MDAwMDAwMTE5MCAwMDAwMCBmDQowMDAwMDAxMTkxIDAwMDAwIGYNCjAwMDAwMDExOTIgMDAwMDAg Zg0KMDAwMDAwMTE5MyAwMDAwMCBmDQowMDAwMDAxMTk0IDAwMDAwIGYNCjAwMDAwMDExOTUgMDAw MDAgZg0KMDAwMDAwMTE5NiAwMDAwMCBmDQowMDAwMDAxMTk3IDAwMDAwIGYNCjAwMDAwMDExOTgg MDAwMDAgZg0KMDAwMDAwMTE5OSAwMDAwMCBmDQowMDAwMDAxMjAwIDAwMDAwIGYNCjAwMDAwMDEy MDEgMDAwMDAgZg0KMDAwMDAwMTIwMiAwMDAwMCBmDQowMDAwMDAxMjAzIDAwMDAwIGYNCjAwMDAw MDEyMDQgMDAwMDAgZg0KMDAwMDAwMTIwNSAwMDAwMCBmDQowMDAwMDAxMjA2IDAwMDAwIGYNCjAw MDAwMDEyMDcgMDAwMDAgZg0KMDAwMDAwMTIwOCAwMDAwMCBmDQowMDAwMDAxMjA5IDAwMDAwIGYN CjAwMDAwMDEyMTAgMDAwMDAgZg0KMDAwMDAwMTIxMSAwMDAwMCBmDQowMDAwMDAxMjEyIDAwMDAw IGYNCjAwMDAwMDEyMTMgMDAwMDAgZg0KMDAwMDAwMTIxNCAwMDAwMCBmDQowMDAwMDAxMjE1IDAw MDAwIGYNCjAwMDAwMDEyMTYgMDAwMDAgZg0KMDAwMDAwMTIxNyAwMDAwMCBmDQowMDAwMDAxMjE4 IDAwMDAwIGYNCjAwMDAwMDEyMTkgMDAwMDAgZg0KMDAwMDAwMTIyMCAwMDAwMCBmDQowMDAwMDAx MjIxIDAwMDAwIGYNCjAwMDAwMDEyMjIgMDAwMDAgZg0KMDAwMDAwMTIyMyAwMDAwMCBmDQowMDAw MDAxMjI0IDAwMDAwIGYNCjAwMDAwMDEyMjUgMDAwMDAgZg0KMDAwMDAwMTIyNiAwMDAwMCBmDQow MDAwMDAxMjI3IDAwMDAwIGYNCjAwMDAwMDEyMjggMDAwMDAgZg0KMDAwMDAwMTIyOSAwMDAwMCBm DQowMDAwMDAxMjMwIDAwMDAwIGYNCjAwMDAwMDEyMzEgMDAwMDAgZg0KMDAwMDAwMTIzMiAwMDAw MCBmDQowMDAwMDAxMjMzIDAwMDAwIGYNCjAwMDAwMDEyMzQgMDAwMDAgZg0KMDAwMDAwMTIzNSAw MDAwMCBmDQowMDAwMDAxMjM2IDAwMDAwIGYNCjAwMDAwMDEyMzcgMDAwMDAgZg0KMDAwMDAwMTIz OCAwMDAwMCBmDQowMDAwMDAxMjM5IDAwMDAwIGYNCjAwMDAwMDEyNDAgMDAwMDAgZg0KMDAwMDAw MTI0MSAwMDAwMCBmDQowMDAwMDAxMjQyIDAwMDAwIGYNCjAwMDAwMDEyNDMgMDAwMDAgZg0KMDAw MDAwMTI0NCAwMDAwMCBmDQowMDAwMDAxMjQ1IDAwMDAwIGYNCjAwMDAwMDEyNDYgMDAwMDAgZg0K MDAwMDAwMTI0NyAwMDAwMCBmDQowMDAwMDAxMjQ4IDAwMDAwIGYNCjAwMDAwMDEyNDkgMDAwMDAg Zg0KMDAwMDAwMTI1MCAwMDAwMCBmDQowMDAwMDAxMjUxIDAwMDAwIGYNCjAwMDAwMDEyNTIgMDAw MDAgZg0KMDAwMDAwMTI1MyAwMDAwMCBmDQowMDAwMDAxMjU0IDAwMDAwIGYNCjAwMDAwMDEyNTUg MDAwMDAgZg0KMDAwMDAwMTI1NiAwMDAwMCBmDQowMDAwMDAxMjU3IDAwMDAwIGYNCjAwMDAwMDEy NTggMDAwMDAgZg0KMDAwMDAwMTI1OSAwMDAwMCBmDQowMDAwMDAxMjYwIDAwMDAwIGYNCjAwMDAw MDEyNjEgMDAwMDAgZg0KMDAwMDAwMTI2MiAwMDAwMCBmDQowMDAwMDAxMjYzIDAwMDAwIGYNCjAw MDAwMDEyNjQgMDAwMDAgZg0KMDAwMDAwMTI2NSAwMDAwMCBmDQowMDAwMDAxMjY2IDAwMDAwIGYN CjAwMDAwMDEyNjcgMDAwMDAgZg0KMDAwMDAwMTI2OCAwMDAwMCBmDQowMDAwMDAxMjY5IDAwMDAw IGYNCjAwMDAwMDEyNzAgMDAwMDAgZg0KMDAwMDAwMTI3MSAwMDAwMCBmDQowMDAwMDAxMjcyIDAw MDAwIGYNCjAwMDAwMDEyNzMgMDAwMDAgZg0KMDAwMDAwMTI3NCAwMDAwMCBmDQowMDAwMDAxMjc1 IDAwMDAwIGYNCjAwMDAwMDEyNzYgMDAwMDAgZg0KMDAwMDAwMTI3NyAwMDAwMCBmDQowMDAwMDAx Mjc4IDAwMDAwIGYNCjAwMDAwMDEyNzkgMDAwMDAgZg0KMDAwMDAwMTI4MCAwMDAwMCBmDQowMDAw MDAxMjgxIDAwMDAwIGYNCjAwMDAwMDEyODIgMDAwMDAgZg0KMDAwMDAwMTI4MyAwMDAwMCBmDQow MDAwMDAxMjg0IDAwMDAwIGYNCjAwMDAwMDEyODUgMDAwMDAgZg0KMDAwMDAwMTI4NiAwMDAwMCBm DQowMDAwMDAxMjg3IDAwMDAwIGYNCjAwMDAwMDEyODggMDAwMDAgZg0KMDAwMDAwMTI4OSAwMDAw MCBmDQowMDAwMDAxMjkwIDAwMDAwIGYNCjAwMDAwMDEyOTEgMDAwMDAgZg0KMDAwMDAwMTI5MiAw MDAwMCBmDQowMDAwMDAxMjkzIDAwMDAwIGYNCjAwMDAwMDEyOTQgMDAwMDAgZg0KMDAwMDAwMTI5 NSAwMDAwMCBmDQowMDAwMDAxMjk2IDAwMDAwIGYNCjAwMDAwMDEyOTcgMDAwMDAgZg0KMDAwMDAw MTI5OCAwMDAwMCBmDQowMDAwMDAxMjk5IDAwMDAwIGYNCjAwMDAwMDEzMDAgMDAwMDAgZg0KMDAw MDAwMTMwMSAwMDAwMCBmDQowMDAwMDAxMzAyIDAwMDAwIGYNCjAwMDAwMDEzMDMgMDAwMDAgZg0K MDAwMDAwMTMwNCAwMDAwMCBmDQowMDAwMDAxMzA1IDAwMDAwIGYNCjAwMDAwMDEzMDYgMDAwMDAg Zg0KMDAwMDAwMTMwNyAwMDAwMCBmDQowMDAwMDAxMzA4IDAwMDAwIGYNCjAwMDAwMDEzMDkgMDAw MDAgZg0KMDAwMDAwMTMxMCAwMDAwMCBmDQowMDAwMDAxMzExIDAwMDAwIGYNCjAwMDAwMDEzMTIg MDAwMDAgZg0KMDAwMDAwMTMxMyAwMDAwMCBmDQowMDAwMDAxMzE0IDAwMDAwIGYNCjAwMDAwMDEz MTUgMDAwMDAgZg0KMDAwMDAwMTMxNiAwMDAwMCBmDQowMDAwMDAxMzE3IDAwMDAwIGYNCjAwMDAw MDEzMTggMDAwMDAgZg0KMDAwMDAwMTMxOSAwMDAwMCBmDQowMDAwMDAxMzIwIDAwMDAwIGYNCjAw MDAwMDEzMjEgMDAwMDAgZg0KMDAwMDAwMTMyMiAwMDAwMCBmDQowMDAwMDAxMzIzIDAwMDAwIGYN CjAwMDAwMDEzMjQgMDAwMDAgZg0KMDAwMDAwMTMyNSAwMDAwMCBmDQowMDAwMDAxMzI2IDAwMDAw IGYNCjAwMDAwMDEzMjcgMDAwMDAgZg0KMDAwMDAwMTMyOCAwMDAwMCBmDQowMDAwMDAxMzI5IDAw MDAwIGYNCjAwMDAwMDEzMzAgMDAwMDAgZg0KMDAwMDAwMTMzMSAwMDAwMCBmDQowMDAwMDAxMzMy IDAwMDAwIGYNCjAwMDAwMDEzMzMgMDAwMDAgZg0KMDAwMDAwMTMzNCAwMDAwMCBmDQowMDAwMDAx MzM1IDAwMDAwIGYNCjAwMDAwMDEzMzYgMDAwMDAgZg0KMDAwMDAwMTMzNyAwMDAwMCBmDQowMDAw MDAxMzM4IDAwMDAwIGYNCjAwMDAwMDEzMzkgMDAwMDAgZg0KMDAwMDAwMTM0MCAwMDAwMCBmDQow MDAwMDAxMzQxIDAwMDAwIGYNCjAwMDAwMDEzNDIgMDAwMDAgZg0KMDAwMDAwMTM0MyAwMDAwMCBm DQowMDAwMDAxMzQ0IDAwMDAwIGYNCjAwMDAwMDEzNDUgMDAwMDAgZg0KMDAwMDAwMTM0NiAwMDAw MCBmDQowMDAwMDAxMzQ3IDAwMDAwIGYNCjAwMDAwMDEzNDggMDAwMDAgZg0KMDAwMDAwMTM0OSAw MDAwMCBmDQowMDAwMDAxMzUwIDAwMDAwIGYNCjAwMDAwMDEzNTEgMDAwMDAgZg0KMDAwMDAwMTM1 MiAwMDAwMCBmDQowMDAwMDAxMzUzIDAwMDAwIGYNCjAwMDAwMDEzNTQgMDAwMDAgZg0KMDAwMDAw MTM1NSAwMDAwMCBmDQowMDAwMDAxMzU2IDAwMDAwIGYNCjAwMDAwMDEzNTcgMDAwMDAgZg0KMDAw MDAwMTM1OCAwMDAwMCBmDQowMDAwMDAxMzU5IDAwMDAwIGYNCjAwMDAwMDEzNjAgMDAwMDAgZg0K MDAwMDAwMTM2MSAwMDAwMCBmDQowMDAwMDAxMzYyIDAwMDAwIGYNCjAwMDAwMDEzNjMgMDAwMDAg Zg0KMDAwMDAwMTM2NCAwMDAwMCBmDQowMDAwMDAxMzY1IDAwMDAwIGYNCjAwMDAwMDEzNjYgMDAw MDAgZg0KMDAwMDAwMTM2NyAwMDAwMCBmDQowMDAwMDAxMzY4IDAwMDAwIGYNCjAwMDAwMDEzNjkg MDAwMDAgZg0KMDAwMDAwMTM3MCAwMDAwMCBmDQowMDAwMDAxMzcxIDAwMDAwIGYNCjAwMDAwMDEz NzIgMDAwMDAgZg0KMDAwMDAwMTM3MyAwMDAwMCBmDQowMDAwMDAxMzc0IDAwMDAwIGYNCjAwMDAw MDEzNzUgMDAwMDAgZg0KMDAwMDAwMTM3NiAwMDAwMCBmDQowMDAwMDAxMzc3IDAwMDAwIGYNCjAw MDAwMDEzNzggMDAwMDAgZg0KMDAwMDAwMTM3OSAwMDAwMCBmDQowMDAwMDAxMzgwIDAwMDAwIGYN CjAwMDAwMDEzODEgMDAwMDAgZg0KMDAwMDAwMTM4MiAwMDAwMCBmDQowMDAwMDAxMzgzIDAwMDAw IGYNCjAwMDAwMDEzODQgMDAwMDAgZg0KMDAwMDAwMTM4NSAwMDAwMCBmDQowMDAwMDAxMzg2IDAw MDAwIGYNCjAwMDAwMDEzODcgMDAwMDAgZg0KMDAwMDAwMTM4OCAwMDAwMCBmDQowMDAwMDAxMzg5 IDAwMDAwIGYNCjAwMDAwMDEzOTAgMDAwMDAgZg0KMDAwMDAwMTM5MSAwMDAwMCBmDQowMDAwMDAx MzkyIDAwMDAwIGYNCjAwMDAwMDEzOTMgMDAwMDAgZg0KMDAwMDAwMTM5NCAwMDAwMCBmDQowMDAw MDAxMzk1IDAwMDAwIGYNCjAwMDAwMDEzOTYgMDAwMDAgZg0KMDAwMDAwMTM5NyAwMDAwMCBmDQow MDAwMDAxMzk4IDAwMDAwIGYNCjAwMDAwMDEzOTkgMDAwMDAgZg0KMDAwMDAwMTQwMCAwMDAwMCBm DQowMDAwMDAxNDAxIDAwMDAwIGYNCjAwMDAwMDE0MDIgMDAwMDAgZg0KMDAwMDAwMTQwMyAwMDAw MCBmDQowMDAwMDAxNDA0IDAwMDAwIGYNCjAwMDAwMDE0MDUgMDAwMDAgZg0KMDAwMDAwMTQwNiAw MDAwMCBmDQowMDAwMDAxNDA3IDAwMDAwIGYNCjAwMDAwMDE0MDggMDAwMDAgZg0KMDAwMDAwMTQw OSAwMDAwMCBmDQowMDAwMDAxNDEwIDAwMDAwIGYNCjAwMDAwMDE0MTEgMDAwMDAgZg0KMDAwMDAw MTQxMiAwMDAwMCBmDQowMDAwMDAxNDEzIDAwMDAwIGYNCjAwMDAwMDE0MTQgMDAwMDAgZg0KMDAw MDAwMTQxNSAwMDAwMCBmDQowMDAwMDAxNDE2IDAwMDAwIGYNCjAwMDAwMDE0MTcgMDAwMDAgZg0K MDAwMDAwMTQxOCAwMDAwMCBmDQowMDAwMDAxNDE5IDAwMDAwIGYNCjAwMDAwMDE0MjAgMDAwMDAg Zg0KMDAwMDAwMTQyMSAwMDAwMCBmDQowMDAwMDAxNDIyIDAwMDAwIGYNCjAwMDAwMDE0MjMgMDAw MDAgZg0KMDAwMDAwMTQyNCAwMDAwMCBmDQowMDAwMDAxNDI1IDAwMDAwIGYNCjAwMDAwMDE0MjYg MDAwMDAgZg0KMDAwMDAwMTQyNyAwMDAwMCBmDQowMDAwMDAxNDI4IDAwMDAwIGYNCjAwMDAwMDE0 MjkgMDAwMDAgZg0KMDAwMDAwMTQzMCAwMDAwMCBmDQowMDAwMDAxNDMxIDAwMDAwIGYNCjAwMDAw MDE0MzIgMDAwMDAgZg0KMDAwMDAwMTQzMyAwMDAwMCBmDQowMDAwMDAxNDM0IDAwMDAwIGYNCjAw MDAwMDE0MzUgMDAwMDAgZg0KMDAwMDAwMTQzNiAwMDAwMCBmDQowMDAwMDAxNDM3IDAwMDAwIGYN CjAwMDAwMDE0MzggMDAwMDAgZg0KMDAwMDAwMTQzOSAwMDAwMCBmDQowMDAwMDAxNDQwIDAwMDAw IGYNCjAwMDAwMDE0NDEgMDAwMDAgZg0KMDAwMDAwMTQ0MiAwMDAwMCBmDQowMDAwMDAxNDQzIDAw MDAwIGYNCjAwMDAwMDE0NDQgMDAwMDAgZg0KMDAwMDAwMTQ0NSAwMDAwMCBmDQowMDAwMDAxNDQ2 IDAwMDAwIGYNCjAwMDAwMDE0NDcgMDAwMDAgZg0KMDAwMDAwMTQ0OCAwMDAwMCBmDQowMDAwMDAx NDQ5IDAwMDAwIGYNCjAwMDAwMDE0NTAgMDAwMDAgZg0KMDAwMDAwMTQ1MSAwMDAwMCBmDQowMDAw MDAxNDUyIDAwMDAwIGYNCjAwMDAwMDE0NTMgMDAwMDAgZg0KMDAwMDAwMTQ1NCAwMDAwMCBmDQow MDAwMDAxNDU1IDAwMDAwIGYNCjAwMDAwMDE0NTYgMDAwMDAgZg0KMDAwMDAwMTQ1NyAwMDAwMCBm DQowMDAwMDAxNDU4IDAwMDAwIGYNCjAwMDAwMDE0NTkgMDAwMDAgZg0KMDAwMDAwMTQ2MCAwMDAw MCBmDQowMDAwMDAxNDYxIDAwMDAwIGYNCjAwMDAwMDE0NjIgMDAwMDAgZg0KMDAwMDAwMTQ2MyAw MDAwMCBmDQowMDAwMDAxNDY0IDAwMDAwIGYNCjAwMDAwMDE0NjUgMDAwMDAgZg0KMDAwMDAwMTQ2 NiAwMDAwMCBmDQowMDAwMDAxNDY3IDAwMDAwIGYNCjAwMDAwMDE0NjggMDAwMDAgZg0KMDAwMDAw MTQ2OSAwMDAwMCBmDQowMDAwMDAxNDcwIDAwMDAwIGYNCjAwMDAwMDE0NzEgMDAwMDAgZg0KMDAw MDAwMTQ3MiAwMDAwMCBmDQowMDAwMDAxNDczIDAwMDAwIGYNCjAwMDAwMDE0NzQgMDAwMDAgZg0K MDAwMDAwMTQ3NSAwMDAwMCBmDQowMDAwMDAxNDc2IDAwMDAwIGYNCjAwMDAwMDE0NzcgMDAwMDAg Zg0KMDAwMDAwMTQ3OCAwMDAwMCBmDQowMDAwMDAxNDc5IDAwMDAwIGYNCjAwMDAwMDE0ODAgMDAw MDAgZg0KMDAwMDAwMTQ4MSAwMDAwMCBmDQowMDAwMDAxNDgyIDAwMDAwIGYNCjAwMDAwMDE0ODMg MDAwMDAgZg0KMDAwMDAwMTQ4NCAwMDAwMCBmDQowMDAwMDAxNDg1IDAwMDAwIGYNCjAwMDAwMDE0 ODYgMDAwMDAgZg0KMDAwMDAwMTQ4NyAwMDAwMCBmDQowMDAwMDAxNDg4IDAwMDAwIGYNCjAwMDAw MDE0ODkgMDAwMDAgZg0KMDAwMDAwMTQ5MCAwMDAwMCBmDQowMDAwMDAxNDkxIDAwMDAwIGYNCjAw MDAwMDE0OTIgMDAwMDAgZg0KMDAwMDAwMTQ5MyAwMDAwMCBmDQowMDAwMDAxNDk0IDAwMDAwIGYN CjAwMDAwMDE0OTUgMDAwMDAgZg0KMDAwMDAwMTQ5NiAwMDAwMCBmDQowMDAwMDAxNDk3IDAwMDAw IGYNCjAwMDAwMDE0OTggMDAwMDAgZg0KMDAwMDAwMTQ5OSAwMDAwMCBmDQowMDAwMDAxNTAwIDAw MDAwIGYNCjAwMDAwMDE1MDEgMDAwMDAgZg0KMDAwMDAwMTUwMiAwMDAwMCBmDQowMDAwMDAxNTAz IDAwMDAwIGYNCjAwMDAwMDE1MDQgMDAwMDAgZg0KMDAwMDAwMTUwNSAwMDAwMCBmDQowMDAwMDAx NTA2IDAwMDAwIGYNCjAwMDAwMDE1MDcgMDAwMDAgZg0KMDAwMDAwMTUwOCAwMDAwMCBmDQowMDAw MDAxNTA5IDAwMDAwIGYNCjAwMDAwMDE1MTAgMDAwMDAgZg0KMDAwMDAwMTUxMSAwMDAwMCBmDQow MDAwMDAxNTEyIDAwMDAwIGYNCjAwMDAwMDE1MTMgMDAwMDAgZg0KMDAwMDAwMTUxNCAwMDAwMCBm DQowMDAwMDAxNTE1IDAwMDAwIGYNCjAwMDAwMDE1MTYgMDAwMDAgZg0KMDAwMDAwMTUxNyAwMDAw MCBmDQowMDAwMDAxNTE4IDAwMDAwIGYNCjAwMDAwMDE1MTkgMDAwMDAgZg0KMDAwMDAwMTUyMCAw MDAwMCBmDQowMDAwMDAxNTIxIDAwMDAwIGYNCjAwMDAwMDE1MjIgMDAwMDAgZg0KMDAwMDAwMTUy MyAwMDAwMCBmDQowMDAwMDAxNTI0IDAwMDAwIGYNCjAwMDAwMDE1MjUgMDAwMDAgZg0KMDAwMDAw MTUyNiAwMDAwMCBmDQowMDAwMDAxNTI3IDAwMDAwIGYNCjAwMDAwMDE1MjggMDAwMDAgZg0KMDAw MDAwMTUyOSAwMDAwMCBmDQowMDAwMDAxNTMwIDAwMDAwIGYNCjAwMDAwMDE1MzEgMDAwMDAgZg0K MDAwMDAwMTUzMiAwMDAwMCBmDQowMDAwMDAxNTMzIDAwMDAwIGYNCjAwMDAwMDE1MzQgMDAwMDAg Zg0KMDAwMDAwMTUzNSAwMDAwMCBmDQowMDAwMDAxNTM2IDAwMDAwIGYNCjAwMDAwMDE1MzcgMDAw MDAgZg0KMDAwMDAwMTUzOCAwMDAwMCBmDQowMDAwMDAxNTM5IDAwMDAwIGYNCjAwMDAwMDE1NDAg MDAwMDAgZg0KMDAwMDAwMTU0MSAwMDAwMCBmDQowMDAwMDAxNTQyIDAwMDAwIGYNCjAwMDAwMDE1 NDMgMDAwMDAgZg0KMDAwMDAwMTU0NCAwMDAwMCBmDQowMDAwMDAxNTQ1IDAwMDAwIGYNCjAwMDAw MDE1NDYgMDAwMDAgZg0KMDAwMDAwMTU0NyAwMDAwMCBmDQowMDAwMDAxNTQ4IDAwMDAwIGYNCjAw MDAwMDE1NDkgMDAwMDAgZg0KMDAwMDAwMTU1MCAwMDAwMCBmDQowMDAwMDAxNTUxIDAwMDAwIGYN CjAwMDAwMDE1NTIgMDAwMDAgZg0KMDAwMDAwMTU1MyAwMDAwMCBmDQowMDAwMDAxNTU0IDAwMDAw IGYNCjAwMDAwMDE1NTUgMDAwMDAgZg0KMDAwMDAwMTU1NiAwMDAwMCBmDQowMDAwMDAxNTU3IDAw MDAwIGYNCjAwMDAwMDE1NTggMDAwMDAgZg0KMDAwMDAwMTU1OSAwMDAwMCBmDQowMDAwMDAxNTYw IDAwMDAwIGYNCjAwMDAwMDE1NjEgMDAwMDAgZg0KMDAwMDAwMTU2MiAwMDAwMCBmDQowMDAwMDAx NTYzIDAwMDAwIGYNCjAwMDAwMDE1NjQgMDAwMDAgZg0KMDAwMDAwMTU2NSAwMDAwMCBmDQowMDAw MDAxNTY2IDAwMDAwIGYNCjAwMDAwMDE1NjcgMDAwMDAgZg0KMDAwMDAwMTU2OCAwMDAwMCBmDQow MDAwMDAxNTY5IDAwMDAwIGYNCjAwMDAwMDE1NzAgMDAwMDAgZg0KMDAwMDAwMTU3MSAwMDAwMCBm DQowMDAwMDAxNTcyIDAwMDAwIGYNCjAwMDAwMDE1NzMgMDAwMDAgZg0KMDAwMDAwMTU3NCAwMDAw MCBmDQowMDAwMDAxNTc1IDAwMDAwIGYNCjAwMDAwMDE1NzYgMDAwMDAgZg0KMDAwMDAwMTU3NyAw MDAwMCBmDQowMDAwMDAxNTc4IDAwMDAwIGYNCjAwMDAwMDE1NzkgMDAwMDAgZg0KMDAwMDAwMTU4 MCAwMDAwMCBmDQowMDAwMDAxNTgxIDAwMDAwIGYNCjAwMDAwMDE1ODIgMDAwMDAgZg0KMDAwMDAw MTU4MyAwMDAwMCBmDQowMDAwMDAxNTg0IDAwMDAwIGYNCjAwMDAwMDE1ODUgMDAwMDAgZg0KMDAw MDAwMTU4NiAwMDAwMCBmDQowMDAwMDAxNTg3IDAwMDAwIGYNCjAwMDAwMDE1ODggMDAwMDAgZg0K MDAwMDAwMTU4OSAwMDAwMCBmDQowMDAwMDAxNTkwIDAwMDAwIGYNCjAwMDAwMDE1OTEgMDAwMDAg Zg0KMDAwMDAwMTU5MiAwMDAwMCBmDQowMDAwMDAxNTkzIDAwMDAwIGYNCjAwMDAwMDE1OTQgMDAw MDAgZg0KMDAwMDAwMTU5NSAwMDAwMCBmDQowMDAwMDAxNTk2IDAwMDAwIGYNCjAwMDAwMDE1OTcg MDAwMDAgZg0KMDAwMDAwMTU5OCAwMDAwMCBmDQowMDAwMDAxNTk5IDAwMDAwIGYNCjAwMDAwMDE2 MDAgMDAwMDAgZg0KMDAwMDAwMTYwMSAwMDAwMCBmDQowMDAwMDAxNjAyIDAwMDAwIGYNCjAwMDAw MDE2MDMgMDAwMDAgZg0KMDAwMDAwMTYwNCAwMDAwMCBmDQowMDAwMDAxNjA1IDAwMDAwIGYNCjAw MDAwMDE2MDYgMDAwMDAgZg0KMDAwMDAwMTYwNyAwMDAwMCBmDQowMDAwMDAxNjA4IDAwMDAwIGYN CjAwMDAwMDE2MDkgMDAwMDAgZg0KMDAwMDAwMTYxMCAwMDAwMCBmDQowMDAwMDAxNjExIDAwMDAw IGYNCjAwMDAwMDE2MTIgMDAwMDAgZg0KMDAwMDAwMTYxMyAwMDAwMCBmDQowMDAwMDAxNjE0IDAw MDAwIGYNCjAwMDAwMDE2MTUgMDAwMDAgZg0KMDAwMDAwMTYxNiAwMDAwMCBmDQowMDAwMDAxNjE3 IDAwMDAwIGYNCjAwMDAwMDE2MTggMDAwMDAgZg0KMDAwMDAwMTYxOSAwMDAwMCBmDQowMDAwMDAx NjIwIDAwMDAwIGYNCjAwMDAwMDE2MjEgMDAwMDAgZg0KMDAwMDAwMTYyMiAwMDAwMCBmDQowMDAw MDAxNjIzIDAwMDAwIGYNCjAwMDAwMDE2MjQgMDAwMDAgZg0KMDAwMDAwMTYyNSAwMDAwMCBmDQow MDAwMDAxNjI2IDAwMDAwIGYNCjAwMDAwMDE2MjcgMDAwMDAgZg0KMDAwMDAwMTYyOCAwMDAwMCBm DQowMDAwMDAxNjI5IDAwMDAwIGYNCjAwMDAwMDE2MzAgMDAwMDAgZg0KMDAwMDAwMTYzMSAwMDAw MCBmDQowMDAwMDAxNjMyIDAwMDAwIGYNCjAwMDAwMDE2MzMgMDAwMDAgZg0KMDAwMDAwMTYzNCAw MDAwMCBmDQowMDAwMDAxNjM1IDAwMDAwIGYNCjAwMDAwMDE2MzYgMDAwMDAgZg0KMDAwMDAwMTYz NyAwMDAwMCBmDQowMDAwMDAxNjM4IDAwMDAwIGYNCjAwMDAwMDE2MzkgMDAwMDAgZg0KMDAwMDAw MTY0MCAwMDAwMCBmDQowMDAwMDAxNjQxIDAwMDAwIGYNCjAwMDAwMDE2NDIgMDAwMDAgZg0KMDAw MDAwMTY0MyAwMDAwMCBmDQowMDAwMDAxNjQ0IDAwMDAwIGYNCjAwMDAwMDE2NDUgMDAwMDAgZg0K MDAwMDAwMTY0NiAwMDAwMCBmDQowMDAwMDAxNjQ3IDAwMDAwIGYNCjAwMDAwMDE2NDggMDAwMDAg Zg0KMDAwMDAwMTY0OSAwMDAwMCBmDQowMDAwMDAxNjUwIDAwMDAwIGYNCjAwMDAwMDE2NTEgMDAw MDAgZg0KMDAwMDAwMTY1MiAwMDAwMCBmDQowMDAwMDAxNjUzIDAwMDAwIGYNCjAwMDAwMDE2NTQg MDAwMDAgZg0KMDAwMDAwMTY1NSAwMDAwMCBmDQowMDAwMDAxNjU2IDAwMDAwIGYNCjAwMDAwMDE2 NTcgMDAwMDAgZg0KMDAwMDAwMTY1OCAwMDAwMCBmDQowMDAwMDAxNjU5IDAwMDAwIGYNCjAwMDAw MDE2NjAgMDAwMDAgZg0KMDAwMDAwMTY2MSAwMDAwMCBmDQowMDAwMDAxNjYyIDAwMDAwIGYNCjAw MDAwMDE2NjMgMDAwMDAgZg0KMDAwMDAwMTY2NCAwMDAwMCBmDQowMDAwMDAxNjY1IDAwMDAwIGYN CjAwMDAwMDE2NjYgMDAwMDAgZg0KMDAwMDAwMTY2NyAwMDAwMCBmDQowMDAwMDAxNjY4IDAwMDAw IGYNCjAwMDAwMDE2NjkgMDAwMDAgZg0KMDAwMDAwMTY3MCAwMDAwMCBmDQowMDAwMDAxNjcxIDAw MDAwIGYNCjAwMDAwMDE2NzIgMDAwMDAgZg0KMDAwMDAwMTY3MyAwMDAwMCBmDQowMDAwMDAxNjc0 IDAwMDAwIGYNCjAwMDAwMDE2NzUgMDAwMDAgZg0KMDAwMDAwMTY3NiAwMDAwMCBmDQowMDAwMDAx Njc3IDAwMDAwIGYNCjAwMDAwMDE2NzggMDAwMDAgZg0KMDAwMDAwMTY3OSAwMDAwMCBmDQowMDAw MDAxNjgwIDAwMDAwIGYNCjAwMDAwMDE2ODEgMDAwMDAgZg0KMDAwMDAwMTY4MiAwMDAwMCBmDQow MDAwMDAxNjgzIDAwMDAwIGYNCjAwMDAwMDE2ODQgMDAwMDAgZg0KMDAwMDAwMTY4NSAwMDAwMCBm DQowMDAwMDAxNjg2IDAwMDAwIGYNCjAwMDAwMDE2ODcgMDAwMDAgZg0KMDAwMDAwMTY4OCAwMDAw MCBmDQowMDAwMDAxNjg5IDAwMDAwIGYNCjAwMDAwMDE2OTAgMDAwMDAgZg0KMDAwMDAwMTY5MSAw MDAwMCBmDQowMDAwMDAxNjkyIDAwMDAwIGYNCjAwMDAwMDE2OTMgMDAwMDAgZg0KMDAwMDAwMTY5 NCAwMDAwMCBmDQowMDAwMDAxNjk1IDAwMDAwIGYNCjAwMDAwMDE2OTYgMDAwMDAgZg0KMDAwMDAw MTY5NyAwMDAwMCBmDQowMDAwMDAxNjk4IDAwMDAwIGYNCjAwMDAwMDE2OTkgMDAwMDAgZg0KMDAw MDAwMTcwMCAwMDAwMCBmDQowMDAwMDAxNzAxIDAwMDAwIGYNCjAwMDAwMDE3MDIgMDAwMDAgZg0K MDAwMDAwMTcwMyAwMDAwMCBmDQowMDAwMDAxNzA0IDAwMDAwIGYNCjAwMDAwMDE3MDUgMDAwMDAg Zg0KMDAwMDAwMTcwNiAwMDAwMCBmDQowMDAwMDAxNzA3IDAwMDAwIGYNCjAwMDAwMDE3MDggMDAw MDAgZg0KMDAwMDAwMTcwOSAwMDAwMCBmDQowMDAwMDAxNzEwIDAwMDAwIGYNCjAwMDAwMDE3MTEg MDAwMDAgZg0KMDAwMDAwMTcxMiAwMDAwMCBmDQowMDAwMDAxNzEzIDAwMDAwIGYNCjAwMDAwMDE3 MTQgMDAwMDAgZg0KMDAwMDAwMTcxNSAwMDAwMCBmDQowMDAwMDAxNzE2IDAwMDAwIGYNCjAwMDAw MDE3MTcgMDAwMDAgZg0KMDAwMDAwMTcxOCAwMDAwMCBmDQowMDAwMDAxNzE5IDAwMDAwIGYNCjAw MDAwMDE3MjAgMDAwMDAgZg0KMDAwMDAwMTcyMSAwMDAwMCBmDQowMDAwMDAxNzIyIDAwMDAwIGYN CjAwMDAwMDE3MjMgMDAwMDAgZg0KMDAwMDAwMTcyNCAwMDAwMCBmDQowMDAwMDAxNzI1IDAwMDAw IGYNCjAwMDAwMDE3MjYgMDAwMDAgZg0KMDAwMDAwMTcyNyAwMDAwMCBmDQowMDAwMDAxNzI4IDAw MDAwIGYNCjAwMDAwMDE3MjkgMDAwMDAgZg0KMDAwMDAwMTczMCAwMDAwMCBmDQowMDAwMDAxNzMx IDAwMDAwIGYNCjAwMDAwMDE3MzIgMDAwMDAgZg0KMDAwMDAwMTczMyAwMDAwMCBmDQowMDAwMDAx NzM0IDAwMDAwIGYNCjAwMDAwMDE3MzUgMDAwMDAgZg0KMDAwMDAwMTczNiAwMDAwMCBmDQowMDAw MDAxNzM3IDAwMDAwIGYNCjAwMDAwMDE3MzggMDAwMDAgZg0KMDAwMDAwMTczOSAwMDAwMCBmDQow MDAwMDAxNzQwIDAwMDAwIGYNCjAwMDAwMDE3NDEgMDAwMDAgZg0KMDAwMDAwMTc0MiAwMDAwMCBm DQowMDAwMDAxNzQzIDAwMDAwIGYNCjAwMDAwMDE3NDQgMDAwMDAgZg0KMDAwMDAwMTc0NSAwMDAw MCBmDQowMDAwMDAxNzQ2IDAwMDAwIGYNCjAwMDAwMDE3NDcgMDAwMDAgZg0KMDAwMDAwMTc0OCAw MDAwMCBmDQowMDAwMDAxNzQ5IDAwMDAwIGYNCjAwMDAwMDE3NTAgMDAwMDAgZg0KMDAwMDAwMTc1 MSAwMDAwMCBmDQowMDAwMDAxNzUyIDAwMDAwIGYNCjAwMDAwMDE3NTMgMDAwMDAgZg0KMDAwMDAw MTc1NCAwMDAwMCBmDQowMDAwMDAxNzU1IDAwMDAwIGYNCjAwMDAwMDE3NTYgMDAwMDAgZg0KMDAw MDAwMTc1NyAwMDAwMCBmDQowMDAwMDAxNzU4IDAwMDAwIGYNCjAwMDAwMDE3NTkgMDAwMDAgZg0K MDAwMDAwMTc2MCAwMDAwMCBmDQowMDAwMDAxNzYxIDAwMDAwIGYNCjAwMDAwMDE3NjIgMDAwMDAg Zg0KMDAwMDAwMTc2MyAwMDAwMCBmDQowMDAwMDAxNzY0IDAwMDAwIGYNCjAwMDAwMDE3NjUgMDAw MDAgZg0KMDAwMDAwMTc2NiAwMDAwMCBmDQowMDAwMDAxNzY3IDAwMDAwIGYNCjAwMDAwMDE3Njgg MDAwMDAgZg0KMDAwMDAwMTc2OSAwMDAwMCBmDQowMDAwMDAxNzcwIDAwMDAwIGYNCjAwMDAwMDE3 NzEgMDAwMDAgZg0KMDAwMDAwMTc3MiAwMDAwMCBmDQowMDAwMDAxNzczIDAwMDAwIGYNCjAwMDAw MDE3NzQgMDAwMDAgZg0KMDAwMDAwMTc3NSAwMDAwMCBmDQowMDAwMDAxNzc2IDAwMDAwIGYNCjAw MDAwMDE3NzcgMDAwMDAgZg0KMDAwMDAwMTc3OCAwMDAwMCBmDQowMDAwMDAxNzc5IDAwMDAwIGYN CjAwMDAwMDE3ODAgMDAwMDAgZg0KMDAwMDAwMTc4MSAwMDAwMCBmDQowMDAwMDAxNzgyIDAwMDAw IGYNCjAwMDAwMDE3ODMgMDAwMDAgZg0KMDAwMDAwMTc4NCAwMDAwMCBmDQowMDAwMDAxNzg1IDAw MDAwIGYNCjAwMDAwMDE3ODYgMDAwMDAgZg0KMDAwMDAwMTc4NyAwMDAwMCBmDQowMDAwMDAxNzg4 IDAwMDAwIGYNCjAwMDAwMDE3ODkgMDAwMDAgZg0KMDAwMDAwMTc5MCAwMDAwMCBmDQowMDAwMDAx NzkxIDAwMDAwIGYNCjAwMDAwMDE3OTIgMDAwMDAgZg0KMDAwMDAwMTc5MyAwMDAwMCBmDQowMDAw MDAxNzk0IDAwMDAwIGYNCjAwMDAwMDE3OTUgMDAwMDAgZg0KMDAwMDAwMTc5NiAwMDAwMCBmDQow MDAwMDAxNzk3IDAwMDAwIGYNCjAwMDAwMDE3OTggMDAwMDAgZg0KMDAwMDAwMTc5OSAwMDAwMCBm DQowMDAwMDAxODAwIDAwMDAwIGYNCjAwMDAwMDE4MDEgMDAwMDAgZg0KMDAwMDAwMTgwMiAwMDAw MCBmDQowMDAwMDAxODAzIDAwMDAwIGYNCjAwMDAwMDE4MDQgMDAwMDAgZg0KMDAwMDAwMTgwNSAw MDAwMCBmDQowMDAwMDAxODA2IDAwMDAwIGYNCjAwMDAwMDE4MDcgMDAwMDAgZg0KMDAwMDAwMTgw OCAwMDAwMCBmDQowMDAwMDAxODA5IDAwMDAwIGYNCjAwMDAwMDE4MTAgMDAwMDAgZg0KMDAwMDAw MTgxMSAwMDAwMCBmDQowMDAwMDAxODEyIDAwMDAwIGYNCjAwMDAwMDE4MTMgMDAwMDAgZg0KMDAw MDAwMTgxNCAwMDAwMCBmDQowMDAwMDAxODE1IDAwMDAwIGYNCjAwMDAwMDE4MTYgMDAwMDAgZg0K MDAwMDAwMTgxNyAwMDAwMCBmDQowMDAwMDAxODE4IDAwMDAwIGYNCjAwMDAwMDE4MTkgMDAwMDAg Zg0KMDAwMDAwMTgyMCAwMDAwMCBmDQowMDAwMDAxODIxIDAwMDAwIGYNCjAwMDAwMDE4MjIgMDAw MDAgZg0KMDAwMDAwMTgyMyAwMDAwMCBmDQowMDAwMDAxODI0IDAwMDAwIGYNCjAwMDAwMDE4MjUg MDAwMDAgZg0KMDAwMDAwMTgyNiAwMDAwMCBmDQowMDAwMDAxODI3IDAwMDAwIGYNCjAwMDAwMDE4 MjggMDAwMDAgZg0KMDAwMDAwMTgyOSAwMDAwMCBmDQowMDAwMDAxODMwIDAwMDAwIGYNCjAwMDAw MDE4MzEgMDAwMDAgZg0KMDAwMDAwMTgzMiAwMDAwMCBmDQowMDAwMDAxODMzIDAwMDAwIGYNCjAw MDAwMDE4MzQgMDAwMDAgZg0KMDAwMDAwMTgzNSAwMDAwMCBmDQowMDAwMDAxODM2IDAwMDAwIGYN CjAwMDAwMDE4MzcgMDAwMDAgZg0KMDAwMDAwMTgzOCAwMDAwMCBmDQowMDAwMDAxODM5IDAwMDAw IGYNCjAwMDAwMDE4NDAgMDAwMDAgZg0KMDAwMDAwMTg0MSAwMDAwMCBmDQowMDAwMDAxODQyIDAw MDAwIGYNCjAwMDAwMDE4NDMgMDAwMDAgZg0KMDAwMDAwMTg0NCAwMDAwMCBmDQowMDAwMDAxODQ1 IDAwMDAwIGYNCjAwMDAwMDE4NDYgMDAwMDAgZg0KMDAwMDAwMTg0NyAwMDAwMCBmDQowMDAwMDAx ODQ4IDAwMDAwIGYNCjAwMDAwMDE4NDkgMDAwMDAgZg0KMDAwMDAwMTg1MCAwMDAwMCBmDQowMDAw MDAxODUxIDAwMDAwIGYNCjAwMDAwMDE4NTIgMDAwMDAgZg0KMDAwMDAwMTg1MyAwMDAwMCBmDQow MDAwMDAxODU0IDAwMDAwIGYNCjAwMDAwMDE4NTUgMDAwMDAgZg0KMDAwMDAwMTg1NiAwMDAwMCBm DQowMDAwMDAxODU3IDAwMDAwIGYNCjAwMDAwMDE4NTggMDAwMDAgZg0KMDAwMDAwMTg1OSAwMDAw MCBmDQowMDAwMDAxODYwIDAwMDAwIGYNCjAwMDAwMDE4NjEgMDAwMDAgZg0KMDAwMDAwMTg2MiAw MDAwMCBmDQowMDAwMDAxODYzIDAwMDAwIGYNCjAwMDAwMDE4NjQgMDAwMDAgZg0KMDAwMDAwMTg2 NSAwMDAwMCBmDQowMDAwMDAxODY2IDAwMDAwIGYNCjAwMDAwMDE4NjcgMDAwMDAgZg0KMDAwMDAw MTg2OCAwMDAwMCBmDQowMDAwMDAxODY5IDAwMDAwIGYNCjAwMDAwMDE4NzAgMDAwMDAgZg0KMDAw MDAwMTg3MSAwMDAwMCBmDQowMDAwMDAxODcyIDAwMDAwIGYNCjAwMDAwMDE4NzMgMDAwMDAgZg0K MDAwMDAwMTg3NCAwMDAwMCBmDQowMDAwMDAxODc1IDAwMDAwIGYNCjAwMDAwMDE4NzYgMDAwMDAg Zg0KMDAwMDAwMTg3NyAwMDAwMCBmDQowMDAwMDAxODc4IDAwMDAwIGYNCjAwMDAwMDE4NzkgMDAw MDAgZg0KMDAwMDAwMTg4MCAwMDAwMCBmDQowMDAwMDAxODgxIDAwMDAwIGYNCjAwMDAwMDE4ODIg MDAwMDAgZg0KMDAwMDAwMTg4MyAwMDAwMCBmDQowMDAwMDAxODg0IDAwMDAwIGYNCjAwMDAwMDE4 ODUgMDAwMDAgZg0KMDAwMDAwMTg4NiAwMDAwMCBmDQowMDAwMDAxODg3IDAwMDAwIGYNCjAwMDAw MDE4ODggMDAwMDAgZg0KMDAwMDAwMTg4OSAwMDAwMCBmDQowMDAwMDAxODkwIDAwMDAwIGYNCjAw MDAwMDE4OTEgMDAwMDAgZg0KMDAwMDAwMTg5MiAwMDAwMCBmDQowMDAwMDAxODkzIDAwMDAwIGYN CjAwMDAwMDE4OTQgMDAwMDAgZg0KMDAwMDAwMTg5NSAwMDAwMCBmDQowMDAwMDAxODk2IDAwMDAw IGYNCjAwMDAwMDE4OTcgMDAwMDAgZg0KMDAwMDAwMTg5OCAwMDAwMCBmDQowMDAwMDAxODk5IDAw MDAwIGYNCjAwMDAwMDE5MDAgMDAwMDAgZg0KMDAwMDAwMTkwMSAwMDAwMCBmDQowMDAwMDAxOTAy IDAwMDAwIGYNCjAwMDAwMDE5MDMgMDAwMDAgZg0KMDAwMDAwMTkwNCAwMDAwMCBmDQowMDAwMDAx OTA1IDAwMDAwIGYNCjAwMDAwMDE5MDYgMDAwMDAgZg0KMDAwMDAwMTkwNyAwMDAwMCBmDQowMDAw MDAxOTA4IDAwMDAwIGYNCjAwMDAwMDE5MDkgMDAwMDAgZg0KMDAwMDAwMTkxMCAwMDAwMCBmDQow MDAwMDAxOTExIDAwMDAwIGYNCjAwMDAwMDE5MTIgMDAwMDAgZg0KMDAwMDAwMTkxMyAwMDAwMCBm DQowMDAwMDAxOTE0IDAwMDAwIGYNCjAwMDAwMDE5MTUgMDAwMDAgZg0KMDAwMDAwMTkxNiAwMDAw MCBmDQowMDAwMDAxOTE3IDAwMDAwIGYNCjAwMDAwMDE5MTggMDAwMDAgZg0KMDAwMDAwMTkxOSAw MDAwMCBmDQowMDAwMDAxOTIwIDAwMDAwIGYNCjAwMDAwMDE5MjEgMDAwMDAgZg0KMDAwMDAwMTky MiAwMDAwMCBmDQowMDAwMDAxOTIzIDAwMDAwIGYNCjAwMDAwMDE5MjQgMDAwMDAgZg0KMDAwMDAw MTkyNSAwMDAwMCBmDQowMDAwMDAxOTI2IDAwMDAwIGYNCjAwMDAwMDE5MjcgMDAwMDAgZg0KMDAw MDAwMTkyOCAwMDAwMCBmDQowMDAwMDAxOTI5IDAwMDAwIGYNCjAwMDAwMDE5MzAgMDAwMDAgZg0K MDAwMDAwMTkzMSAwMDAwMCBmDQowMDAwMDAxOTMyIDAwMDAwIGYNCjAwMDAwMDE5MzMgMDAwMDAg Zg0KMDAwMDAwMTkzNCAwMDAwMCBmDQowMDAwMDAxOTM1IDAwMDAwIGYNCjAwMDAwMDE5MzYgMDAw MDAgZg0KMDAwMDAwMTkzNyAwMDAwMCBmDQowMDAwMDAxOTM4IDAwMDAwIGYNCjAwMDAwMDE5Mzkg MDAwMDAgZg0KMDAwMDAwMTk0MCAwMDAwMCBmDQowMDAwMDAxOTQxIDAwMDAwIGYNCjAwMDAwMDE5 NDIgMDAwMDAgZg0KMDAwMDAwMTk0MyAwMDAwMCBmDQowMDAwMDAxOTQ0IDAwMDAwIGYNCjAwMDAw MDE5NDUgMDAwMDAgZg0KMDAwMDAwMTk0NiAwMDAwMCBmDQowMDAwMDAxOTQ3IDAwMDAwIGYNCjAw MDAwMDE5NDggMDAwMDAgZg0KMDAwMDAwMTk0OSAwMDAwMCBmDQowMDAwMDAxOTUwIDAwMDAwIGYN CjAwMDAwMDE5NTEgMDAwMDAgZg0KMDAwMDAwMTk1MiAwMDAwMCBmDQowMDAwMDAxOTUzIDAwMDAw IGYNCjAwMDAwMDE5NTQgMDAwMDAgZg0KMDAwMDAwMTk1NSAwMDAwMCBmDQowMDAwMDAxOTU2IDAw MDAwIGYNCjAwMDAwMDE5NTcgMDAwMDAgZg0KMDAwMDAwMTk1OCAwMDAwMCBmDQowMDAwMDAxOTU5 IDAwMDAwIGYNCjAwMDAwMDE5NjAgMDAwMDAgZg0KMDAwMDAwMTk2MSAwMDAwMCBmDQowMDAwMDAx OTYyIDAwMDAwIGYNCjAwMDAwMDE5NjMgMDAwMDAgZg0KMDAwMDAwMTk2NCAwMDAwMCBmDQowMDAw MDAxOTY1IDAwMDAwIGYNCjAwMDAwMDE5NjYgMDAwMDAgZg0KMDAwMDAwMTk2NyAwMDAwMCBmDQow MDAwMDAxOTY4IDAwMDAwIGYNCjAwMDAwMDE5NjkgMDAwMDAgZg0KMDAwMDAwMTk3MCAwMDAwMCBm DQowMDAwMDAxOTcxIDAwMDAwIGYNCjAwMDAwMDE5NzIgMDAwMDAgZg0KMDAwMDAwMTk3MyAwMDAw MCBmDQowMDAwMDAxOTc0IDAwMDAwIGYNCjAwMDAwMDE5NzUgMDAwMDAgZg0KMDAwMDAwMTk3NiAw MDAwMCBmDQowMDAwMDAxOTc3IDAwMDAwIGYNCjAwMDAwMDE5NzggMDAwMDAgZg0KMDAwMDAwMTk3 OSAwMDAwMCBmDQowMDAwMDAxOTgwIDAwMDAwIGYNCjAwMDAwMDE5ODEgMDAwMDAgZg0KMDAwMDAw MTk4MiAwMDAwMCBmDQowMDAwMDAxOTgzIDAwMDAwIGYNCjAwMDAwMDE5ODQgMDAwMDAgZg0KMDAw MDAwMTk4NSAwMDAwMCBmDQowMDAwMDAxOTg2IDAwMDAwIGYNCjAwMDAwMDE5ODcgMDAwMDAgZg0K MDAwMDAwMTk4OCAwMDAwMCBmDQowMDAwMDAxOTg5IDAwMDAwIGYNCjAwMDAwMDE5OTAgMDAwMDAg Zg0KMDAwMDAwMTk5MSAwMDAwMCBmDQowMDAwMDAxOTkyIDAwMDAwIGYNCjAwMDAwMDE5OTMgMDAw MDAgZg0KMDAwMDAwMTk5NCAwMDAwMCBmDQowMDAwMDAxOTk1IDAwMDAwIGYNCjAwMDAwMDE5OTYg MDAwMDAgZg0KMDAwMDAwMTk5NyAwMDAwMCBmDQowMDAwMDAxOTk4IDAwMDAwIGYNCjAwMDAwMDE5 OTkgMDAwMDAgZg0KMDAwMDAwMjAwMCAwMDAwMCBmDQowMDAwMDAyMDAxIDAwMDAwIGYNCjAwMDAw MDIwMDIgMDAwMDAgZg0KMDAwMDAwMjAwMyAwMDAwMCBmDQowMDAwMDAyMDA0IDAwMDAwIGYNCjAw MDAwMDIwMDUgMDAwMDAgZg0KMDAwMDAwMjAwNiAwMDAwMCBmDQowMDAwMDAyMDA3IDAwMDAwIGYN CjAwMDAwMDIwMDggMDAwMDAgZg0KMDAwMDAwMjAwOSAwMDAwMCBmDQowMDAwMDAyMDEwIDAwMDAw IGYNCjAwMDAwMDIwMTEgMDAwMDAgZg0KMDAwMDAwMjAxMiAwMDAwMCBmDQowMDAwMDAyMDEzIDAw MDAwIGYNCjAwMDAwMDIwMTQgMDAwMDAgZg0KMDAwMDAwMjAxNSAwMDAwMCBmDQowMDAwMDAyMDE2 IDAwMDAwIGYNCjAwMDAwMDIwMTcgMDAwMDAgZg0KMDAwMDAwMjAxOCAwMDAwMCBmDQowMDAwMDAy MDE5IDAwMDAwIGYNCjAwMDAwMDIwMjAgMDAwMDAgZg0KMDAwMDAwMjAyMSAwMDAwMCBmDQowMDAw MDAyMDIyIDAwMDAwIGYNCjAwMDAwMDIwMjMgMDAwMDAgZg0KMDAwMDAwMjAyNCAwMDAwMCBmDQow MDAwMDAyMDI1IDAwMDAwIGYNCjAwMDAwMDIwMjYgMDAwMDAgZg0KMDAwMDAwMjAyNyAwMDAwMCBm DQowMDAwMDAyMDI4IDAwMDAwIGYNCjAwMDAwMDIwMjkgMDAwMDAgZg0KMDAwMDAwMjAzMCAwMDAw MCBmDQowMDAwMDAyMDMxIDAwMDAwIGYNCjAwMDAwMDIwMzIgMDAwMDAgZg0KMDAwMDAwMjAzMyAw MDAwMCBmDQowMDAwMDAyMDM0IDAwMDAwIGYNCjAwMDAwMDIwMzUgMDAwMDAgZg0KMDAwMDAwMjAz NiAwMDAwMCBmDQowMDAwMDAyMDM3IDAwMDAwIGYNCjAwMDAwMDIwMzggMDAwMDAgZg0KMDAwMDAw MjAzOSAwMDAwMCBmDQowMDAwMDAyMDQwIDAwMDAwIGYNCjAwMDAwMDIwNDEgMDAwMDAgZg0KMDAw MDAwMjA0MiAwMDAwMCBmDQowMDAwMDAyMDQzIDAwMDAwIGYNCjAwMDAwMDIwNDQgMDAwMDAgZg0K MDAwMDAwMjA0NSAwMDAwMCBmDQowMDAwMDAyMDQ2IDAwMDAwIGYNCjAwMDAwMDIwNDcgMDAwMDAg Zg0KMDAwMDAwMjA0OCAwMDAwMCBmDQowMDAwMDAyMDQ5IDAwMDAwIGYNCjAwMDAwMDIwNTAgMDAw MDAgZg0KMDAwMDAwMjA1MSAwMDAwMCBmDQowMDAwMDAyMDUyIDAwMDAwIGYNCjAwMDAwMDIwNTMg MDAwMDAgZg0KMDAwMDAwMjA1NCAwMDAwMCBmDQowMDAwMDAyMDU1IDAwMDAwIGYNCjAwMDAwMDIw NTYgMDAwMDAgZg0KMDAwMDAwMjA1NyAwMDAwMCBmDQowMDAwMDAyMDU4IDAwMDAwIGYNCjAwMDAw MDIwNTkgMDAwMDAgZg0KMDAwMDAwMjA2MCAwMDAwMCBmDQowMDAwMDAyMDYxIDAwMDAwIGYNCjAw MDAwMDIwNjIgMDAwMDAgZg0KMDAwMDAwMjA2MyAwMDAwMCBmDQowMDAwMDAyMDY0IDAwMDAwIGYN CjAwMDAwMDIwNjUgMDAwMDAgZg0KMDAwMDAwMjA2NiAwMDAwMCBmDQowMDAwMDAyMDY3IDAwMDAw IGYNCjAwMDAwMDIwNjggMDAwMDAgZg0KMDAwMDAwMjA2OSAwMDAwMCBmDQowMDAwMDAyMDcwIDAw MDAwIGYNCjAwMDAwMDIwNzEgMDAwMDAgZg0KMDAwMDAwMjA3MiAwMDAwMCBmDQowMDAwMDAyMDcz IDAwMDAwIGYNCjAwMDAwMDIwNzQgMDAwMDAgZg0KMDAwMDAwMjA3NSAwMDAwMCBmDQowMDAwMDAy MDc2IDAwMDAwIGYNCjAwMDAwMDIwNzcgMDAwMDAgZg0KMDAwMDAwMjA3OCAwMDAwMCBmDQowMDAw MDAyMDc5IDAwMDAwIGYNCjAwMDAwMDIwODAgMDAwMDAgZg0KMDAwMDAwMjA4MSAwMDAwMCBmDQow MDAwMDAyMDgyIDAwMDAwIGYNCjAwMDAwMDIwODMgMDAwMDAgZg0KMDAwMDAwMjA4NCAwMDAwMCBm DQowMDAwMDAyMDg1IDAwMDAwIGYNCjAwMDAwMDIwODYgMDAwMDAgZg0KMDAwMDAwMjA4NyAwMDAw MCBmDQowMDAwMDAyMDg4IDAwMDAwIGYNCjAwMDAwMDIwODkgMDAwMDAgZg0KMDAwMDAwMjA5MCAw MDAwMCBmDQowMDAwMDAyMDkxIDAwMDAwIGYNCjAwMDAwMDIwOTIgMDAwMDAgZg0KMDAwMDAwMjA5 MyAwMDAwMCBmDQowMDAwMDAyMDk0IDAwMDAwIGYNCjAwMDAwMDIwOTUgMDAwMDAgZg0KMDAwMDAw MjA5NiAwMDAwMCBmDQowMDAwMDAyMDk3IDAwMDAwIGYNCjAwMDAwMDIwOTggMDAwMDAgZg0KMDAw MDAwMjA5OSAwMDAwMCBmDQowMDAwMDAyMTAwIDAwMDAwIGYNCjAwMDAwMDIxMDEgMDAwMDAgZg0K MDAwMDAwMjEwMiAwMDAwMCBmDQowMDAwMDAyMTAzIDAwMDAwIGYNCjAwMDAwMDIxMDQgMDAwMDAg Zg0KMDAwMDAwMjEwNSAwMDAwMCBmDQowMDAwMDAyMTA2IDAwMDAwIGYNCjAwMDAwMDIxMDcgMDAw MDAgZg0KMDAwMDAwMjEwOCAwMDAwMCBmDQowMDAwMDAyMTA5IDAwMDAwIGYNCjAwMDAwMDIxMTAg MDAwMDAgZg0KMDAwMDAwMjExMSAwMDAwMCBmDQowMDAwMDAyMTEyIDAwMDAwIGYNCjAwMDAwMDIx MTMgMDAwMDAgZg0KMDAwMDAwMjExNCAwMDAwMCBmDQowMDAwMDAyMTE1IDAwMDAwIGYNCjAwMDAw MDIxMTYgMDAwMDAgZg0KMDAwMDAwMjExNyAwMDAwMCBmDQowMDAwMDAyMTE4IDAwMDAwIGYNCjAw MDAwMDIxMTkgMDAwMDAgZg0KMDAwMDAwMjEyMCAwMDAwMCBmDQowMDAwMDAyMTIxIDAwMDAwIGYN CjAwMDAwMDIxMjIgMDAwMDAgZg0KMDAwMDAwMjEyMyAwMDAwMCBmDQowMDAwMDAyMTI0IDAwMDAw IGYNCjAwMDAwMDIxMjUgMDAwMDAgZg0KMDAwMDAwMjEyNiAwMDAwMCBmDQowMDAwMDAyMTI3IDAw MDAwIGYNCjAwMDAwMDIxMjggMDAwMDAgZg0KMDAwMDAwMjEyOSAwMDAwMCBmDQowMDAwMDAyMTMw IDAwMDAwIGYNCjAwMDAwMDIxMzEgMDAwMDAgZg0KMDAwMDAwMjEzMiAwMDAwMCBmDQowMDAwMDAy MTMzIDAwMDAwIGYNCjAwMDAwMDIxMzQgMDAwMDAgZg0KMDAwMDAwMjEzNSAwMDAwMCBmDQowMDAw MDAyMTM2IDAwMDAwIGYNCjAwMDAwMDIxMzcgMDAwMDAgZg0KMDAwMDAwMjEzOCAwMDAwMCBmDQow MDAwMDAyMTM5IDAwMDAwIGYNCjAwMDAwMDIxNDAgMDAwMDAgZg0KMDAwMDAwMjE0MSAwMDAwMCBm DQowMDAwMDAyMTQyIDAwMDAwIGYNCjAwMDAwMDIxNDMgMDAwMDAgZg0KMDAwMDAwMjE0NCAwMDAw MCBmDQowMDAwMDAyMTQ1IDAwMDAwIGYNCjAwMDAwMDIxNDYgMDAwMDAgZg0KMDAwMDAwMjE0NyAw MDAwMCBmDQowMDAwMDAyMTQ4IDAwMDAwIGYNCjAwMDAwMDIxNDkgMDAwMDAgZg0KMDAwMDAwMjE1 MCAwMDAwMCBmDQowMDAwMDAyMTUxIDAwMDAwIGYNCjAwMDAwMDIxNTIgMDAwMDAgZg0KMDAwMDAw MjE1MyAwMDAwMCBmDQowMDAwMDAyMTU0IDAwMDAwIGYNCjAwMDAwMDIxNTUgMDAwMDAgZg0KMDAw MDAwMjE1NiAwMDAwMCBmDQowMDAwMDAyMTU3IDAwMDAwIGYNCjAwMDAwMDIxNTggMDAwMDAgZg0K MDAwMDAwMjE1OSAwMDAwMCBmDQowMDAwMDAyMTYwIDAwMDAwIGYNCjAwMDAwMDIxNjEgMDAwMDAg Zg0KMDAwMDAwMjE2MiAwMDAwMCBmDQowMDAwMDAyMTYzIDAwMDAwIGYNCjAwMDAwMDIxNjQgMDAw MDAgZg0KMDAwMDAwMjE2NSAwMDAwMCBmDQowMDAwMDAyMTY2IDAwMDAwIGYNCjAwMDAwMDIxNjcg MDAwMDAgZg0KMDAwMDAwMjE2OCAwMDAwMCBmDQowMDAwMDAyMTY5IDAwMDAwIGYNCjAwMDAwMDIx NzAgMDAwMDAgZg0KMDAwMDAwMjE3MSAwMDAwMCBmDQowMDAwMDAyMTcyIDAwMDAwIGYNCjAwMDAw MDIxNzMgMDAwMDAgZg0KMDAwMDAwMjE3NCAwMDAwMCBmDQowMDAwMDAyMTc1IDAwMDAwIGYNCjAw MDAwMDIxNzYgMDAwMDAgZg0KMDAwMDAwMjE3NyAwMDAwMCBmDQowMDAwMDAyMTc4IDAwMDAwIGYN CjAwMDAwMDIxNzkgMDAwMDAgZg0KMDAwMDAwMjE4MCAwMDAwMCBmDQowMDAwMDAyMTgxIDAwMDAw IGYNCjAwMDAwMDIxODIgMDAwMDAgZg0KMDAwMDAwMjE4MyAwMDAwMCBmDQowMDAwMDAyMTg0IDAw MDAwIGYNCjAwMDAwMDIxODUgMDAwMDAgZg0KMDAwMDAwMjE4NiAwMDAwMCBmDQowMDAwMDAyMTg3 IDAwMDAwIGYNCjAwMDAwMDIxODggMDAwMDAgZg0KMDAwMDAwMjE4OSAwMDAwMCBmDQowMDAwMDAy MTkwIDAwMDAwIGYNCjAwMDAwMDIxOTEgMDAwMDAgZg0KMDAwMDAwMjE5MiAwMDAwMCBmDQowMDAw MDAyMTkzIDAwMDAwIGYNCjAwMDAwMDIxOTQgMDAwMDAgZg0KMDAwMDAwMjE5NSAwMDAwMCBmDQow MDAwMDAyMTk2IDAwMDAwIGYNCjAwMDAwMDIxOTcgMDAwMDAgZg0KMDAwMDAwMjE5OCAwMDAwMCBm DQowMDAwMDAyMTk5IDAwMDAwIGYNCjAwMDAwMDIyMDAgMDAwMDAgZg0KMDAwMDAwMjIwMSAwMDAw MCBmDQowMDAwMDAyMjAyIDAwMDAwIGYNCjAwMDAwMDIyMDMgMDAwMDAgZg0KMDAwMDAwMjIwNCAw MDAwMCBmDQowMDAwMDAyMjA1IDAwMDAwIGYNCjAwMDAwMDIyMDYgMDAwMDAgZg0KMDAwMDAwMjIw NyAwMDAwMCBmDQowMDAwMDAyMjA4IDAwMDAwIGYNCjAwMDAwMDIyMDkgMDAwMDAgZg0KMDAwMDAw MjIxMCAwMDAwMCBmDQowMDAwMDAyMjExIDAwMDAwIGYNCjAwMDAwMDIyMTIgMDAwMDAgZg0KMDAw MDAwMjIxMyAwMDAwMCBmDQowMDAwMDAyMjE0IDAwMDAwIGYNCjAwMDAwMDIyMTUgMDAwMDAgZg0K MDAwMDAwMjIxNiAwMDAwMCBmDQowMDAwMDAyMjE3IDAwMDAwIGYNCjAwMDAwMDIyMTggMDAwMDAg Zg0KMDAwMDAwMjIxOSAwMDAwMCBmDQowMDAwMDAyMjIwIDAwMDAwIGYNCjAwMDAwMDIyMjEgMDAw MDAgZg0KMDAwMDAwMjIyMiAwMDAwMCBmDQowMDAwMDAyMjIzIDAwMDAwIGYNCjAwMDAwMDIyMjQg MDAwMDAgZg0KMDAwMDAwMjIyNSAwMDAwMCBmDQowMDAwMDAyMjI2IDAwMDAwIGYNCjAwMDAwMDIy MjcgMDAwMDAgZg0KMDAwMDAwMjIyOCAwMDAwMCBmDQowMDAwMDAyMjI5IDAwMDAwIGYNCjAwMDAw MDIyMzAgMDAwMDAgZg0KMDAwMDAwMjIzMSAwMDAwMCBmDQowMDAwMDAyMjMyIDAwMDAwIGYNCjAw MDAwMDIyMzMgMDAwMDAgZg0KMDAwMDAwMjIzNCAwMDAwMCBmDQowMDAwMDAyMjM1IDAwMDAwIGYN CjAwMDAwMDIyMzYgMDAwMDAgZg0KMDAwMDAwMjIzNyAwMDAwMCBmDQowMDAwMDAyMjM4IDAwMDAw IGYNCjAwMDAwMDIyMzkgMDAwMDAgZg0KMDAwMDAwMjI0MCAwMDAwMCBmDQowMDAwMDAyMjQxIDAw MDAwIGYNCjAwMDAwMDIyNDIgMDAwMDAgZg0KMDAwMDAwMjI0MyAwMDAwMCBmDQowMDAwMDAyMjQ0 IDAwMDAwIGYNCjAwMDAwMDIyNDUgMDAwMDAgZg0KMDAwMDAwMjI0NiAwMDAwMCBmDQowMDAwMDAy MjQ3IDAwMDAwIGYNCjAwMDAwMDIyNDggMDAwMDAgZg0KMDAwMDAwMjI0OSAwMDAwMCBmDQowMDAw MDAyMjUwIDAwMDAwIGYNCjAwMDAwMDIyNTEgMDAwMDAgZg0KMDAwMDAwMjI1MiAwMDAwMCBmDQow MDAwMDAyMjUzIDAwMDAwIGYNCjAwMDAwMDIyNTQgMDAwMDAgZg0KMDAwMDAwMjI1NSAwMDAwMCBm DQowMDAwMDAyMjU2IDAwMDAwIGYNCjAwMDAwMDIyNTcgMDAwMDAgZg0KMDAwMDAwMjI1OCAwMDAw MCBmDQowMDAwMDAyMjU5IDAwMDAwIGYNCjAwMDAwMDIyNjAgMDAwMDAgZg0KMDAwMDAwMjI2MSAw MDAwMCBmDQowMDAwMDAyMjYyIDAwMDAwIGYNCjAwMDAwMDIyNjMgMDAwMDAgZg0KMDAwMDAwMjI2 NCAwMDAwMCBmDQowMDAwMDAyMjY1IDAwMDAwIGYNCjAwMDAwMDIyNjYgMDAwMDAgZg0KMDAwMDAw MjI2NyAwMDAwMCBmDQowMDAwMDAyMjY4IDAwMDAwIGYNCjAwMDAwMDIyNjkgMDAwMDAgZg0KMDAw MDAwMjI3MCAwMDAwMCBmDQowMDAwMDAyMjcxIDAwMDAwIGYNCjAwMDAwMDIyNzIgMDAwMDAgZg0K MDAwMDAwMjI3MyAwMDAwMCBmDQowMDAwMDAyMjc0IDAwMDAwIGYNCjAwMDAwMDIyNzUgMDAwMDAg Zg0KMDAwMDAwMjI3NyAwMDAwMCBmDQowMDAwMjg3NDc5IDAwMDAwIG4NCjAwMDAwMDIyNzggMDAw MDAgZg0KMDAwMDAwMjI3OSAwMDAwMCBmDQowMDAwMDAyMjgwIDAwMDAwIGYNCjAwMDAwMDIyODIg MDAwMDAgZg0KMDAwMDI4NzczMiAwMDAwMCBuDQowMDAwMDAyMjgzIDAwMDAwIGYNCjAwMDAwMDIy ODQgMDAwMDAgZg0KMDAwMDAwMjI4NSAwMDAwMCBmDQowMDAwMDAyMjg2IDAwMDAwIGYNCjAwMDAw MDIyODcgMDAwMDAgZg0KMDAwMDAwMjI4OCAwMDAwMCBmDQowMDAwMDAyMjg5IDAwMDAwIGYNCjAw MDAwMDIyOTAgMDAwMDAgZg0KMDAwMDAwMjI5MSAwMDAwMCBmDQowMDAwMDAyMjkzIDAwMDAwIGYN CjAwMDAyODc5NzYgMDAwMDAgbg0KMDAwMDAwMjI5NCAwMDAwMCBmDQowMDAwMDAyMjk1IDAwMDAw IGYNCjAwMDAwMDIyOTYgMDAwMDAgZg0KMDAwMDAwMjI5NyAwMDAwMCBmDQowMDAwMDAyMjk4IDAw MDAwIGYNCjAwMDAwMDIyOTkgMDAwMDAgZg0KMDAwMDAwMjMwMCAwMDAwMCBmDQowMDAwMDAyMzAx IDAwMDAwIGYNCjAwMDAwMDIzMDIgMDAwMDAgZg0KMDAwMDAwMjMwMyAwMDAwMCBmDQowMDAwMDAy MzA0IDAwMDAwIGYNCjAwMDAwMDIzMDUgMDAwMDAgZg0KMDAwMDAwMjMwNiAwMDAwMCBmDQowMDAw MDAyMzA3IDAwMDAwIGYNCjAwMDAwMDIzMDkgMDAwMDAgZg0KMDAwMDI4ODIyNiAwMDAwMCBuDQow MDAwMDAyMzEwIDAwMDAwIGYNCjAwMDAwMDIzMTEgMDAwMDAgZg0KMDAwMDAwMjMxMiAwMDAwMCBm DQowMDAwMDAyMzEzIDAwMDAwIGYNCjAwMDAwMDIzMTQgMDAwMDAgZg0KMDAwMDAwMjMxNSAwMDAw MCBmDQowMDAwMDAyMzE2IDAwMDAwIGYNCjAwMDAwMDIzMTcgMDAwMDAgZg0KMDAwMDAwMjMxOCAw MDAwMCBmDQowMDAwMDAyMzE5IDAwMDAwIGYNCjAwMDAwMDIzMjAgMDAwMDAgZg0KMDAwMDAwMjMy MSAwMDAwMCBmDQowMDAwMDAyMzIyIDAwMDAwIGYNCjAwMDAwMDIzMjMgMDAwMDAgZg0KMDAwMDAw MjMyNCAwMDAwMCBmDQowMDAwMDAyMzI1IDAwMDAwIGYNCjAwMDAwMDIzMjYgMDAwMDAgZg0KMDAw MDAwMjMyNyAwMDAwMCBmDQowMDAwMDAyMzI4IDAwMDAwIGYNCjAwMDAwMDIzMjkgMDAwMDAgZg0K MDAwMDAwMjMzMCAwMDAwMCBmDQowMDAwMDAyMzMxIDAwMDAwIGYNCjAwMDAwMDIzNDAgMDAwMDAg Zg0KMDAwMDI4ODQ1NiAwMDAwMCBuDQowMDAwMjg4ODE5IDAwMDAwIG4NCjAwMDAyODkzMzcgMDAw MDAgbg0KMDAwMDI4OTg5NSAwMDAwMCBuDQowMDAwMjkwMDQ2IDAwMDAwIG4NCjAwMDAyOTA1NDIg MDAwMDAgbg0KMDAwMDI5MDY4NiAwMDAwMCBuDQowMDAwMjkxMDU2IDAwMDAwIG4NCjAwMDAwMDIz NDEgMDAwMDAgZg0KMDAwMDAwMjM0MyAwMDAwMCBmDQowMDAwMjkxMjA1IDAwMDAwIG4NCjAwMDAw MDIzNDQgMDAwMDAgZg0KMDAwMDAwMjM0NyAwMDAwMSBmDQowMDAwMjkxNTgzIDAwMDAwIG4NCjAw MDAyOTIxNzMgMDAwMDAgbg0KMDAwMDAwMjM1MCAwMDAwMCBmDQowMDAwMjkyNzIzIDAwMDAwIG4N CjAwMDAyOTI3NDkgMDAwMDAgbg0KMDAwMDAwMjM1MSAwMDAwMCBmDQowMDAwMDAyMzUyIDAwMDAx IGYNCjAwMDAwMDIzNTMgMDAwMDAgZg0KMDAwMDAwMjM1NSAwMDAwMCBmDQowMDAwMjkzMzYzIDAw MDAwIG4NCjAwMDAwMDIzNTcgMDAwMDAgZg0KMDAwMDI5Mzc0MSAwMDAwMCBuDQowMDAwMDAyMzYw IDAwMDAwIGYNCjAwMDAyOTQzMjUgMDAwMDAgbg0KMDAwMDI5NDM1MSAwMDAwMCBuDQowMDAwMDAy MzYxIDAwMDAwIGYNCjAwMDAwMDIzNjIgMDAwMDEgZg0KMDAwMDAwMjM2MyAwMDAwMCBmDQowMDAw MDAyMzY0IDAwMDAwIGYNCjAwMDAwMDIzNjUgMDAwMDAgZg0KMDAwMDAwMjM2NiAwMDAwMCBmDQow MDAwMDAyMzY3IDAwMDAwIGYNCjAwMDAwMDIzNzIgMDAwMDAgZg0KMDAwMDI5NDk4OCAwMDAwMCBu DQowMDAwMjk1MzU4IDAwMDAwIG4NCjAwMDAyOTU3MzYgMDAwMDAgbg0KMDAwMDI5NjE2MyAwMDAw MCBuDQowMDAwMDAyMzczIDAwMDAwIGYNCjAwMDAwMDIzNzQgMDAwMDAgZg0KMDAwMDAwMjM3NyAw MDAwMCBmDQowMDAwMjk2NjMwIDAwMDAwIG4NCjAwMDAyOTY2NTYgMDAwMDAgbg0KMDAwMDAwMjM3 OCAwMDAwMCBmDQowMDAwMDAyMzc5IDAwMDAwIGYNCjAwMDAwMDIzODAgMDAwMDAgZg0KMDAwMDAw MjM4MSAwMDAwMCBmDQowMDAwMDAyMzgyIDAwMDAwIGYNCjAwMDAwMDIzODMgMDAwMDAgZg0KMDAw MDAwMjM4NCAwMDAwMCBmDQowMDAwMDAyMzg1IDAwMDAwIGYNCjAwMDAwMDIzODYgMDAwMDAgZg0K MDAwMDAwMjM4NyAwMDAwMCBmDQowMDAwMDAyMzg4IDAwMDAwIGYNCjAwMDAwMDIzODkgMDAwMDAg Zg0KMDAwMDAwMjM5MCAwMDAwMCBmDQowMDAwMDAyMzkxIDAwMDAwIGYNCjAwMDAwMDIzOTIgMDAw MDAgZg0KMDAwMDAwMjM5MyAwMDAwMCBmDQowMDAwMDAyMzk0IDAwMDAwIGYNCjAwMDAwMDIzOTUg MDAwMDAgZg0KMDAwMDAwMjM5NiAwMDAwMCBmDQowMDAwMDAyMzk3IDAwMDAwIGYNCjAwMDAwMDIz OTggMDAwMDEgZg0KMDAwMDAwMjM5OSAwMDAwMSBmDQowMDAwMDAyNDAwIDAwMDAxIGYNCjAwMDAw MDI0MDEgMDAwMDAgZg0KMDAwMDAwMjQwMiAwMDAwMCBmDQowMDAwMDAyNDE2IDAwMDAxIGYNCjAw MDAyOTcwMzEgMDAwMDAgbg0KMDAwMDI5NzE0MyAwMDAwMCBuDQowMDAwMjk3MjU3IDAwMDAwIG4N CjAwMDAyOTc0MDEgMDAwMDAgbg0KMDAwMDI5ODAzOCAwMDAwMCBuDQowMDAwMjk4MDY0IDAwMDAw IG4NCjAwMDAyOTg1OTQgMDAwMDAgbg0KMDAwMDI5ODY2NCAwMDAwMCBuDQowMDAwMjk4OTQ5IDAw MDAwIG4NCjAwMDAyOTkwMzAgMDAwMDAgbg0KMDAwMDM0Mzg3NCAwMDAwMCBuDQowMDAwMzQ0MzAx IDAwMDAwIG4NCjAwMDAzNDQ3NjggMDAwMDAgbg0KMDAwMDAwMjQyMCAwMDAwMCBmDQowMDAwMzQ0 OTk4IDAwMDAwIG4NCjAwMDAzNDU0OTQgMDAwMDAgbg0KMDAwMDM0NjA3OCAwMDAwMCBuDQowMDAw MDAyNDI0IDAwMDAwIGYNCjAwMDAzNDYzMjggMDAwMDAgbg0KMDAwMDM0Njg0NiAwMDAwMCBuDQow MDAwMzQ3Mzk2IDAwMDAwIG4NCjAwMDAwMDI0MjkgMDAwMDAgZg0KMDAwMDM0NzY0MCAwMDAwMCBu DQowMDAwMzQ4MDU3IDAwMDAwIG4NCjAwMDAzNDg0MjAgMDAwMDAgbg0KMDAwMDM0ODc5OCAwMDAw MCBuDQowMDAwMDAyNDMxIDAwMDAxIGYNCjAwMDAzNDkwNTEgMDAwMDAgbg0KMDAwMDAwMjQzMiAw MDAwMCBmDQowMDAwMDAyNDMzIDAwMDAxIGYNCjAwMDAwMDI0MzQgMDAwMDEgZg0KMDAwMDAwMjQz NSAwMDAwMSBmDQowMDAwMDAyNDM2IDAwMDAxIGYNCjAwMDAwMDI0MzggMDAwMDEgZg0KMDAwMDM3 NjYxNyAwMDAwMCBuDQowMDAwMDAyNDQ3IDAwMDAxIGYNCjAwMDAzNzg3OTcgMDAwMDAgbg0KMDAw MDM3OTE1NSAwMDAwMCBuDQowMDAwMzc5MjY5IDAwMDAwIG4NCjAwMDAzNzkzMTggMDAwMDAgbg0K MDAwMDM3OTM3NCAwMDAwMCBuDQowMDAwMzc5NjE1IDAwMDAwIG4NCjAwMDAzNzk5MzIgMDAwMDAg bg0KMDAwMDM4MDE0NCAwMDAwMCBuDQowMDAwMDAyNDUyIDAwMDAxIGYNCjAwMDAzODAzMjMgMDAw MDAgbg0KMDAwMDM4MDcxOCAwMDAwMCBuDQowMDAwMzgxMTA4IDAwMDAwIG4NCjAwMDAzODE1MDYg MDAwMDAgbg0KMDAwMDAwMjQ1NiAwMDAwMCBmDQowMDAwMzgxNzMwIDAwMDAwIG4NCjAwMDAzODIy MjMgMDAwMDAgbg0KMDAwMDM4MjYyMSAwMDAwMCBuDQowMDAwMDAyNDY3IDAwMDAwIGYNCjAwMDAz ODI4NTIgMDAwMDAgbg0KMDAwMDM4Mjg4MCAwMDAwMCBuDQowMDAwMzgyOTQ1IDAwMDAwIG4NCjAw MDAzODMwMDEgMDAwMDAgbg0KMDAwMDM4MzA4NCAwMDAwMCBuDQowMDAwMzgzMzE1IDAwMDAwIG4N CjAwMDAzODM3MzEgMDAwMDAgbg0KMDAwMDM4NDEwMSAwMDAwMCBuDQowMDAwMzg0NDc5IDAwMDAw IG4NCjAwMDA0MDAyOTIgMDAwMDAgbg0KMDAwMDAwMjQ2OCAwMDAwMSBmDQowMDAwMDAyNDY5IDAw MDAwIGYNCjAwMDAwMDI0NzAgMDAwMDEgZg0KMDAwMDAwMjQ3MiAwMDAwMSBmDQowMDAwNDA1MjM1 IDAwMDAwIG4NCjAwMDAwMDI0NzMgMDAwMDEgZg0KMDAwMDAwMjQ3NCAwMDAwMSBmDQowMDAwMDAy NDc1IDAwMDAxIGYNCjAwMDAwMDI0NzYgMDAwMDEgZg0KMDAwMDAwMjQ3NyAwMDAwMSBmDQowMDAw MDAyNDc4IDAwMDAxIGYNCjAwMDAwMDI0NzkgMDAwMDEgZg0KMDAwMDAwMjQ4MCAwMDAwMSBmDQow MDAwMDAyNDgxIDAwMDAxIGYNCjAwMDAwMDI0ODIgMDAwMDEgZg0KMDAwMDAwMjQ4MyAwMDAwMSBm DQowMDAwMDAyNDg0IDAwMDAxIGYNCjAwMDAwMDI0ODUgMDAwMDEgZg0KMDAwMDAwMjQ4NiAwMDAw MSBmDQowMDAwMDAyNDg3IDAwMDAxIGYNCjAwMDAwMDI0OTAgMDAwMDEgZg0KMDAwMDQwNTM0OSAw MDAwMCBuDQowMDAwNDA1NDczIDAwMDAwIG4NCjAwMDAwMDI0OTEgMDAwMDEgZg0KMDAwMDAwMjQ5 MiAwMDAwMSBmDQowMDAwMDAyNDkzIDAwMDAwIGYNCjAwMDAwMDI0OTUgMDAwMDEgZg0KMDAwMDQx OTQ1MSAwMDAwMCBuDQowMDAwMDAyNDk2IDAwMDAxIGYNCjAwMDAwMDI0OTcgMDAwMDEgZg0KMDAw MDAwMjQ5OCAwMDAwMSBmDQowMDAwMDAyNDk5IDAwMDAxIGYNCjAwMDAwMDI1MDAgMDAwMDEgZg0K MDAwMDAwMjUwMSAwMDAwMSBmDQowMDAwMDAyNTAyIDAwMDAxIGYNCjAwMDAwMDI1MDMgMDAwMDEg Zg0KMDAwMDAwMjUwNCAwMDAwMSBmDQowMDAwMDAyNTA1IDAwMDAxIGYNCjAwMDAwMDI1MDYgMDAw MDEgZg0KMDAwMDAwMjUwNyAwMDAwMSBmDQowMDAwMDAyNTA4IDAwMDAxIGYNCjAwMDAwMDI1MDkg MDAwMDEgZg0KMDAwMDAwMjUxMCAwMDAwMSBmDQowMDAwMDAyNTExIDAwMDAxIGYNCjAwMDAwMDI1 MTIgMDAwMDEgZg0KMDAwMDAwMjUxMyAwMDAwMSBmDQowMDAwMDAyNTE0IDAwMDAxIGYNCjAwMDAw MDI1MTUgMDAwMDEgZg0KMDAwMDAwMjUxNiAwMDAwMSBmDQowMDAwMDAyNTE3IDAwMDAxIGYNCjAw MDAwMDI1MTggMDAwMDEgZg0KMDAwMDAwMjUxOSAwMDAwMSBmDQowMDAwMDAyNTIwIDAwMDAxIGYN CjAwMDAwMDI1MjEgMDAwMDEgZg0KMDAwMDAwMjUyMiAwMDAwMSBmDQowMDAwMDAyNTIzIDAwMDAx IGYNCjAwMDAwMDI1MjQgMDAwMDEgZg0KMDAwMDAwMjUyNSAwMDAwMSBmDQowMDAwMDAyNTI2IDAw MDAxIGYNCjAwMDAwMDI1MjcgMDAwMDEgZg0KMDAwMDAwMjUyOCAwMDAwMSBmDQowMDAwMDAyNTI5 IDAwMDAxIGYNCjAwMDAwMDI1MzAgMDAwMDEgZg0KMDAwMDAwMjUzMSAwMDAwMSBmDQowMDAwMDAy NTMyIDAwMDAxIGYNCjAwMDAwMDI1MzMgMDAwMDEgZg0KMDAwMDAwMjUzNCAwMDAwMSBmDQowMDAw MDAyNTM1IDAwMDAxIGYNCjAwMDAwMDI1MzYgMDAwMDEgZg0KMDAwMDAwMjUzNyAwMDAwMSBmDQow MDAwMDAyNTM4IDAwMDAxIGYNCjAwMDAwMDI1MzkgMDAwMDEgZg0KMDAwMDAwMjU0MCAwMDAwMSBm DQowMDAwMDAyNTQxIDAwMDAxIGYNCjAwMDAwMDI1NDIgMDAwMDEgZg0KMDAwMDAwMjU0MyAwMDAw MSBmDQowMDAwMDAyNTQ0IDAwMDAxIGYNCjAwMDAwMDI1NDUgMDAwMDEgZg0KMDAwMDAwMjU0NiAw MDAwMSBmDQowMDAwMDAyNTQ3IDAwMDAxIGYNCjAwMDAwMDI1NDggMDAwMDEgZg0KMDAwMDAwMjU0 OSAwMDAwMSBmDQowMDAwMDAyNTUwIDAwMDAxIGYNCjAwMDAwMDI1NTEgMDAwMDEgZg0KMDAwMDAw MjU1MiAwMDAwMSBmDQowMDAwMDAyNTUzIDAwMDAxIGYNCjAwMDAwMDI1NTQgMDAwMDEgZg0KMDAw MDAwMjU1NSAwMDAwMSBmDQowMDAwMDAyNTU2IDAwMDAxIGYNCjAwMDAwMDI1NTcgMDAwMDEgZg0K MDAwMDAwMjU1OCAwMDAwMSBmDQowMDAwMDAyNTU5IDAwMDAxIGYNCjAwMDAwMDI1NjAgMDAwMDEg Zg0KMDAwMDAwMjU2MSAwMDAwMSBmDQowMDAwMDAyNTYyIDAwMDAxIGYNCjAwMDAwMDI1NjMgMDAw MDEgZg0KMDAwMDAwMjU2NCAwMDAwMSBmDQowMDAwMDAyNTY1IDAwMDAxIGYNCjAwMDAwMDI1NjYg MDAwMDEgZg0KMDAwMDAwMjU2NyAwMDAwMSBmDQowMDAwMDAyNTY4IDAwMDAxIGYNCjAwMDAwMDI1 NjkgMDAwMDEgZg0KMDAwMDAwMjU3MCAwMDAwMSBmDQowMDAwMDAyNTcxIDAwMDAxIGYNCjAwMDAw MDI1NzIgMDAwMDEgZg0KMDAwMDAwMjU3MyAwMDAwMSBmDQowMDAwMDAyNTc0IDAwMDAxIGYNCjAw MDAwMDI1NzUgMDAwMDEgZg0KMDAwMDAwMjU3NiAwMDAwMSBmDQowMDAwMDAyNTc3IDAwMDAxIGYN CjAwMDAwMDI1NzggMDAwMDEgZg0KMDAwMDAwMjU3OSAwMDAwMSBmDQowMDAwMDAyNTgwIDAwMDAx IGYNCjAwMDAwMDI1ODEgMDAwMDEgZg0KMDAwMDAwMjU4MiAwMDAwMSBmDQowMDAwMDAyNTgzIDAw MDAxIGYNCjAwMDAwMDI1ODQgMDAwMDEgZg0KMDAwMDAwMjU4NSAwMDAwMSBmDQowMDAwMDAyNTg2 IDAwMDAxIGYNCjAwMDAwMDI1ODcgMDAwMDEgZg0KMDAwMDAwMjU4OCAwMDAwMSBmDQowMDAwMDAy NTg5IDAwMDAxIGYNCjAwMDAwMDI1OTAgMDAwMDEgZg0KMDAwMDAwMjU5MSAwMDAwMSBmDQowMDAw MDAyNTkyIDAwMDAxIGYNCjAwMDAwMDI1OTMgMDAwMDEgZg0KMDAwMDAwMjU5NCAwMDAwMSBmDQow MDAwMDAyNTk1IDAwMDAxIGYNCjAwMDAwMDI1OTYgMDAwMDEgZg0KMDAwMDAwMjU5NyAwMDAwMSBm DQowMDAwMDAyNTk4IDAwMDAxIGYNCjAwMDAwMDI1OTkgMDAwMDEgZg0KMDAwMDAwMjYwMCAwMDAw MSBmDQowMDAwMDAyNjAxIDAwMDAxIGYNCjAwMDAwMDI2MDIgMDAwMDEgZg0KMDAwMDAwMjYwMyAw MDAwMSBmDQowMDAwMDAyNjA0IDAwMDAxIGYNCjAwMDAwMDI2MDYgMDAwMDEgZg0KMDAwMDQxOTU2 NiAwMDAwMCBuDQowMDAwMDAyNjEwIDAwMDAxIGYNCjAwMDA0MjQxNDMgMDAwMDAgbg0KMDAwMDQy NDUzOSAwMDAwMCBuDQowMDAwNDI0OTA5IDAwMDAwIG4NCjAwMDAwMDI2MTEgMDAwMDAgZg0KMDAw MDAwMjYxMyAwMDAwMSBmDQowMDAwNDI1Mjg3IDAwMDAwIG4NCjAwMDAwMDI2MTQgMDAwMDEgZg0K MDAwMDAwMjYxNSAwMDAwMSBmDQowMDAwMDAyNjE2IDAwMDAxIGYNCjAwMDAwMDI2MTcgMDAwMDEg Zg0KMDAwMDAwMjYxOCAwMDAwMSBmDQowMDAwMDAyNjE5IDAwMDAxIGYNCjAwMDAwMDI2MjAgMDAw MDEgZg0KMDAwMDAwMjYyMSAwMDAwMSBmDQowMDAwMDAyNjIyIDAwMDAxIGYNCjAwMDAwMDI2MjMg MDAwMDEgZg0KMDAwMDAwMjYyNCAwMDAwMSBmDQowMDAwMDAyNjI1IDAwMDAxIGYNCjAwMDAwMDI2 MjYgMDAwMDEgZg0KMDAwMDAwMjYyNyAwMDAwMSBmDQowMDAwMDAyNjI4IDAwMDAxIGYNCjAwMDAw MDI2MjkgMDAwMDEgZg0KMDAwMDAwMjYzMCAwMDAwMSBmDQowMDAwMDAyNjMxIDAwMDAxIGYNCjAw MDAwMDI2MzIgMDAwMDEgZg0KMDAwMDAwMjYzMyAwMDAwMSBmDQowMDAwMDAyNjM0IDAwMDAxIGYN CjAwMDAwMDI2MzUgMDAwMDEgZg0KMDAwMDAwMjYzNiAwMDAwMSBmDQowMDAwMDAyNjM3IDAwMDAx IGYNCjAwMDAwMDI2MzggMDAwMDEgZg0KMDAwMDAwMjYzOSAwMDAwMSBmDQowMDAwMDAyNjQwIDAw MDAxIGYNCjAwMDAwMDI2NDEgMDAwMDEgZg0KMDAwMDAwMjY0MiAwMDAwMSBmDQowMDAwMDAyNjQz IDAwMDAxIGYNCjAwMDAwMDI2NDQgMDAwMDEgZg0KMDAwMDAwMjY0NSAwMDAwMSBmDQowMDAwMDAy NjQ2IDAwMDAxIGYNCjAwMDAwMDI2NDcgMDAwMDEgZg0KMDAwMDAwMjY0OCAwMDAwMSBmDQowMDAw MDAyNjQ5IDAwMDAxIGYNCjAwMDAwMDI2NTAgMDAwMDEgZg0KMDAwMDAwMjY1MSAwMDAwMSBmDQow MDAwMDAyNjUyIDAwMDAxIGYNCjAwMDAwMDI2NTMgMDAwMDEgZg0KMDAwMDAwMjY1NCAwMDAwMSBm DQowMDAwMDAyNjU1IDAwMDAxIGYNCjAwMDAwMDI2NTYgMDAwMDEgZg0KMDAwMDAwMjY1NyAwMDAw MSBmDQowMDAwMDAyNjU4IDAwMDAxIGYNCjAwMDAwMDI2NTkgMDAwMDEgZg0KMDAwMDAwMjY2MCAw MDAwMSBmDQowMDAwMDAyNjYxIDAwMDAxIGYNCjAwMDAwMDI2NjIgMDAwMDEgZg0KMDAwMDAwMjY2 MyAwMDAwMSBmDQowMDAwMDAyNjY0IDAwMDAxIGYNCjAwMDAwMDI2NjUgMDAwMDEgZg0KMDAwMDAw MjY2NiAwMDAwMSBmDQowMDAwMDAyNjY3IDAwMDAxIGYNCjAwMDAwMDI2NjggMDAwMDEgZg0KMDAw MDAwMjY2OSAwMDAwMSBmDQowMDAwMDAyNjcwIDAwMDAxIGYNCjAwMDAwMDI2NzEgMDAwMDEgZg0K MDAwMDAwMjY3MiAwMDAwMSBmDQowMDAwMDAyNjczIDAwMDAxIGYNCjAwMDAwMDI2NzQgMDAwMDEg Zg0KMDAwMDAwMjY3NSAwMDAwMSBmDQowMDAwMDAyNjc2IDAwMDAxIGYNCjAwMDAwMDI2NzcgMDAw MDEgZg0KMDAwMDAwMjY3OCAwMDAwMSBmDQowMDAwMDAyNjc5IDAwMDAxIGYNCjAwMDAwMDI2ODAg MDAwMDEgZg0KMDAwMDAwMjY4MSAwMDAwMSBmDQowMDAwMDAyNjgyIDAwMDAxIGYNCjAwMDAwMDI2 ODMgMDAwMDEgZg0KMDAwMDAwMjY4NCAwMDAwMSBmDQowMDAwMDAyNjg1IDAwMDAxIGYNCjAwMDAw MDI2ODYgMDAwMDEgZg0KMDAwMDAwMjY4NyAwMDAwMSBmDQowMDAwMDAyNjg4IDAwMDAxIGYNCjAw MDAwMDI2ODkgMDAwMDEgZg0KMDAwMDAwMjY5MCAwMDAwMSBmDQowMDAwMDAyNjkxIDAwMDAxIGYN CjAwMDAwMDI2OTIgMDAwMDEgZg0KMDAwMDAwMjY5MyAwMDAwMSBmDQowMDAwMDAyNjk0IDAwMDAx IGYNCjAwMDAwMDI2OTUgMDAwMDEgZg0KMDAwMDAwMjY5NiAwMDAwMSBmDQowMDAwMDAyNjk3IDAw MDAxIGYNCjAwMDAwMDI2OTggMDAwMDEgZg0KMDAwMDAwMjY5OSAwMDAwMSBmDQowMDAwMDAyNzAw IDAwMDAxIGYNCjAwMDAwMDI3MDEgMDAwMDEgZg0KMDAwMDAwMjcwMiAwMDAwMSBmDQowMDAwMDAy NzAzIDAwMDAxIGYNCjAwMDAwMDI3MDQgMDAwMDEgZg0KMDAwMDAwMjcwNSAwMDAwMSBmDQowMDAw MDAyNzA2IDAwMDAxIGYNCjAwMDAwMDI3MDcgMDAwMDEgZg0KMDAwMDAwMjcwOCAwMDAwMSBmDQow MDAwMDAyNzA5IDAwMDAxIGYNCjAwMDAwMDI3MTAgMDAwMDEgZg0KMDAwMDAwMjcxMSAwMDAwMSBm DQowMDAwMDAyNzEyIDAwMDAxIGYNCjAwMDAwMDI3MTMgMDAwMDEgZg0KMDAwMDAwMjcxNCAwMDAw MSBmDQowMDAwMDAyNzE1IDAwMDAxIGYNCjAwMDAwMDI3MTYgMDAwMDEgZg0KMDAwMDAwMjcxNyAw MDAwMSBmDQowMDAwMDAyNzE4IDAwMDAxIGYNCjAwMDAwMDI3MTkgMDAwMDEgZg0KMDAwMDAwMjcy MCAwMDAwMSBmDQowMDAwMDAyNzIxIDAwMDAxIGYNCjAwMDAwMDI3MjIgMDAwMDEgZg0KMDAwMDAw MjcyMyAwMDAwMSBmDQowMDAwMDAyNzI0IDAwMDAxIGYNCjAwMDAwMDI3MjUgMDAwMDEgZg0KMDAw MDAwMjcyNiAwMDAwMSBmDQowMDAwMDAyNzI3IDAwMDAxIGYNCjAwMDAwMDI3MjggMDAwMDEgZg0K MDAwMDAwMjcyOSAwMDAwMSBmDQowMDAwMDAyNzMwIDAwMDAxIGYNCjAwMDAwMDI3MzEgMDAwMDEg Zg0KMDAwMDAwMjczMiAwMDAwMSBmDQowMDAwMDAyNzMzIDAwMDAxIGYNCjAwMDAwMDI3MzQgMDAw MDEgZg0KMDAwMDAwMjczNSAwMDAwMSBmDQowMDAwMDAyNzM2IDAwMDAxIGYNCjAwMDAwMDI3Mzcg MDAwMDEgZg0KMDAwMDAwMjczOCAwMDAwMSBmDQowMDAwMDAyNzM5IDAwMDAxIGYNCjAwMDAwMDI3 NDAgMDAwMDEgZg0KMDAwMDAwMjc0MSAwMDAwMSBmDQowMDAwMDAyNzQyIDAwMDAxIGYNCjAwMDAw MDI3NDMgMDAwMDEgZg0KMDAwMDAwMjc0NCAwMDAwMSBmDQowMDAwMDAyNzQ1IDAwMDAxIGYNCjAw MDAwMDI3NDYgMDAwMDEgZg0KMDAwMDAwMjc0NyAwMDAwMSBmDQowMDAwMDAyNzQ4IDAwMDAxIGYN CjAwMDAwMDI3NTAgMDAwMDEgZg0KMDAwMDQyNTQwMiAwMDAwMCBuDQowMDAwMDAyNzUxIDAwMDAx IGYNCjAwMDAwMDI3NTIgMDAwMDAgZg0KMDAwMDAwMjc1NCAwMDAwMSBmDQowMDAwNDMwMDg1IDAw MDAwIG4NCjAwMDAwMDI3NTUgMDAwMDEgZg0KMDAwMDAwMjc1NiAwMDAwMSBmDQowMDAwMDAyNzU3 IDAwMDAxIGYNCjAwMDAwMDI3NTggMDAwMDEgZg0KMDAwMDAwMjc1OSAwMDAwMSBmDQowMDAwMDAy NzYwIDAwMDAxIGYNCjAwMDAwMDI3NjEgMDAwMDEgZg0KMDAwMDAwMjc2MiAwMDAwMSBmDQowMDAw MDAyNzYzIDAwMDAxIGYNCjAwMDAwMDI3NjQgMDAwMDEgZg0KMDAwMDAwMjc2NSAwMDAwMSBmDQow MDAwMDAyNzY2IDAwMDAxIGYNCjAwMDAwMDI3NjcgMDAwMDEgZg0KMDAwMDAwMjc2OCAwMDAwMSBm DQowMDAwMDAyNzY5IDAwMDAxIGYNCjAwMDAwMDI3NzAgMDAwMDEgZg0KMDAwMDAwMjc3MSAwMDAw MSBmDQowMDAwMDAyNzcyIDAwMDAxIGYNCjAwMDAwMDI3NzMgMDAwMDEgZg0KMDAwMDAwMjc3NCAw MDAwMSBmDQowMDAwMDAyNzc1IDAwMDAxIGYNCjAwMDAwMDI3NzYgMDAwMDEgZg0KMDAwMDAwMjc3 NyAwMDAwMSBmDQowMDAwMDAyNzc4IDAwMDAxIGYNCjAwMDAwMDI3NzkgMDAwMDEgZg0KMDAwMDAw Mjc4MCAwMDAwMSBmDQowMDAwMDAyNzgxIDAwMDAxIGYNCjAwMDAwMDI3ODIgMDAwMDEgZg0KMDAw MDAwMjc4MyAwMDAwMSBmDQowMDAwMDAyNzg0IDAwMDAxIGYNCjAwMDAwMDI3ODUgMDAwMDEgZg0K MDAwMDAwMjc4NiAwMDAwMSBmDQowMDAwMDAyNzg3IDAwMDAxIGYNCjAwMDAwMDI3ODggMDAwMDEg Zg0KMDAwMDAwMjc4OSAwMDAwMSBmDQowMDAwMDAyNzkwIDAwMDAxIGYNCjAwMDAwMDI3OTEgMDAw MDEgZg0KMDAwMDAwMjc5MiAwMDAwMSBmDQowMDAwMDAyNzkzIDAwMDAxIGYNCjAwMDAwMDI3OTQg MDAwMDEgZg0KMDAwMDAwMjc5NSAwMDAwMSBmDQowMDAwMDAyNzk2IDAwMDAxIGYNCjAwMDAwMDI3 OTcgMDAwMDEgZg0KMDAwMDAwMjc5OCAwMDAwMSBmDQowMDAwMDAyNzk5IDAwMDAxIGYNCjAwMDAw MDI4MDAgMDAwMDEgZg0KMDAwMDAwMjgwMSAwMDAwMSBmDQowMDAwMDAyODAyIDAwMDAxIGYNCjAw MDAwMDI4MDMgMDAwMDEgZg0KMDAwMDAwMjgwNCAwMDAwMSBmDQowMDAwMDAyODA1IDAwMDAxIGYN CjAwMDAwMDI4MDYgMDAwMDEgZg0KMDAwMDAwMjgwNyAwMDAwMSBmDQowMDAwMDAyODA4IDAwMDAx IGYNCjAwMDAwMDI4MDkgMDAwMDEgZg0KMDAwMDAwMjgxMCAwMDAwMSBmDQowMDAwMDAyODExIDAw MDAxIGYNCjAwMDAwMDI4MTIgMDAwMDEgZg0KMDAwMDAwMjgxMyAwMDAwMSBmDQowMDAwMDAyODE0 IDAwMDAxIGYNCjAwMDAwMDI4MTUgMDAwMDEgZg0KMDAwMDAwMjgxNiAwMDAwMSBmDQowMDAwMDAy ODE3IDAwMDAxIGYNCjAwMDAwMDI4MTggMDAwMDEgZg0KMDAwMDAwMjgxOSAwMDAwMSBmDQowMDAw MDAyODIwIDAwMDAxIGYNCjAwMDAwMDI4MjEgMDAwMDEgZg0KMDAwMDAwMjgyMiAwMDAwMSBmDQow MDAwMDAyODIzIDAwMDAxIGYNCjAwMDAwMDI4MjQgMDAwMDEgZg0KMDAwMDAwMjgyNSAwMDAwMSBm DQowMDAwMDAyODI2IDAwMDAxIGYNCjAwMDAwMDI4MjcgMDAwMDEgZg0KMDAwMDAwMjgyOCAwMDAw MSBmDQowMDAwMDAyODI5IDAwMDAxIGYNCjAwMDAwMDI4MzAgMDAwMDEgZg0KMDAwMDAwMjgzMSAw MDAwMSBmDQowMDAwMDAyODMyIDAwMDAxIGYNCjAwMDAwMDI4MzMgMDAwMDEgZg0KMDAwMDAwMjgz NCAwMDAwMSBmDQowMDAwMDAyODM1IDAwMDAxIGYNCjAwMDAwMDI4MzYgMDAwMDEgZg0KMDAwMDAw MjgzNyAwMDAwMSBmDQowMDAwMDAyODM4IDAwMDAxIGYNCjAwMDAwMDI4MzkgMDAwMDEgZg0KMDAw MDAwMjg0MCAwMDAwMSBmDQowMDAwMDAyODQxIDAwMDAxIGYNCjAwMDAwMDI4NDIgMDAwMDEgZg0K MDAwMDAwMjg0MyAwMDAwMSBmDQowMDAwMDAyODQ0IDAwMDAxIGYNCjAwMDAwMDI4NDUgMDAwMDEg Zg0KMDAwMDAwMjg0NiAwMDAwMSBmDQowMDAwMDAyODQ3IDAwMDAxIGYNCjAwMDAwMDI4NDggMDAw MDEgZg0KMDAwMDAwMjg0OSAwMDAwMSBmDQowMDAwMDAyODUwIDAwMDAxIGYNCjAwMDAwMDI4NTEg MDAwMDEgZg0KMDAwMDAwMjg1MiAwMDAwMSBmDQowMDAwMDAyODUzIDAwMDAxIGYNCjAwMDAwMDI4 NTQgMDAwMDEgZg0KMDAwMDAwMjg1NSAwMDAwMSBmDQowMDAwMDAyODU2IDAwMDAxIGYNCjAwMDAw MDI4NTcgMDAwMDEgZg0KMDAwMDAwMjg1OCAwMDAwMSBmDQowMDAwMDAyODU5IDAwMDAxIGYNCjAw MDAwMDI4NjAgMDAwMDEgZg0KMDAwMDAwMjg2MSAwMDAwMSBmDQowMDAwMDAyODYyIDAwMDAxIGYN CjAwMDAwMDI4NjMgMDAwMDEgZg0KMDAwMDAwMjg2NCAwMDAwMSBmDQowMDAwMDAyODY1IDAwMDAx IGYNCjAwMDAwMDI4NjYgMDAwMDEgZg0KMDAwMDAwMjg2NyAwMDAwMSBmDQowMDAwMDAyODY4IDAw MDAxIGYNCjAwMDAwMDI4NjkgMDAwMDEgZg0KMDAwMDAwMjg3MCAwMDAwMSBmDQowMDAwMDAyODcx IDAwMDAxIGYNCjAwMDAwMDI4NzIgMDAwMDEgZg0KMDAwMDAwMjg3MyAwMDAwMSBmDQowMDAwMDAy ODc0IDAwMDAxIGYNCjAwMDAwMDI4NzUgMDAwMDEgZg0KMDAwMDAwMjg3NiAwMDAwMSBmDQowMDAw MDAyODc4IDAwMDAxIGYNCjAwMDA0MzAyMDAgMDAwMDAgbg0KMDAwMDAwMjg3OSAwMDAwMSBmDQow MDAwMDAyODgwIDAwMDAwIGYNCjAwMDAwMDI4ODIgMDAwMDEgZg0KMDAwMDQzNDkzMyAwMDAwMCBu DQowMDAwMDAyODgzIDAwMDAxIGYNCjAwMDAwMDI4ODQgMDAwMDEgZg0KMDAwMDAwMjg4NSAwMDAw MSBmDQowMDAwMDAyODg2IDAwMDAxIGYNCjAwMDAwMDI4ODcgMDAwMDEgZg0KMDAwMDAwMjg4OCAw MDAwMSBmDQowMDAwMDAyODg5IDAwMDAxIGYNCjAwMDAwMDI4OTAgMDAwMDEgZg0KMDAwMDAwMjg5 MSAwMDAwMSBmDQowMDAwMDAyODkyIDAwMDAxIGYNCjAwMDAwMDI4OTMgMDAwMDEgZg0KMDAwMDAw Mjg5NCAwMDAwMSBmDQowMDAwMDAyODk1IDAwMDAxIGYNCjAwMDAwMDI4OTYgMDAwMDEgZg0KMDAw MDAwMjg5NyAwMDAwMSBmDQowMDAwMDAyODk4IDAwMDAxIGYNCjAwMDAwMDI4OTkgMDAwMDEgZg0K MDAwMDAwMjkwMCAwMDAwMSBmDQowMDAwMDAyOTAxIDAwMDAxIGYNCjAwMDAwMDI5MDIgMDAwMDEg Zg0KMDAwMDAwMjkwMyAwMDAwMSBmDQowMDAwMDAyOTA0IDAwMDAxIGYNCjAwMDAwMDI5MDUgMDAw MDEgZg0KMDAwMDAwMjkwNiAwMDAwMSBmDQowMDAwMDAyOTA3IDAwMDAxIGYNCjAwMDAwMDI5MDgg MDAwMDEgZg0KMDAwMDAwMjkwOSAwMDAwMSBmDQowMDAwMDAyOTEwIDAwMDAxIGYNCjAwMDAwMDI5 MTEgMDAwMDEgZg0KMDAwMDAwMjkxMiAwMDAwMSBmDQowMDAwMDAyOTEzIDAwMDAxIGYNCjAwMDAw MDI5MTQgMDAwMDEgZg0KMDAwMDAwMjkxNSAwMDAwMSBmDQowMDAwMDAyOTE2IDAwMDAxIGYNCjAw MDAwMDI5MTcgMDAwMDEgZg0KMDAwMDAwMjkxOCAwMDAwMSBmDQowMDAwMDAyOTE5IDAwMDAxIGYN CjAwMDAwMDI5MjAgMDAwMDEgZg0KMDAwMDAwMjkyMSAwMDAwMSBmDQowMDAwMDAyOTIyIDAwMDAx IGYNCjAwMDAwMDI5MjMgMDAwMDEgZg0KMDAwMDAwMjkyNCAwMDAwMSBmDQowMDAwMDAyOTI1IDAw MDAxIGYNCjAwMDAwMDI5MjYgMDAwMDEgZg0KMDAwMDAwMjkyNyAwMDAwMSBmDQowMDAwMDAyOTI4 IDAwMDAxIGYNCjAwMDAwMDI5MjkgMDAwMDEgZg0KMDAwMDAwMjkzMCAwMDAwMSBmDQowMDAwMDAy OTMxIDAwMDAxIGYNCjAwMDAwMDI5MzIgMDAwMDEgZg0KMDAwMDAwMjkzMyAwMDAwMSBmDQowMDAw MDAyOTM0IDAwMDAxIGYNCjAwMDAwMDI5MzUgMDAwMDEgZg0KMDAwMDAwMjkzNiAwMDAwMSBmDQow MDAwMDAyOTM3IDAwMDAxIGYNCjAwMDAwMDI5MzggMDAwMDEgZg0KMDAwMDAwMjkzOSAwMDAwMSBm DQowMDAwMDAyOTQwIDAwMDAxIGYNCjAwMDAwMDI5NDEgMDAwMDEgZg0KMDAwMDAwMjk0MiAwMDAw MSBmDQowMDAwMDAyOTQzIDAwMDAxIGYNCjAwMDAwMDI5NDQgMDAwMDEgZg0KMDAwMDAwMjk0NSAw MDAwMSBmDQowMDAwMDAyOTQ2IDAwMDAxIGYNCjAwMDAwMDI5NDcgMDAwMDEgZg0KMDAwMDAwMjk0 OCAwMDAwMSBmDQowMDAwMDAyOTQ5IDAwMDAxIGYNCjAwMDAwMDI5NTAgMDAwMDEgZg0KMDAwMDAw Mjk1MSAwMDAwMSBmDQowMDAwMDAyOTUyIDAwMDAxIGYNCjAwMDAwMDI5NTMgMDAwMDEgZg0KMDAw MDAwMjk1NCAwMDAwMSBmDQowMDAwMDAyOTU1IDAwMDAxIGYNCjAwMDAwMDI5NTYgMDAwMDEgZg0K MDAwMDAwMjk1NyAwMDAwMSBmDQowMDAwMDAyOTU4IDAwMDAxIGYNCjAwMDAwMDI5NTkgMDAwMDEg Zg0KMDAwMDAwMjk2MCAwMDAwMSBmDQowMDAwMDAyOTYxIDAwMDAxIGYNCjAwMDAwMDI5NjIgMDAw MDEgZg0KMDAwMDAwMjk2MyAwMDAwMSBmDQowMDAwMDAyOTY0IDAwMDAxIGYNCjAwMDAwMDI5NjUg MDAwMDEgZg0KMDAwMDAwMjk2NiAwMDAwMSBmDQowMDAwMDAyOTY3IDAwMDAxIGYNCjAwMDAwMDI5 NjggMDAwMDEgZg0KMDAwMDAwMjk2OSAwMDAwMSBmDQowMDAwMDAyOTcwIDAwMDAxIGYNCjAwMDAw MDI5NzEgMDAwMDEgZg0KMDAwMDAwMjk3MiAwMDAwMSBmDQowMDAwMDAyOTczIDAwMDAxIGYNCjAw MDAwMDI5NzQgMDAwMDEgZg0KMDAwMDAwMjk3NSAwMDAwMSBmDQowMDAwMDAyOTc2IDAwMDAxIGYN CjAwMDAwMDI5NzcgMDAwMDEgZg0KMDAwMDAwMjk3OCAwMDAwMSBmDQowMDAwMDAyOTc5IDAwMDAx IGYNCjAwMDAwMDI5ODAgMDAwMDEgZg0KMDAwMDAwMjk4MSAwMDAwMSBmDQowMDAwMDAyOTgyIDAw MDAxIGYNCjAwMDAwMDI5ODMgMDAwMDEgZg0KMDAwMDAwMjk4NCAwMDAwMSBmDQowMDAwMDAyOTg1 IDAwMDAxIGYNCjAwMDAwMDI5ODYgMDAwMDEgZg0KMDAwMDAwMjk4NyAwMDAwMSBmDQowMDAwMDAy OTg4IDAwMDAxIGYNCjAwMDAwMDI5ODkgMDAwMDEgZg0KMDAwMDAwMjk5MCAwMDAwMSBmDQowMDAw MDAyOTkxIDAwMDAxIGYNCjAwMDAwMDI5OTMgMDAwMDEgZg0KMDAwMDQzNTA0OCAwMDAwMCBuDQow MDAwMDAyOTk0IDAwMDAxIGYNCjAwMDAwMDI5OTUgMDAwMDAgZg0KMDAwMDAwMjk5NyAwMDAwMSBm DQowMDAwNDQwMzA3IDAwMDAwIG4NCjAwMDAwMDI5OTggMDAwMDEgZg0KMDAwMDAwMjk5OSAwMDAw MSBmDQowMDAwMDAzMDAwIDAwMDAxIGYNCjAwMDAwMDMwMDEgMDAwMDEgZg0KMDAwMDAwMzAwMiAw MDAwMSBmDQowMDAwMDAzMDAzIDAwMDAxIGYNCjAwMDAwMDMwMDQgMDAwMDEgZg0KMDAwMDAwMzAw NSAwMDAwMSBmDQowMDAwMDAzMDA2IDAwMDAxIGYNCjAwMDAwMDMwMDcgMDAwMDEgZg0KMDAwMDAw MzAwOCAwMDAwMSBmDQowMDAwMDAzMDA5IDAwMDAxIGYNCjAwMDAwMDMwMTAgMDAwMDEgZg0KMDAw MDAwMzAxMSAwMDAwMSBmDQowMDAwMDAzMDEyIDAwMDAxIGYNCjAwMDAwMDMwMTMgMDAwMDEgZg0K MDAwMDAwMzAxNCAwMDAwMSBmDQowMDAwMDAzMDE1IDAwMDAxIGYNCjAwMDAwMDMwMTYgMDAwMDEg Zg0KMDAwMDAwMzAxNyAwMDAwMSBmDQowMDAwMDAzMDE4IDAwMDAxIGYNCjAwMDAwMDMwMTkgMDAw MDEgZg0KMDAwMDAwMzAyMCAwMDAwMSBmDQowMDAwMDAzMDIxIDAwMDAxIGYNCjAwMDAwMDMwMjIg MDAwMDEgZg0KMDAwMDAwMzAyMyAwMDAwMSBmDQowMDAwMDAzMDI0IDAwMDAxIGYNCjAwMDAwMDMw MjUgMDAwMDEgZg0KMDAwMDAwMzAyNiAwMDAwMSBmDQowMDAwMDAzMDI3IDAwMDAxIGYNCjAwMDAw MDMwMjggMDAwMDEgZg0KMDAwMDAwMzAyOSAwMDAwMSBmDQowMDAwMDAzMDMwIDAwMDAxIGYNCjAw MDAwMDMwMzEgMDAwMDEgZg0KMDAwMDAwMzAzMiAwMDAwMSBmDQowMDAwMDAzMDMzIDAwMDAxIGYN CjAwMDAwMDMwMzQgMDAwMDEgZg0KMDAwMDAwMzAzNSAwMDAwMSBmDQowMDAwMDAzMDM2IDAwMDAx IGYNCjAwMDAwMDMwMzcgMDAwMDEgZg0KMDAwMDAwMzAzOCAwMDAwMSBmDQowMDAwMDAzMDM5IDAw MDAxIGYNCjAwMDAwMDMwNDAgMDAwMDEgZg0KMDAwMDAwMzA0MSAwMDAwMSBmDQowMDAwMDAzMDQy IDAwMDAxIGYNCjAwMDAwMDMwNDMgMDAwMDEgZg0KMDAwMDAwMzA0NCAwMDAwMSBmDQowMDAwMDAz MDQ1IDAwMDAxIGYNCjAwMDAwMDMwNDYgMDAwMDEgZg0KMDAwMDAwMzA0NyAwMDAwMSBmDQowMDAw MDAzMDQ4IDAwMDAxIGYNCjAwMDAwMDMwNDkgMDAwMDEgZg0KMDAwMDAwMzA1MCAwMDAwMSBmDQow MDAwMDAzMDUxIDAwMDAxIGYNCjAwMDAwMDMwNTIgMDAwMDEgZg0KMDAwMDAwMzA1MyAwMDAwMSBm DQowMDAwMDAzMDU0IDAwMDAxIGYNCjAwMDAwMDMwNTUgMDAwMDEgZg0KMDAwMDAwMzA1NiAwMDAw MSBmDQowMDAwMDAzMDU3IDAwMDAxIGYNCjAwMDAwMDMwNTggMDAwMDEgZg0KMDAwMDAwMzA1OSAw MDAwMSBmDQowMDAwMDAzMDYwIDAwMDAxIGYNCjAwMDAwMDMwNjEgMDAwMDEgZg0KMDAwMDAwMzA2 MiAwMDAwMSBmDQowMDAwMDAzMDYzIDAwMDAxIGYNCjAwMDAwMDMwNjQgMDAwMDEgZg0KMDAwMDAw MzA2NSAwMDAwMSBmDQowMDAwMDAzMDY2IDAwMDAxIGYNCjAwMDAwMDMwNjcgMDAwMDEgZg0KMDAw MDAwMzA2OCAwMDAwMSBmDQowMDAwMDAzMDY5IDAwMDAxIGYNCjAwMDAwMDMwNzAgMDAwMDEgZg0K MDAwMDAwMzA3MSAwMDAwMSBmDQowMDAwMDAzMDcyIDAwMDAxIGYNCjAwMDAwMDMwNzMgMDAwMDEg Zg0KMDAwMDAwMzA3NCAwMDAwMSBmDQowMDAwMDAzMDc1IDAwMDAxIGYNCjAwMDAwMDMwNzYgMDAw MDEgZg0KMDAwMDAwMzA3NyAwMDAwMSBmDQowMDAwMDAzMDc4IDAwMDAxIGYNCjAwMDAwMDMwNzkg MDAwMDEgZg0KMDAwMDAwMzA4MCAwMDAwMSBmDQowMDAwMDAzMDgxIDAwMDAxIGYNCjAwMDAwMDMw ODIgMDAwMDEgZg0KMDAwMDAwMzA4MyAwMDAwMSBmDQowMDAwMDAzMDg0IDAwMDAxIGYNCjAwMDAw MDMwODUgMDAwMDEgZg0KMDAwMDAwMzA4NiAwMDAwMSBmDQowMDAwMDAzMDg3IDAwMDAxIGYNCjAw MDAwMDMwODggMDAwMDEgZg0KMDAwMDAwMzA4OSAwMDAwMSBmDQowMDAwMDAzMDkwIDAwMDAxIGYN CjAwMDAwMDMwOTEgMDAwMDEgZg0KMDAwMDAwMzA5MiAwMDAwMSBmDQowMDAwMDAzMDkzIDAwMDAx IGYNCjAwMDAwMDMwOTQgMDAwMDEgZg0KMDAwMDAwMzA5NSAwMDAwMSBmDQowMDAwMDAzMDk2IDAw MDAxIGYNCjAwMDAwMDMwOTcgMDAwMDEgZg0KMDAwMDAwMzA5OCAwMDAwMSBmDQowMDAwMDAzMDk5 IDAwMDAxIGYNCjAwMDAwMDMxMDAgMDAwMDEgZg0KMDAwMDAwMzEwMSAwMDAwMSBmDQowMDAwMDAz MTAyIDAwMDAxIGYNCjAwMDAwMDMxMDMgMDAwMDEgZg0KMDAwMDAwMzEwNCAwMDAwMSBmDQowMDAw MDAzMTA1IDAwMDAxIGYNCjAwMDAwMDMxMDYgMDAwMDEgZg0KMDAwMDAwMzEwNyAwMDAwMSBmDQow MDAwMDAzMTA4IDAwMDAxIGYNCjAwMDAwMDMxMDkgMDAwMDEgZg0KMDAwMDAwMzExMCAwMDAwMSBm DQowMDAwMDAzMTExIDAwMDAxIGYNCjAwMDAwMDMxMTIgMDAwMDEgZg0KMDAwMDAwMzExMyAwMDAw MSBmDQowMDAwMDAzMTE0IDAwMDAxIGYNCjAwMDAwMDMxMTUgMDAwMDEgZg0KMDAwMDAwMzExNiAw MDAwMSBmDQowMDAwMDAzMTE3IDAwMDAxIGYNCjAwMDAwMDMxMTggMDAwMDEgZg0KMDAwMDAwMzEx OSAwMDAwMSBmDQowMDAwMDAzMTIxIDAwMDAxIGYNCjAwMDA0NDA0MjIgMDAwMDAgbg0KMDAwMDAw MzEzMCAwMDAwMSBmDQowMDAwNDQ1MDgzIDAwMDAwIG4NCjAwMDA0NDUyMzIgMDAwMDAgbg0KMDAw MDQ0NTYwNyAwMDAwMCBuDQowMDAwNDQ1NjMzIDAwMDAwIG4NCjAwMDA0NDU5MDcgMDAwMDAgbg0K MDAwMDQ0NTk3NyAwMDAwMCBuDQowMDAwNDQ2MjY4IDAwMDAwIG4NCjAwMDA0NDYzNDkgMDAwMDAg bg0KMDAwMDAwMzEzMSAwMDAwMCBmDQowMDAwMDAzMTMzIDAwMDAxIGYNCjAwMDA0NjQ0OTcgMDAw MDAgbg0KMDAwMDAwMzEzNCAwMDAwMSBmDQowMDAwMDAzMTM1IDAwMDAxIGYNCjAwMDAwMDMxMzYg MDAwMDEgZg0KMDAwMDAwMzEzNyAwMDAwMSBmDQowMDAwMDAzMTM4IDAwMDAxIGYNCjAwMDAwMDMx MzkgMDAwMDEgZg0KMDAwMDAwMzE0MCAwMDAwMSBmDQowMDAwMDAzMTQxIDAwMDAxIGYNCjAwMDAw MDMxNDIgMDAwMDEgZg0KMDAwMDAwMzE0MyAwMDAwMSBmDQowMDAwMDAzMTQ0IDAwMDAxIGYNCjAw MDAwMDMxNDUgMDAwMDEgZg0KMDAwMDAwMzE0NiAwMDAwMSBmDQowMDAwMDAzMTQ3IDAwMDAxIGYN CjAwMDAwMDMxNDggMDAwMDEgZg0KMDAwMDAwMzE0OSAwMDAwMSBmDQowMDAwMDAzMTUwIDAwMDAx IGYNCjAwMDAwMDMxNTEgMDAwMDEgZg0KMDAwMDAwMzE1MiAwMDAwMSBmDQowMDAwMDAzMTUzIDAw MDAxIGYNCjAwMDAwMDMxNTQgMDAwMDEgZg0KMDAwMDAwMzE1NSAwMDAwMSBmDQowMDAwMDAzMTU2 IDAwMDAxIGYNCjAwMDAwMDMxNTcgMDAwMDEgZg0KMDAwMDAwMzE1OCAwMDAwMSBmDQowMDAwMDAz MTU5IDAwMDAxIGYNCjAwMDAwMDMxNjAgMDAwMDEgZg0KMDAwMDAwMzE2MSAwMDAwMSBmDQowMDAw MDAzMTYyIDAwMDAxIGYNCjAwMDAwMDMxNjMgMDAwMDEgZg0KMDAwMDAwMzE2NCAwMDAwMSBmDQow MDAwMDAzMTY1IDAwMDAxIGYNCjAwMDAwMDMxNjYgMDAwMDEgZg0KMDAwMDAwMzE2NyAwMDAwMSBm DQowMDAwMDAzMTY4IDAwMDAxIGYNCjAwMDAwMDMxNjkgMDAwMDEgZg0KMDAwMDAwMzE3MCAwMDAw MSBmDQowMDAwMDAzMTcxIDAwMDAxIGYNCjAwMDAwMDMxNzIgMDAwMDEgZg0KMDAwMDAwMzE3MyAw MDAwMSBmDQowMDAwMDAzMTc0IDAwMDAxIGYNCjAwMDAwMDMxNzUgMDAwMDEgZg0KMDAwMDAwMzE3 NiAwMDAwMSBmDQowMDAwMDAzMTc3IDAwMDAxIGYNCjAwMDAwMDMxNzggMDAwMDEgZg0KMDAwMDAw MzE3OSAwMDAwMSBmDQowMDAwMDAzMTgwIDAwMDAxIGYNCjAwMDAwMDMxODEgMDAwMDEgZg0KMDAw MDAwMzE4MiAwMDAwMSBmDQowMDAwMDAzMTgzIDAwMDAxIGYNCjAwMDAwMDMxODQgMDAwMDEgZg0K MDAwMDAwMzE4NSAwMDAwMSBmDQowMDAwMDAzMTg2IDAwMDAxIGYNCjAwMDAwMDMxODcgMDAwMDEg Zg0KMDAwMDAwMzE4OCAwMDAwMSBmDQowMDAwMDAzMTg5IDAwMDAxIGYNCjAwMDAwMDMxOTAgMDAw MDEgZg0KMDAwMDAwMzE5MSAwMDAwMSBmDQowMDAwMDAzMTkyIDAwMDAxIGYNCjAwMDAwMDMxOTMg MDAwMDEgZg0KMDAwMDAwMzE5NCAwMDAwMSBmDQowMDAwMDAzMTk1IDAwMDAxIGYNCjAwMDAwMDMx OTYgMDAwMDEgZg0KMDAwMDAwMzE5NyAwMDAwMSBmDQowMDAwMDAzMTk4IDAwMDAxIGYNCjAwMDAw MDMxOTkgMDAwMDEgZg0KMDAwMDAwMzIwMCAwMDAwMSBmDQowMDAwMDAzMjAxIDAwMDAxIGYNCjAw MDAwMDMyMDIgMDAwMDEgZg0KMDAwMDAwMzIwMyAwMDAwMSBmDQowMDAwMDAzMjA0IDAwMDAxIGYN CjAwMDAwMDMyMDUgMDAwMDEgZg0KMDAwMDAwMzIwNiAwMDAwMSBmDQowMDAwMDAzMjA3IDAwMDAx IGYNCjAwMDAwMDMyMDggMDAwMDEgZg0KMDAwMDAwMzIwOSAwMDAwMSBmDQowMDAwMDAzMjEwIDAw MDAxIGYNCjAwMDAwMDMyMTEgMDAwMDEgZg0KMDAwMDAwMzIxMiAwMDAwMSBmDQowMDAwMDAzMjEz IDAwMDAxIGYNCjAwMDAwMDMyMTQgMDAwMDEgZg0KMDAwMDAwMzIxNSAwMDAwMSBmDQowMDAwMDAz MjE2IDAwMDAxIGYNCjAwMDAwMDMyMTcgMDAwMDEgZg0KMDAwMDAwMzIxOCAwMDAwMSBmDQowMDAw MDAzMjE5IDAwMDAxIGYNCjAwMDAwMDMyMjAgMDAwMDEgZg0KMDAwMDAwMzIyMSAwMDAwMSBmDQow MDAwMDAzMjIyIDAwMDAxIGYNCjAwMDAwMDMyMjMgMDAwMDEgZg0KMDAwMDAwMzIyNCAwMDAwMSBm DQowMDAwMDAzMjI1IDAwMDAxIGYNCjAwMDAwMDMyMjYgMDAwMDEgZg0KMDAwMDAwMzIyNyAwMDAw MSBmDQowMDAwMDAzMjI4IDAwMDAxIGYNCjAwMDAwMDMyMjkgMDAwMDEgZg0KMDAwMDAwMzIzMCAw MDAwMSBmDQowMDAwMDAzMjMxIDAwMDAxIGYNCjAwMDAwMDMyMzIgMDAwMDEgZg0KMDAwMDAwMzIz MyAwMDAwMSBmDQowMDAwMDAzMjM0IDAwMDAxIGYNCjAwMDAwMDMyMzUgMDAwMDEgZg0KMDAwMDAw MzIzNiAwMDAwMSBmDQowMDAwMDAzMjM3IDAwMDAxIGYNCjAwMDAwMDMyMzggMDAwMDEgZg0KMDAw MDAwMzIzOSAwMDAwMSBmDQowMDAwMDAzMjQwIDAwMDAxIGYNCjAwMDAwMDMyNDEgMDAwMDEgZg0K MDAwMDAwMzI0MiAwMDAwMSBmDQowMDAwMDAzMjQ0IDAwMDAxIGYNCjAwMDA0NjQ2MTIgMDAwMDAg bg0KMDAwMDAwMzI0NSAwMDAwMSBmDQowMDAwMDAzMjQ2IDAwMDAwIGYNCjAwMDAwMDMyNDggMDAw MDEgZg0KMDAwMDQ2OTM2OSAwMDAwMCBuDQowMDAwMDAzMjQ5IDAwMDAxIGYNCjAwMDAwMDMyNTAg MDAwMDEgZg0KMDAwMDAwMzI1MSAwMDAwMSBmDQowMDAwMDAzMjUyIDAwMDAxIGYNCjAwMDAwMDMy NTMgMDAwMDEgZg0KMDAwMDAwMzI1NCAwMDAwMSBmDQowMDAwMDAzMjU1IDAwMDAxIGYNCjAwMDAw MDMyNTYgMDAwMDEgZg0KMDAwMDAwMzI1NyAwMDAwMSBmDQowMDAwMDAzMjU4IDAwMDAxIGYNCjAw MDAwMDMyNTkgMDAwMDEgZg0KMDAwMDAwMzI2MCAwMDAwMSBmDQowMDAwMDAzMjYxIDAwMDAxIGYN CjAwMDAwMDMyNjIgMDAwMDEgZg0KMDAwMDAwMzI2MyAwMDAwMSBmDQowMDAwMDAzMjY0IDAwMDAx IGYNCjAwMDAwMDMyNjUgMDAwMDEgZg0KMDAwMDAwMzI2NiAwMDAwMSBmDQowMDAwMDAzMjY3IDAw MDAxIGYNCjAwMDAwMDMyNjggMDAwMDEgZg0KMDAwMDAwMzI2OSAwMDAwMSBmDQowMDAwMDAzMjcw IDAwMDAxIGYNCjAwMDAwMDMyNzEgMDAwMDEgZg0KMDAwMDAwMzI3MiAwMDAwMSBmDQowMDAwMDAz MjczIDAwMDAxIGYNCjAwMDAwMDMyNzQgMDAwMDEgZg0KMDAwMDAwMzI3NSAwMDAwMSBmDQowMDAw MDAzMjc2IDAwMDAxIGYNCjAwMDAwMDMyNzcgMDAwMDEgZg0KMDAwMDAwMzI3OCAwMDAwMSBmDQow MDAwMDAzMjc5IDAwMDAxIGYNCjAwMDAwMDMyODAgMDAwMDEgZg0KMDAwMDAwMzI4MSAwMDAwMSBm DQowMDAwMDAzMjgyIDAwMDAxIGYNCjAwMDAwMDMyODMgMDAwMDEgZg0KMDAwMDAwMzI4NCAwMDAw MSBmDQowMDAwMDAzMjg1IDAwMDAxIGYNCjAwMDAwMDMyODYgMDAwMDEgZg0KMDAwMDAwMzI4NyAw MDAwMSBmDQowMDAwMDAzMjg4IDAwMDAxIGYNCjAwMDAwMDMyODkgMDAwMDEgZg0KMDAwMDAwMzI5 MCAwMDAwMSBmDQowMDAwMDAzMjkxIDAwMDAxIGYNCjAwMDAwMDMyOTIgMDAwMDEgZg0KMDAwMDAw MzI5MyAwMDAwMSBmDQowMDAwMDAzMjk0IDAwMDAxIGYNCjAwMDAwMDMyOTUgMDAwMDEgZg0KMDAw MDAwMzI5NiAwMDAwMSBmDQowMDAwMDAzMjk3IDAwMDAxIGYNCjAwMDAwMDMyOTggMDAwMDEgZg0K MDAwMDAwMzI5OSAwMDAwMSBmDQowMDAwMDAzMzAwIDAwMDAxIGYNCjAwMDAwMDMzMDEgMDAwMDEg Zg0KMDAwMDAwMzMwMiAwMDAwMSBmDQowMDAwMDAzMzAzIDAwMDAxIGYNCjAwMDAwMDMzMDQgMDAw MDEgZg0KMDAwMDAwMzMwNSAwMDAwMSBmDQowMDAwMDAzMzA2IDAwMDAxIGYNCjAwMDAwMDMzMDcg MDAwMDEgZg0KMDAwMDAwMzMwOCAwMDAwMSBmDQowMDAwMDAzMzA5IDAwMDAxIGYNCjAwMDAwMDMz MTAgMDAwMDEgZg0KMDAwMDAwMzMxMSAwMDAwMSBmDQowMDAwMDAzMzEyIDAwMDAxIGYNCjAwMDAw MDMzMTMgMDAwMDEgZg0KMDAwMDAwMzMxNCAwMDAwMSBmDQowMDAwMDAzMzE1IDAwMDAxIGYNCjAw MDAwMDMzMTYgMDAwMDEgZg0KMDAwMDAwMzMxNyAwMDAwMSBmDQowMDAwMDAzMzE4IDAwMDAxIGYN CjAwMDAwMDMzMTkgMDAwMDEgZg0KMDAwMDAwMzMyMCAwMDAwMSBmDQowMDAwMDAzMzIxIDAwMDAx IGYNCjAwMDAwMDMzMjIgMDAwMDEgZg0KMDAwMDAwMzMyMyAwMDAwMSBmDQowMDAwMDAzMzI0IDAw MDAxIGYNCjAwMDAwMDMzMjUgMDAwMDEgZg0KMDAwMDAwMzMyNiAwMDAwMSBmDQowMDAwMDAzMzI3 IDAwMDAxIGYNCjAwMDAwMDMzMjggMDAwMDEgZg0KMDAwMDAwMzMyOSAwMDAwMSBmDQowMDAwMDAz MzMwIDAwMDAxIGYNCjAwMDAwMDMzMzEgMDAwMDEgZg0KMDAwMDAwMzMzMiAwMDAwMSBmDQowMDAw MDAzMzMzIDAwMDAxIGYNCjAwMDAwMDMzMzQgMDAwMDEgZg0KMDAwMDAwMzMzNSAwMDAwMSBmDQow MDAwMDAzMzM2IDAwMDAxIGYNCjAwMDAwMDMzMzcgMDAwMDEgZg0KMDAwMDAwMzMzOCAwMDAwMSBm DQowMDAwMDAzMzM5IDAwMDAxIGYNCjAwMDAwMDMzNDAgMDAwMDEgZg0KMDAwMDAwMzM0MSAwMDAw MSBmDQowMDAwMDAzMzQyIDAwMDAxIGYNCjAwMDAwMDMzNDMgMDAwMDEgZg0KMDAwMDAwMzM0NCAw MDAwMSBmDQowMDAwMDAzMzQ1IDAwMDAxIGYNCjAwMDAwMDMzNDYgMDAwMDEgZg0KMDAwMDAwMzM0 NyAwMDAwMSBmDQowMDAwMDAzMzQ4IDAwMDAxIGYNCjAwMDAwMDMzNDkgMDAwMDEgZg0KMDAwMDAw MzM1MCAwMDAwMSBmDQowMDAwMDAzMzUxIDAwMDAxIGYNCjAwMDAwMDMzNTIgMDAwMDEgZg0KMDAw MDAwMzM1MyAwMDAwMSBmDQowMDAwMDAzMzU0IDAwMDAxIGYNCjAwMDAwMDMzNTUgMDAwMDEgZg0K MDAwMDAwMzM1NiAwMDAwMSBmDQowMDAwMDAzMzU3IDAwMDAxIGYNCjAwMDAwMDMzNTggMDAwMDEg Zg0KMDAwMDAwMzM1OSAwMDAwMSBmDQowMDAwMDAzMzYwIDAwMDAxIGYNCjAwMDAwMDMzNjEgMDAw MDEgZg0KMDAwMDAwMzM2MiAwMDAwMSBmDQowMDAwMDAzMzYzIDAwMDAxIGYNCjAwMDAwMDMzNjQg MDAwMDEgZg0KMDAwMDAwMzM2NSAwMDAwMSBmDQowMDAwMDAzMzY2IDAwMDAxIGYNCjAwMDAwMDMz NjcgMDAwMDEgZg0KMDAwMDAwMzM2OCAwMDAwMSBmDQowMDAwMDAzMzY5IDAwMDAxIGYNCjAwMDAw MDMzNzAgMDAwMDEgZg0KMDAwMDAwMzM3MiAwMDAwMSBmDQowMDAwNDY5NDg0IDAwMDAwIG4NCjAw MDAwMDMzNzMgMDAwMDEgZg0KMDAwMDAwMzM3NCAwMDAwMCBmDQowMDAwMDAzMzc2IDAwMDAxIGYN CjAwMDA0NzQxNjggMDAwMDAgbg0KMDAwMDAwMzM3NyAwMDAwMSBmDQowMDAwMDAzMzc4IDAwMDAx IGYNCjAwMDAwMDMzNzkgMDAwMDEgZg0KMDAwMDAwMzM4MCAwMDAwMSBmDQowMDAwMDAzMzgxIDAw MDAxIGYNCjAwMDAwMDMzODIgMDAwMDEgZg0KMDAwMDAwMzM4MyAwMDAwMSBmDQowMDAwMDAzMzg0 IDAwMDAxIGYNCjAwMDAwMDMzODUgMDAwMDEgZg0KMDAwMDAwMzM4NiAwMDAwMSBmDQowMDAwMDAz Mzg3IDAwMDAxIGYNCjAwMDAwMDMzODggMDAwMDEgZg0KMDAwMDAwMzM4OSAwMDAwMSBmDQowMDAw MDAzMzkwIDAwMDAxIGYNCjAwMDAwMDMzOTEgMDAwMDEgZg0KMDAwMDAwMzM5MiAwMDAwMSBmDQow MDAwMDAzMzkzIDAwMDAxIGYNCjAwMDAwMDMzOTQgMDAwMDEgZg0KMDAwMDAwMzM5NSAwMDAwMSBm DQowMDAwMDAzMzk2IDAwMDAxIGYNCjAwMDAwMDMzOTcgMDAwMDEgZg0KMDAwMDAwMzM5OCAwMDAw MSBmDQowMDAwMDAzMzk5IDAwMDAxIGYNCjAwMDAwMDM0MDAgMDAwMDEgZg0KMDAwMDAwMzQwMSAw MDAwMSBmDQowMDAwMDAzNDAyIDAwMDAxIGYNCjAwMDAwMDM0MDMgMDAwMDEgZg0KMDAwMDAwMzQw NCAwMDAwMSBmDQowMDAwMDAzNDA1IDAwMDAxIGYNCjAwMDAwMDM0MDYgMDAwMDEgZg0KMDAwMDAw MzQwNyAwMDAwMSBmDQowMDAwMDAzNDA4IDAwMDAxIGYNCjAwMDAwMDM0MDkgMDAwMDEgZg0KMDAw MDAwMzQxMCAwMDAwMSBmDQowMDAwMDAzNDExIDAwMDAxIGYNCjAwMDAwMDM0MTIgMDAwMDEgZg0K MDAwMDAwMzQxMyAwMDAwMSBmDQowMDAwMDAzNDE0IDAwMDAxIGYNCjAwMDAwMDM0MTUgMDAwMDEg Zg0KMDAwMDAwMzQxNiAwMDAwMSBmDQowMDAwMDAzNDE3IDAwMDAxIGYNCjAwMDAwMDM0MTggMDAw MDEgZg0KMDAwMDAwMzQxOSAwMDAwMSBmDQowMDAwMDAzNDIwIDAwMDAxIGYNCjAwMDAwMDM0MjEg MDAwMDEgZg0KMDAwMDAwMzQyMiAwMDAwMSBmDQowMDAwMDAzNDIzIDAwMDAxIGYNCjAwMDAwMDM0 MjQgMDAwMDEgZg0KMDAwMDAwMzQyNSAwMDAwMSBmDQowMDAwMDAzNDI2IDAwMDAxIGYNCjAwMDAw MDM0MjcgMDAwMDEgZg0KMDAwMDAwMzQyOCAwMDAwMSBmDQowMDAwMDAzNDI5IDAwMDAxIGYNCjAw MDAwMDM0MzAgMDAwMDEgZg0KMDAwMDAwMzQzMSAwMDAwMSBmDQowMDAwMDAzNDMyIDAwMDAxIGYN CjAwMDAwMDM0MzMgMDAwMDEgZg0KMDAwMDAwMzQzNCAwMDAwMSBmDQowMDAwMDAzNDM1IDAwMDAx IGYNCjAwMDAwMDM0MzYgMDAwMDEgZg0KMDAwMDAwMzQzNyAwMDAwMSBmDQowMDAwMDAzNDM4IDAw MDAxIGYNCjAwMDAwMDM0MzkgMDAwMDEgZg0KMDAwMDAwMzQ0MCAwMDAwMSBmDQowMDAwMDAzNDQx IDAwMDAxIGYNCjAwMDAwMDM0NDIgMDAwMDEgZg0KMDAwMDAwMzQ0MyAwMDAwMSBmDQowMDAwMDAz NDQ0IDAwMDAxIGYNCjAwMDAwMDM0NDUgMDAwMDEgZg0KMDAwMDAwMzQ0NiAwMDAwMSBmDQowMDAw MDAzNDQ3IDAwMDAxIGYNCjAwMDAwMDM0NDggMDAwMDEgZg0KMDAwMDAwMzQ0OSAwMDAwMSBmDQow MDAwMDAzNDUwIDAwMDAxIGYNCjAwMDAwMDM0NTEgMDAwMDEgZg0KMDAwMDAwMzQ1MiAwMDAwMSBm DQowMDAwMDAzNDUzIDAwMDAxIGYNCjAwMDAwMDM0NTQgMDAwMDEgZg0KMDAwMDAwMzQ1NSAwMDAw MSBmDQowMDAwMDAzNDU2IDAwMDAxIGYNCjAwMDAwMDM0NTcgMDAwMDEgZg0KMDAwMDAwMzQ1OCAw MDAwMSBmDQowMDAwMDAzNDU5IDAwMDAxIGYNCjAwMDAwMDM0NjAgMDAwMDEgZg0KMDAwMDAwMzQ2 MSAwMDAwMSBmDQowMDAwMDAzNDYyIDAwMDAxIGYNCjAwMDAwMDM0NjMgMDAwMDEgZg0KMDAwMDAw MzQ2NCAwMDAwMSBmDQowMDAwMDAzNDY1IDAwMDAxIGYNCjAwMDAwMDM0NjYgMDAwMDEgZg0KMDAw MDAwMzQ2NyAwMDAwMSBmDQowMDAwMDAzNDY4IDAwMDAxIGYNCjAwMDAwMDM0NjkgMDAwMDEgZg0K MDAwMDAwMzQ3MCAwMDAwMSBmDQowMDAwMDAzNDcxIDAwMDAxIGYNCjAwMDAwMDM0NzIgMDAwMDEg Zg0KMDAwMDAwMzQ3MyAwMDAwMSBmDQowMDAwMDAzNDc0IDAwMDAxIGYNCjAwMDAwMDM0NzUgMDAw MDEgZg0KMDAwMDAwMzQ3NiAwMDAwMSBmDQowMDAwMDAzNDc3IDAwMDAxIGYNCjAwMDAwMDM0Nzgg MDAwMDEgZg0KMDAwMDAwMzQ3OSAwMDAwMSBmDQowMDAwMDAzNDgwIDAwMDAxIGYNCjAwMDAwMDM0 ODEgMDAwMDEgZg0KMDAwMDAwMzQ4MiAwMDAwMSBmDQowMDAwMDAzNDgzIDAwMDAxIGYNCjAwMDAw MDM0ODQgMDAwMDEgZg0KMDAwMDAwMzQ4NSAwMDAwMSBmDQowMDAwMDAzNDg2IDAwMDAxIGYNCjAw MDAwMDM0ODcgMDAwMDEgZg0KMDAwMDAwMzQ4OCAwMDAwMSBmDQowMDAwMDAzNDg5IDAwMDAxIGYN CjAwMDAwMDM0OTAgMDAwMDEgZg0KMDAwMDAwMzQ5MSAwMDAwMSBmDQowMDAwMDAzNDkyIDAwMDAx IGYNCjAwMDAwMDM0OTMgMDAwMDEgZg0KMDAwMDAwMzQ5NCAwMDAwMSBmDQowMDAwMDAzNDk1IDAw MDAxIGYNCjAwMDAwMDM0OTYgMDAwMDEgZg0KMDAwMDAwMzQ5NyAwMDAwMSBmDQowMDAwMDAzNDk4 IDAwMDAxIGYNCjAwMDAwMDM1MDAgMDAwMDEgZg0KMDAwMDQ3NDI4MyAwMDAwMCBuDQowMDAwMDAz NTAxIDAwMDAxIGYNCjAwMDAwMDM1MDIgMDAwMDAgZg0KMDAwMDAwMzUwNCAwMDAwMSBmDQowMDAw NDc5MTk4IDAwMDAwIG4NCjAwMDAwMDM1MDUgMDAwMDEgZg0KMDAwMDAwMzUwNiAwMDAwMSBmDQow MDAwMDAzNTA3IDAwMDAxIGYNCjAwMDAwMDM1MDggMDAwMDEgZg0KMDAwMDAwMzUwOSAwMDAwMSBm DQowMDAwMDAzNTEwIDAwMDAxIGYNCjAwMDAwMDM1MTEgMDAwMDEgZg0KMDAwMDAwMzUxMiAwMDAw MSBmDQowMDAwMDAzNTEzIDAwMDAxIGYNCjAwMDAwMDM1MTQgMDAwMDEgZg0KMDAwMDAwMzUxNSAw MDAwMSBmDQowMDAwMDAzNTE2IDAwMDAxIGYNCjAwMDAwMDM1MTcgMDAwMDEgZg0KMDAwMDAwMzUx OCAwMDAwMSBmDQowMDAwMDAzNTE5IDAwMDAxIGYNCjAwMDAwMDM1MjAgMDAwMDEgZg0KMDAwMDAw MzUyMSAwMDAwMSBmDQowMDAwMDAzNTIyIDAwMDAxIGYNCjAwMDAwMDM1MjMgMDAwMDEgZg0KMDAw MDAwMzUyNCAwMDAwMSBmDQowMDAwMDAzNTI1IDAwMDAxIGYNCjAwMDAwMDM1MjYgMDAwMDEgZg0K MDAwMDAwMzUyNyAwMDAwMSBmDQowMDAwMDAzNTI4IDAwMDAxIGYNCjAwMDAwMDM1MjkgMDAwMDEg Zg0KMDAwMDAwMzUzMCAwMDAwMSBmDQowMDAwMDAzNTMxIDAwMDAxIGYNCjAwMDAwMDM1MzIgMDAw MDEgZg0KMDAwMDAwMzUzMyAwMDAwMSBmDQowMDAwMDAzNTM0IDAwMDAxIGYNCjAwMDAwMDM1MzUg MDAwMDEgZg0KMDAwMDAwMzUzNiAwMDAwMSBmDQowMDAwMDAzNTM3IDAwMDAxIGYNCjAwMDAwMDM1 MzggMDAwMDEgZg0KMDAwMDAwMzUzOSAwMDAwMSBmDQowMDAwMDAzNTQwIDAwMDAxIGYNCjAwMDAw MDM1NDEgMDAwMDEgZg0KMDAwMDAwMzU0MiAwMDAwMSBmDQowMDAwMDAzNTQzIDAwMDAxIGYNCjAw MDAwMDM1NDQgMDAwMDEgZg0KMDAwMDAwMzU0NSAwMDAwMSBmDQowMDAwMDAzNTQ2IDAwMDAxIGYN CjAwMDAwMDM1NDcgMDAwMDEgZg0KMDAwMDAwMzU0OCAwMDAwMSBmDQowMDAwMDAzNTQ5IDAwMDAx IGYNCjAwMDAwMDM1NTAgMDAwMDEgZg0KMDAwMDAwMzU1MSAwMDAwMSBmDQowMDAwMDAzNTUyIDAw MDAxIGYNCjAwMDAwMDM1NTMgMDAwMDEgZg0KMDAwMDAwMzU1NCAwMDAwMSBmDQowMDAwMDAzNTU1 IDAwMDAxIGYNCjAwMDAwMDM1NTYgMDAwMDEgZg0KMDAwMDAwMzU1NyAwMDAwMSBmDQowMDAwMDAz NTU4IDAwMDAxIGYNCjAwMDAwMDM1NTkgMDAwMDEgZg0KMDAwMDAwMzU2MCAwMDAwMSBmDQowMDAw MDAzNTYxIDAwMDAxIGYNCjAwMDAwMDM1NjIgMDAwMDEgZg0KMDAwMDAwMzU2MyAwMDAwMSBmDQow MDAwMDAzNTY0IDAwMDAxIGYNCjAwMDAwMDM1NjUgMDAwMDEgZg0KMDAwMDAwMzU2NiAwMDAwMSBm DQowMDAwMDAzNTY3IDAwMDAxIGYNCjAwMDAwMDM1NjggMDAwMDEgZg0KMDAwMDAwMzU2OSAwMDAw MSBmDQowMDAwMDAzNTcwIDAwMDAxIGYNCjAwMDAwMDM1NzEgMDAwMDEgZg0KMDAwMDAwMzU3MiAw MDAwMSBmDQowMDAwMDAzNTczIDAwMDAxIGYNCjAwMDAwMDM1NzQgMDAwMDEgZg0KMDAwMDAwMzU3 NSAwMDAwMSBmDQowMDAwMDAzNTc2IDAwMDAxIGYNCjAwMDAwMDM1NzcgMDAwMDEgZg0KMDAwMDAw MzU3OCAwMDAwMSBmDQowMDAwMDAzNTc5IDAwMDAxIGYNCjAwMDAwMDM1ODAgMDAwMDEgZg0KMDAw MDAwMzU4MSAwMDAwMSBmDQowMDAwMDAzNTgyIDAwMDAxIGYNCjAwMDAwMDM1ODMgMDAwMDEgZg0K MDAwMDAwMzU4NCAwMDAwMSBmDQowMDAwMDAzNTg2IDAwMDAxIGYNCjAwMDA0NzkzMTMgMDAwMDAg bg0KMDAwMDAwMzU5NyAwMDAwMSBmDQowMDAwNDgyOTU3IDAwMDAwIG4NCjAwMDA0ODMxMDggMDAw MDAgbg0KMDAwMDQ4MzcyMiAwMDAwMCBuDQowMDAwNDgzNzQ4IDAwMDAwIG4NCjAwMDA0ODQyNDUg MDAwMDAgbg0KMDAwMDQ4NDMxNSAwMDAwMCBuDQowMDAwNDg0NjEwIDAwMDAwIG4NCjAwMDA0ODQ2 OTEgMDAwMDAgbg0KMDAwMDUxNzgxMiAwMDAwMCBuDQowMDAwNTE4MzcwIDAwMDAwIG4NCjAwMDAw MDM1OTggMDAwMDAgZg0KMDAwMDAwMzYwMCAwMDAwMSBmDQowMDAwNTE4OTYwIDAwMDAwIG4NCjAw MDAwMDM2MDEgMDAwMDEgZg0KMDAwMDAwMzYwMiAwMDAwMCBmDQowMDAwMDAzNjA3IDAwMDAxIGYN CjAwMDA1MjMwNzkgMDAwMDAgbg0KMDAwMDUyNjM5MCAwMDAwMCBuDQowMDAwNTcxMjU1IDAwMDAw IG4NCjAwMDA1ODk0NjkgMDAwMDAgbg0KMDAwMDAwMzYwOCAwMDAwMSBmDQowMDAwMDAzNjA5IDAw MDAwIGYNCjAwMDAwMDAwMDAgMDAwMDEgZg0KMDAwMDYyMjYxNiAwMDAwMCBuDQowMDAwMDAwODI3 IDY1NTM1IGYNCjAwMDAwMDM2MTEgNjU1MzUgZg0KMDAwMDAwMzYxMiA2NTUzNSBmDQowMDAwMDAz NjEzIDY1NTM1IGYNCjAwMDAwMDM2MTQgNjU1MzUgZg0KMDAwMDAwMzYxNSA2NTUzNSBmDQp0cmFp bGVyDQo8PC9TaXplIDM2MTcvUm9vdCA4MzAgMCBSPj4NCnhyZWYNCjAgMA0KdHJhaWxlcg0KPDwv U2l6ZSAzNjE3L1ByZXYgNzI3MDEwL1hSZWZTdG0gODExOC9Sb290IDgzMCAwIFIvSW5mbyAxMTkg MCBSL0lEWzxDOTJEOERGQjg2ODc0OEU0QTQwNTJGN0I0NjJDQjFEOT48OUE4MTU2QzEwQkQ0MEY0 RUE5MkE3QjdDNTVEOUUyQzY+XT4+DQpzdGFydHhyZWYNCjc5OTQwMg0KJSVFT0YNCg== ------=_NextPart_000_0065_01CDFE1C.173597A0-- From gffletch@aol.com Tue Jan 29 15:29:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150DA21F87FE for ; Tue, 29 Jan 2013 15:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWc6poAyEdEo for ; Tue, 29 Jan 2013 15:29:36 -0800 (PST) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by ietfa.amsl.com (Postfix) with ESMTP id 5373521F87CC for ; Tue, 29 Jan 2013 15:29:36 -0800 (PST) Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-db01.mx.aol.com (Outbound Mail Relay) with ESMTP id B455538000076; Tue, 29 Jan 2013 18:29:35 -0500 (EST) Received: from palantir.local (unknown [10.172.1.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9CA31E0000A6; Tue, 29 Jan 2013 18:29:27 -0500 (EST) Message-ID: <51085B43.3080103@aol.com> Date: Tue, 29 Jan 2013 18:29:07 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Donald F Coffin References: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> In-Reply-To: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> Content-Type: multipart/alternative; boundary="------------040208080007090701030704" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1359502175; bh=xnXsF9w9t6aXmgB4JSryg9/olCQyUkGB2y6zO+9e6no=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=XGLTaUBR7VYdG3VC1sXlF+lOdCVuoMgC/r+FnEkFbccWFR4k2PPaZYeWw2dTgdXFf sG+HxjGsfoz2F9EubjmqvlrOAfN6kZT5VpoSPnKuU5Z3UF73zrLD7H3Y7mf/T8NDFE HFX2HExDgrDXRDQX5KLwMsvakr9UolqhJNcfAK24= X-AOL-SCOLL-SCORE: 0:2:496676992:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290451085b5705b2 X-AOL-IP: 10.172.1.27 Cc: John Adkins , Marty Burns , Scott Crowder , Dave Robin , John Teeter , pmadsen@pingidentity.com, Edward Denson , oauth@ietf.org, Ray Perlner , Anne Hendry , Lynne Rodoni , Uday Verma Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 23:29:40 -0000 This is a multi-part message in MIME format. --------------040208080007090701030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First, just want to say this is a great write up of the situation. Thanks! A couple of additional thoughts regarding token management and processing... 1. If all tokens being revoked are tokens issued by the same Authorization Server (AS) then it can easily mark which are refresh and which are access such that I'm not sure an additional parameter is needed. If the issue is integrating with legacy tokens, then I can see a short term need as an optimization while the tokens rotate through. The question is whether the short term need of the parameter justifies it if long term it's not needed. Maybe an option is for the ESPI profile to specify an additional parameter that is not required by this spec. 2. I don't think you can always revoke the refresh_token if an access_token is revoked. I can see a use case where a client gets a refresh_token and an access_token. The client uses the access_token for 5 minutes but the access_token is good for an hour. So the client revokes the access_token to ensure it can't be used again. The client will just use it's refresh_token when it needs another access_token. In this case, revoking the refresh_token would "break" the client. In addition, unless you add audience style checking to the token processing rules, you open up the AS to a denial of service attack. Basically, if the AS revokes the refresh_token when an access_token is revoked, I can steal an access_token and send it to the revocation endpoint causing the real client's refresh_token to be revoked. To prevent this, the tokens should be bound to the client_id to which they were issued, and should only be revocable from that client_id. 3. If the standard OAuth spec does not provide enough control, your profile of OAuth2 for the ESPI can tighten it to provide the protections desired. Thanks, George On 1/29/13 3:28 PM, Donald F Coffin wrote: > > Hi Thorsten, > > I am working with the OpenADE Task Force to document how the "*/Energy > Service Provider Interface (ESPI) Standard/* " published by the *North > American Energy Standards Board* (NAESB) in October of 2011 should be > implemented. The *ESPI Standard* defines how Retail Customers, Third > Party applications, and Data Custodians (i.e. electrical, gas, or > water utility) must interface to each other and the data format used > to exchange energy information. The interface between the Retail > Customer and the Data Custodian is known as "*Download My Data*", > which defines how a Retail Customer receives their energy information > in an XML file downloaded to them by the Data Custodian. The > interface between the Third Party application and the Data Custodian > is known as "*Connect My Data*", which defines the message exchanges > between the Third Party application and the Data Custodian to allow > the Third Party to access data at the Data Custodian after a Retail > Customer has granted the Third Party application access. > > It is my responsibility within the OpenADE Task Force to document the > integration of the *OAuth 2.0* protocol with the *ESPI Standard.* > Since the *ESPI Standard* requires Retail Customers, Third Party > applications, and Data Custodians to revoke Tokens (i.e. Access and > Refresh Tokens) I am very interested in the "*/Token Revocation > (draft-ietf-oath-revocation-xx)/*" work being done by you and your > working group. > > *_Token Revocation Request_* > > The *Token Revocation* request has only the "token" parameter with the > description that the authorization server is supposed to detect the > token type automatically. I would like to request that an addition > parameter "token_type" be added to the request. The "token_type" > parameter could be optional and would define the type of token being > revoked (i.e. "access", "refresh", "registration access", etc.). > > The *ESPI Standard* was developed to support the *Advanced Meter > Interface* *(AMI) *which is the interface used by "Smart Meters" to > provide automated energy usage collection and other operational > information about a Retail Customer's residence to their Data > Custodian. Third Party applications will be required to obtain the > approval if each Retail Customer that has had a "Smart Meter" > installed before they will be able to access the data provided by > their "Smart Meter". The number of "Smart Meters" currently installed > at the three largest California utilities (Pacific Gas & Electric, > Southern California Edison, and San Diego Gas & Electric) is in excess > of 10.0 M and growing. The following table indicates the number of > "Smart Meters" each of the three utilities had installed as of May 2012: > > *Utility* > > > > *"Smart Meters" Installed* > > Pacific Gas & Electric (PG&E) > > > > 4,696,000 > > San Diego Gas & Electric (SDG&E) > > > > 1,364,000 > > Southern California Edison (SCE) > > > > 3,900,000 > > The numbers in the chart were taken from the "*/Utility-Scale Smart > Meter Deployments, Plans, & Proposals -- IEE Report/*" published May > 2012 by *The Edison Foundation Institute for Electric Efficiency" > *which I have attached. The number of "Smart Meters" currently > installed are even larger than shown in the report as I compose this > email. Assuming 10% of Pacific Gas & Electric's Retail Customers > decide to utilize a Third Party application (3 Third Party > applications are currently supported and are 3 more Third Party > applications are preparing to be supported) in order to support the > ability to revoke a token they would be required to track 500,000 > access tokens and 500,000 refresh tokens. Requiring PG&E's > authorization server to "automatically" determine the type of Token > being revoked begins to negatively impact their processing > capability. If the *Token Revocation* request was capable of > indicating the type of Token to be revoked, the amount of time it will > take PG&E's authorization server would show a significant time savings > to process the request. > > *_Authorization Server Revocation Policy_* > > 6.Does the revocation of the access token also revoke the refresh > token (if it was provided) ? Or is this a revocation policy decision ? > > - if the token passed to the request is a refresh token and the server > supports access token revocation, the server SHOULD also revoke them. > - if the token passed to the request is an access token, the server > may decide to revoke the respective refresh token as well. > > I believe that if the token passed in the request is an access token, > the server MUST revoke any respective refresh token. Otherwise, their > exist a potential security risk of the respective refresh token being > used to gain access to the resources for which the access token was > issued. It also means the authorization server will have potential > "junk" in the refresh token file to search through for any additional > Token Revocation request. > > I look forward to receiving your response. > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > REMI Networks > > 22751 El Prado Suite 6216 > > Rancho Santa Margarita, CA 92688-3836 > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040208080007090701030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit First, just want to say this is a great write up of the situation. Thanks!

A couple of additional thoughts regarding token management and processing...

1. If all tokens being revoked are tokens issued by the same Authorization Server (AS) then it can easily mark which are refresh and which are access such that I'm not sure an additional parameter is needed. If the issue is integrating with legacy tokens, then I can see a short term need as an optimization while the tokens rotate through. The question is whether the short term need of the parameter justifies it if long term it's not needed. Maybe an option is for the ESPI profile to specify an additional parameter that is not required by this spec.

2. I don't think you can always revoke the refresh_token if an access_token is revoked. I can see a use case where a client gets a refresh_token and an access_token. The client uses the access_token for 5 minutes but the access_token is good for an hour. So the client revokes the access_token to ensure it can't be used again. The client will just use it's refresh_token when it needs another access_token. In this case, revoking the refresh_token would "break" the client. In addition, unless you add audience style checking to the token processing rules, you open up the AS to a denial of service attack. Basically, if the AS revokes the refresh_token when an access_token is revoked, I can steal an access_token and send it to the revocation endpoint causing the real client's refresh_token to be revoked. To prevent this, the tokens should be bound to the client_id to which they were issued, and should only be revocable from that client_id.

3. If the standard OAuth spec does not provide enough control, your profile of OAuth2 for the ESPI can tighten it to provide the protections desired.

Thanks,
George
On 1/29/13 3:28 PM, Donald F Coffin wrote:

Hi Thorsten,

 

I am working with the OpenADE Task Force to document how the “Energy Service Provider Interface (ESPI) Standard ” published by the North American Energy Standards Board (NAESB) in October of 2011 should be implemented.  The ESPI Standard defines how Retail Customers, Third Party applications, and Data Custodians (i.e. electrical, gas, or water utility) must interface to each other and the data format used to exchange energy information.   The interface between the Retail Customer and the Data Custodian is known as “Download My Data”, which defines how a Retail Customer receives their energy information in an XML file downloaded to them by the Data Custodian.  The interface between the Third Party application and the Data Custodian is known as “Connect My Data”, which defines the message exchanges between the Third Party application and the Data Custodian to allow the Third Party to access data at the Data Custodian after a Retail Customer has granted the Third Party application access.

 

It is my responsibility within the OpenADE Task Force to document the integration of the OAuth 2.0 protocol with the ESPI Standard.  Since the ESPI Standard requires Retail Customers, Third Party applications, and Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I am very interested in the “Token Revocation (draft-ietf-oath-revocation-xx)” work being done by you and your working group.

 

Token Revocation Request

 

The Token Revocation request has only the “token” parameter with the description that the authorization server is supposed to detect the token type automatically.  I would like to request that an addition parameter “token_type” be added to the request.  The “token_type” parameter could be optional and would define the type of token being revoked (i.e. “access”, “refresh”, “registration access”, etc.).

 

The ESPI Standard was developed to support the Advanced Meter Interface (AMI) which is the interface used by “Smart Meters” to provide automated energy usage collection and other operational information about a Retail Customer’s residence to their Data Custodian.  Third Party applications will be required to obtain the approval if each Retail Customer that has had a “Smart Meter” installed before they will be able to access the data provided by their “Smart Meter”.  The number of “Smart Meters” currently installed at the three largest California utilities (Pacific Gas & Electric, Southern California Edison, and San Diego Gas & Electric) is in excess of 10.0 M and growing.  The following table indicates the number of “Smart Meters” each of the three utilities had installed as of May 2012:

 

Utility

“Smart Meters” Installed

Pacific Gas & Electric (PG&E)

4,696,000

San Diego Gas & Electric (SDG&E)

1,364,000

Southern California Edison (SCE)

3,900,000

 

The numbers in the chart were taken from the “Utility-Scale Smart Meter Deployments, Plans, & Proposals -- IEE Report” published May 2012 by The Edison Foundation Institute for Electric Efficiency” which I have attached.  The number of “Smart Meters” currently installed are even larger than shown in the report as I compose this email.  Assuming 10% of Pacific Gas & Electric’s Retail Customers decide to utilize a Third Party application (3 Third Party applications are currently supported and are 3 more Third Party applications are preparing to be supported) in order to support the ability to revoke a token they would be required to track 500,000 access tokens and 500,000 refresh tokens.  Requiring PG&E’s authorization server to “automatically” determine the type of Token being revoked begins to negatively impact their processing capability.  If the Token Revocation request was capable of indicating the type of Token to be revoked, the amount of time it will take PG&E’s authorization server would show a significant time savings to process the request.

 

Authorization Server Revocation Policy

 

 

      6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?

 

- if the token passed to the request is a refresh token and the server supports access token revocation, the server SHOULD also revoke them.
- if the token passed to the request is an access token, the server may decide to revoke the respective refresh token as well.

 

I believe that if the token passed in the request is an access token, the server MUST revoke any respective refresh token.  Otherwise, their exist a potential security risk of the respective refresh token being used to gain access to the resources for which the access token was issued.  It also means the authorization server will have potential “junk” in the refresh token file to search through for any additional Token Revocation request.

 

I look forward to receiving your response.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

 



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

--------------040208080007090701030704-- From donald.coffin@reminetworks.com Tue Jan 29 16:31:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE121F86FF for ; Tue, 29 Jan 2013 16:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiHfDXu6H8Be for ; Tue, 29 Jan 2013 16:31:01 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 7357021F86F6 for ; Tue, 29 Jan 2013 16:31:01 -0800 (PST) Received: (qmail 18633 invoked by uid 0); 30 Jan 2013 00:30:37 -0000 Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy1.bluehost.com with SMTP; 30 Jan 2013 00:30:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=AGaIY+0gB/2z0p724H4AuC3tC5fL2E6zZuJ0euQrjfk=; b=EA1NW6oYkcKO2LqWNioAUPzznGwVY/gnGxHVU/ANu//W2NW8IE85idE5QkbQcJ+5M9p7dfoyedNDkf+VOz2RaXYKE8XynVWchT08H379OfSZR0h+r9IhGpQOhSKdLp1q; Received: from [68.4.207.246] (port=7449 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0LZU-0007aR-Sy; Tue, 29 Jan 2013 17:30:37 -0700 From: "Donald F Coffin" To: "'George Fletcher'" References: <006401cdfe5f$2555f170$7001d450$@reminetworks.com> <51085B43.3080103@aol.com> In-Reply-To: <51085B43.3080103@aol.com> Date: Tue, 29 Jan 2013 16:29:45 -0800 Message-ID: <00c901cdfe80$e7d0eb30$b772c190$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CDFE3D.D9B26620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGqJs1aP2O8OPoDFE4j2TX8/D0+WgJbNiMKmJXMDtA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com} Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:31:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01CDFE3D.D9B26620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit George, Thanks for the quick response. I've added my comments after your responses below. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: George Fletcher [mailto:gffletch@aol.com] Sent: Tuesday, January 29, 2013 3:29 PM To: Donald F Coffin Cc: Torsten Lodderstedt; John Adkins; Scott Crowder; Dave Robin; John Teeter; pmadsen@pingidentity.com; Edward Denson; Marty Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 First, just want to say this is a great write up of the situation. Thanks! A couple of additional thoughts regarding token management and processing... 1. If all tokens being revoked are tokens issued by the same Authorization Server (AS) then it can easily mark which are refresh and which are access such that I'm not sure an additional parameter is needed. If the issue is integrating with legacy tokens, then I can see a short term need as an optimization while the tokens rotate through. The question is whether the short term need of the parameter justifies it if long term it's not needed. Maybe an option is for the ESPI profile to specify an additional parameter that is not required by this spec. [Don] A few utilities have launched "Connect My Data" programs with Third Party applications, but these are using Certificates as a means of identifying Third Party applications. There are no utilities, to my knowledge, with "Connect My Data" programs that have implemented OAuth 2.0. The current ESPI Standard requires the implementation of OAuth 1.0. Therefore, there should not be a legacy token issue. As a result of the work our group is doing, we will shortly submit a request to NAESB to revise the existing standard to reflect the migration from OAuth 1.0 to OAuth 2.0. Your suggestion to "mark which are refresh and which are access" tokens while providing a method to identify what type of token was issued after it has been found, still poses a processing problem if the only parameter on the Token Revocation request is the Token. Even implementing your suggestion it will still be necessary to scan the entire set of Tokens to locate and identify what type of Token is being revoked. If a token_type parameter is provided with the Token Revocation request the only Tokens that need to be scanned are those matching the type being revoked. This will significantly reduce the size of the dataset and therefore expedite the search. I realize assigning the Token value as an index key would also improve the retrieval time. Since that is an implementation feature, it is beyond the scope of the activity our group is chartered to perform. 2. I don't think you can always revoke the refresh_token if an access_token is revoked. I can see a use case where a client gets a refresh_token and an access_token. The client uses the access_token for 5 minutes but the access_token is good for an hour. So the client revokes the access_token to ensure it can't be used again. The client will just use it's refresh_token when it needs another access_token. In this case, revoking the refresh_token would "break" the client. In addition, unless you add audience style checking to the token processing rules, you open up the AS to a denial of service attack. Basically, if the AS revokes the refresh_token when an access_token is revoked, I can steal an access_token and send it to the revocation endpoint causing the real client's refresh_token to be revoked. To prevent this, the tokens should be bound to the client_id to which they were issued, and should only be revocable from that client_id. [Don] The focus of the ESPI Standard is to provide Retail Customer's with access to a single UsagePoint (i.e. their Smart Meter). Therefore an access and refresh token will be tightly correlated with the type and frequency of data the Smart Meter provides. There are only a few reasons defined within the ESPI Standard list of use cases that will require the Token Revocation request to be issued. The following summarizes the situations that require a Token Revocation request: . A Third Party application wishes to terminate their relationship with a Retail Customer. . A Third Party application wishes to terminate their relationship with a Data Custodian. . A Retail Customer wishes to terminate their relationship with a Third Party application. . A Retail Customer wishes to change the data (i.e. scope) a Third Party application has permission to access. In none of the above situations will it be valid to retain a refresh token, which I realize is implementation dependent, due to the nature of the ESPI Standard. Perhaps the section on the Server's Revocation Policy should address a few of the reasons why a client may want or need to revoke a token. The current description provides no consideration for the relationship between tokens and scope, although there clearly is a relationship. 3. If the standard OAuth spec does not provide enough control, your profile of OAuth2 for the ESPI can tighten it to provide the protections desired. [Don] I am aware we can provide additional parameters required to integrate OAuth 2.0 with the ESPI Standard by submitting those parameter values to the OAuth Parameters registry. I would prefer not to do that, given the large amount of work being done on RFC-drafts to resolve many of the issues we are facing to integrate OAuth 2.0 with the ESPI Standard, since the need to use those extensions will most likely be short lived. Thanks, George On 1/29/13 3:28 PM, Donald F Coffin wrote: Hi Thorsten, I am working with the OpenADE Task Force to document how the "Energy Service Provider Interface (ESPI) Standard " published by the North American Energy Standards Board (NAESB) in October of 2011 should be implemented. The ESPI Standard defines how Retail Customers, Third Party applications, and Data Custodians (i.e. electrical, gas, or water utility) must interface to each other and the data format used to exchange energy information. The interface between the Retail Customer and the Data Custodian is known as "Download My Data", which defines how a Retail Customer receives their energy information in an XML file downloaded to them by the Data Custodian. The interface between the Third Party application and the Data Custodian is known as "Connect My Data", which defines the message exchanges between the Third Party application and the Data Custodian to allow the Third Party to access data at the Data Custodian after a Retail Customer has granted the Third Party application access. It is my responsibility within the OpenADE Task Force to document the integration of the OAuth 2.0 protocol with the ESPI Standard. Since the ESPI Standard requires Retail Customers, Third Party applications, and Data Custodians to revoke Tokens (i.e. Access and Refresh Tokens) I am very interested in the "Token Revocation (draft-ietf-oath-revocation-xx)" work being done by you and your working group. Token Revocation Request The Token Revocation request has only the "token" parameter with the description that the authorization server is supposed to detect the token type automatically. I would like to request that an addition parameter "token_type" be added to the request. The "token_type" parameter could be optional and would define the type of token being revoked (i.e. "access", "refresh", "registration access", etc.). The ESPI Standard was developed to support the Advanced Meter Interface (AMI) which is the interface used by "Smart Meters" to provide automated energy usage collection and other operational information about a Retail Customer's residence to their Data Custodian. Third Party applications will be required to obtain the approval if each Retail Customer that has had a "Smart Meter" installed before they will be able to access the data provided by their "Smart Meter". The number of "Smart Meters" currently installed at the three largest California utilities (Pacific Gas & Electric, Southern California Edison, and San Diego Gas & Electric) is in excess of 10.0 M and growing. The following table indicates the number of "Smart Meters" each of the three utilities had installed as of May 2012: Utility "Smart Meters" Installed Pacific Gas & Electric (PG&E) 4,696,000 San Diego Gas & Electric (SDG&E) 1,364,000 Southern California Edison (SCE) 3,900,000 The numbers in the chart were taken from the "Utility-Scale Smart Meter Deployments, Plans, & Proposals -- IEE Report" published May 2012 by The Edison Foundation Institute for Electric Efficiency" which I have attached. The number of "Smart Meters" currently installed are even larger than shown in the report as I compose this email. Assuming 10% of Pacific Gas & Electric's Retail Customers decide to utilize a Third Party application (3 Third Party applications are currently supported and are 3 more Third Party applications are preparing to be supported) in order to support the ability to revoke a token they would be required to track 500,000 access tokens and 500,000 refresh tokens. Requiring PG&E's authorization server to "automatically" determine the type of Token being revoked begins to negatively impact their processing capability. If the Token Revocation request was capable of indicating the type of Token to be revoked, the amount of time it will take PG&E's authorization server would show a significant time savings to process the request. Authorization Server Revocation Policy 6. Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ? - if the token passed to the request is a refresh token and the server supports access token revocation, the server SHOULD also revoke them. - if the token passed to the request is an access token, the server may decide to revoke the respective refresh token as well. I believe that if the token passed in the request is an access token, the server MUST revoke any respective refresh token. Otherwise, their exist a potential security risk of the respective refresh token being used to gain access to the resources for which the access token was issued. It also means the authorization server will have potential "junk" in the refresh token file to search through for any additional Token Revocation request. I look forward to receiving your response. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_00CA_01CDFE3D.D9B26620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

George,

 

Thanks for the quick response.  I’ve added my comments after = your responses below.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO=

 

<= p class=3DMsoNormal>REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA  92688-3836

 

<= p class=3DMsoNormal>Phone:    = ;  (949) 636-8571

Email:    = ;   donald.coffin@reminetworks.com=

 

From: George Fletcher [mailto:gffletch@aol.com]
Sent: = Tuesday, January 29, 2013 3:29 PM
To: Donald F = Coffin
Cc: Torsten Lodderstedt; John Adkins; Scott Crowder; = Dave Robin; John Teeter; pmadsen@pingidentity.com; Edward Denson; Marty = Burns; Uday Verma; Ray Perlner; Anne Hendry; Lynne Rodoni; = oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-ietf-oauth-revocation-04

 

First, just want to say = this is a great write up of the situation. Thanks!

A couple of = additional thoughts regarding token management and = processing...

1. If all tokens being revoked are tokens issued by = the same Authorization Server (AS) then it can easily mark which are = refresh and which are access such that I'm not sure an additional = parameter is needed. If the issue is integrating with legacy tokens, = then I can see a short term need as an optimization while the tokens = rotate through. The question is whether the short term need of the = parameter justifies it if long term it's not needed. Maybe an option is = for the ESPI profile to specify an additional parameter that is not = required by this spec.

[D= on] A few utilities have launched “Connect My Data” = programs with Third Party applications, but these are using Certificates = as a means of identifying Third Party applications.  There are no = utilities, to my knowledge, with “Connect My Data” = programs that have implemented OAuth 2.0.  The current = ESPI Standard requires the implementation of OAuth = 1.0.  Therefore, there should not be a legacy token issue. =  As a result of the work our group is doing, we will shortly submit = a request to NAESB to revise the existing standard to reflect the = migration from OAuth 1.0 to OAuth 2.0.

Your = suggestion to “mark which are refresh and which are access” = tokens while providing a method to identify what type of token was = issued after it has been found, still poses a processing problem if the = only parameter on the Token Revocation request is the = Token.  Even implementing your suggestion it will still be = necessary to scan the entire set of Tokens to locate and identify what = type of Token is being revoked.  If a token_type parameter = is provided with the Token Revocation request the only Tokens = that need to be scanned are those matching the type being revoked.  = This will significantly reduce the size of the dataset and therefore = expedite the search.  I realize assigning the Token value as an = index key would also improve the retrieval time.  Since that is an = implementation feature, it is beyond the scope of the activity our group = is chartered to perform.


2. I don't think = you can always revoke the refresh_token if an access_token is revoked. I = can see a use case where a client gets a refresh_token and an = access_token. The client uses the access_token for 5 minutes but the = access_token is good for an hour. So the client revokes the access_token = to ensure it can't be used again. The client will just use it's = refresh_token when it needs another access_token. In this case, revoking = the refresh_token would "break" the client. In addition, = unless you add audience style checking to the token processing rules, = you open up the AS to a denial of service attack. Basically, if the AS = revokes the refresh_token when an access_token is revoked, I can steal = an access_token and send it to the revocation endpoint causing the real = client's refresh_token to be revoked. To prevent this, the tokens should = be bound to the client_id to which they were issued, and should only be = revocable from that client_id.

 

[D= on] The focus of the ESPI Standard is to provide Retail = Customer’s with access to a single UsagePoint (i.e. their Smart = Meter).  Therefore an access and refresh token will be tightly = correlated with the type and frequency of data the Smart Meter = provides.  There are only a few reasons defined within the ESPI = Standard list of use cases that will require the Token = Revocation request to be issued.  The following summarizes the = situations that require a Token Revocation = request:

·         = A = Third Party application wishes to terminate their relationship with a = Retail Customer.

·         = A = Third Party application wishes to terminate their relationship with a = Data Custodian.

·         = A = Retail Customer wishes to terminate their relationship with a Third = Party application.

·         = A = Retail Customer wishes to change the data (i.e. scope) a Third Party = application has permission to access.

In= none of the above situations will it be valid to retain a refresh = token, which I realize is implementation dependent, due to the nature of = the ESPI Standard.

Pe= rhaps the section on the Server’s Revocation Policy should = address a few of the reasons why a client may want or need to revoke a = token.  The current description provides no consideration for the = relationship between tokens and scope, although there clearly is a = relationship.

3. If the standard OAuth = spec does not provide enough control, your profile of OAuth2 for the = ESPI can tighten it to provide the protections desired.

[D= on] I am aware we can provide additional parameters required to = integrate OAuth 2.0 with the ESPI Standard by submitting = those parameter values to the OAuth Parameters registry. I would = prefer not to do that, given the large amount of work being done on = RFC-drafts to resolve many of the issues we are facing to integrate = OAuth 2.0 with the ESPI Standard, since the need to use = those extensions will most likely be short lived.

Thanks,
George

On 1/29/13 3:28 PM, Donald F = Coffin wrote:

Hi = Thorsten,

 

I am working = with the OpenADE Task Force to document how the “Energy = Service Provider Interface (ESPI) Standard ” published by = the North American Energy Standards Board (NAESB) in October of = 2011 should be implemented.  The ESPI Standard defines how = Retail Customers, Third Party applications, and Data Custodians (i.e. = electrical, gas, or water utility) must interface to each other and the = data format used to exchange energy information.   The = interface between the Retail Customer and the Data Custodian is known as = “Download My Data”, which defines how a Retail = Customer receives their energy information in an XML file downloaded to = them by the Data Custodian.  The interface between the Third Party = application and the Data Custodian is known as “Connect My = Data”, which defines the message exchanges between the Third = Party application and the Data Custodian to allow the Third Party to = access data at the Data Custodian after a Retail Customer has granted = the Third Party application access.

 

It is my = responsibility within the OpenADE Task Force to document the integration = of the OAuth 2.0 protocol with the ESPI Standard.  = Since the ESPI Standard requires Retail Customers, Third Party = applications, and Data Custodians to revoke Tokens (i.e. Access and = Refresh Tokens) I am very interested in the “Token = Revocation (draft-ietf-oath-revocation-xx)” work being = done by you and your working group.

 

Token = Revocation Request

 

The Token = Revocation request has only the “token” parameter with = the description that the authorization server is supposed to detect the = token type automatically.  I would like to request that an addition = parameter “token_type” be added to the request.  The = “token_type” parameter could be optional and would define = the type of token being revoked (i.e. “access”, = “refresh”, “registration access”, = etc.).

 

The ESPI = Standard was developed to support the Advanced Meter = Interface (AMI) which is the interface used by “Smart = Meters” to provide automated energy usage collection and other = operational information about a Retail Customer’s residence to = their Data Custodian.  Third Party applications will be required to = obtain the approval if each Retail Customer that has had a “Smart = Meter” installed before they will be able to access the data = provided by their “Smart Meter”.  The number of = “Smart Meters” currently installed at the three largest = California utilities (Pacific Gas & Electric, Southern California = Edison, and San Diego Gas & Electric) is in excess of 10.0 M and = growing.  The following table indicates the number of “Smart = Meters” each of the three utilities had installed as of May = 2012:

 

Utility

“Smart = Meters” Installed

Pacific Gas = & Electric (PG&E)

4,696,000=

San Diego Gas = & Electric (SDG&E)

1,364,000=

Southern = California Edison (SCE)

3,900,000=

 

The numbers in = the chart were taken from the “Utility-Scale Smart Meter = Deployments, Plans, & Proposals -- IEE Report” = published May 2012 by The Edison Foundation Institute for Electric = Efficiency” which I have attached.  The number of = “Smart Meters” currently installed are even larger than = shown in the report as I compose this email.  Assuming 10% of = Pacific Gas & Electric’s Retail Customers decide to utilize a = Third Party application (3 Third Party applications are currently = supported and are 3 more Third Party applications are preparing to be = supported) in order to support the ability to revoke a token they would = be required to track 500,000 access tokens and 500,000 refresh = tokens.  Requiring PG&E’s authorization server to = “automatically” determine the type of Token being revoked = begins to negatively impact their processing capability.  If the = Token Revocation request was capable of indicating the type of = Token to be revoked, the amount of time it will take PG&E’s = authorization server would show a significant time savings to process = the request.

 

Authorization = Server Revocation Policy

 

 

  &nbs= p;   6.       Does the = revocation of the access token also revoke the refresh token (if it was = provided) ? Or is this a revocation policy decision ?

 

- if the token passed to the request is a refresh token = and the server supports access token revocation, the server SHOULD also = revoke them.
- if the token passed to the request is an access token, = the server may decide to revoke the respective refresh token as = well.

 

I believe that if the token passed in the request is an = access token, the server MUST revoke any respective refresh token.  = Otherwise, their exist a potential security risk of the respective = refresh token being used to gain access to the resources for which the = access token was issued.  It also means the authorization server = will have potential “junk” in the refresh token file to = search through for any additional Token Revocation = request.

 

I look forward to receiving your = response.

 

Best = regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, CA  = 92688-3836

 

Phone:      (949) = 636-8571

Email:       donald.coffin@reminetworks= .com

 




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

 

------=_NextPart_000_00CA_01CDFE3D.D9B26620-- From jricher@mitre.org Wed Jan 30 07:21:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410721F88CC for ; Wed, 30 Jan 2013 07:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYdwVj6Ps7Eh for ; Wed, 30 Jan 2013 07:21:03 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED73B21F88C8 for ; Wed, 30 Jan 2013 07:21:02 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D6AEF1F2779; Wed, 30 Jan 2013 10:20:57 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 769471F2716; Wed, 30 Jan 2013 10:20:57 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 10:20:56 -0500 Message-ID: <51093A3D.8030306@mitre.org> Date: Wed, 30 Jan 2013 10:20:29 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Shiu Fun Poon References: <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020907040708070806070805" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Concerning OAuth introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 15:21:07 -0000 --------------020907040708070806070805 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit > Hi.. Tony.. You are able to present this better than I do. > > Justin, > > Currently as it is, the spec is unflexible. So when I send a request > to an endpoint, the endpoint will need to have information like > /revoke, /introspection, and others. I can imagine the documented > usage of this will a pages long just to describe all the endpoint that > is needed to support an application. (so far, /authz, /token, > /introspection, /revoke, /.....), and this will be painful in the > multi-tenant environment. > > So why not allow the flexibility of using one endpoint /token (example > only), and make the caller to tell you want the caller wants ? It can > be an optional field, and a hint to the authorization/token endpoint > on what you want to do. > This is incompatible with OAuth as it stands today, which defines the auth endpoint and token endpoint as logically separate, and therefore there is not a parameter defined that would allow for such functionality switching. That said, an *installation* could implement it this way if they wanted to, they'd just have to document the endpoints like this: token endpoint: /oauth?op=token auth endpoint: /oauth?op=auth introspection endpoint: /oauth?op=introspect revocation endpoint: /oauth?op=revoke etc. The key difference here is that the "op=" parameter is *system specific* and is *not* part of the spec itself. And I think that's a good design to continue to follow. Right now, the registration endpoint is the only one that defines an "operation" parameter, and I was positing the question of defining it in terms of three different endpoints instead. Most of the time, these endpoints will have different URLs, as outlined below, but specific instances could use some kind of "operation" parameter if they wanted to. Defining it as one endpoint with a switch parameter actually decreses flexibility quite a lot, especially if you're talking about dispatching to different kinds of functionality all together, which is the use case you brought up. There are some places where that could make sense, and the definition of different endpoints allows you to do that in specific instances of a system without breaking the assumptions of clients. What Tony was talking about was allowing something to be either three different URLs *or* using a spec-defined "operation" parameter. That suggestion is completely nuts, in my opinion. > And it does not violate the rest/json guideline. Yes it absolutely does. The REST principle is that a URL represents one entity and the HTTP verbs represent different actions on that entity. Using a query parameter to switch is very much directly against REST guidelines. Not to say that OAuth is RESTful -- it's not, by a long shot. But it does follow many rest-like principles, the endpoint definitions being one of them. > > Even with oauth specification, it provides a hint on what is to come, > e.g. grant_type refresh_token, indicates you want to exchange a valid > refresh_token to an access_token. There is something in the payload > which tell you what you need to do. In this case, there is nothing in > the payload which indicate what is expected. These are functionality switches on the same kind of action, not dispatch to different actions. you still do authentication/authorization at the auth endpoint, you still get tokens from the token endpoint, etc. > > If you standard that now (on the optional field), there is a chance > that companies can implement this according to what will work best for > them, and we actually have a chance to get this working between > different products. It's too late to standardize that field in the core, which is really where it would belong. But as it stands today, an OAuth client is going to need to be able to handle separate URLs for each defined endpoint already, so it can already handle the case where it happens to be the same base URL with different operations. For what it's worth, what I was trying to get discussion on was whether it made sense to make Dynamic Registration look like the rest of OAuth with separate endpoints, or not. -- Justin > > > On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer > wrote: > > I am very confused, and I need someone to explain to me what I am > missing. Why won't it work to just pick one? What are people > "already stuck with" that this would affect? It's not like we're > trying to unseat a well-established protocol with a wide > installation base here. > > How will giving people the choice between: > > /oauth/register?operation=client_register > /oauth/register?operation=client_update > /oauth/register?operation=rotate_secret > > > and: > > /oauth/client_register > /oauth/client_update > /oauth/rotate_secret > > > help multitenancy? How does it even affect that use case? Consider > that the base URL for all of these is completely up to the host > environment (nothing is bound to the root URL). Consider that > clients still have to know what the URL (or URLs) are, in either > case. Consider that clients still need to know how to manage all > the parameters and responses. > > If anything, keeping it the way that it is with a single URL could > be argued to help multitenancy because setting up routing to > multiple URL endpoints can sometimes be problematic in hosted > environments. However, OAuth already defines a bunch of endpoints, > and we have to define at least one more with this extension, so > I'm not convinced that having three with specific functions is > really any different from having one with three functions from a > development, deployment, and implementation perspective. I can > tell you from experience that in our own server code, the > difference is trivial. (And from OAuth1 experience, you can always > have a query parameter as part of your endpoint URL if you need > to. You might hate yourself for doing it that way, but nothing > says your base URL can't already have parameters on it. A client > just needs to know how to appropriately tack its parameters onto > an existing URL, and any HTTP client worth its salt will know how > to augment a query parameter set with new items.) > > The *real* difference between the two approaches is a > philosophical design one. The former overloads one URL with > multiple functions switched by a flag, the latter uses the URL > itself as an implicit flag. Under the hood, these could (and in > many cases will) be all served by the same chunks of code. The > only difference is how this switch in functionality is presented. > > > With that said, can somebody please explain to me how allowing > *both* of these as options simultaneously (what I understand Tony > to be suggesting) is a good idea, or how multitenancy even comes > into play? Because I am completely not seeing how these are related. > > Thanks, > -- Justin > > > > > On 01/23/2013 12:46 PM, Anthony Nadalin wrote: >> It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it. >> >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Wednesday, January 23, 2013 9:27 AM >> To: Anthony Nadalin >> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >> >> I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish? >> >> You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts. >> >> >> -- Justin >> >> >> >> On 01/23/2013 12:21 PM, Anthony Nadalin wrote: >>> Registration has to work in a multi-tenant environment so flexibility >>> is needed >>> >>> -----Original Message----- >>> From: Justin Richer [mailto:jricher@mitre.org] >>> Sent: Wednesday, January 23, 2013 9:18 AM >>> To: Anthony Nadalin >>> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>> >>> Because then nobody would know how to actually use the thing. >>> >>> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. >>> >>> -- Justin >>> >>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote: >>>> Why not just have a physical and logical endpoint options >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Justin Richer >>>> Sent: Wednesday, January 23, 2013 7:47 AM >>>> To: Nat Sakimura >>>> Cc: Shiu Fun Poon; oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>>> >>>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations. >>>> >>>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think? >>>> >>>> -- Justin >>>> >>>> >>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>>>> "Action" goes against REST principle. >>>>> I do not think it is a good idea. >>>>> >>>>> =nat via iPhone >>>>> >>>>> Jan 23, 2013 4:00、Justin Richer のメッセージ: >>>>> >>>>>> (CC'ing the working group) >>>>>> >>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?" >>>>>> >>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>>>> Justin, >>>>>>> >>>>>>> This spec is looking good.. >>>>>>> >>>>>>> One thing I would like to recommend is to add "action"/"operation" >>>>>>> to the request. (and potentially add client_id and client_secret) >>>>>>> >>>>>>> So the request will be like : >>>>>>> token REQUIRED >>>>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke ... >>>>>>> resource_id OPTIONAL >>>>>>> client_id OPTIONAL >>>>>>> client_secret OPTIONAL >>>>>>> >>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication). >>>>>>> >>>>>>> Please consider. >>>>>>> >>>>>>> ShiuFun >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >> > > --------------020907040708070806070805 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit
Hi.. Tony.. You are able to present this better than I do.

Justin,

Currently as it is, the spec is unflexible.   So when I send a request to an endpoint, the endpoint will need to have information like /revoke, /introspection, and others.  I can imagine the documented usage of this will a pages long just to describe all the endpoint that is needed to support an application.  (so far, /authz, /token, /introspection, /revoke, /.....), and this will be painful in the multi-tenant environment.

So why not allow the flexibility of using one endpoint /token (example only), and make the caller to tell you want the caller wants ?  It can be an optional field, and a hint to the authorization/token endpoint on what you want to do.

This is incompatible with OAuth as it stands today, which defines the auth endpoint and token endpoint as logically separate, and therefore there is not a parameter defined that would allow for such functionality switching.

That said, an *installation* could implement it this way if they wanted to, they'd just have to document the endpoints like this:

token endpoint: /oauth?op=token
auth endpoint: /oauth?op=auth
introspection endpoint: /oauth?op=introspect
revocation endpoint: /oauth?op=revoke

etc. The key difference here is that the "op=" parameter is *system specific* and is *not* part of the spec itself. And I think that's a good design to continue to follow.

Right now, the registration endpoint is the only one that defines an "operation" parameter, and I was positing the question of defining it in terms of three different endpoints instead. Most of the time, these endpoints will have different URLs, as outlined below, but specific instances could use some kind of "operation" parameter if they wanted to.

Defining it as one endpoint with a switch parameter actually decreses flexibility quite a lot, especially if you're talking about dispatching to different kinds of functionality all together, which is the use case you brought up. There are some places where that could make sense, and the definition of different endpoints allows you to do that in specific instances of a system without breaking the assumptions of clients.

What Tony was talking about was allowing something to be either three different URLs *or* using a spec-defined "operation" parameter. That suggestion is completely nuts, in my opinion.

And it does not violate the rest/json guideline.  
Yes it absolutely does. The REST principle is that a URL represents one entity and the HTTP verbs represent different actions on that entity. Using a query parameter to switch is very much directly against REST guidelines. Not to say that OAuth is RESTful -- it's not, by a long shot. But it does follow many rest-like principles, the endpoint definitions being one of them.


Even with oauth specification, it provides a hint on what is to come, e.g. grant_type refresh_token, indicates you want to exchange a valid refresh_token to an access_token.  There is something in the payload which tell you what you need to do.  In this case, there is nothing in the payload which indicate what is expected.
These are functionality switches on the same kind of action, not dispatch to different actions. you still do authentication/authorization at the auth endpoint, you still get tokens from the token endpoint, etc.


If you standard that now (on the optional field), there is a chance that companies can implement this according to what will work best for them, and we actually have a chance to get this working between different products.
It's too late to standardize that field in the core, which is really where it would belong. But as it stands today, an OAuth client is going to need to be able to handle separate URLs for each defined endpoint already, so it can already handle the case where it happens to be the same base URL with different operations.

For what it's worth, what I was trying to get discussion on was whether it made sense to make Dynamic Registration look like the rest of OAuth with separate endpoints, or not.

 -- Justin




On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer <jricher@mitre.org> wrote:
I am very confused, and I need someone to explain to me what I am missing. Why won't it work to just pick one? What are people "already stuck with" that this would affect? It's not like we're trying to unseat a well-established protocol with a wide installation base here.

How will giving people the choice between:

/oauth/register?operation=client_register
/oauth/register?operation=client_update
/oauth/register?operation=rotate_secret

and:

/oauth/client_register
/oauth/client_update
/oauth/rotate_secret

help multitenancy? How does it even affect that use case? Consider that the base URL for all of these is completely up to the host environment (nothing is bound to the root URL). Consider that clients still have to know what the URL (or URLs) are, in either case. Consider that clients still need to know how to manage all the parameters and responses.

If anything, keeping it the way that it is with a single URL could be argued to help multitenancy because setting up routing to multiple URL endpoints can sometimes be problematic in hosted environments. However, OAuth already defines a bunch of endpoints, and we have to define at least one more with this extension, so I'm not convinced that having three with specific functions is really any different from having one with three functions from a development, deployment, and implementation perspective. I can tell you from experience that in our own server code, the difference is trivial. (And from OAuth1 experience, you can always have a query parameter as part of your endpoint URL if you need to. You might hate yourself for doing it that way, but nothing says your base URL can't already have parameters on it. A client just needs to know how to appropriately tack its parameters onto an existing URL, and any HTTP client worth its salt will know how to augment a query parameter set with new items.)

The *real* difference between the two approaches is a philosophical design one. The former overloads one URL with multiple functions switched by a flag, the latter uses the URL itself as an implicit flag. Under the hood, these could (and in many cases will) be all served by the same chunks of code. The only difference is how this switch in functionality is presented.


With that said, can somebody please explain to me how allowing *both* of these as options simultaneously (what I understand Tony to be suggesting) is a good idea, or how multitenancy even comes into play? Because I am completely not seeing how these are related.

Thanks,
 -- Justin




On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?

You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.


-- Justin



On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

Registration has to work in a multi-tenant environment  so flexibility 
is needed

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

Because then nobody would know how to actually use the thing.

In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.

-- Justin

On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

Why not just have a physical and logical endpoint options

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 
Behalf Of Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.

I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?

-- Justin


On 01/22/2013 08:05 PM, Nat Sakimura wrote:

"Action" goes against REST principle.
I do not think it is a good idea.

=nat via iPhone

Jan 23, 2013 4:00、Justin Richer <jricher@mitre.org> のメッセージ:


(CC'ing the working group)

I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

 -- Justin

On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

Justin,

This spec is looking good..

One thing I would like to recommend is to add "action"/"operation" 
to the request.  (and potentially add client_id and client_secret)

So the request will be like :
token                                             REQUIRED
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
resource_id                                    OPTIONAL
client_id                                         OPTIONAL
client_secret                                   OPTIONAL

And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

Please consider.

ShiuFun

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

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





                    

                    



                  

                  

                

              

            

          

        

        

      

    

    

  


--------------020907040708070806070805--

From ve7jtb@ve7jtb.com  Wed Jan 30 07:56:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4898221F8864 for ; Wed, 30 Jan 2013 07:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q16Gs8bfdzRe for ; Wed, 30 Jan 2013 07:56:04 -0800 (PST)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1EABF21F8778 for ; Wed, 30 Jan 2013 07:56:03 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id 1so768202qeb.41 for ; Wed, 30 Jan 2013 07:56:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WHQA6gWEfCpEZBj5rSzoEwX6I8UPGJIFrqBvuFwsltU=; b=fOjaAEFS+HVj59gxDGgv6agieK4MDYYU5yc44U6v0qJbvXfN2q8oMgKXTjsPt1NK5A bahW13I3FgXPbUgwlcyctTRdefw10kLQavBH3U0MyxPasPOlw0XysH1lmgnIs/6b8YAk 5dpSeR/TO4mhnOuvNNAD6DGe1uOaRIYWdpUqvsQF5tmeu2jfBFr7uN0qlRCsiOLCIl+d xzMUxfKU4wmedEfqyuT9GfNKVA6dubaZhKRg3DBAiwzAsVJcMHe84DmX6dcFmivaP7cj Tpn/VkPBPViySYtSxEPEvK0R/yTQh9Das8O67UZ06IdqU7klBTgKn6lsey++H1iPuw0c 7YWQ==
X-Received: by 10.224.33.136 with SMTP id h8mr5366928qad.7.1359561363365; Wed, 30 Jan 2013 07:56:03 -0800 (PST)
Received: from [192.168.1.211] (190-20-20-78.baf.movistar.cl. [190.20.20.78]) by mx.google.com with ESMTPS id t2sm1724608qav.1.2013.01.30.07.56.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 07:56:02 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <51014484.50001@mitre.org>
Date: Wed, 30 Jan 2013 12:55:51 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkOo2DZDIlNboY5YQj0gdOruIHwY4lNOtxmJtD0cExJKrGVYJZ8Iu8W7J8wErwBOy42i2tZ
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 15:56:05 -0000

My feeling was that letting the registration endpoint be a single URL =
(any url) and using query paramaters was easer for servers and clients.

Saying take the base URI for the registration endpoint and append these =
paths to it to do different operations seems more likely to go wrong fro =
developers.

Allowing both bath and query parameters is the worst option.

I am sympathetic with using POST and PUT and perhaps GET but I worry =
about OAuth developers not getting it.

I also don't get Tony's point about multi tenancy.  If each tenant can =
have there own registration endpoint I don't see a problem beyond =
finding the endpoint and that is what we have WF for.

John B.

On 2013-01-24, at 11:26 AM, Justin Richer  wrote:

>=20
> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>=20
>> I like this most, would rename it to say
>>=20
>> /oauth/client/registration
>> or
>> /oauth/client-registration
>>=20
>> etc
>>=20
>> and reword the spec such that it will let those who implement do it =
with one endpoint or many, whatever is preferred
>>=20
>=20
> That's the whole point of this discussion -- I don't believe you can =
have it both ways.
>=20
> In one way, you say there are three endpoints and, if you're keeping =
with the rest of OAuth, you don't give them official URL patterns that =
they must follow. How the client gets those endpoints is up to discovery =
or configuration, but the client has an internal map from each bit of =
functionality to a particular URL that's specific to the service, much =
in the same way that the client today has to map the authorization and =
token endpoints. In the other method, you've got one endpoint that the =
client sends a well-defined parameter to in order to accomplish the same =
goal.
>=20
> So if you allow both at once, does a client send the "operation" =
parameter or not? Is it looking for one url or three to store in its =
configuration? I don't think this level of flexibility buys you anything =
useful, and I strongly believe that it will deeply hurt the =
functionality of dynamic registration if it's allowed.
>=20
> As it stands today, you can still make the URL whatever you want. If =
we went with three endpoints you could also make those URLs whatever you =
wanted. Nobody has yet pointed out to me what the actual benefit is of =
making both valid.
>=20
> I personally prefer the method of three endpoint URLs because it's =
cleaner and semantically equivalent, but I am hesitant to change that =
behavior unless there's strong working group support for it. I haven't =
seen real support for it yet -- it's not a good call to make it fully =
RESTful, and it's not a good call to leave it undefined. A client MUST =
have a very clear recipe of what to do on startup for this to work in =
the wild.
>=20
> -- Justin
>=20
>>=20
>>>=20
>>>=20
>>> help multitenancy? How does it even affect that use case? Consider =
that
>>> the base URL for all of these is completely up to the host =
environment
>>> (nothing is bound to the root URL). Consider that clients still have =
to
>>> know what the URL (or URLs) are, in either case. Consider that =
clients
>>> still need to know how to manage all the parameters and responses.
>>>=20
>>> If anything, keeping it the way that it is with a single URL could =
be
>>> argued to help multitenancy because setting up routing to multiple =
URL
>>> endpoints can sometimes be problematic in hosted environments. =
However,
>>> OAuth already defines a bunch of endpoints, and we have to define at
>>> least one more with this extension, so I'm not convinced that having
>>> three with specific functions is really any different from having =
one
>>> with three functions from a development, deployment, and =
implementation
>>> perspective. I can tell you from experience that in our own server =
code,
>>> the difference is trivial. (And from OAuth1 experience, you can =
always
>>> have a query parameter as part of your endpoint URL if you need to. =
You
>>> might hate yourself for doing it that way, but nothing says your =
base
>>> URL can't already have parameters on it. A client just needs to know =
how
>>> to appropriately tack its parameters onto an existing URL, and any =
HTTP
>>> client worth its salt will know how to augment a query parameter set
>>> with new items.)
>>>=20
>>> The *real* difference between the two approaches is a philosophical
>>> design one. The former overloads one URL with multiple functions
>>> switched by a flag, the latter uses the URL itself as an implicit =
flag.
>>> Under the hood, these could (and in many cases will) be all served =
by
>>> the same chunks of code. The only difference is how this switch in
>>> functionality is presented.
>>>=20
>>>=20
>>> With that said, can somebody please explain to me how allowing =
*both* of
>>> these as options simultaneously (what I understand Tony to be
>>> suggesting) is a good idea, or how multitenancy even comes into =
play?
>>> Because I am completely not seeing how these are related.
>>>=20
>>> Thanks,
>>> -- Justin
>>>=20
>>>=20
>>>=20
>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>> It will not work the way you have it, as people do multi-tendency =
different and they are already stuck with the method that they have =
chosen, so they need the flexability, to restrict this is nuts as people =
won't use it.
>>>>=20
>>>> -----Original Message-----
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>> To: Anthony Nadalin
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>=20
>>>> I completely disagree with this assessment. Multi-tenancy will work =
just fine (or even better) if everyone uses the same pattern. Telling =
someone "it might be three different urls or it might be all one url =
with a parameter" is just asking for a complete disaster. What does the =
flexibility of allowing two approaches actually accomplish?
>>>>=20
>>>> You can argue about the merits of either approach, but having both =
as unspecified options for registration, which is meant to help things =
get going in a cold-boot environment, is just plain nuts.
>>>>=20
>>>>=20
>>>> -- Justin
>>>>=20
>>>>=20
>>>>=20
>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>> Registration has to work in a multi-tenant environment  so =
flexibility
>>>>> is needed
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>> To: Anthony Nadalin
>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>=20
>>>>> Because then nobody would know how to actually use the thing.
>>>>>=20
>>>>> In my opinion, this is a key place where this kind of flexibility =
is a very bad thing. Registration needs to work one fairly predictable =
way.
>>>>>=20
>>>>> -- Justin
>>>>>=20
>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>> Why not just have a physical and logical endpoint options
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>> Behalf Of Justin Richer
>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>> To: Nat Sakimura
>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>=20
>>>>>> Which brings up an interesting question for the Registration doc: =
right now, it's set up as a single endpoint with three operations. We =
could instead define three endpoints for the different operations.
>>>>>>=20
>>>>>> I've not been keen to make that deep of a cutting change to it, =
but it would certainly be cleaner and more RESTful API design. What do =
others think?
>>>>>>=20
>>>>>> -- Justin
>>>>>>=20
>>>>>>=20
>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>> "Action" goes against REST principle.
>>>>>>> I do not think it is a good idea.
>>>>>>>=20
>>>>>>> =3Dnat via iPhone
>>>>>>>=20
>>>>>>> Jan 23, 2013 4:00=E3=80=81Justin Richer  =
=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>>>>>>>=20
>>>>>>>> (CC'ing the working group)
>>>>>>>>=20
>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. =
The idea behind having different endpoints in OAuth is that they each do =
different kinds of things. The only "action/operation" that I had =
envisioned for the introspection endpoint is introspection itself: "I =
have a token, what does it mean?"
>>>>>>>>=20
>>>>>>>> Note that client_id and client_secret *can* already be used at =
this endpoint if the server supports that as part of their client =
credentials setup. The examples use HTTP Basic with client id and secret =
right now. Basically, the client can authenticate however it wants, =
including any of the methods that OAuth2 allows on the token endpoint. =
It could also authenticate with an access token. At least, that's the =
intent of the introspection draft -- if that's unclear, I'd be happy to =
accept suggested changes to clarify this text.
>>>>>>>>=20
>>>>>>>>  -- Justin
>>>>>>>>=20
>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>> Justin,
>>>>>>>>>=20
>>>>>>>>> This spec is looking good..
>>>>>>>>>=20
>>>>>>>>> One thing I would like to recommend is to add =
"action"/"operation"
>>>>>>>>> to the request.  (and potentially add client_id and =
client_secret)
>>>>>>>>>=20
>>>>>>>>> So the request will be like :
>>>>>>>>> token REQUIRED
>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire =
(default) | revoke ...
>>>>>>>>> resource_id OPTIONAL
>>>>>>>>> client_id OPTIONAL
>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>=20
>>>>>>>>> And for the OAuth client information, it should be an optional =
parameter (in case it is a public client or client is authenticated with =
SSL mutual authentication).
>>>>>>>>>=20
>>>>>>>>> Please consider.
>>>>>>>>>=20
>>>>>>>>> ShiuFun
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From jricher@mitre.org  Wed Jan 30 08:18:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86C321F8915 for ; Wed, 30 Jan 2013 08:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.541
X-Spam-Level: 
X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7KrunQ-4qq7 for ; Wed, 30 Jan 2013 08:18:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9721F890F for ; Wed, 30 Jan 2013 08:18:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D1F015311191; Wed, 30 Jan 2013 11:18:08 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C6D371F0B16; Wed, 30 Jan 2013 11:18:08 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 11:18:08 -0500
Message-ID: <510947A5.3000904@mitre.org>
Date: Wed, 30 Jan 2013 11:17:41 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org> <49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com>
In-Reply-To: <49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 16:18:10 -0000

On 01/30/2013 10:55 AM, John Bradley wrote:
> My feeling was that letting the registration endpoint be a single URL (any url) and using query paramaters was easer for servers and clients.
>
> Saying take the base URI for the registration endpoint and append these paths to it to do different operations seems more likely to go wrong fro developers.
Right, and to clarify, this isn't what I was saying. The spec wouldn't 
specify the path at all, just say that they're three different endpoint 
URLs. The same way that we specify that the auth endpoint and token 
endpoint are different URLs.

I think my example might have been misleading. The URLs could just as 
easily be:

client_register -> /register_a_new_client
rotate_secret -> /client/go_get_a_secret_or_something
client_update-> /maintenance/update_client_information



>
> Allowing both bath and query parameters is the worst option.
>
> I am sympathetic with using POST and PUT and perhaps GET but I worry about OAuth developers not getting it.
>
> I also don't get Tony's point about multi tenancy.  If each tenant can have there own registration endpoint I don't see a problem beyond finding the endpoint and that is what we have WF for.
Exactly. And to Bill's point in another thread, we could also register a 
link type for each endpoint to help facilitate discovery: 
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06

  -- Justin

>
> John B.
>
> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>
>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>> I like this most, would rename it to say
>>>
>>> /oauth/client/registration
>>> or
>>> /oauth/client-registration
>>>
>>> etc
>>>
>>> and reword the spec such that it will let those who implement do it with one endpoint or many, whatever is preferred
>>>
>> That's the whole point of this discussion -- I don't believe you can have it both ways.
>>
>> In one way, you say there are three endpoints and, if you're keeping with the rest of OAuth, you don't give them official URL patterns that they must follow. How the client gets those endpoints is up to discovery or configuration, but the client has an internal map from each bit of functionality to a particular URL that's specific to the service, much in the same way that the client today has to map the authorization and token endpoints. In the other method, you've got one endpoint that the client sends a well-defined parameter to in order to accomplish the same goal.
>>
>> So if you allow both at once, does a client send the "operation" parameter or not? Is it looking for one url or three to store in its configuration? I don't think this level of flexibility buys you anything useful, and I strongly believe that it will deeply hurt the functionality of dynamic registration if it's allowed.
>>
>> As it stands today, you can still make the URL whatever you want. If we went with three endpoints you could also make those URLs whatever you wanted. Nobody has yet pointed out to me what the actual benefit is of making both valid.
>>
>> I personally prefer the method of three endpoint URLs because it's cleaner and semantically equivalent, but I am hesitant to change that behavior unless there's strong working group support for it. I haven't seen real support for it yet -- it's not a good call to make it fully RESTful, and it's not a good call to leave it undefined. A client MUST have a very clear recipe of what to do on startup for this to work in the wild.
>>
>> -- Justin
>>
>>>>
>>>> help multitenancy? How does it even affect that use case? Consider that
>>>> the base URL for all of these is completely up to the host environment
>>>> (nothing is bound to the root URL). Consider that clients still have to
>>>> know what the URL (or URLs) are, in either case. Consider that clients
>>>> still need to know how to manage all the parameters and responses.
>>>>
>>>> If anything, keeping it the way that it is with a single URL could be
>>>> argued to help multitenancy because setting up routing to multiple URL
>>>> endpoints can sometimes be problematic in hosted environments. However,
>>>> OAuth already defines a bunch of endpoints, and we have to define at
>>>> least one more with this extension, so I'm not convinced that having
>>>> three with specific functions is really any different from having one
>>>> with three functions from a development, deployment, and implementation
>>>> perspective. I can tell you from experience that in our own server code,
>>>> the difference is trivial. (And from OAuth1 experience, you can always
>>>> have a query parameter as part of your endpoint URL if you need to. You
>>>> might hate yourself for doing it that way, but nothing says your base
>>>> URL can't already have parameters on it. A client just needs to know how
>>>> to appropriately tack its parameters onto an existing URL, and any HTTP
>>>> client worth its salt will know how to augment a query parameter set
>>>> with new items.)
>>>>
>>>> The *real* difference between the two approaches is a philosophical
>>>> design one. The former overloads one URL with multiple functions
>>>> switched by a flag, the latter uses the URL itself as an implicit flag.
>>>> Under the hood, these could (and in many cases will) be all served by
>>>> the same chunks of code. The only difference is how this switch in
>>>> functionality is presented.
>>>>
>>>>
>>>> With that said, can somebody please explain to me how allowing *both* of
>>>> these as options simultaneously (what I understand Tony to be
>>>> suggesting) is a good idea, or how multitenancy even comes into play?
>>>> Because I am completely not seeing how these are related.
>>>>
>>>> Thanks,
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>> It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>> To: Anthony Nadalin
>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>
>>>>> I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?
>>>>>
>>>>> You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.
>>>>>
>>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>> Registration has to work in a multi-tenant environment  so flexibility
>>>>>> is needed
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>
>>>>>> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>> Behalf Of Justin Richer
>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>> To: Nat Sakimura
>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>
>>>>>>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.
>>>>>>>
>>>>>>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?
>>>>>>>
>>>>>>> -- Justin
>>>>>>>
>>>>>>>
>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>> "Action" goes against REST principle.
>>>>>>>> I do not think it is a good idea.
>>>>>>>>
>>>>>>>> =nat via iPhone
>>>>>>>>
>>>>>>>> Jan 23, 2013 4:00Justin Richer  :
>>>>>>>>
>>>>>>>>> (CC'ing the working group)
>>>>>>>>>
>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>>>>
>>>>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>>>>
>>>>>>>>>   -- Justin
>>>>>>>>>
>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>> Justin,
>>>>>>>>>>
>>>>>>>>>> This spec is looking good..
>>>>>>>>>>
>>>>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>>>>> to the request.  (and potentially add client_id and client_secret)
>>>>>>>>>>
>>>>>>>>>> So the request will be like :
>>>>>>>>>> token REQUIRED
>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>
>>>>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>>>>
>>>>>>>>>> Please consider.
>>>>>>>>>>
>>>>>>>>>> ShiuFun
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From Michael.Jones@microsoft.com  Wed Jan 30 08:43:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D834A21F886B for ; Wed, 30 Jan 2013 08:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPapUbkR1Cfk for ; Wed, 30 Jan 2013 08:43:02 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3021F87DC for ; Wed, 30 Jan 2013 08:43:02 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.203) by BY2FFO11HUB011.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 16:43:00 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 16:42:59 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 16:42:36 +0000
From: Mike Jones 
To: Justin Richer , John Bradley 
Thread-Topic: [OAUTH-WG] Concerning OAuth introspection
Thread-Index: AQHN+NLaih7lXcajhEyfjdYsUHHYWJhWGdYAgAD2SICAABiJAIAAAPsAgAAA0gCAAAGWgIAABZMAgAAFGgCAARqSgIAAOpYAgAmHCYCAAAYZgIAABSew
Date: Wed, 30 Jan 2013 16:42:34 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673E6800@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org>	<49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com> <510947A5.3000904@mitre.org>
In-Reply-To: <510947A5.3000904@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(52314002)(51704002)(24454001)(164054002)(199002)(13464002)(189002)(479174001)(54356001)(550184003)(31966008)(53806001)(47736001)(51856001)(33656001)(63696002)(74662001)(20776003)(16406001)(5343655001)(15202345001)(47446002)(56776001)(77982001)(74502001)(49866001)(47776003)(47976001)(59766001)(23676001)(55846006)(54316002)(76482001)(44976002)(79102001)(50466001)(4396001)(50986001)(56816002)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB011; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 16:43:04 -0000

SSBiZWxpZXZlIHRoYXQgd2hhdCB3ZSBoYXZlIG5vdyAtIGEgc2luZ2xlIGVuZHBvaW50IHdpdGgg
YW4gIm9wZXJhdGlvbiIgcGFyYW1ldGVyLCBpcyBtb3JlIG5hdHVyYWwgdGhhbiBoYXZpbmcgYSBk
aWZmZXJlbnQgZW5kcG9pbnQgcGVyIG9wZXJhdGlvbi4gIEluIGFsbCBsaWtlbGlob29kLCB0aGUg
aW1wbGVtZW50YXRpb24gb2YgYWxsIHRoZSBvcGVyYXRpb25zIChjbGllbnRfcmVnaXN0ZXIsIGNs
aWVudF91cGRhdGUsIGFuZCByb3RhdGVfc2VjcmV0KSB3b3VsZCBlbmQgdXAgZ29pbmcgdGhyb3Vn
aCB0aGUgc2FtZSBjb2RlIHBhdGggYW55d2F5LCB1c2luZyBhbiBvcGVyYXRpb24gcGFyYW1ldGVy
LiAgU28gbGV0J3MganVzdCBrZWVwIGV4cHJlc3NpbmcgaXQgdGhhdCB3YXkgb24gdGhlIHdpcmUg
dG9vLg0KDQpIYXZpbmcgdG8gbWFpbnRhaW4gYW5kIHJlZ2lzdGVyIG1hbnkgZW5kcG9pbnRzIGZv
ciBvbmUgbG9naWNhbCBzZXQgb2YgZnVuY3Rpb25hbGl0eSB3b3VsZCBqdXN0IG1ha2UgdGhpbmdz
IGhhcmRlciBpbiBhIHByYWN0aWNhbCBzZW5zZS4gIExldCdzIGxlYXZlIHRoaW5ncyB0aGUgd2F5
IHRoZXkgYXJlLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg
MzAsIDIwMTMgODoxOCBBTQ0KVG86IEpvaG4gQnJhZGxleQ0KQ2M6IG9hdXRoQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25jZXJuaW5nIE9BdXRoIGludHJvc3BlY3Rpb24NCg0K
DQpPbiAwMS8zMC8yMDEzIDEwOjU1IEFNLCBKb2huIEJyYWRsZXkgd3JvdGU6DQo+IE15IGZlZWxp
bmcgd2FzIHRoYXQgbGV0dGluZyB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IGJlIGEgc2luZ2xl
IFVSTCAoYW55IHVybCkgYW5kIHVzaW5nIHF1ZXJ5IHBhcmFtYXRlcnMgd2FzIGVhc2VyIGZvciBz
ZXJ2ZXJzIGFuZCBjbGllbnRzLg0KPg0KPiBTYXlpbmcgdGFrZSB0aGUgYmFzZSBVUkkgZm9yIHRo
ZSByZWdpc3RyYXRpb24gZW5kcG9pbnQgYW5kIGFwcGVuZCB0aGVzZSBwYXRocyB0byBpdCB0byBk
byBkaWZmZXJlbnQgb3BlcmF0aW9ucyBzZWVtcyBtb3JlIGxpa2VseSB0byBnbyB3cm9uZyBmcm8g
ZGV2ZWxvcGVycy4NClJpZ2h0LCBhbmQgdG8gY2xhcmlmeSwgdGhpcyBpc24ndCB3aGF0IEkgd2Fz
IHNheWluZy4gVGhlIHNwZWMgd291bGRuJ3Qgc3BlY2lmeSB0aGUgcGF0aCBhdCBhbGwsIGp1c3Qg
c2F5IHRoYXQgdGhleSdyZSB0aHJlZSBkaWZmZXJlbnQgZW5kcG9pbnQgVVJMcy4gVGhlIHNhbWUg
d2F5IHRoYXQgd2Ugc3BlY2lmeSB0aGF0IHRoZSBhdXRoIGVuZHBvaW50IGFuZCB0b2tlbiBlbmRw
b2ludCBhcmUgZGlmZmVyZW50IFVSTHMuDQoNCkkgdGhpbmsgbXkgZXhhbXBsZSBtaWdodCBoYXZl
IGJlZW4gbWlzbGVhZGluZy4gVGhlIFVSTHMgY291bGQganVzdCBhcyBlYXNpbHkgYmU6DQoNCmNs
aWVudF9yZWdpc3RlciAtPiAvcmVnaXN0ZXJfYV9uZXdfY2xpZW50IHJvdGF0ZV9zZWNyZXQgLT4g
L2NsaWVudC9nb19nZXRfYV9zZWNyZXRfb3Jfc29tZXRoaW5nDQpjbGllbnRfdXBkYXRlLT4gL21h
aW50ZW5hbmNlL3VwZGF0ZV9jbGllbnRfaW5mb3JtYXRpb24NCg0KDQoNCj4NCj4gQWxsb3dpbmcg
Ym90aCBiYXRoIGFuZCBxdWVyeSBwYXJhbWV0ZXJzIGlzIHRoZSB3b3JzdCBvcHRpb24uDQo+DQo+
IEkgYW0gc3ltcGF0aGV0aWMgd2l0aCB1c2luZyBQT1NUIGFuZCBQVVQgYW5kIHBlcmhhcHMgR0VU
IGJ1dCBJIHdvcnJ5IGFib3V0IE9BdXRoIGRldmVsb3BlcnMgbm90IGdldHRpbmcgaXQuDQo+DQo+
IEkgYWxzbyBkb24ndCBnZXQgVG9ueSdzIHBvaW50IGFib3V0IG11bHRpIHRlbmFuY3kuICBJZiBl
YWNoIHRlbmFudCBjYW4gaGF2ZSB0aGVyZSBvd24gcmVnaXN0cmF0aW9uIGVuZHBvaW50IEkgZG9u
J3Qgc2VlIGEgcHJvYmxlbSBiZXlvbmQgZmluZGluZyB0aGUgZW5kcG9pbnQgYW5kIHRoYXQgaXMg
d2hhdCB3ZSBoYXZlIFdGIGZvci4NCkV4YWN0bHkuIEFuZCB0byBCaWxsJ3MgcG9pbnQgaW4gYW5v
dGhlciB0aHJlYWQsIHdlIGNvdWxkIGFsc28gcmVnaXN0ZXIgYSBsaW5rIHR5cGUgZm9yIGVhY2gg
ZW5kcG9pbnQgdG8gaGVscCBmYWNpbGl0YXRlIGRpc2NvdmVyeTogDQpodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC13bWlsbHMtb2F1dGgtbHJkZC0wNg0KDQogIC0tIEp1c3Rpbg0KDQo+
DQo+IEpvaG4gQi4NCj4NCj4gT24gMjAxMy0wMS0yNCwgYXQgMTE6MjYgQU0sIEp1c3RpbiBSaWNo
ZXIgPGpyaWNoZXJAbWl0cmUub3JnPiB3cm90ZToNCj4NCj4+IE9uIDAxLzI0LzIwMTMgMDU6NTYg
QU0sIFNlcmdleSBCZXJ5b3praW4gd3JvdGU6DQo+Pj4gSSBsaWtlIHRoaXMgbW9zdCwgd291bGQg
cmVuYW1lIGl0IHRvIHNheQ0KPj4+DQo+Pj4gL29hdXRoL2NsaWVudC9yZWdpc3RyYXRpb24NCj4+
PiBvcg0KPj4+IC9vYXV0aC9jbGllbnQtcmVnaXN0cmF0aW9uDQo+Pj4NCj4+PiBldGMNCj4+Pg0K
Pj4+IGFuZCByZXdvcmQgdGhlIHNwZWMgc3VjaCB0aGF0IGl0IHdpbGwgbGV0IHRob3NlIHdobyBp
bXBsZW1lbnQgZG8gaXQgDQo+Pj4gd2l0aCBvbmUgZW5kcG9pbnQgb3IgbWFueSwgd2hhdGV2ZXIg
aXMgcHJlZmVycmVkDQo+Pj4NCj4+IFRoYXQncyB0aGUgd2hvbGUgcG9pbnQgb2YgdGhpcyBkaXNj
dXNzaW9uIC0tIEkgZG9uJ3QgYmVsaWV2ZSB5b3UgY2FuIGhhdmUgaXQgYm90aCB3YXlzLg0KPj4N
Cj4+IEluIG9uZSB3YXksIHlvdSBzYXkgdGhlcmUgYXJlIHRocmVlIGVuZHBvaW50cyBhbmQsIGlm
IHlvdSdyZSBrZWVwaW5nIHdpdGggdGhlIHJlc3Qgb2YgT0F1dGgsIHlvdSBkb24ndCBnaXZlIHRo
ZW0gb2ZmaWNpYWwgVVJMIHBhdHRlcm5zIHRoYXQgdGhleSBtdXN0IGZvbGxvdy4gSG93IHRoZSBj
bGllbnQgZ2V0cyB0aG9zZSBlbmRwb2ludHMgaXMgdXAgdG8gZGlzY292ZXJ5IG9yIGNvbmZpZ3Vy
YXRpb24sIGJ1dCB0aGUgY2xpZW50IGhhcyBhbiBpbnRlcm5hbCBtYXAgZnJvbSBlYWNoIGJpdCBv
ZiBmdW5jdGlvbmFsaXR5IHRvIGEgcGFydGljdWxhciBVUkwgdGhhdCdzIHNwZWNpZmljIHRvIHRo
ZSBzZXJ2aWNlLCBtdWNoIGluIHRoZSBzYW1lIHdheSB0aGF0IHRoZSBjbGllbnQgdG9kYXkgaGFz
IHRvIG1hcCB0aGUgYXV0aG9yaXphdGlvbiBhbmQgdG9rZW4gZW5kcG9pbnRzLiBJbiB0aGUgb3Ro
ZXIgbWV0aG9kLCB5b3UndmUgZ290IG9uZSBlbmRwb2ludCB0aGF0IHRoZSBjbGllbnQgc2VuZHMg
YSB3ZWxsLWRlZmluZWQgcGFyYW1ldGVyIHRvIGluIG9yZGVyIHRvIGFjY29tcGxpc2ggdGhlIHNh
bWUgZ29hbC4NCj4+DQo+PiBTbyBpZiB5b3UgYWxsb3cgYm90aCBhdCBvbmNlLCBkb2VzIGEgY2xp
ZW50IHNlbmQgdGhlICJvcGVyYXRpb24iIHBhcmFtZXRlciBvciBub3Q/IElzIGl0IGxvb2tpbmcg
Zm9yIG9uZSB1cmwgb3IgdGhyZWUgdG8gc3RvcmUgaW4gaXRzIGNvbmZpZ3VyYXRpb24/IEkgZG9u
J3QgdGhpbmsgdGhpcyBsZXZlbCBvZiBmbGV4aWJpbGl0eSBidXlzIHlvdSBhbnl0aGluZyB1c2Vm
dWwsIGFuZCBJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBpdCB3aWxsIGRlZXBseSBodXJ0IHRoZSBm
dW5jdGlvbmFsaXR5IG9mIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGlmIGl0J3MgYWxsb3dlZC4NCj4+
DQo+PiBBcyBpdCBzdGFuZHMgdG9kYXksIHlvdSBjYW4gc3RpbGwgbWFrZSB0aGUgVVJMIHdoYXRl
dmVyIHlvdSB3YW50LiBJZiB3ZSB3ZW50IHdpdGggdGhyZWUgZW5kcG9pbnRzIHlvdSBjb3VsZCBh
bHNvIG1ha2UgdGhvc2UgVVJMcyB3aGF0ZXZlciB5b3Ugd2FudGVkLiBOb2JvZHkgaGFzIHlldCBw
b2ludGVkIG91dCB0byBtZSB3aGF0IHRoZSBhY3R1YWwgYmVuZWZpdCBpcyBvZiBtYWtpbmcgYm90
aCB2YWxpZC4NCj4+DQo+PiBJIHBlcnNvbmFsbHkgcHJlZmVyIHRoZSBtZXRob2Qgb2YgdGhyZWUg
ZW5kcG9pbnQgVVJMcyBiZWNhdXNlIGl0J3MgY2xlYW5lciBhbmQgc2VtYW50aWNhbGx5IGVxdWl2
YWxlbnQsIGJ1dCBJIGFtIGhlc2l0YW50IHRvIGNoYW5nZSB0aGF0IGJlaGF2aW9yIHVubGVzcyB0
aGVyZSdzIHN0cm9uZyB3b3JraW5nIGdyb3VwIHN1cHBvcnQgZm9yIGl0LiBJIGhhdmVuJ3Qgc2Vl
biByZWFsIHN1cHBvcnQgZm9yIGl0IHlldCAtLSBpdCdzIG5vdCBhIGdvb2QgY2FsbCB0byBtYWtl
IGl0IGZ1bGx5IFJFU1RmdWwsIGFuZCBpdCdzIG5vdCBhIGdvb2QgY2FsbCB0byBsZWF2ZSBpdCB1
bmRlZmluZWQuIEEgY2xpZW50IE1VU1QgaGF2ZSBhIHZlcnkgY2xlYXIgcmVjaXBlIG9mIHdoYXQg
dG8gZG8gb24gc3RhcnR1cCBmb3IgdGhpcyB0byB3b3JrIGluIHRoZSB3aWxkLg0KPj4NCj4+IC0t
IEp1c3Rpbg0KPj4NCj4+Pj4NCj4+Pj4gaGVscCBtdWx0aXRlbmFuY3k/IEhvdyBkb2VzIGl0IGV2
ZW4gYWZmZWN0IHRoYXQgdXNlIGNhc2U/IENvbnNpZGVyIA0KPj4+PiB0aGF0IHRoZSBiYXNlIFVS
TCBmb3IgYWxsIG9mIHRoZXNlIGlzIGNvbXBsZXRlbHkgdXAgdG8gdGhlIGhvc3QgDQo+Pj4+IGVu
dmlyb25tZW50IChub3RoaW5nIGlzIGJvdW5kIHRvIHRoZSByb290IFVSTCkuIENvbnNpZGVyIHRo
YXQgDQo+Pj4+IGNsaWVudHMgc3RpbGwgaGF2ZSB0byBrbm93IHdoYXQgdGhlIFVSTCAob3IgVVJM
cykgYXJlLCBpbiBlaXRoZXIgDQo+Pj4+IGNhc2UuIENvbnNpZGVyIHRoYXQgY2xpZW50cyBzdGls
bCBuZWVkIHRvIGtub3cgaG93IHRvIG1hbmFnZSBhbGwgdGhlIHBhcmFtZXRlcnMgYW5kIHJlc3Bv
bnNlcy4NCj4+Pj4NCj4+Pj4gSWYgYW55dGhpbmcsIGtlZXBpbmcgaXQgdGhlIHdheSB0aGF0IGl0
IGlzIHdpdGggYSBzaW5nbGUgVVJMIGNvdWxkIA0KPj4+PiBiZSBhcmd1ZWQgdG8gaGVscCBtdWx0
aXRlbmFuY3kgYmVjYXVzZSBzZXR0aW5nIHVwIHJvdXRpbmcgdG8gDQo+Pj4+IG11bHRpcGxlIFVS
TCBlbmRwb2ludHMgY2FuIHNvbWV0aW1lcyBiZSBwcm9ibGVtYXRpYyBpbiBob3N0ZWQgDQo+Pj4+
IGVudmlyb25tZW50cy4gSG93ZXZlciwgT0F1dGggYWxyZWFkeSBkZWZpbmVzIGEgYnVuY2ggb2Yg
ZW5kcG9pbnRzLCANCj4+Pj4gYW5kIHdlIGhhdmUgdG8gZGVmaW5lIGF0IGxlYXN0IG9uZSBtb3Jl
IHdpdGggdGhpcyBleHRlbnNpb24sIHNvIEknbSANCj4+Pj4gbm90IGNvbnZpbmNlZCB0aGF0IGhh
dmluZyB0aHJlZSB3aXRoIHNwZWNpZmljIGZ1bmN0aW9ucyBpcyByZWFsbHkgDQo+Pj4+IGFueSBk
aWZmZXJlbnQgZnJvbSBoYXZpbmcgb25lIHdpdGggdGhyZWUgZnVuY3Rpb25zIGZyb20gYSANCj4+
Pj4gZGV2ZWxvcG1lbnQsIGRlcGxveW1lbnQsIGFuZCBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2
ZS4gSSBjYW4gdGVsbCANCj4+Pj4geW91IGZyb20gZXhwZXJpZW5jZSB0aGF0IGluIG91ciBvd24g
c2VydmVyIGNvZGUsIHRoZSBkaWZmZXJlbmNlIGlzIA0KPj4+PiB0cml2aWFsLiAoQW5kIGZyb20g
T0F1dGgxIGV4cGVyaWVuY2UsIHlvdSBjYW4gYWx3YXlzIGhhdmUgYSBxdWVyeSANCj4+Pj4gcGFy
YW1ldGVyIGFzIHBhcnQgb2YgeW91ciBlbmRwb2ludCBVUkwgaWYgeW91IG5lZWQgdG8uIFlvdSBt
aWdodCANCj4+Pj4gaGF0ZSB5b3Vyc2VsZiBmb3IgZG9pbmcgaXQgdGhhdCB3YXksIGJ1dCBub3Ro
aW5nIHNheXMgeW91ciBiYXNlIFVSTCANCj4+Pj4gY2FuJ3QgYWxyZWFkeSBoYXZlIHBhcmFtZXRl
cnMgb24gaXQuIEEgY2xpZW50IGp1c3QgbmVlZHMgdG8ga25vdyANCj4+Pj4gaG93IHRvIGFwcHJv
cHJpYXRlbHkgdGFjayBpdHMgcGFyYW1ldGVycyBvbnRvIGFuIGV4aXN0aW5nIFVSTCwgYW5kIA0K
Pj4+PiBhbnkgSFRUUCBjbGllbnQgd29ydGggaXRzIHNhbHQgd2lsbCBrbm93IGhvdyB0byBhdWdt
ZW50IGEgcXVlcnkgDQo+Pj4+IHBhcmFtZXRlciBzZXQgd2l0aCBuZXcgaXRlbXMuKQ0KPj4+Pg0K
Pj4+PiBUaGUgKnJlYWwqIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvIGFwcHJvYWNoZXMgaXMg
YSBwaGlsb3NvcGhpY2FsIA0KPj4+PiBkZXNpZ24gb25lLiBUaGUgZm9ybWVyIG92ZXJsb2FkcyBv
bmUgVVJMIHdpdGggbXVsdGlwbGUgZnVuY3Rpb25zIA0KPj4+PiBzd2l0Y2hlZCBieSBhIGZsYWcs
IHRoZSBsYXR0ZXIgdXNlcyB0aGUgVVJMIGl0c2VsZiBhcyBhbiBpbXBsaWNpdCBmbGFnLg0KPj4+
PiBVbmRlciB0aGUgaG9vZCwgdGhlc2UgY291bGQgKGFuZCBpbiBtYW55IGNhc2VzIHdpbGwpIGJl
IGFsbCBzZXJ2ZWQgDQo+Pj4+IGJ5IHRoZSBzYW1lIGNodW5rcyBvZiBjb2RlLiBUaGUgb25seSBk
aWZmZXJlbmNlIGlzIGhvdyB0aGlzIHN3aXRjaCANCj4+Pj4gaW4gZnVuY3Rpb25hbGl0eSBpcyBw
cmVzZW50ZWQuDQo+Pj4+DQo+Pj4+DQo+Pj4+IFdpdGggdGhhdCBzYWlkLCBjYW4gc29tZWJvZHkg
cGxlYXNlIGV4cGxhaW4gdG8gbWUgaG93IGFsbG93aW5nIA0KPj4+PiAqYm90aCogb2YgdGhlc2Ug
YXMgb3B0aW9ucyBzaW11bHRhbmVvdXNseSAod2hhdCBJIHVuZGVyc3RhbmQgVG9ueSANCj4+Pj4g
dG8gYmUNCj4+Pj4gc3VnZ2VzdGluZykgaXMgYSBnb29kIGlkZWEsIG9yIGhvdyBtdWx0aXRlbmFu
Y3kgZXZlbiBjb21lcyBpbnRvIHBsYXk/DQo+Pj4+IEJlY2F1c2UgSSBhbSBjb21wbGV0ZWx5IG5v
dCBzZWVpbmcgaG93IHRoZXNlIGFyZSByZWxhdGVkLg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+
IC0tIEp1c3Rpbg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAwMS8yMy8yMDEzIDEyOjQ2IFBN
LCBBbnRob255IE5hZGFsaW4gd3JvdGU6DQo+Pj4+PiBJdCB3aWxsIG5vdCB3b3JrIHRoZSB3YXkg
eW91IGhhdmUgaXQsIGFzIHBlb3BsZSBkbyBtdWx0aS10ZW5kZW5jeSBkaWZmZXJlbnQgYW5kIHRo
ZXkgYXJlIGFscmVhZHkgc3R1Y2sgd2l0aCB0aGUgbWV0aG9kIHRoYXQgdGhleSBoYXZlIGNob3Nl
biwgc28gdGhleSBuZWVkIHRoZSBmbGV4YWJpbGl0eSwgdG8gcmVzdHJpY3QgdGhpcyBpcyBudXRz
IGFzIHBlb3BsZSB3b24ndCB1c2UgaXQuDQo+Pj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4+Pj4+IEZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJl
Lm9yZ10NCj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyA5OjI3IEFNDQo+
Pj4+PiBUbzogQW50aG9ueSBOYWRhbGluDQo+Pj4+PiBDYzogTmF0IFNha2ltdXJhOyBTaGl1IEZ1
biBQb29uO29hdXRoQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25j
ZXJuaW5nIE9BdXRoIGludHJvc3BlY3Rpb24NCj4+Pj4+DQo+Pj4+PiBJIGNvbXBsZXRlbHkgZGlz
YWdyZWUgd2l0aCB0aGlzIGFzc2Vzc21lbnQuIE11bHRpLXRlbmFuY3kgd2lsbCB3b3JrIGp1c3Qg
ZmluZSAob3IgZXZlbiBiZXR0ZXIpIGlmIGV2ZXJ5b25lIHVzZXMgdGhlIHNhbWUgcGF0dGVybi4g
VGVsbGluZyBzb21lb25lICJpdCBtaWdodCBiZSB0aHJlZSBkaWZmZXJlbnQgdXJscyBvciBpdCBt
aWdodCBiZSBhbGwgb25lIHVybCB3aXRoIGEgcGFyYW1ldGVyIiBpcyBqdXN0IGFza2luZyBmb3Ig
YSBjb21wbGV0ZSBkaXNhc3Rlci4gV2hhdCBkb2VzIHRoZSBmbGV4aWJpbGl0eSBvZiBhbGxvd2lu
ZyB0d28gYXBwcm9hY2hlcyBhY3R1YWxseSBhY2NvbXBsaXNoPw0KPj4+Pj4NCj4+Pj4+IFlvdSBj
YW4gYXJndWUgYWJvdXQgdGhlIG1lcml0cyBvZiBlaXRoZXIgYXBwcm9hY2gsIGJ1dCBoYXZpbmcg
Ym90aCBhcyB1bnNwZWNpZmllZCBvcHRpb25zIGZvciByZWdpc3RyYXRpb24sIHdoaWNoIGlzIG1l
YW50IHRvIGhlbHAgdGhpbmdzIGdldCBnb2luZyBpbiBhIGNvbGQtYm9vdCBlbnZpcm9ubWVudCwg
aXMganVzdCBwbGFpbiBudXRzLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLSBKdXN0aW4NCj4+Pj4+
DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDAxLzIzLzIwMTMgMTI6MjEgUE0sIEFudGhvbnkgTmFk
YWxpbiB3cm90ZToNCj4+Pj4+PiBSZWdpc3RyYXRpb24gaGFzIHRvIHdvcmsgaW4gYSBtdWx0aS10
ZW5hbnQgZW52aXJvbm1lbnQgIHNvIA0KPj4+Pj4+IGZsZXhpYmlsaXR5IGlzIG5lZWRlZA0KPj4+
Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBKdXN0
aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXRyZS5vcmddDQo+Pj4+Pj4gU2VudDogV2VkbmVz
ZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDk6MTggQU0NCj4+Pj4+PiBUbzogQW50aG9ueSBOYWRhbGlu
DQo+Pj4+Pj4gQ2M6IE5hdCBTYWtpbXVyYTsgU2hpdSBGdW4gUG9vbjtvYXV0aEBpZXRmLm9yZw0K
Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENvbmNlcm5pbmcgT0F1dGggaW50cm9zcGVj
dGlvbg0KPj4+Pj4+DQo+Pj4+Pj4gQmVjYXVzZSB0aGVuIG5vYm9keSB3b3VsZCBrbm93IGhvdyB0
byBhY3R1YWxseSB1c2UgdGhlIHRoaW5nLg0KPj4+Pj4+DQo+Pj4+Pj4gSW4gbXkgb3Bpbmlvbiwg
dGhpcyBpcyBhIGtleSBwbGFjZSB3aGVyZSB0aGlzIGtpbmQgb2YgZmxleGliaWxpdHkgaXMgYSB2
ZXJ5IGJhZCB0aGluZy4gUmVnaXN0cmF0aW9uIG5lZWRzIHRvIHdvcmsgb25lIGZhaXJseSBwcmVk
aWN0YWJsZSB3YXkuDQo+Pj4+Pj4NCj4+Pj4+PiAtLSBKdXN0aW4NCj4+Pj4+Pg0KPj4+Pj4+IE9u
IDAxLzIzLzIwMTMgMTI6MTQgUE0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZToNCj4+Pj4+Pj4gV2h5
IG5vdCBqdXN0IGhhdmUgYSBwaHlzaWNhbCBhbmQgbG9naWNhbCBlbmRwb2ludCBvcHRpb25zDQo+
Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206
b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IA0KPj4+Pj4+PiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KPj4+Pj4+PiBTZW50OiBXZWRuZXNk
YXksIEphbnVhcnkgMjMsIDIwMTMgNzo0NyBBTQ0KPj4+Pj4+PiBUbzogTmF0IFNha2ltdXJhDQo+
Pj4+Pj4+IENjOiBTaGl1IEZ1biBQb29uO29hdXRoQGlldGYub3JnDQo+Pj4+Pj4+IFN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIENvbmNlcm5pbmcgT0F1dGggaW50cm9zcGVjdGlvbg0KPj4+Pj4+Pg0K
Pj4+Pj4+PiBXaGljaCBicmluZ3MgdXAgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gZm9yIHRoZSBS
ZWdpc3RyYXRpb24gZG9jOiByaWdodCBub3csIGl0J3Mgc2V0IHVwIGFzIGEgc2luZ2xlIGVuZHBv
aW50IHdpdGggdGhyZWUgb3BlcmF0aW9ucy4gV2UgY291bGQgaW5zdGVhZCBkZWZpbmUgdGhyZWUg
ZW5kcG9pbnRzIGZvciB0aGUgZGlmZmVyZW50IG9wZXJhdGlvbnMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+
IEkndmUgbm90IGJlZW4ga2VlbiB0byBtYWtlIHRoYXQgZGVlcCBvZiBhIGN1dHRpbmcgY2hhbmdl
IHRvIGl0LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGJlIGNsZWFuZXIgYW5kIG1vcmUgUkVTVGZ1
bCBBUEkgZGVzaWduLiBXaGF0IGRvIG90aGVycyB0aGluaz8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0g
SnVzdGluDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDAxLzIyLzIwMTMgMDg6MDUgUE0s
IE5hdCBTYWtpbXVyYSB3cm90ZToNCj4+Pj4+Pj4+ICJBY3Rpb24iIGdvZXMgYWdhaW5zdCBSRVNU
IHByaW5jaXBsZS4NCj4+Pj4+Pj4+IEkgZG8gbm90IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhLg0K
Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ID1uYXQgdmlhIGlQaG9uZQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEph
biAyMywgMjAxMyA0OjAw44CBSnVzdGluIFJpY2hlcjxqcmljaGVyQG1pdHJlLm9yZz4gIOOBruOD
oeODg+OCu+ODvOOCuDoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gKENDJ2luZyB0aGUgd29ya2luZyBn
cm91cCkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEknbSBub3Qgc3VyZSB3aGF0IHRoZSAiYWN0aW9u
L29wZXJhdGlvbiIgZmxhZyB3b3VsZCBhY2NvbXBsaXNoLiBUaGUgaWRlYSBiZWhpbmQgaGF2aW5n
IGRpZmZlcmVudCBlbmRwb2ludHMgaW4gT0F1dGggaXMgdGhhdCB0aGV5IGVhY2ggZG8gZGlmZmVy
ZW50IGtpbmRzIG9mIHRoaW5ncy4gVGhlIG9ubHkgImFjdGlvbi9vcGVyYXRpb24iIHRoYXQgSSBo
YWQgZW52aXNpb25lZCBmb3IgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgaXMgaW50cm9zcGVj
dGlvbiBpdHNlbGY6ICJJIGhhdmUgYSB0b2tlbiwgd2hhdCBkb2VzIGl0IG1lYW4/Ig0KPj4+Pj4+
Pj4+DQo+Pj4+Pj4+Pj4gTm90ZSB0aGF0IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCAqY2Fu
KiBhbHJlYWR5IGJlIHVzZWQgYXQgdGhpcyBlbmRwb2ludCBpZiB0aGUgc2VydmVyIHN1cHBvcnRz
IHRoYXQgYXMgcGFydCBvZiB0aGVpciBjbGllbnQgY3JlZGVudGlhbHMgc2V0dXAuIFRoZSBleGFt
cGxlcyB1c2UgSFRUUCBCYXNpYyB3aXRoIGNsaWVudCBpZCBhbmQgc2VjcmV0IHJpZ2h0IG5vdy4g
QmFzaWNhbGx5LCB0aGUgY2xpZW50IGNhbiBhdXRoZW50aWNhdGUgaG93ZXZlciBpdCB3YW50cywg
aW5jbHVkaW5nIGFueSBvZiB0aGUgbWV0aG9kcyB0aGF0IE9BdXRoMiBhbGxvd3Mgb24gdGhlIHRv
a2VuIGVuZHBvaW50LiBJdCBjb3VsZCBhbHNvIGF1dGhlbnRpY2F0ZSB3aXRoIGFuIGFjY2VzcyB0
b2tlbi4gQXQgbGVhc3QsIHRoYXQncyB0aGUgaW50ZW50IG9mIHRoZSBpbnRyb3NwZWN0aW9uIGRy
YWZ0IC0tIGlmIHRoYXQncyB1bmNsZWFyLCBJJ2QgYmUgaGFwcHkgdG8gYWNjZXB0IHN1Z2dlc3Rl
ZCBjaGFuZ2VzIHRvIGNsYXJpZnkgdGhpcyB0ZXh0Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAt
LSBKdXN0aW4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDAxLzIyLzIwMTMgMDE6MDAgUE0sIFNo
aXUgRnVuIFBvb24gd3JvdGU6DQo+Pj4+Pj4+Pj4+IEp1c3RpbiwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+
Pj4+Pj4gVGhpcyBzcGVjIGlzIGxvb2tpbmcgZ29vZC4uDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+
IE9uZSB0aGluZyBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIGlzIHRvIGFkZCAiYWN0aW9uIi8i
b3BlcmF0aW9uIg0KPj4+Pj4+Pj4+PiB0byB0aGUgcmVxdWVzdC4gIChhbmQgcG90ZW50aWFsbHkg
YWRkIGNsaWVudF9pZCBhbmQgDQo+Pj4+Pj4+Pj4+IGNsaWVudF9zZWNyZXQpDQo+Pj4+Pj4+Pj4+
DQo+Pj4+Pj4+Pj4+IFNvIHRoZSByZXF1ZXN0IHdpbGwgYmUgbGlrZSA6DQo+Pj4+Pj4+Pj4+IHRv
a2VuIFJFUVVJUkVEDQo+Pj4+Pj4+Pj4+IG9wZXJhdGlvbiAod29yZGluZyB0byBiZSBkZXRlcm1p
bmUpICBPUFRJT05BTCBpbnF1aXJlIChkZWZhdWx0KSB8IHJldm9rZSAuLi4NCj4+Pj4+Pj4+Pj4g
cmVzb3VyY2VfaWQgT1BUSU9OQUwNCj4+Pj4+Pj4+Pj4gY2xpZW50X2lkIE9QVElPTkFMDQo+Pj4+
Pj4+Pj4+IGNsaWVudF9zZWNyZXQgT1BUSU9OQUwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQW5k
IGZvciB0aGUgT0F1dGggY2xpZW50IGluZm9ybWF0aW9uLCBpdCBzaG91bGQgYmUgYW4gb3B0aW9u
YWwgcGFyYW1ldGVyIChpbiBjYXNlIGl0IGlzIGEgcHVibGljIGNsaWVudCBvciBjbGllbnQgaXMg
YXV0aGVudGljYXRlZCB3aXRoIFNTTCBtdXR1YWwgYXV0aGVudGljYXRpb24pLg0KPj4+Pj4+Pj4+
Pg0KPj4+Pj4+Pj4+PiBQbGVhc2UgY29uc2lkZXIuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFNo
aXVGdW4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IE9BdXRoQGll
dGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcN
Cj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+
Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+Pj4N
Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+
Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0K
Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmcNCj4+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1
dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cg==

From sberyozkin@gmail.com  Wed Jan 30 09:01:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D321F88CC for ; Wed, 30 Jan 2013 09:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.465
X-Spam-Level: 
X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p209ktWCgsJZ for ; Wed, 30 Jan 2013 09:01:08 -0800 (PST)
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23221F88D1 for ; Wed, 30 Jan 2013 09:01:06 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id jm19so924462bkc.2 for ; Wed, 30 Jan 2013 09:01:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bVCgDAREua0wITzx5t5FS0p6HljT0VHuyjqv904v62c=; b=oyD6n8htl8VoDqhgTij17UcYT4+TOnaOio2aGUpCoINulVNoWtct5qb6O/O6WM42rP 55OL0XCojWXC3LbUz8l1xr7g3O78XRH/3s5taZwP56ddceXfO4hKslNBv4uTk9n79M4c JXQLbwnnpe9J1JBK3X+mxE8e0cOcl3+39Qo0kM5NbqfA1FYHtgOXP3CSEc9sXs1jW5wy C5D/DqJCzB1rqpDuc/LGRl4rSMOa/UCrZ5xmSTfsG2+BQA4Uy0ptE9Sqsob4hvEDbqWN 7sOQ3Up8BucUzB1eQCfpG1JyebP2DyKqVSVNmzhkxZFXIYm+dlRk5uJqSv2ujgQ1C/Rp sxJA==
X-Received: by 10.204.9.16 with SMTP id j16mr1464245bkj.53.1359565263580; Wed, 30 Jan 2013 09:01:03 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id c10sm848680bkw.1.2013.01.30.09.01.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 09:01:02 -0800 (PST)
Message-ID: <510951CC.9020400@gmail.com>
Date: Wed, 30 Jan 2013 17:01:00 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org>	<49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com> <510947A5.3000904@mitre.org> <4E1F6AAD24975D4BA5B1680429673943673E6800@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943673E6800@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 17:01:09 -0000

On 30/01/13 16:42, Mike Jones wrote:
> I believe that what we have now - a single endpoint with an "operation" parameter, is more natural than having a different endpoint per operation.  In all likelihood, the implementation of all the operations (client_register, client_update, and rotate_secret) would end up going through the same code path anyway, using an operation parameter.  So let's just keep expressing it that way on the wire too.
>
> Having to maintain and register many endpoints for one logical set of functionality would just make things harder in a practical sense.  Let's leave things the way they are.

For whatever it is worth: -1 to using operation parameters;

honestly I haven't thought, with my WS experience, that I will 
contribute to this discussion :-), but "/oauth?operation=register" or 
similar will just get REST gurus having a lot of criticism on it, it 
won't of course the implementers from supporting it but this will just 
distract many people from adopting OAuth2, this minor fact alone, when 
all start saying, look, in OAuth2 they use query parameters as actions...

Just my 2c, Sergey



>
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Wednesday, January 30, 2013 8:18 AM
> To: John Bradley
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>
>
> On 01/30/2013 10:55 AM, John Bradley wrote:
>> My feeling was that letting the registration endpoint be a single URL (any url) and using query paramaters was easer for servers and clients.
>>
>> Saying take the base URI for the registration endpoint and append these paths to it to do different operations seems more likely to go wrong fro developers.
> Right, and to clarify, this isn't what I was saying. The spec wouldn't specify the path at all, just say that they're three different endpoint URLs. The same way that we specify that the auth endpoint and token endpoint are different URLs.
>
> I think my example might have been misleading. The URLs could just as easily be:
>
> client_register ->  /register_a_new_client rotate_secret ->  /client/go_get_a_secret_or_something
> client_update->  /maintenance/update_client_information
>
>
>
>>
>> Allowing both bath and query parameters is the worst option.
>>
>> I am sympathetic with using POST and PUT and perhaps GET but I worry about OAuth developers not getting it.
>>
>> I also don't get Tony's point about multi tenancy.  If each tenant can have there own registration endpoint I don't see a problem beyond finding the endpoint and that is what we have WF for.
> Exactly. And to Bill's point in another thread, we could also register a link type for each endpoint to help facilitate discovery:
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
>
>    -- Justin
>
>>
>> John B.
>>
>> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>>
>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>> I like this most, would rename it to say
>>>>
>>>> /oauth/client/registration
>>>> or
>>>> /oauth/client-registration
>>>>
>>>> etc
>>>>
>>>> and reword the spec such that it will let those who implement do it
>>>> with one endpoint or many, whatever is preferred
>>>>
>>> That's the whole point of this discussion -- I don't believe you can have it both ways.
>>>
>>> In one way, you say there are three endpoints and, if you're keeping with the rest of OAuth, you don't give them official URL patterns that they must follow. How the client gets those endpoints is up to discovery or configuration, but the client has an internal map from each bit of functionality to a particular URL that's specific to the service, much in the same way that the client today has to map the authorization and token endpoints. In the other method, you've got one endpoint that the client sends a well-defined parameter to in order to accomplish the same goal.
>>>
>>> So if you allow both at once, does a client send the "operation" parameter or not? Is it looking for one url or three to store in its configuration? I don't think this level of flexibility buys you anything useful, and I strongly believe that it will deeply hurt the functionality of dynamic registration if it's allowed.
>>>
>>> As it stands today, you can still make the URL whatever you want. If we went with three endpoints you could also make those URLs whatever you wanted. Nobody has yet pointed out to me what the actual benefit is of making both valid.
>>>
>>> I personally prefer the method of three endpoint URLs because it's cleaner and semantically equivalent, but I am hesitant to change that behavior unless there's strong working group support for it. I haven't seen real support for it yet -- it's not a good call to make it fully RESTful, and it's not a good call to leave it undefined. A client MUST have a very clear recipe of what to do on startup for this to work in the wild.
>>>
>>> -- Justin
>>>
>>>>>
>>>>> help multitenancy? How does it even affect that use case? Consider
>>>>> that the base URL for all of these is completely up to the host
>>>>> environment (nothing is bound to the root URL). Consider that
>>>>> clients still have to know what the URL (or URLs) are, in either
>>>>> case. Consider that clients still need to know how to manage all the parameters and responses.
>>>>>
>>>>> If anything, keeping it the way that it is with a single URL could
>>>>> be argued to help multitenancy because setting up routing to
>>>>> multiple URL endpoints can sometimes be problematic in hosted
>>>>> environments. However, OAuth already defines a bunch of endpoints,
>>>>> and we have to define at least one more with this extension, so I'm
>>>>> not convinced that having three with specific functions is really
>>>>> any different from having one with three functions from a
>>>>> development, deployment, and implementation perspective. I can tell
>>>>> you from experience that in our own server code, the difference is
>>>>> trivial. (And from OAuth1 experience, you can always have a query
>>>>> parameter as part of your endpoint URL if you need to. You might
>>>>> hate yourself for doing it that way, but nothing says your base URL
>>>>> can't already have parameters on it. A client just needs to know
>>>>> how to appropriately tack its parameters onto an existing URL, and
>>>>> any HTTP client worth its salt will know how to augment a query
>>>>> parameter set with new items.)
>>>>>
>>>>> The *real* difference between the two approaches is a philosophical
>>>>> design one. The former overloads one URL with multiple functions
>>>>> switched by a flag, the latter uses the URL itself as an implicit flag.
>>>>> Under the hood, these could (and in many cases will) be all served
>>>>> by the same chunks of code. The only difference is how this switch
>>>>> in functionality is presented.
>>>>>
>>>>>
>>>>> With that said, can somebody please explain to me how allowing
>>>>> *both* of these as options simultaneously (what I understand Tony
>>>>> to be
>>>>> suggesting) is a good idea, or how multitenancy even comes into play?
>>>>> Because I am completely not seeing how these are related.
>>>>>
>>>>> Thanks,
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>> It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?
>>>>>>
>>>>>> You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.
>>>>>>
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>> Registration has to work in a multi-tenant environment  so
>>>>>>> flexibility is needed
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>
>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>
>>>>>>> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
>>>>>>>
>>>>>>> -- Justin
>>>>>>>
>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura
>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>
>>>>>>>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.
>>>>>>>>
>>>>>>>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>
>>>>>>>>> =nat via iPhone
>>>>>>>>>
>>>>>>>>> Jan 23, 2013 4:00Justin Richer   :
>>>>>>>>>
>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>
>>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>>>>>
>>>>>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>>>>>
>>>>>>>>>>    -- Justin
>>>>>>>>>>
>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>> Justin,
>>>>>>>>>>>
>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>
>>>>>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>>>>>> to the request.  (and potentially add client_id and
>>>>>>>>>>> client_secret)
>>>>>>>>>>>
>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED
>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>
>>>>>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>>>>>
>>>>>>>>>>> Please consider.
>>>>>>>>>>>
>>>>>>>>>>> ShiuFun
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hannes.tschofenig@gmx.net  Wed Jan 30 09:12:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8760521F87D9 for ; Wed, 30 Jan 2013 09:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.144
X-Spam-Level: 
X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWBbzRutQ2SL for ; Wed, 30 Jan 2013 09:12:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 03C9E21F850E for ; Wed, 30 Jan 2013 09:12:02 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MUSgH-1UREzT3bal-00RGVX for ; Wed, 30 Jan 2013 18:12:00 +0100
Received: (qmail invoked by alias); 30 Jan 2013 17:12:00 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp030) with SMTP; 30 Jan 2013 18:12:00 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19zx+guv09z/3gOY2q0AKJre+SLc7fHCpkplJEZ2i 02qg06bj9T2gSG
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 30 Jan 2013 19:11:59 +0200
Message-Id: <6F2CD871-CFC4-435A-B127-37FA92CE6C0E@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Reminder: Design Team Conference Call - Feb. 4th at 1pm EST
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 17:12:03 -0000

And we are using John's/Nat's conference bridge again:
https://www3.gotomeeting.com/join/695548174 


From tonynad@microsoft.com  Wed Jan 30 13:41:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8495921F88E2 for ; Wed, 30 Jan 2013 13:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level: 
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THfOENNq6fdc for ; Wed, 30 Jan 2013 13:41:04 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 97D5821F88C7 for ; Wed, 30 Jan 2013 13:41:02 -0800 (PST)
Received: from BL2FFO11FD011.protection.gbl (10.173.161.201) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 21:40:55 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 21:40:55 +0000
Received: from db3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 30 Jan 2013 21:40:31 +0000
Received: from mail85-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 Jan 2013 21:39:24 +0000
Received: from mail85-db3 (localhost [127.0.0.1])	by mail85-db3-R.bigfish.com (Postfix) with ESMTP id 2CFA280134	for ; Wed, 30 Jan 2013 21:39:24 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Id6eah542I1418Ic85ah4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h9a9j1155h)
Received-SPF: softfail (mail85-db3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail85-db3 (localhost.localdomain [127.0.0.1]) by mail85-db3 (MessageSwitch) id 1359581956442480_22186; Wed, 30 Jan 2013 21:39:16 +0000 (UTC)
Received: from DB3EHSMHS020.bigfish.com (unknown [10.3.81.252])	by mail85-db3.bigfish.com (Postfix) with ESMTP id 690A120075; Wed, 30 Jan 2013 21:39:16 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS020.bigfish.com (10.3.87.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 Jan 2013 21:39:11 +0000
Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 30 Jan 2013 21:38:49 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.614.5; Wed, 30 Jan 2013 21:38:12 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.165]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.165]) with mapi id 15.00.0614.003; Wed, 30 Jan 2013 21:38:12 +0000
From: Anthony Nadalin 
To: Justin Richer , Shiu Fun Poon 
Thread-Topic: [OAUTH-WG] Concerning OAuth introspection
Thread-Index: AQHN+NM+tPsrUD5ZNEKigQoex6SLPZhWGdUAgAD2SICAABhS8IAAATIAgAAAnxCAAAHJgIAABNmwgAAF1QCACb6ugIABE6CAgABn4fA=
Date: Wed, 30 Jan 2013 21:38:11 +0000
Message-ID: <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org>
In-Reply-To: <51093A3D.8030306@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.182]
Content-Type: multipart/alternative; boundary="_000_68b9a48845df4dd2ade2536cc5a2dfb5BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(199002)(377454001)(13464002)(164054002)(24454001)(479174001)(189002)(56776001)(20776003)(50986001)(5343655001)(56816002)(53806001)(76482001)(512904001)(16236675001)(54356001)(16676001)(51856001)(74662001)(550184003)(47976001)(63696002)(54316002)(49866001)(31966008)(79102001)(44976002)(5343635001)(4396001)(74502001)(15202345001)(77982001)(6806001)(46102001)(59766001)(47736001)(33646001)(47446002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 21:41:06 -0000

--_000_68b9a48845df4dd2ade2536cc5a2dfb5BY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

I would not say that this is incompatible with OAUTH at all , as OAUTH has =
a physical and logical endpoints. We had to live through the Web Service en=
dpoint nightmare were we had to have separate services, nuts

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, January 30, 2013 7:20 AM
To: Shiu Fun Poon
Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection



Hi.. Tony.. You are able to present this better than I do.
Justin,
Currently as it is, the spec is unflexible.   So when I send a request to a=
n endpoint, the endpoint will need to have information like /revoke, /intro=
spection, and others.  I can imagine the documented usage of this will a pa=
ges long just to describe all the endpoint that is needed to support an app=
lication.  (so far, /authz, /token, /introspection, /revoke, /.....), and t=
his will be painful in the multi-tenant environment.

So why not allow the flexibility of using one endpoint /token (example only=
), and make the caller to tell you want the caller wants ?  It can be an op=
tional field, and a hint to the authorization/token endpoint on what you wa=
nt to do.
This is incompatible with OAuth as it stands today, which defines the auth =
endpoint and token endpoint as logically separate, and therefore there is n=
ot a parameter defined that would allow for such functionality switching.

That said, an *installation* could implement it this way if they wanted to,=
 they'd just have to document the endpoints like this:

token endpoint: /oauth?op=3Dtoken
auth endpoint: /oauth?op=3Dauth
introspection endpoint: /oauth?op=3Dintrospect
revocation endpoint: /oauth?op=3Drevoke

etc. The key difference here is that the "op=3D" parameter is *system speci=
fic* and is *not* part of the spec itself. And I think that's a good design=
 to continue to follow.

Right now, the registration endpoint is the only one that defines an "opera=
tion" parameter, and I was positing the question of defining it in terms of=
 three different endpoints instead. Most of the time, these endpoints will =
have different URLs, as outlined below, but specific instances could use so=
me kind of "operation" parameter if they wanted to.

Defining it as one endpoint with a switch parameter actually decreses flexi=
bility quite a lot, especially if you're talking about dispatching to diffe=
rent kinds of functionality all together, which is the use case you brought=
 up. There are some places where that could make sense, and the definition =
of different endpoints allows you to do that in specific instances of a sys=
tem without breaking the assumptions of clients.

What Tony was talking about was allowing something to be either three diffe=
rent URLs *or* using a spec-defined "operation" parameter. That suggestion =
is completely nuts, in my opinion.


And it does not violate the rest/json guideline.
Yes it absolutely does. The REST principle is that a URL represents one ent=
ity and the HTTP verbs represent different actions on that entity. Using a =
query parameter to switch is very much directly against REST guidelines. No=
t to say that OAuth is RESTful -- it's not, by a long shot. But it does fol=
low many rest-like principles, the endpoint definitions being one of them.



Even with oauth specification, it provides a hint on what is to come, e.g. =
grant_type refresh_token, indicates you want to exchange a valid refresh_to=
ken to an access_token.  There is something in the payload which tell you w=
hat you need to do.  In this case, there is nothing in the payload which in=
dicate what is expected.
These are functionality switches on the same kind of action, not dispatch t=
o different actions. you still do authentication/authorization at the auth =
endpoint, you still get tokens from the token endpoint, etc.



If you standard that now (on the optional field), there is a chance that co=
mpanies can implement this according to what will work best for them, and w=
e actually have a chance to get this working between different products.
It's too late to standardize that field in the core, which is really where =
it would belong. But as it stands today, an OAuth client is going to need t=
o be able to handle separate URLs for each defined endpoint already, so it =
can already handle the case where it happens to be the same base URL with d=
ifferent operations.

For what it's worth, what I was trying to get discussion on was whether it =
made sense to make Dynamic Registration look like the rest of OAuth with se=
parate endpoints, or not.

 -- Justin




On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer > wrote:
I am very confused, and I need someone to explain to me what I am missing. =
Why won't it work to just pick one? What are people "already stuck with" th=
at this would affect? It's not like we're trying to unseat a well-establish=
ed protocol with a wide installation base here.

How will giving people the choice between:
/oauth/register?operation=3Dclient_register
/oauth/register?operation=3Dclient_update
/oauth/register?operation=3Drotate_secret

and:
/oauth/client_register
/oauth/client_update
/oauth/rotate_secret

help multitenancy? How does it even affect that use case? Consider that the=
 base URL for all of these is completely up to the host environment (nothin=
g is bound to the root URL). Consider that clients still have to know what =
the URL (or URLs) are, in either case. Consider that clients still need to =
know how to manage all the parameters and responses.

If anything, keeping it the way that it is with a single URL could be argue=
d to help multitenancy because setting up routing to multiple URL endpoints=
 can sometimes be problematic in hosted environments. However, OAuth alread=
y defines a bunch of endpoints, and we have to define at least one more wit=
h this extension, so I'm not convinced that having three with specific func=
tions is really any different from having one with three functions from a d=
evelopment, deployment, and implementation perspective. I can tell you from=
 experience that in our own server code, the difference is trivial. (And fr=
om OAuth1 experience, you can always have a query parameter as part of your=
 endpoint URL if you need to. You might hate yourself for doing it that way=
, but nothing says your base URL can't already have parameters on it. A cli=
ent just needs to know how to appropriately tack its parameters onto an exi=
sting URL, and any HTTP client worth its salt will know how to augment a qu=
ery parameter set with new items.)

The *real* difference between the two approaches is a philosophical design =
one. The former overloads one URL with multiple functions switched by a fla=
g, the latter uses the URL itself as an implicit flag. Under the hood, thes=
e could (and in many cases will) be all served by the same chunks of code. =
The only difference is how this switch in functionality is presented.


With that said, can somebody please explain to me how allowing *both* of th=
ese as options simultaneously (what I understand Tony to be suggesting) is =
a good idea, or how multitenancy even comes into play? Because I am complet=
ely not seeing how these are related.

Thanks,
 -- Justin



On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

It will not work the way you have it, as people do multi-tendency different=
 and they are already stuck with the method that they have chosen, so they =
need the flexability, to restrict this is nuts as people won't use it.



-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, January 23, 2013 9:27 AM

To: Anthony Nadalin

Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



I completely disagree with this assessment. Multi-tenancy will work just fi=
ne (or even better) if everyone uses the same pattern. Telling someone "it =
might be three different urls or it might be all one url with a parameter" =
is just asking for a complete disaster. What does the flexibility of allowi=
ng two approaches actually accomplish?



You can argue about the merits of either approach, but having both as unspe=
cified options for registration, which is meant to help things get going in=
 a cold-boot environment, is just plain nuts.





-- Justin







On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

Registration has to work in a multi-tenant environment  so flexibility

is needed



-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, January 23, 2013 9:18 AM

To: Anthony Nadalin

Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



Because then nobody would know how to actually use the thing.



In my opinion, this is a key place where this kind of flexibility is a very=
 bad thing. Registration needs to work one fairly predictable way.



-- Justin



On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

Why not just have a physical and logical endpoint options



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On

Behalf Of Justin Richer

Sent: Wednesday, January 23, 2013 7:47 AM

To: Nat Sakimura

Cc: Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



Which brings up an interesting question for the Registration doc: right now=
, it's set up as a single endpoint with three operations. We could instead =
define three endpoints for the different operations.



I've not been keen to make that deep of a cutting change to it, but it woul=
d certainly be cleaner and more RESTful API design. What do others think?



-- Justin





On 01/22/2013 08:05 PM, Nat Sakimura wrote:

"Action" goes against REST principle.

I do not think it is a good idea.



=3Dnat via iPhone



Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer  =1B$B$N%a%C%;!<%8=1B(B:



(CC'ing the working group)



I'm not sure what the "action/operation" flag would accomplish. The idea be=
hind having different endpoints in OAuth is that they each do different kin=
ds of things. The only "action/operation" that I had envisioned for the int=
rospection endpoint is introspection itself: "I have a token, what does it =
mean?"



Note that client_id and client_secret *can* already be used at this endpoin=
t if the server supports that as part of their client credentials setup. Th=
e examples use HTTP Basic with client id and secret right now. Basically, t=
he client can authenticate however it wants, including any of the methods t=
hat OAuth2 allows on the token endpoint. It could also authenticate with an=
 access token. At least, that's the intent of the introspection draft -- if=
 that's unclear, I'd be happy to accept suggested changes to clarify this t=
ext.



 -- Justin



On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

Justin,



This spec is looking good..



One thing I would like to recommend is to add "action"/"operation"

to the request.  (and potentially add client_id and client_secret)



So the request will be like :

token                                             REQUIRED

operation (wording to be determine)  OPTIONAL inquire (default) | revoke ..=
.

resource_id                                    OPTIONAL

client_id                                         OPTIONAL

client_secret                                   OPTIONAL



And for the OAuth client information, it should be an optional parameter (i=
n case it is a public client or client is authenticated with SSL mutual aut=
hentication).



Please consider.



ShiuFun

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth
















--_000_68b9a48845df4dd2ade2536cc5a2dfb5BY2PR03MB041namprd03pro_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable











 






From: Justin Richer [mailto:jricher@mitre.org]


Sent: Wednesday, January 30, 2013 7:20 AM

To: Shiu Fun Poon

Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection






 



















Hi.. Tony.. You are a=
ble to present this better than I do.





Justin, 



Currently as it is, t=
he spec is unflexible.   So when I send a request to an endpoint,=
 the endpoint will need to have information like /revoke, /introspection, a=
nd others.  I can imagine the documented usage
 of this will a pages long just to describe all the endpoint that is needed=
 to support an application.  (so far, /authz, /token, /introspection, =
/revoke, /.....), and this will be painful in the multi-tenant environment.=




So why not allow the flexibility of using one endpoint /token (example only=
), and make the caller to tell you want the caller wants ?  It can be =
an optional field, and a hint to the authorization/token endpoint on what y=
ou want to do.









This is incompatible with OAuth as it stands today, =
which defines the auth endpoint and token endpoint as logically separate, a=
nd therefore there is not a parameter defined that would allow for such fun=
ctionality switching.



That said, an *installation* could implement it this way if they wanted to,=
 they'd just have to document the endpoints like this:



token endpoint: /oauth?op=3Dtoken

auth endpoint: /oauth?op=3Dauth

introspection endpoint: /oauth?op=3Dintrospect

revocation endpoint: /oauth?op=3Drevoke



etc. The key difference here is that the "op=3D" parameter is *sy=
stem specific* and is *not* part of the spec itself. And I think that's a g=
ood design to continue to follow.




Right now, the registration endpoint is the only one that defines an "=
operation" parameter, and I was positing the question of defining it i=
n terms of three different endpoints instead. Most of the time, these endpo=
ints will have different URLs, as outlined
 below, but specific instances could use some kind of "operation"=
 parameter if they wanted to.



Defining it as one endpoint with a switch parameter actually decreses flexi=
bility quite a lot, especially if you're talking about dispatching to diffe=
rent kinds of functionality all together, which is the use case you brought=
 up. There are some places where
 that could make sense, and the definition of different endpoints allows yo=
u to do that in specific instances of a system without breaking the assumpt=
ions of clients.



What Tony was talking about was allowing something to be either three diffe=
rent URLs *or* using a spec-defined "operation" parameter. That s=
uggestion is completely nuts, in my opinion.














And it does not violate the rest/json guideline.&nbs=
p;  








Yes it absolutely does. The REST principle is that a=
 URL represents one entity and the HTTP verbs represent different actions o=
n that entity. Using a query parameter to switch is very much directly agai=
nst REST guidelines. Not to say that
 OAuth is RESTful -- it's not, by a long shot. But it does follow many rest=
-like principles, the endpoint definitions being one of them.
















Even with oauth specification, it provides a hint on what is to come, e.g. =
grant_type refresh_token, indicates you want to exchange a valid refresh_to=
ken to an access_token.  There is something in the payload which tell =
you what you need to do.  In this case,
 there is nothing in the payload which indicate what is expected.








These are functionality switches on the same kind of=
 action, not dispatch to different actions. you still do authentication/aut=
horization at the auth endpoint, you still get tokens from the token endpoi=
nt, etc.














 






If you standard that now (on the optional field), th=
ere is a chance that companies can implement this according to what will wo=
rk best for them, and we actually have a chance to get this working between=
 different products.









It's too late to standardize that field in the core,=
 which is really where it would belong. But as it stands today, an OAuth cl=
ient is going to need to be able to handle separate URLs for each defined e=
ndpoint already, so it can already
 handle the case where it happens to be the same base URL with different op=
erations.



For what it's worth, what I was trying to get discussion on was whether it =
made sense to make Dynamic Registration look like the rest of OAuth with se=
parate endpoints, or not.



 -- Justin














 




On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer <<=
a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org=
> wrote:






I am very confused, a=
nd I need someone to explain to me what I am missing. Why won't it work to =
just pick one? What are people "already stuck with" that this wou=
ld affect? It's not like we're trying to unseat
 a well-established protocol with a wide installation base here.



How will giving people the choice between:




/oauth/register?operation=3Dclient_register

/oauth/register?operation=3Dclient_update

/oauth/register?operation=3Drotate_secret






and:




/oauth/client_register

/oauth/client_update

/oauth/rotate_secret






help multitenancy? How does it even affect that use case? Consider that the=
 base URL for all of these is completely up to the host environment (nothin=
g is bound to the root URL). Consider that clients still have to know what =
the URL (or URLs) are, in either
 case. Consider that clients still need to know how to manage all the param=
eters and responses.



If anything, keeping it the way that it is with a single URL could be argue=
d to help multitenancy because setting up routing to multiple URL endpoints=
 can sometimes be problematic in hosted environments. However, OAuth alread=
y defines a bunch of endpoints,
 and we have to define at least one more with this extension, so I'm not co=
nvinced that having three with specific functions is really any different f=
rom having one with three functions from a development, deployment, and imp=
lementation perspective. I can tell
 you from experience that in our own server code, the difference is trivial=
. (And from OAuth1 experience, you can always have a query parameter as par=
t of your endpoint URL if you need to. You might hate yourself for doing it=
 that way, but nothing says your
 base URL can't already have parameters on it. A client just needs to know =
how to appropriately tack its parameters onto an existing URL, and any HTTP=
 client worth its salt will know how to augment a query parameter set with =
new items.)



The *real* difference between the two approaches is a philosophical design =
one. The former overloads one URL with multiple functions switched by a fla=
g, the latter uses the URL itself as an implicit flag. Under the hood, thes=
e could (and in many cases will)
 be all served by the same chunks of code. The only difference is how this =
switch in functionality is presented.





With that said, can somebody please explain to me how allowing *both* of th=
ese as options simultaneously (what I understand Tony to be suggesting) is =
a good idea, or how multitenancy even comes into play? Because I am complet=
ely not seeing how these are related.



Thanks,

 -- Justin 

















On 01/23/2013 12:46 PM, Anthony Nadalin wrote:<=
/o:p>






It will not work the way you have it, as people do multi-tendency diff=
erent and they are already stuck with the method that they have chosen, so =
they need the flexability, to restrict this is nuts as people won't use it.=



 


-----Original Message-----


From: Justin Richer [mailto:jricher@mitre.org] 


Sent: Wednesday, January 23, 2013 9:27 AM


To: Anthony Nadalin


Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


I completely disagree with this assessment. Multi-tenancy will work ju=
st fine (or even better) if everyone uses the same pattern. Telling someone=
 "it might be three different urls or it might be all one url with a p=
arameter" is just asking for a complete disaster. What does the flexib=
ility of allowing two approaches actually accomplish?


 


You can argue about the merits of either approach, but having both as =
unspecified options for registration, which is meant to help things get goi=
ng in a cold-boot environment, is just plain nuts.


 


 


-- Justin


 


 


 


On 01/23/2013 12:21 PM, Anthony Nadalin wrote:




Registration has to work in a multi-tenant environment  so flexib=
ility 


is needed


 


-----Original Message-----


From: Justin Richer [mailto:jricher@mitre.org]


Sent: Wednesday, January 23, 2013 9:18 AM


To: Anthony Nadalin


Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


Because then nobody would know how to actually use the thing.


 


In my opinion, this is a key place where this kind of flexibility is a=
 very bad thing. Registration needs to work one fairly predictable way.


 


-- Justin


 


On 01/23/2013 12:14 PM, Anthony Nadalin wrote:




Why not just have a physical and logical endpoint options

 


-----Original Message-----


From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 


Behalf Of Justin Richer


Sent: Wednesday, January 23, 2013 7:47 AM


To: Nat Sakimura


Cc: Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


Which brings up an interesting question for the Registration doc: righ=
t now, it's set up as a single endpoint with three operations. We could ins=
tead define three endpoints for the different operations.


 


I've not been keen to make that deep of a cutting change to it, but it=
 would certainly be cleaner and more RESTful API design. What do others thi=
nk?


 


-- Justin


 


 


On 01/22/2013 08:05 PM, Nat Sakimura wrote:




"Action" goes against REST principle.


I do not think it is a good idea.


 


=3Dnat via iPhone


 


Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer <jricher@mitre.org&=
gt; =1B$B$N%a%C%;!<%8=1B(B:


 




(CC'ing the working group)


 


I'm not sure what the "action/operation" flag would accompli=
sh. The idea behind having different endpoints in OAuth is that they each d=
o different kinds of things. The only "action/operation" that I h=
ad envisioned for the introspection endpoint is introspection itself: "=
;I have a token, what does it mean?"


 


Note that client_id and client_secret *can* already be used at this en=
dpoint if the server supports that as part of their client credentials setu=
p. The examples use HTTP Basic with client id and secret right now. Basical=
ly, the client can authenticate however it wants, including any of the meth=
ods that OAuth2 allows on the token endpoint. It could also authenticate wi=
th an access token. At least, that's the intent of the introspection draft =
-- if that's unclear, I'd be happy to accept suggested changes to clarify t=
his text.


 


 -- Justin


 


On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:




Justin,


 


This spec is looking good..


 


One thing I would like to recommend is to add "action"/"=
;operation" 


to the request.  (and potentially add client_id and client_secret=
)


 


So the request will be like :


token           =
;            &n=
bsp;            =
;         REQUIRED


operation (wording to be determine)  OPTIONAL inquire (default) |=
 revoke ...


resource_id          =
;            &n=
bsp;            =
; OPTIONAL


client_id          &=
nbsp;           &nbs=
p;            &=
nbsp;     OPTIONAL


client_secret         &nb=
sp;            =
             OP=
TIONAL


 


And for the OAuth client information, it should be an optional paramet=
er (in case it is a public client or client is authenticated with SSL mutua=
l authentication).


 


Please consider.


 


ShiuFun




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


 


 


 




 




 


 




 












 






 






--_000_68b9a48845df4dd2ade2536cc5a2dfb5BY2PR03MB041namprd03pro_--

From Michael.Jones@microsoft.com  Wed Jan 30 13:52:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75DF21F8780 for ; Wed, 30 Jan 2013 13:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHDzAyg7Gguv for ; Wed, 30 Jan 2013 13:52:39 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD821F87D3 for ; Wed, 30 Jan 2013 13:52:37 -0800 (PST)
Received: from BL2FFO11FD009.protection.gbl (10.173.161.204) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 21:52:33 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 21:52:32 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 21:51:59 +0000
From: Mike Jones 
To: Anthony Nadalin , Justin Richer , Shiu Fun Poon 
Thread-Topic: [OAUTH-WG] Concerning OAuth introspection
Thread-Index: AQHN/v2JW34lzhNbb06oE8RjJSijtZhiZjiAgAABAAA=
Date: Wed, 30 Jan 2013 21:51:58 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943673EB05CTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(377454001)(24454001)(199002)(164054002)(479174001)(189002)(13464002)(15202345001)(77982001)(59766001)(74502001)(5343635001)(16406001)(51856001)(63696002)(50986001)(4396001)(54356001)(47976001)(53806001)(56816002)(1511001)(54316002)(44976002)(55846006)(46102001)(79102001)(20776003)(47446002)(512904001)(33656001)(16236675001)(47736001)(74662001)(49866001)(550184003)(5343655001)(56776001)(16297215001)(76482001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 21:52:41 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943673EB05CTK5EX14MBXC284r_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

I=1B$B!G=1B(Bll note that the OAuth token endpoint changes behaviors depend=
ing upon the grant_type and whether code or refresh_token parameters are pr=
esent.  The first case is described at http://tools.ietf.org/html/rfc6749#s=
ection-4.1.3.  The second case is described at http://tools.ietf.org/html/r=
fc6749#section-6.

There are already a bunch of ways in which OAuth is not RESTful in a strict=
 sense of the term.  It doesn=1B$B!G=1B(Bt seem to be a problem in practice=
.

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A=
nthony Nadalin
Sent: Wednesday, January 30, 2013 1:38 PM
To: Justin Richer; Shiu Fun Poon
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

I would not say that this is incompatible with OAUTH at all , as OAUTH has =
a physical and logical endpoints. We had to live through the Web Service en=
dpoint nightmare were we had to have separate services, nuts

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, January 30, 2013 7:20 AM
To: Shiu Fun Poon
Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection


Hi.. Tony.. You are able to present this better than I do.
Justin,
Currently as it is, the spec is unflexible.   So when I send a request to a=
n endpoint, the endpoint will need to have information like /revoke, /intro=
spection, and others.  I can imagine the documented usage of this will a pa=
ges long just to describe all the endpoint that is needed to support an app=
lication.  (so far, /authz, /token, /introspection, /revoke, /.....), and t=
his will be painful in the multi-tenant environment.

So why not allow the flexibility of using one endpoint /token (example only=
), and make the caller to tell you want the caller wants ?  It can be an op=
tional field, and a hint to the authorization/token endpoint on what you wa=
nt to do.
This is incompatible with OAuth as it stands today, which defines the auth =
endpoint and token endpoint as logically separate, and therefore there is n=
ot a parameter defined that would allow for such functionality switching.

That said, an *installation* could implement it this way if they wanted to,=
 they'd just have to document the endpoints like this:

token endpoint: /oauth?op=3Dtoken
auth endpoint: /oauth?op=3Dauth
introspection endpoint: /oauth?op=3Dintrospect
revocation endpoint: /oauth?op=3Drevoke

etc. The key difference here is that the "op=3D" parameter is *system speci=
fic* and is *not* part of the spec itself. And I think that's a good design=
 to continue to follow.

Right now, the registration endpoint is the only one that defines an "opera=
tion" parameter, and I was positing the question of defining it in terms of=
 three different endpoints instead. Most of the time, these endpoints will =
have different URLs, as outlined below, but specific instances could use so=
me kind of "operation" parameter if they wanted to.

Defining it as one endpoint with a switch parameter actually decreses flexi=
bility quite a lot, especially if you're talking about dispatching to diffe=
rent kinds of functionality all together, which is the use case you brought=
 up. There are some places where that could make sense, and the definition =
of different endpoints allows you to do that in specific instances of a sys=
tem without breaking the assumptions of clients.

What Tony was talking about was allowing something to be either three diffe=
rent URLs *or* using a spec-defined "operation" parameter. That suggestion =
is completely nuts, in my opinion.

And it does not violate the rest/json guideline.
Yes it absolutely does. The REST principle is that a URL represents one ent=
ity and the HTTP verbs represent different actions on that entity. Using a =
query parameter to switch is very much directly against REST guidelines. No=
t to say that OAuth is RESTful -- it's not, by a long shot. But it does fol=
low many rest-like principles, the endpoint definitions being one of them.


Even with oauth specification, it provides a hint on what is to come, e.g. =
grant_type refresh_token, indicates you want to exchange a valid refresh_to=
ken to an access_token.  There is something in the payload which tell you w=
hat you need to do.  In this case, there is nothing in the payload which in=
dicate what is expected.
These are functionality switches on the same kind of action, not dispatch t=
o different actions. you still do authentication/authorization at the auth =
endpoint, you still get tokens from the token endpoint, etc.


If you standard that now (on the optional field), there is a chance that co=
mpanies can implement this according to what will work best for them, and w=
e actually have a chance to get this working between different products.
It's too late to standardize that field in the core, which is really where =
it would belong. But as it stands today, an OAuth client is going to need t=
o be able to handle separate URLs for each defined endpoint already, so it =
can already handle the case where it happens to be the same base URL with d=
ifferent operations.

For what it's worth, what I was trying to get discussion on was whether it =
made sense to make Dynamic Registration look like the rest of OAuth with se=
parate endpoints, or not.

 -- Justin



On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer > wrote:
I am very confused, and I need someone to explain to me what I am missing. =
Why won't it work to just pick one? What are people "already stuck with" th=
at this would affect? It's not like we're trying to unseat a well-establish=
ed protocol with a wide installation base here.

How will giving people the choice between:
/oauth/register?operation=3Dclient_register
/oauth/register?operation=3Dclient_update
/oauth/register?operation=3Drotate_secret

and:
/oauth/client_register
/oauth/client_update
/oauth/rotate_secret

help multitenancy? How does it even affect that use case? Consider that the=
 base URL for all of these is completely up to the host environment (nothin=
g is bound to the root URL). Consider that clients still have to know what =
the URL (or URLs) are, in either case. Consider that clients still need to =
know how to manage all the parameters and responses.

If anything, keeping it the way that it is with a single URL could be argue=
d to help multitenancy because setting up routing to multiple URL endpoints=
 can sometimes be problematic in hosted environments. However, OAuth alread=
y defines a bunch of endpoints, and we have to define at least one more wit=
h this extension, so I'm not convinced that having three with specific func=
tions is really any different from having one with three functions from a d=
evelopment, deployment, and implementation perspective. I can tell you from=
 experience that in our own server code, the difference is trivial. (And fr=
om OAuth1 experience, you can always have a query parameter as part of your=
 endpoint URL if you need to. You might hate yourself for doing it that way=
, but nothing says your base URL can't already have parameters on it. A cli=
ent just needs to know how to appropriately tack its parameters onto an exi=
sting URL, and any HTTP client worth its salt will know how to augment a qu=
ery parameter set with new items.)

The *real* difference between the two approaches is a philosophical design =
one. The former overloads one URL with multiple functions switched by a fla=
g, the latter uses the URL itself as an implicit flag. Under the hood, thes=
e could (and in many cases will) be all served by the same chunks of code. =
The only difference is how this switch in functionality is presented.


With that said, can somebody please explain to me how allowing *both* of th=
ese as options simultaneously (what I understand Tony to be suggesting) is =
a good idea, or how multitenancy even comes into play? Because I am complet=
ely not seeing how these are related.

Thanks,
 -- Justin


On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

It will not work the way you have it, as people do multi-tendency different=
 and they are already stuck with the method that they have chosen, so they =
need the flexability, to restrict this is nuts as people won't use it.



-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, January 23, 2013 9:27 AM

To: Anthony Nadalin

Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



I completely disagree with this assessment. Multi-tenancy will work just fi=
ne (or even better) if everyone uses the same pattern. Telling someone "it =
might be three different urls or it might be all one url with a parameter" =
is just asking for a complete disaster. What does the flexibility of allowi=
ng two approaches actually accomplish?



You can argue about the merits of either approach, but having both as unspe=
cified options for registration, which is meant to help things get going in=
 a cold-boot environment, is just plain nuts.





-- Justin







On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

Registration has to work in a multi-tenant environment  so flexibility

is needed



-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, January 23, 2013 9:18 AM

To: Anthony Nadalin

Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



Because then nobody would know how to actually use the thing.



In my opinion, this is a key place where this kind of flexibility is a very=
 bad thing. Registration needs to work one fairly predictable way.



-- Justin



On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

Why not just have a physical and logical endpoint options



-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On

Behalf Of Justin Richer

Sent: Wednesday, January 23, 2013 7:47 AM

To: Nat Sakimura

Cc: Shiu Fun Poon; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection



Which brings up an interesting question for the Registration doc: right now=
, it's set up as a single endpoint with three operations. We could instead =
define three endpoints for the different operations.



I've not been keen to make that deep of a cutting change to it, but it woul=
d certainly be cleaner and more RESTful API design. What do others think?



-- Justin





On 01/22/2013 08:05 PM, Nat Sakimura wrote:

"Action" goes against REST principle.

I do not think it is a good idea.



=3Dnat via iPhone



Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer  =1B$B$N%a%C%;!<%8=1B(B:



(CC'ing the working group)



I'm not sure what the "action/operation" flag would accomplish. The idea be=
hind having different endpoints in OAuth is that they each do different kin=
ds of things. The only "action/operation" that I had envisioned for the int=
rospection endpoint is introspection itself: "I have a token, what does it =
mean?"



Note that client_id and client_secret *can* already be used at this endpoin=
t if the server supports that as part of their client credentials setup. Th=
e examples use HTTP Basic with client id and secret right now. Basically, t=
he client can authenticate however it wants, including any of the methods t=
hat OAuth2 allows on the token endpoint. It could also authenticate with an=
 access token. At least, that's the intent of the introspection draft -- if=
 that's unclear, I'd be happy to accept suggested changes to clarify this t=
ext.



 -- Justin



On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

Justin,



This spec is looking good..



One thing I would like to recommend is to add "action"/"operation"

to the request.  (and potentially add client_id and client_secret)



So the request will be like :

token                                             REQUIRED

operation (wording to be determine)  OPTIONAL inquire (default) | revoke ..=
.

resource_id                                    OPTIONAL

client_id                                         OPTIONAL

client_secret                                   OPTIONAL



And for the OAuth client information, it should be an optional parameter (i=
n case it is a public client or client is authenticated with SSL mutual aut=
hentication).



Please consider.



ShiuFun

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth
















--_000_4E1F6AAD24975D4BA5B1680429673943673EB05CTK5EX14MBXC284r_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable











I=1B$B!G=1B(Bll note that=
 the OAuth token endpoint changes behaviors depending upon the grant_type a=
nd whether code or refresh_token parameters are present.  The first
 case is described at 
http://tools.ietf.org/html/rfc6749#section-4.1.3.  The second case=
 is described at
http://tools.ietf.=
org/html/rfc6749#section-6.


 <=
/p>

There are already a bunch=
 of ways in which OAuth is not RESTful in a strict sense of the term. =
 It doesn=1B$B!G=1B(Bt seem to be a problem in practice.<=
/p>

 <=
/p>

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


 <=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of Anthony Nadalin

Sent: Wednesday, January 30, 2013 1:38 PM

To: Justin Richer; Shiu Fun Poon

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection






 


 






From: Justin Richer [mailto:jricher@mitre.org]


Sent: Wednesday, January 30, 2013 7:20 AM

To: Shiu Fun Poon

Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org

Subject: Re: [OAUTH-WG] Concerning OAuth introspection






 


 












Hi.. Tony.. You are a=
ble to present this better than I do.





Justin, 



Currently as it is, t=
he spec is unflexible.   So when I send a request to an endpoint,=
 the endpoint will need to have information like /revoke, /introspection, a=
nd others.  I can imagine the documented usage
 of this will a pages long just to describe all the endpoint that is needed=
 to support an application.  (so far, /authz, /token, /introspection, =
/revoke, /.....), and this will be painful in the multi-tenant environment.=




So why not allow the flexibility of using one endpoint /token (example only=
), and make the caller to tell you want the caller wants ?  It can be =
an optional field, and a hint to the authorization/token endpoint on what y=
ou want to do.









This is incompatible =
with OAuth as it stands today, which defines the auth endpoint and token en=
dpoint as logically separate, and therefore there is not a parameter define=
d that would allow for such functionality
 switching.



That said, an *installation* could implement it this way if they wanted to,=
 they'd just have to document the endpoints like this:



token endpoint: /oauth?op=3Dtoken

auth endpoint: /oauth?op=3Dauth

introspection endpoint: /oauth?op=3Dintrospect

revocation endpoint: /oauth?op=3Drevoke



etc. The key difference here is that the "op=3D" parameter is *sy=
stem specific* and is *not* part of the spec itself. And I think that's a g=
ood design to continue to follow.




Right now, the registration endpoint is the only one that defines an "=
operation" parameter, and I was positing the question of defining it i=
n terms of three different endpoints instead. Most of the time, these endpo=
ints will have different URLs, as outlined
 below, but specific instances could use some kind of "operation"=
 parameter if they wanted to.



Defining it as one endpoint with a switch parameter actually decreses flexi=
bility quite a lot, especially if you're talking about dispatching to diffe=
rent kinds of functionality all together, which is the use case you brought=
 up. There are some places where
 that could make sense, and the definition of different endpoints allows yo=
u to do that in specific instances of a system without breaking the assumpt=
ions of clients.



What Tony was talking about was allowing something to be either three diffe=
rent URLs *or* using a spec-defined "operation" parameter. That s=
uggestion is completely nuts, in my opinion.












And it does not violate the rest/json guideline.&nbs=
p;  








Yes it absolutely doe=
s. The REST principle is that a URL represents one entity and the HTTP verb=
s represent different actions on that entity. Using a query parameter to sw=
itch is very much directly against REST
 guidelines. Not to say that OAuth is RESTful -- it's not, by a long shot. =
But it does follow many rest-like principles, the endpoint definitions bein=
g one of them.














Even with oauth specification, it provides a hint on what is to come, e.g. =
grant_type refresh_token, indicates you want to exchange a valid refresh_to=
ken to an access_token.  There is something in the payload which tell =
you what you need to do.  In this case,
 there is nothing in the payload which indicate what is expected.








These are functionali=
ty switches on the same kind of action, not dispatch to different actions. =
you still do authentication/authorization at the auth endpoint, you still g=
et tokens from the token endpoint, etc.












 






If you standard that now (on the optional field), th=
ere is a chance that companies can implement this according to what will wo=
rk best for them, and we actually have a chance to get this working between=
 different products.









It's too late to stan=
dardize that field in the core, which is really where it would belong. But =
as it stands today, an OAuth client is going to need to be able to handle s=
eparate URLs for each defined endpoint
 already, so it can already handle the case where it happens to be the same=
 base URL with different operations.



For what it's worth, what I was trying to get discussion on was whether it =
made sense to make Dynamic Registration look like the rest of OAuth with se=
parate endpoints, or not.



 -- Justin












 




On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer <<=
a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org=
> wrote:






I am very confused, a=
nd I need someone to explain to me what I am missing. Why won't it work to =
just pick one? What are people "already stuck with" that this wou=
ld affect? It's not like we're trying to unseat
 a well-established protocol with a wide installation base here.



How will giving people the choice between:




/oauth/register?operation=3Dclient_register

/oauth/register?operation=3Dclient_update

/oauth/register?operation=3Drotate_secret






and:




/oauth/client_register

/oauth/client_update

/oauth/rotate_secret






help multitenancy? How does it even affect that use case? Consider that the=
 base URL for all of these is completely up to the host environment (nothin=
g is bound to the root URL). Consider that clients still have to know what =
the URL (or URLs) are, in either
 case. Consider that clients still need to know how to manage all the param=
eters and responses.



If anything, keeping it the way that it is with a single URL could be argue=
d to help multitenancy because setting up routing to multiple URL endpoints=
 can sometimes be problematic in hosted environments. However, OAuth alread=
y defines a bunch of endpoints,
 and we have to define at least one more with this extension, so I'm not co=
nvinced that having three with specific functions is really any different f=
rom having one with three functions from a development, deployment, and imp=
lementation perspective. I can tell
 you from experience that in our own server code, the difference is trivial=
. (And from OAuth1 experience, you can always have a query parameter as par=
t of your endpoint URL if you need to. You might hate yourself for doing it=
 that way, but nothing says your
 base URL can't already have parameters on it. A client just needs to know =
how to appropriately tack its parameters onto an existing URL, and any HTTP=
 client worth its salt will know how to augment a query parameter set with =
new items.)



The *real* difference between the two approaches is a philosophical design =
one. The former overloads one URL with multiple functions switched by a fla=
g, the latter uses the URL itself as an implicit flag. Under the hood, thes=
e could (and in many cases will)
 be all served by the same chunks of code. The only difference is how this =
switch in functionality is presented.





With that said, can somebody please explain to me how allowing *both* of th=
ese as options simultaneously (what I understand Tony to be suggesting) is =
a good idea, or how multitenancy even comes into play? Because I am complet=
ely not seeing how these are related.



Thanks,

 -- Justin 















On 01/23/2013 12:46 PM, Anthony Nadalin wrote:<=
/o:p>






It will not work the way you have it, as people do multi-tendency diff=
erent and they are already stuck with the method that they have chosen, so =
they need the flexability, to restrict this is nuts as people won't use it.=



 


-----Original Message-----


From: Justin Richer [mailto:jricher@mitre.org] 


Sent: Wednesday, January 23, 2013 9:27 AM


To: Anthony Nadalin


Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


I completely disagree with this assessment. Multi-tenancy will work ju=
st fine (or even better) if everyone uses the same pattern. Telling someone=
 "it might be three different urls or it might be all one url with a p=
arameter" is just asking for a complete disaster. What does the flexib=
ility of allowing two approaches actually accomplish?


 


You can argue about the merits of either approach, but having both as =
unspecified options for registration, which is meant to help things get goi=
ng in a cold-boot environment, is just plain nuts.


 


 


-- Justin


 


 


 


On 01/23/2013 12:21 PM, Anthony Nadalin wrote:




Registration has to work in a multi-tenant environment  so flexib=
ility 


is needed


 


-----Original Message-----


From: Justin Richer [mailto:jricher@mitre.org]


Sent: Wednesday, January 23, 2013 9:18 AM


To: Anthony Nadalin


Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


Because then nobody would know how to actually use the thing.


 


In my opinion, this is a key place where this kind of flexibility is a=
 very bad thing. Registration needs to work one fairly predictable way.


 


-- Justin


 


On 01/23/2013 12:14 PM, Anthony Nadalin wrote:




Why not just have a physical and logical endpoint options

 


-----Original Message-----


From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 


Behalf Of Justin Richer


Sent: Wednesday, January 23, 2013 7:47 AM


To: Nat Sakimura


Cc: Shiu Fun Poon; oauth@ietf.org


Subject: Re: [OAUTH-WG] Concerning OAuth introspection

 


Which brings up an interesting question for the Registration doc: righ=
t now, it's set up as a single endpoint with three operations. We could ins=
tead define three endpoints for the different operations.


 


I've not been keen to make that deep of a cutting change to it, but it=
 would certainly be cleaner and more RESTful API design. What do others thi=
nk?


 


-- Justin


 


 


On 01/22/2013 08:05 PM, Nat Sakimura wrote:




"Action" goes against REST principle.


I do not think it is a good idea.


 


=3Dnat via iPhone


 


Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer <jricher@mitre.org&=
gt; =1B$B$N%a%C%;!<%8=1B(B:


 




(CC'ing the working group)


 


I'm not sure what the "action/operation" flag would accompli=
sh. The idea behind having different endpoints in OAuth is that they each d=
o different kinds of things. The only "action/operation" that I h=
ad envisioned for the introspection endpoint is introspection itself: "=
;I have a token, what does it mean?"


 


Note that client_id and client_secret *can* already be used at this en=
dpoint if the server supports that as part of their client credentials setu=
p. The examples use HTTP Basic with client id and secret right now. Basical=
ly, the client can authenticate however it wants, including any of the meth=
ods that OAuth2 allows on the token endpoint. It could also authenticate wi=
th an access token. At least, that's the intent of the introspection draft =
-- if that's unclear, I'd be happy to accept suggested changes to clarify t=
his text.


 


 -- Justin


 


On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:




Justin,


 


This spec is looking good..


 


One thing I would like to recommend is to add "action"/"=
;operation" 


to the request.  (and potentially add client_id and client_secret=
)


 


So the request will be like :


token           =
;            &n=
bsp;            =
;         REQUIRED


operation (wording to be determine)  OPTIONAL inquire (default) |=
 revoke ...


resource_id          =
;            &n=
bsp;            =
; OPTIONAL


client_id          &=
nbsp;           &nbs=
p;            &=
nbsp;     OPTIONAL


client_secret         &nb=
sp;            =
             OP=
TIONAL


 


And for the OAuth client information, it should be an optional paramet=
er (in case it is a public client or client is authenticated with SSL mutua=
l authentication).


 


Please consider.


 


ShiuFun




_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/listinfo/oauth


 


 


 




 




 


 




 












 






 






--_000_4E1F6AAD24975D4BA5B1680429673943673EB05CTK5EX14MBXC284r_--

From jricher@mitre.org  Wed Jan 30 14:09:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4321F883C for ; Wed, 30 Jan 2013 14:09:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.545
X-Spam-Level: 
X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3b5y3yy6MbZ for ; Wed, 30 Jan 2013 14:09:01 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED40821F8855 for ; Wed, 30 Jan 2013 14:08:53 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB3FA5311297; Wed, 30 Jan 2013 17:08:51 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5E3175311294; Wed, 30 Jan 2013 17:08:51 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 17:08:51 -0500
Message-ID: <510999D7.3000805@mitre.org>
Date: Wed, 30 Jan 2013 17:08:23 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------070606040402050604080603"
X-Originating-IP: [129.83.31.58]
Cc: Shiu Fun Poon , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:09:03 -0000

--------------070606040402050604080603
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

I completely agree that OAuth is not RESTful in any meaningful sense of
the term (and have stated so several times in this thread). I'm not at
all against using query parameters to change behaviors. That's why
they're there. But I'll point out that the examples that you give are
still *doing* the same thing qualitatively (returning a token, in this
instance), even though the mechanisms for doing so are a bit different.
They're still basically the same "action", and if there were a
protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
they would all have the same value for it. The client registration
endpoint is different, because even though all the actions are *about*
client registration, they're different actions. This is the whole
purpose of the "operation=" parameter in the first place. That's the
reason that I brought up this idea of defining them as separate endpoints.

Regardless, the group seems about even split on one mode versus the
other. As such, I'm inclined to leave the "operation=" parameter in
place on the registration endpoint even though I don't prefer it.

I still am very strongly against the idea of defining a protocol-wide
"operation=" parameter for switching between all endpoints, even if it
were possible to do such a thing.

-- Justin

On 01/30/2013 04:51 PM, Mike Jones wrote:
>
> I’ll note that the OAuth token endpoint changes behaviors depending
> upon the grant_type and whether code or refresh_token parameters are
> present. The first case is described at
> http://tools.ietf.org/html/rfc6749#section-4.1.3
> . The second case is
> described at http://tools.ietf.org/html/rfc6749#section-6.
>
> There are already a bunch of ways in which OAuth is not RESTful in a
> strict sense of the term. It doesn’t seem to be a problem in practice.
>
> -- Mike
>
> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
> Behalf Of *Anthony Nadalin
> *Sent:* Wednesday, January 30, 2013 1:38 PM
> *To:* Justin Richer; Shiu Fun Poon
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>
> I would not say that this is incompatible with OAUTH at all , as OAUTH
> has a physical and logical endpoints. We had to live through the Web
> Service endpoint nightmare were we had to have separate services, nuts
>
> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Wednesday, January 30, 2013 7:20 AM
> *To:* Shiu Fun Poon
> *Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
> 
> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>
>     Hi.. Tony.. You are able to present this better than I do.
>
>     Justin,
>
>     Currently as it is, the spec is unflexible. So when I send a
>     request to an endpoint, the endpoint will need to have information
>     like /revoke, /introspection, and others. I can imagine the
>     documented usage of this will a pages long just to describe all
>     the endpoint that is needed to support an application. (so far,
>     /authz, /token, /introspection, /revoke, /.....), and this will be
>     painful in the multi-tenant environment.
>
>     So why not allow the flexibility of using one endpoint /token
>     (example only), and make the caller to tell you want the caller
>     wants ? It can be an optional field, and a hint to the
>     authorization/token endpoint on what you want to do.
>
> This is incompatible with OAuth as it stands today, which defines the
> auth endpoint and token endpoint as logically separate, and therefore
> there is not a parameter defined that would allow for such
> functionality switching.
>
> That said, an *installation* could implement it this way if they
> wanted to, they'd just have to document the endpoints like this:
>
> token endpoint: /oauth?op=token
> auth endpoint: /oauth?op=auth
> introspection endpoint: /oauth?op=introspect
> revocation endpoint: /oauth?op=revoke
>
> etc. The key difference here is that the "op=" parameter is *system
> specific* and is *not* part of the spec itself. And I think that's a
> good design to continue to follow.
>
> Right now, the registration endpoint is the only one that defines an
> "operation" parameter, and I was positing the question of defining it
> in terms of three different endpoints instead. Most of the time, these
> endpoints will have different URLs, as outlined below, but specific
> instances could use some kind of "operation" parameter if they wanted to.
>
> Defining it as one endpoint with a switch parameter actually decreses
> flexibility quite a lot, especially if you're talking about
> dispatching to different kinds of functionality all together, which is
> the use case you brought up. There are some places where that could
> make sense, and the definition of different endpoints allows you to do
> that in specific instances of a system without breaking the
> assumptions of clients.
>
> What Tony was talking about was allowing something to be either three
> different URLs *or* using a spec-defined "operation" parameter. That
> suggestion is completely nuts, in my opinion.
>
>     And it does not violate the rest/json guideline.
>
> Yes it absolutely does. The REST principle is that a URL represents
> one entity and the HTTP verbs represent different actions on that
> entity. Using a query parameter to switch is very much directly
> against REST guidelines. Not to say that OAuth is RESTful -- it's not,
> by a long shot. But it does follow many rest-like principles, the
> endpoint definitions being one of them.
>
>
>     Even with oauth specification, it provides a hint on what is to
>     come, e.g. grant_type refresh_token, indicates you want to
>     exchange a valid refresh_token to an access_token. There is
>     something in the payload which tell you what you need to do. In
>     this case, there is nothing in the payload which indicate what is
>     expected.
>
> These are functionality switches on the same kind of action, not
> dispatch to different actions. you still do
> authentication/authorization at the auth endpoint, you still get
> tokens from the token endpoint, etc.
>
>     If you standard that now (on the optional field), there is a
>     chance that companies can implement this according to what will
>     work best for them, and we actually have a chance to get this
>     working between different products.
>
> It's too late to standardize that field in the core, which is really
> where it would belong. But as it stands today, an OAuth client is
> going to need to be able to handle separate URLs for each defined
> endpoint already, so it can already handle the case where it happens
> to be the same base URL with different operations.
>
> For what it's worth, what I was trying to get discussion on was
> whether it made sense to make Dynamic Registration look like the rest
> of OAuth with separate endpoints, or not.
>
> -- Justin
>
>
>     On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer      > wrote:
>
>         I am very confused, and I need someone to explain to me what I
>         am missing. Why won't it work to just pick one? What are
>         people "already stuck with" that this would affect? It's not
>         like we're trying to unseat a well-established protocol with a
>         wide installation base here.
>
>         How will giving people the choice between:
>
>             /oauth/register?operation=client_register
>             /oauth/register?operation=client_update
>             /oauth/register?operation=rotate_secret
>
>
>         and:
>
>             /oauth/client_register
>             /oauth/client_update
>             /oauth/rotate_secret
>
>
>         help multitenancy? How does it even affect that use case?
>         Consider that the base URL for all of these is completely up
>         to the host environment (nothing is bound to the root URL).
>         Consider that clients still have to know what the URL (or
>         URLs) are, in either case. Consider that clients still need to
>         know how to manage all the parameters and responses.
>
>         If anything, keeping it the way that it is with a single URL
>         could be argued to help multitenancy because setting up
>         routing to multiple URL endpoints can sometimes be problematic
>         in hosted environments. However, OAuth already defines a bunch
>         of endpoints, and we have to define at least one more with
>         this extension, so I'm not convinced that having three with
>         specific functions is really any different from having one
>         with three functions from a development, deployment, and
>         implementation perspective. I can tell you from experience
>         that in our own server code, the difference is trivial. (And
>         from OAuth1 experience, you can always have a query parameter
>         as part of your endpoint URL if you need to. You might hate
>         yourself for doing it that way, but nothing says your base URL
>         can't already have parameters on it. A client just needs to
>         know how to appropriately tack its parameters onto an existing
>         URL, and any HTTP client worth its salt will know how to
>         augment a query parameter set with new items.)
>
>         The *real* difference between the two approaches is a
>         philosophical design one. The former overloads one URL with
>         multiple functions switched by a flag, the latter uses the URL
>         itself as an implicit flag. Under the hood, these could (and
>         in many cases will) be all served by the same chunks of code.
>         The only difference is how this switch in functionality is
>         presented.
>
>
>         With that said, can somebody please explain to me how allowing
>         *both* of these as options simultaneously (what I understand
>         Tony to be suggesting) is a good idea, or how multitenancy
>         even comes into play? Because I am completely not seeing how
>         these are related.
>
>         Thanks,
>         -- Justin
>
>
>
>         On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>
>             It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.
>
>              
>
>             -----Original Message-----
>
>             From: Justin Richer [mailto:jricher@mitre.org] 
>
>             Sent: Wednesday, January 23, 2013 9:27 AM
>
>             To: Anthony Nadalin
>
>             Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org 
>
>             Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>
>              
>
>             I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?
>
>              
>
>             You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.
>
>              
>
>              
>
>             -- Justin
>
>              
>
>              
>
>              
>
>             On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>
>                 Registration has to work in a multi-tenant environment  so flexibility 
>
>                 is needed
>
>                  
>
>                 -----Original Message-----
>
>                 From: Justin Richer [mailto:jricher@mitre.org]
>
>                 Sent: Wednesday, January 23, 2013 9:18 AM
>
>                 To: Anthony Nadalin
>
>                 Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org 
>
>                 Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>
>                  
>
>                 Because then nobody would know how to actually use the thing.
>
>                  
>
>                 In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
>
>                  
>
>                 -- Justin
>
>                  
>
>                 On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>
>                     Why not just have a physical and logical endpoint options
>
>                      
>
>                     -----Original Message-----
>
>                     From: oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On 
>
>                     Behalf Of Justin Richer
>
>                     Sent: Wednesday, January 23, 2013 7:47 AM
>
>                     To: Nat Sakimura
>
>                     Cc: Shiu Fun Poon; oauth@ietf.org 
>
>                     Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>
>                      
>
>                     Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.
>
>                      
>
>                     I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?
>
>                      
>
>                     -- Justin
>
>                      
>
>                      
>
>                     On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>
>                         "Action" goes against REST principle.
>
>                         I do not think it is a good idea.
>
>                          
>
>                         =nat via iPhone
>
>                          
>
>                         Jan 23, 2013 4:00、Justin Richer   のメッセージ:
>
>                          
>
>                             (CC'ing the working group)
>
>                              
>
>                             I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>
>                              
>
>                             Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>
>                              
>
>                              -- Justin
>
>                              
>
>                             On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>
>                                 Justin,
>
>                                  
>
>                                 This spec is looking good..
>
>                                  
>
>                                 One thing I would like to recommend is to add "action"/"operation" 
>
>                                 to the request.  (and potentially add client_id and client_secret)
>
>                                  
>
>                                 So the request will be like :
>
>                                 token                                             REQUIRED
>
>                                 operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>
>                                 resource_id                                    OPTIONAL
>
>                                 client_id                                         OPTIONAL
>
>                                 client_secret                                   OPTIONAL
>
>                                  
>
>                                 And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>
>                                  
>
>                                 Please consider.
>
>                                  
>
>                                 ShiuFun
>
>                             _______________________________________________
>
>                             OAuth mailing list
>
>                             OAuth@ietf.org 
>
>                             https://www.ietf.org/mailman/listinfo/oauth
>
>                     _______________________________________________
>
>                     OAuth mailing list
>
>                     OAuth@ietf.org 
>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>                      
>
>                      
>
>                      
>
>                  
>
>              
>
>              
>


--------------070606040402050604080603
Content-Type: text/html; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit


  
    
  
  
    I completely agree that OAuth is not RESTful in any meaningful sense
    of the term (and have stated so several times in this thread). I'm
    not at all against using query parameters to change behaviors.
    That's why they're there. But I'll point out that the examples that
    you give are still *doing* the same thing qualitatively (returning a
    token, in this instance), even though the mechanisms for doing so
    are a bit different. They're still basically the same "action", and
    if there were a protocol-wide "operation=" parameter as Shiu Fun
    Poon is suggesting, they would all have the same value for it. The
    client registration endpoint is different, because even though all
    the actions are *about* client registration, they're different
    actions. This is the whole purpose of the "operation=" parameter in
    the first place. That's the reason that I brought up this idea of
    defining them as separate endpoints. 

    

    Regardless, the group seems about even split on one mode versus the
    other. As such, I'm inclined to leave the "operation=" parameter in
    place on the registration endpoint even though I don't prefer it.

    

    I still am very strongly against the idea of defining a
    protocol-wide "operation=" parameter for switching between all
    endpoints, even if it were possible to do such a thing.

    

     -- Justin

    

    
On 01/30/2013 04:51 PM, Mike Jones
      wrote:

    

    

      
      
      
      

        
I’ll
            note that the OAuth token endpoint changes behaviors
            depending upon the grant_type and whether code or
            refresh_token parameters are present.  The first case is
            described at 
              http://tools.ietf.org/html/rfc6749#section-4.1.3.  The
            second case is described at
            http://tools.ietf.org/html/rfc6749#section-6.

        
 

        
There
            are already a bunch of ways in which OAuth is not RESTful in
            a strict sense of the term.  It doesn’t seem to be a problem
            in practice.

        
 

        
                                                               
            -- Mike

        
 

        

          

            
From:
                oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                On Behalf Of Anthony Nadalin

                Sent: Wednesday, January 30, 2013 1:38 PM

                To: Justin Richer; Shiu Fun Poon

                Cc: oauth@ietf.org

                Subject: Re: [OAUTH-WG] Concerning OAuth
                introspection

          

        

        
 

        
I
            would not say that this is incompatible with OAUTH at all ,
            as OAUTH has a physical and logical endpoints. We had to
            live through the Web Service endpoint nightmare were we had
            to have separate services, nuts

        
 

        

          

            
From:
                Justin Richer [mailto:jricher@mitre.org]
                

                Sent: Wednesday, January 30, 2013 7:20 AM

                To: Shiu Fun Poon

                Cc: Anthony Nadalin; Nat Sakimura; oauth@ietf.org

                Subject: Re: [OAUTH-WG] Concerning OAuth
                introspection

          

        

        
 

        
 

        

          

            

              

                

                  
Hi..
                    Tony.. You are able to present this better than I
                    do.
                    

                

                
Justin,
                  

              

              
Currently
                as it is, the spec is unflexible.   So when I send a
                request to an endpoint, the endpoint will need to have
                information like /revoke, /introspection, and others.  I
                can imagine the documented usage of this will a pages
                long just to describe all the endpoint that is needed to
                support an application.  (so far, /authz, /token,
                /introspection, /revoke, /.....), and this will be
                painful in the multi-tenant environment.

                

                So why not allow the flexibility of using one endpoint
                /token (example only), and make the caller to tell you
                want the caller wants ?  It can be an optional field,
                and a hint to the authorization/token endpoint on what
                you want to do.
                

            

          

        

        
This is
          incompatible with OAuth as it stands today, which defines the
          auth endpoint and token endpoint as logically separate, and
          therefore there is not a parameter defined that would allow
          for such functionality switching.

          

          That said, an *installation* could implement it this way if
          they wanted to, they'd just have to document the endpoints
          like this:

          

          token endpoint: /oauth?op=token

          auth endpoint: /oauth?op=auth

          introspection endpoint: /oauth?op=introspect

          revocation endpoint: /oauth?op=revoke

          

          etc. The key difference here is that the "op=" parameter is
          *system specific* and is *not* part of the spec itself. And I
          think that's a good design to continue to follow.
          

          

          Right now, the registration endpoint is the only one that
          defines an "operation" parameter, and I was positing the
          question of defining it in terms of three different endpoints
          instead. Most of the time, these endpoints will have different
          URLs, as outlined below, but specific instances could use some
          kind of "operation" parameter if they wanted to.

          

          Defining it as one endpoint with a switch parameter actually
          decreses flexibility quite a lot, especially if you're talking
          about dispatching to different kinds of functionality all
          together, which is the use case you brought up. There are some
          places where that could make sense, and the definition of
          different endpoints allows you to do that in specific
          instances of a system without breaking the assumptions of
          clients.

          

          What Tony was talking about was allowing something to be
          either three different URLs *or* using a spec-defined
          "operation" parameter. That suggestion is completely nuts, in
          my opinion.

          

          

        

          

            

              
And it does not violate the rest/json
                guideline.   

            

          

        

        
Yes it
          absolutely does. The REST principle is that a URL represents
          one entity and the HTTP verbs represent different actions on
          that entity. Using a query parameter to switch is very much
          directly against REST guidelines. Not to say that OAuth is
          RESTful -- it's not, by a long shot. But it does follow many
          rest-like principles, the endpoint definitions being one of
          them.

          

          

        

          

            

              


                Even with oauth specification, it provides a hint on
                what is to come, e.g. grant_type refresh_token,
                indicates you want to exchange a valid refresh_token to
                an access_token.  There is something in the payload
                which tell you what you need to do.  In this case, there
                is nothing in the payload which indicate what is
                expected.

            

          

        

        
These are
          functionality switches on the same kind of action, not
          dispatch to different actions. you still do
          authentication/authorization at the auth endpoint, you still
          get tokens from the token endpoint, etc.

          

          

        

          

            

              
 

            

            

              
If you standard that now (on the
                optional field), there is a chance that companies can
                implement this according to what will work best for
                them, and we actually have a chance to get this working
                between different products.
                

            

          

        

        
It's too late
          to standardize that field in the core, which is really where
          it would belong. But as it stands today, an OAuth client is
          going to need to be able to handle separate URLs for each
          defined endpoint already, so it can already handle the case
          where it happens to be the same base URL with different
          operations.

          

          For what it's worth, what I was trying to get discussion on
          was whether it made sense to make Dynamic Registration look
          like the rest of OAuth with separate endpoints, or not.

          

           -- Justin

          

          

          

        

          

            
 

            

              
On Wed, Jan 23, 2013 at 1:05 PM,
                Justin Richer <jricher@mitre.org>
                wrote:

              

                

                  
I am
                    very confused, and I need someone to explain to me
                    what I am missing. Why won't it work to just pick
                    one? What are people "already stuck with" that this
                    would affect? It's not like we're trying to unseat a
                    well-established protocol with a wide installation
                    base here.

                    

                    How will giving people the choice between:

                  

                    
/oauth/register?operation=client_register

                      /oauth/register?operation=client_update

                      /oauth/register?operation=rotate_secret

                  

                  


                    and:

                  

                    
/oauth/client_register

                      /oauth/client_update

                      /oauth/rotate_secret

                  

                  


                    help multitenancy? How does it even affect that use
                    case? Consider that the base URL for all of these is
                    completely up to the host environment (nothing is
                    bound to the root URL). Consider that clients still
                    have to know what the URL (or URLs) are, in either
                    case. Consider that clients still need to know how
                    to manage all the parameters and responses.

                    

                    If anything, keeping it the way that it is with a
                    single URL could be argued to help multitenancy
                    because setting up routing to multiple URL endpoints
                    can sometimes be problematic in hosted environments.
                    However, OAuth already defines a bunch of endpoints,
                    and we have to define at least one more with this
                    extension, so I'm not convinced that having three
                    with specific functions is really any different from
                    having one with three functions from a development,
                    deployment, and implementation perspective. I can
                    tell you from experience that in our own server
                    code, the difference is trivial. (And from OAuth1
                    experience, you can always have a query parameter as
                    part of your endpoint URL if you need to. You might
                    hate yourself for doing it that way, but nothing
                    says your base URL can't already have parameters on
                    it. A client just needs to know how to appropriately
                    tack its parameters onto an existing URL, and any
                    HTTP client worth its salt will know how to augment
                    a query parameter set with new items.)

                    

                    The *real* difference between the two approaches is
                    a philosophical design one. The former overloads one
                    URL with multiple functions switched by a flag, the
                    latter uses the URL itself as an implicit flag.
                    Under the hood, these could (and in many cases will)
                    be all served by the same chunks of code. The only
                    difference is how this switch in functionality is
                    presented.

                    

                    

                    With that said, can somebody please explain to me
                    how allowing *both* of these as options
                    simultaneously (what I understand Tony to be
                    suggesting) is a good idea, or how multitenancy even
                    comes into play? Because I am completely not seeing
                    how these are related.

                    

                    Thanks,

                     -- Justin 

                  

                    

                      


                        

                        

                      

                        
On 01/23/2013 12:46 PM,
                          Anthony Nadalin wrote:

                      

                      

                        
It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.

                        
 

                        
-----Original Message-----

                        
From: Justin Richer [mailto:jricher@mitre.org] 

                        
Sent: Wednesday, January 23, 2013 9:27 AM

                        
To: Anthony Nadalin

                        
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

                        
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

                        
 

                        
I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?

                        
 

                        
You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.

                        
 

                        
 

                        
-- Justin

                        
 

                        
 

                        
 

                        
On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

                        

                          
Registration has to work in a multi-tenant environment  so flexibility 

                          
is needed

                          
 

                          
-----Original Message-----

                          
From: Justin Richer [mailto:jricher@mitre.org]

                          
Sent: Wednesday, January 23, 2013 9:18 AM

                          
To: Anthony Nadalin

                          
Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org

                          
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

                          
 

                          
Because then nobody would know how to actually use the thing.

                          
 

                          
In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.

                          
 

                          
-- Justin

                          
 

                          
On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

                          

                            
Why not just have a physical and logical endpoint options

                            
 

                            
-----Original Message-----

                            
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 

                            
Behalf Of Justin Richer

                            
Sent: Wednesday, January 23, 2013 7:47 AM

                            
To: Nat Sakimura

                            
Cc: Shiu Fun Poon; oauth@ietf.org

                            
Subject: Re: [OAUTH-WG] Concerning OAuth introspection

                            
 

                            
Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.

                            
 

                            
I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?

                            
 

                            
-- Justin

                            
 

                            
 

                            
On 01/22/2013 08:05 PM, Nat Sakimura wrote:

                            

                              
"Action" goes against REST principle.

                              
I do not think it is a good idea.

                              
 

                              
=nat via iPhone

                              
 

                              
Jan 23, 2013 4:00、Justin Richer <jricher@mitre.org> のメッセージ:

                              
 

                              

                                
(CC'ing the working group)

                                
 

                                
I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

                                
 

                                
Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

                                
 

                                
 -- Justin

                                
 

                                
On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

                                

                                  
Justin,

                                  
 

                                  
This spec is looking good..

                                  
 

                                  
One thing I would like to recommend is to add "action"/"operation" 

                                  
to the request.  (and potentially add client_id and client_secret)

                                  
 

                                  
So the request will be like :

                                  
token                                             REQUIRED

                                  
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...

                                  
resource_id                                    OPTIONAL

                                  
client_id                                         OPTIONAL

                                  
client_secret                                   OPTIONAL

                                  
 

                                  
And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

                                  
 

                                  
Please consider.

                                  
 

                                  
ShiuFun

                                

                                
_______________________________________________

                                
OAuth mailing list

                                
OAuth@ietf.org

                                
https://www.ietf.org/mailman/listinfo/oauth

                              

                            

                            
_______________________________________________

                            
OAuth mailing list

                            
OAuth@ietf.org

                            
https://www.ietf.org/mailman/listinfo/oauth

                            
 

                            
 

                            
 

                          

                          
 

                        

                        
 

                        
 

                      

                      
 

                    

                  

                

              

            

            
 

          

        

        
 

      

    

    

  


--------------070606040402050604080603--

From sberyozkin@gmail.com  Wed Jan 30 14:24:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706921F87A3 for ; Wed, 30 Jan 2013 14:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.77
X-Spam-Level: 
X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=-1.627,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnhGWk3RCbkp for ; Wed, 30 Jan 2013 14:24:11 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06421F8795 for ; Wed, 30 Jan 2013 14:24:10 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id x8so1658717wey.34 for ; Wed, 30 Jan 2013 14:24:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p9zbut1/LQmAYUWJjII5fx/F5HTq0k8ed0JQZXmvgYw=; b=bptVKVLWib37LudmxcRHUNPSIKWLQNlfqHime5sp8QnnRLFjzHZzgoXR5yu40VjNpi 77UaOdVwsW6jhKFlqf6cYmsXh7WQPfg+ZPZNzBqJgQlFn1DjIBKHJ1i+zv5giplX96j0 2iyhvSirfqYzhsiaaGMHzBKn7+0Lq9Ze+VhQqSPzj9AFA0b3vCqSpD+38ZhkvbKyXYsw Wfww9gbsT/DdcJuzyyTg0yaHOb49uXdxv6WCjlaIj7q5RM9S1JuXpwTgpi4E1+kGNDdN pMlgo3pMyGZkCXvWki11z9R9MeCW+yqVTkaFyJedg1hsK9ASTu2cAiEuC1HgmaltXxqT 3Qiw==
X-Received: by 10.194.108.229 with SMTP id hn5mr11900799wjb.8.1359584649867; Wed, 30 Jan 2013 14:24:09 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id gz3sm11853227wib.2.2013.01.30.14.24.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 14:24:08 -0800 (PST)
Message-ID: <51099D86.8070708@gmail.com>
Date: Wed, 30 Jan 2013 22:24:06 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com> <510999D7.3000805@mitre.org>
In-Reply-To: <510999D7.3000805@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:24:12 -0000

On 30/01/13 22:08, Justin Richer wrote:
> I completely agree that OAuth is not RESTful in any meaningful sense of
> the term (and have stated so several times in this thread).

That is fine, this is not the issue, OAuth2 itself does not have to be 
'pure' but having individual bits from which the whole ecosystem is 
build upon offering a RESTful interface when possible is very important 
IMHO and in this case it is possible.

What if the introspection endpoint would also offer an ability to search 
? Some query parameters will mean 'action', some - something else, not 
cool really

Anyway, too much noise I guess from someone who is not even a member of 
the working group, sorry :-)

Thanks, Sergey

> I'm not at
> all against using query parameters to change behaviors. That's why
> they're there. But I'll point out that the examples that you give are
> still *doing* the same thing qualitatively (returning a token, in this
> instance), even though the mechanisms for doing so are a bit different.
> They're still basically the same "action", and if there were a
> protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
> they would all have the same value for it. The client registration
> endpoint is different, because even though all the actions are *about*
> client registration, they're different actions. This is the whole
> purpose of the "operation=" parameter in the first place. That's the
> reason that I brought up this idea of defining them as separate endpoints.
>
> Regardless, the group seems about even split on one mode versus the
> other. As such, I'm inclined to leave the "operation=" parameter in
> place on the registration endpoint even though I don't prefer it.
>
> I still am very strongly against the idea of defining a protocol-wide
> "operation=" parameter for switching between all endpoints, even if it
> were possible to do such a thing.
>
> -- Justin
>
> On 01/30/2013 04:51 PM, Mike Jones wrote:
>>
>> Ill note that the OAuth token endpoint changes behaviors depending
>> upon the grant_type and whether code or refresh_token parameters are
>> present. The first case is described at
>> http://tools.ietf.org/html/rfc6749#section-4.1.3. The second case is
>> described at http://tools.ietf.org/html/rfc6749#section-6.
>>
>> There are already a bunch of ways in which OAuth is not RESTful in a
>> strict sense of the term. It doesnt seem to be a problem in practice.
>>
>> -- Mike
>>
>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>> Behalf Of *Anthony Nadalin
>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>> *To:* Justin Richer; Shiu Fun Poon
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>
>> I would not say that this is incompatible with OAUTH at all , as OAUTH
>> has a physical and logical endpoints. We had to live through the Web
>> Service endpoint nightmare were we had to have separate services, nuts
>>
>> *From:*Justin Richer [mailto:jricher@mitre.org]
>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>> *To:* Shiu Fun Poon
>> *Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
>> 
>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>
>>     Hi.. Tony.. You are able to present this better than I do.
>>
>>     Justin,
>>
>>     Currently as it is, the spec is unflexible. So when I send a
>>     request to an endpoint, the endpoint will need to have information
>>     like /revoke, /introspection, and others. I can imagine the
>>     documented usage of this will a pages long just to describe all
>>     the endpoint that is needed to support an application. (so far,
>>     /authz, /token, /introspection, /revoke, /.....), and this will be
>>     painful in the multi-tenant environment.
>>
>>     So why not allow the flexibility of using one endpoint /token
>>     (example only), and make the caller to tell you want the caller
>>     wants ? It can be an optional field, and a hint to the
>>     authorization/token endpoint on what you want to do.
>>
>> This is incompatible with OAuth as it stands today, which defines the
>> auth endpoint and token endpoint as logically separate, and therefore
>> there is not a parameter defined that would allow for such
>> functionality switching.
>>
>> That said, an *installation* could implement it this way if they
>> wanted to, they'd just have to document the endpoints like this:
>>
>> token endpoint: /oauth?op=token
>> auth endpoint: /oauth?op=auth
>> introspection endpoint: /oauth?op=introspect
>> revocation endpoint: /oauth?op=revoke
>>
>> etc. The key difference here is that the "op=" parameter is *system
>> specific* and is *not* part of the spec itself. And I think that's a
>> good design to continue to follow.
>>
>> Right now, the registration endpoint is the only one that defines an
>> "operation" parameter, and I was positing the question of defining it
>> in terms of three different endpoints instead. Most of the time, these
>> endpoints will have different URLs, as outlined below, but specific
>> instances could use some kind of "operation" parameter if they wanted to.
>>
>> Defining it as one endpoint with a switch parameter actually decreses
>> flexibility quite a lot, especially if you're talking about
>> dispatching to different kinds of functionality all together, which is
>> the use case you brought up. There are some places where that could
>> make sense, and the definition of different endpoints allows you to do
>> that in specific instances of a system without breaking the
>> assumptions of clients.
>>
>> What Tony was talking about was allowing something to be either three
>> different URLs *or* using a spec-defined "operation" parameter. That
>> suggestion is completely nuts, in my opinion.
>>
>>     And it does not violate the rest/json guideline.
>>
>> Yes it absolutely does. The REST principle is that a URL represents
>> one entity and the HTTP verbs represent different actions on that
>> entity. Using a query parameter to switch is very much directly
>> against REST guidelines. Not to say that OAuth is RESTful -- it's not,
>> by a long shot. But it does follow many rest-like principles, the
>> endpoint definitions being one of them.
>>
>>
>>     Even with oauth specification, it provides a hint on what is to
>>     come, e.g. grant_type refresh_token, indicates you want to
>>     exchange a valid refresh_token to an access_token. There is
>>     something in the payload which tell you what you need to do. In
>>     this case, there is nothing in the payload which indicate what is
>>     expected.
>>
>> These are functionality switches on the same kind of action, not
>> dispatch to different actions. you still do
>> authentication/authorization at the auth endpoint, you still get
>> tokens from the token endpoint, etc.
>>
>>     If you standard that now (on the optional field), there is a
>>     chance that companies can implement this according to what will
>>     work best for them, and we actually have a chance to get this
>>     working between different products.
>>
>> It's too late to standardize that field in the core, which is really
>> where it would belong. But as it stands today, an OAuth client is
>> going to need to be able to handle separate URLs for each defined
>> endpoint already, so it can already handle the case where it happens
>> to be the same base URL with different operations.
>>
>> For what it's worth, what I was trying to get discussion on was
>> whether it made sense to make Dynamic Registration look like the rest
>> of OAuth with separate endpoints, or not.
>>
>> -- Justin
>>
>>
>>     On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer >     > wrote:
>>
>>         I am very confused, and I need someone to explain to me what I
>>         am missing. Why won't it work to just pick one? What are
>>         people "already stuck with" that this would affect? It's not
>>         like we're trying to unseat a well-established protocol with a
>>         wide installation base here.
>>
>>         How will giving people the choice between:
>>
>>             /oauth/register?operation=client_register
>>             /oauth/register?operation=client_update
>>             /oauth/register?operation=rotate_secret
>>
>>
>>         and:
>>
>>             /oauth/client_register
>>             /oauth/client_update
>>             /oauth/rotate_secret
>>
>>
>>         help multitenancy? How does it even affect that use case?
>>         Consider that the base URL for all of these is completely up
>>         to the host environment (nothing is bound to the root URL).
>>         Consider that clients still have to know what the URL (or
>>         URLs) are, in either case. Consider that clients still need to
>>         know how to manage all the parameters and responses.
>>
>>         If anything, keeping it the way that it is with a single URL
>>         could be argued to help multitenancy because setting up
>>         routing to multiple URL endpoints can sometimes be problematic
>>         in hosted environments. However, OAuth already defines a bunch
>>         of endpoints, and we have to define at least one more with
>>         this extension, so I'm not convinced that having three with
>>         specific functions is really any different from having one
>>         with three functions from a development, deployment, and
>>         implementation perspective. I can tell you from experience
>>         that in our own server code, the difference is trivial. (And
>>         from OAuth1 experience, you can always have a query parameter
>>         as part of your endpoint URL if you need to. You might hate
>>         yourself for doing it that way, but nothing says your base URL
>>         can't already have parameters on it. A client just needs to
>>         know how to appropriately tack its parameters onto an existing
>>         URL, and any HTTP client worth its salt will know how to
>>         augment a query parameter set with new items.)
>>
>>         The *real* difference between the two approaches is a
>>         philosophical design one. The former overloads one URL with
>>         multiple functions switched by a flag, the latter uses the URL
>>         itself as an implicit flag. Under the hood, these could (and
>>         in many cases will) be all served by the same chunks of code.
>>         The only difference is how this switch in functionality is
>>         presented.
>>
>>
>>         With that said, can somebody please explain to me how allowing
>>         *both* of these as options simultaneously (what I understand
>>         Tony to be suggesting) is a good idea, or how multitenancy
>>         even comes into play? Because I am completely not seeing how
>>         these are related.
>>
>>         Thanks,
>>         -- Justin
>>
>>
>>
>>         On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>
>>             It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.
>>
>>
>>
>>             -----Original Message-----
>>
>>             From: Justin Richer [mailto:jricher@mitre.org]
>>
>>             Sent: Wednesday, January 23, 2013 9:27 AM
>>
>>             To: Anthony Nadalin
>>
>>             Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org  
>>
>>             Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>
>>
>>
>>             I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?
>>
>>
>>
>>             You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.
>>
>>
>>
>>
>>
>>             -- Justin
>>
>>
>>
>>
>>
>>
>>
>>             On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>
>>                 Registration has to work in a multi-tenant environment    so flexibility
>>
>>                 is needed
>>
>>
>>
>>                 -----Original Message-----
>>
>>                 From: Justin Richer [mailto:jricher@mitre.org]
>>
>>                 Sent: Wednesday, January 23, 2013 9:18 AM
>>
>>                 To: Anthony Nadalin
>>
>>                 Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org  
>>
>>                 Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>
>>
>>
>>                 Because then nobody would know how to actually use the thing.
>>
>>
>>
>>                 In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
>>
>>
>>
>>                 -- Justin
>>
>>
>>
>>                 On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>
>>                     Why not just have a physical and logical endpoint options
>>
>>
>>
>>                     -----Original Message-----
>>
>>                     From:oauth-bounces@ietf.org    [mailto:oauth-bounces@ietf.org] On
>>
>>                     Behalf Of Justin Richer
>>
>>                     Sent: Wednesday, January 23, 2013 7:47 AM
>>
>>                     To: Nat Sakimura
>>
>>                     Cc: Shiu Fun Poon;oauth@ietf.org  
>>
>>                     Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>
>>
>>
>>                     Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.
>>
>>
>>
>>                     I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?
>>
>>
>>
>>                     -- Justin
>>
>>
>>
>>
>>
>>                     On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>
>>                         "Action" goes against REST principle.
>>
>>                         I do not think it is a good idea.
>>
>>
>>
>>                         =nat via iPhone
>>
>>
>>
>>                         Jan 23, 2013 4:00Justin Richer    :
>>
>>
>>
>>                             (CC'ing the working group)
>>
>>
>>
>>                             I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>
>>
>>
>>                             Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>
>>
>>
>>                               -- Justin
>>
>>
>>
>>                             On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>
>>                                 Justin,
>>
>>
>>
>>                                 This spec is looking good..
>>
>>
>>
>>                                 One thing I would like to recommend is to add "action"/"operation"
>>
>>                                 to the request.    (and potentially add client_id and client_secret)
>>
>>
>>
>>                                 So the request will be like :
>>
>>                                 token                                                                                          REQUIRED
>>
>>                                 operation (wording to be determine)    OPTIONAL inquire (default) | revoke ...
>>
>>                                 resource_id                                                                        OPTIONAL
>>
>>                                 client_id                                                                                  OPTIONAL
>>
>>                                 client_secret                                                                      OPTIONAL
>>
>>
>>
>>                                 And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>
>>
>>
>>                                 Please consider.
>>
>>
>>
>>                                 ShiuFun
>>
>>                             _______________________________________________
>>
>>                             OAuth mailing list
>>
>>                             OAuth@ietf.org  
>>
>>                             https://www.ietf.org/mailman/listinfo/oauth
>>
>>                     _______________________________________________
>>
>>                     OAuth mailing 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 lainhart@us.ibm.com  Wed Jan 30 14:27:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F85F21F844F for ; Wed, 30 Jan 2013 14:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.437
X-Spam-Level: 
X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO89MU3mR6-P for ; Wed, 30 Jan 2013 14:27:30 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8342321F8442 for ; Wed, 30 Jan 2013 14:27:30 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 30 Jan 2013 17:27:29 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 30 Jan 2013 17:27:27 -0500
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id EFE3C6E803C for ; Wed, 30 Jan 2013 17:27:25 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0UMRRZR304640 for ; Wed, 30 Jan 2013 17:27:27 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0UMRIYp009011 for ; Wed, 30 Jan 2013 17:27:18 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0UMRDHF008801 for ; Wed, 30 Jan 2013 17:27:14 -0500
To: "IETF oauth WG" 
MIME-Version: 1.0
X-KeepSent: 3031393A:750F4AB2-85257B03:007AD84B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Wed, 30 Jan 2013 17:27:11 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/30/2013 17:27:13, Serialize complete at 01/30/2013 17:27:13
Content-Type: multipart/alternative; boundary="=_alternative 007B56E785257B03_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13013022-7182-0000-0000-000004D28B5E
Subject: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:27:31 -0000

This is a multipart message in MIME format.
--=_alternative 007B56E785257B03_=
Content-Type: text/plain; charset="US-ASCII"

That the scope syntax in draft-richer-oauth-introspection-01 is different 
than RFC 6749 Section 3.3, as in:


   "scope": ["read", "write", "dolphin"],

vs.

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

Should introspection-01 follow the 6749 syntax for scopes?




--=_alternative 007B56E785257B03_=
Content-Type: text/html; charset="US-ASCII"

That the scope syntax in draft-richer-oauth-introspection-01
is different than RFC 6749 Section 3.3, as in:





   "scope":
["read", "write", "dolphin"],



vs.



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

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



Should introspection-01 follow the 6749
syntax for scopes?












--=_alternative 007B56E785257B03_=--


From jricher@mitre.org  Wed Jan 30 14:28:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46CE21F87CD for ; Wed, 30 Jan 2013 14:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Level: 
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqKLeEdR2McN for ; Wed, 30 Jan 2013 14:28:07 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 99E0C21F87A4 for ; Wed, 30 Jan 2013 14:28:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1F1EE53112D4; Wed, 30 Jan 2013 17:27:53 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0F70353112D1; Wed, 30 Jan 2013 17:27:53 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 17:27:52 -0500
Message-ID: <51099E4C.9030403@mitre.org>
Date: Wed, 30 Jan 2013 17:27:24 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Sergey Beryozkin 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com> <510999D7.3000805@mitre.org> <51099D86.8070708@gmail.com>
In-Reply-To: <51099D86.8070708@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:28:30 -0000

On 01/30/2013 05:24 PM, Sergey Beryozkin wrote:
> On 30/01/13 22:08, Justin Richer wrote:
>> I completely agree that OAuth is not RESTful in any meaningful sense of
>> the term (and have stated so several times in this thread).
>
> That is fine, this is not the issue, OAuth2 itself does not have to be 
> 'pure' but having individual bits from which the whole ecosystem is 
> build upon offering a RESTful interface when possible is very 
> important IMHO and in this case it is possible.
>
> What if the introspection endpoint would also offer an ability to 
> search ? Some query parameters will mean 'action', some - something 
> else, not cool really

If a service were to offer other functionalities from the same URL as 
the token endpoint, and those other functionalities were switched by 
some kind of parameter, then this is well outside the definition of the 
introspection endpoint.

>
> Anyway, too much noise I guess from someone who is not even a member 
> of the working group, sorry :-)

In the IETF, if you post to the list, you're in the working group. 
Welcome. :)

  -- Justin


>
> Thanks, Sergey
>
>> I'm not at
>> all against using query parameters to change behaviors. That's why
>> they're there. But I'll point out that the examples that you give are
>> still *doing* the same thing qualitatively (returning a token, in this
>> instance), even though the mechanisms for doing so are a bit different.
>> They're still basically the same "action", and if there were a
>> protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
>> they would all have the same value for it. The client registration
>> endpoint is different, because even though all the actions are *about*
>> client registration, they're different actions. This is the whole
>> purpose of the "operation=" parameter in the first place. That's the
>> reason that I brought up this idea of defining them as separate 
>> endpoints.
>>
>> Regardless, the group seems about even split on one mode versus the
>> other. As such, I'm inclined to leave the "operation=" parameter in
>> place on the registration endpoint even though I don't prefer it.
>>
>> I still am very strongly against the idea of defining a protocol-wide
>> "operation=" parameter for switching between all endpoints, even if it
>> were possible to do such a thing.
>>
>> -- Justin
>>
>> On 01/30/2013 04:51 PM, Mike Jones wrote:
>>>
>>> Ill note that the OAuth token endpoint changes behaviors depending
>>> upon the grant_type and whether code or refresh_token parameters are
>>> present. The first case is described at
>>> http://tools.ietf.org/html/rfc6749#section-4.1.3. The second case is
>>> described at http://tools.ietf.org/html/rfc6749#section-6.
>>>
>>> There are already a bunch of ways in which OAuth is not RESTful in a
>>> strict sense of the term. It doesnt seem to be a problem in practice.
>>>
>>> -- Mike
>>>
>>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>>> Behalf Of *Anthony Nadalin
>>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>>> *To:* Justin Richer; Shiu Fun Poon
>>> *Cc:* oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>> I would not say that this is incompatible with OAUTH at all , as OAUTH
>>> has a physical and logical endpoints. We had to live through the Web
>>> Service endpoint nightmare were we had to have separate services, nuts
>>>
>>> *From:*Justin Richer [mailto:jricher@mitre.org]
>>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>>> *To:* Shiu Fun Poon
>>> *Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
>>> 
>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>>     Hi.. Tony.. You are able to present this better than I do.
>>>
>>>     Justin,
>>>
>>>     Currently as it is, the spec is unflexible. So when I send a
>>>     request to an endpoint, the endpoint will need to have information
>>>     like /revoke, /introspection, and others. I can imagine the
>>>     documented usage of this will a pages long just to describe all
>>>     the endpoint that is needed to support an application. (so far,
>>>     /authz, /token, /introspection, /revoke, /.....), and this will be
>>>     painful in the multi-tenant environment.
>>>
>>>     So why not allow the flexibility of using one endpoint /token
>>>     (example only), and make the caller to tell you want the caller
>>>     wants ? It can be an optional field, and a hint to the
>>>     authorization/token endpoint on what you want to do.
>>>
>>> This is incompatible with OAuth as it stands today, which defines the
>>> auth endpoint and token endpoint as logically separate, and therefore
>>> there is not a parameter defined that would allow for such
>>> functionality switching.
>>>
>>> That said, an *installation* could implement it this way if they
>>> wanted to, they'd just have to document the endpoints like this:
>>>
>>> token endpoint: /oauth?op=token
>>> auth endpoint: /oauth?op=auth
>>> introspection endpoint: /oauth?op=introspect
>>> revocation endpoint: /oauth?op=revoke
>>>
>>> etc. The key difference here is that the "op=" parameter is *system
>>> specific* and is *not* part of the spec itself. And I think that's a
>>> good design to continue to follow.
>>>
>>> Right now, the registration endpoint is the only one that defines an
>>> "operation" parameter, and I was positing the question of defining it
>>> in terms of three different endpoints instead. Most of the time, these
>>> endpoints will have different URLs, as outlined below, but specific
>>> instances could use some kind of "operation" parameter if they 
>>> wanted to.
>>>
>>> Defining it as one endpoint with a switch parameter actually decreses
>>> flexibility quite a lot, especially if you're talking about
>>> dispatching to different kinds of functionality all together, which is
>>> the use case you brought up. There are some places where that could
>>> make sense, and the definition of different endpoints allows you to do
>>> that in specific instances of a system without breaking the
>>> assumptions of clients.
>>>
>>> What Tony was talking about was allowing something to be either three
>>> different URLs *or* using a spec-defined "operation" parameter. That
>>> suggestion is completely nuts, in my opinion.
>>>
>>>     And it does not violate the rest/json guideline.
>>>
>>> Yes it absolutely does. The REST principle is that a URL represents
>>> one entity and the HTTP verbs represent different actions on that
>>> entity. Using a query parameter to switch is very much directly
>>> against REST guidelines. Not to say that OAuth is RESTful -- it's not,
>>> by a long shot. But it does follow many rest-like principles, the
>>> endpoint definitions being one of them.
>>>
>>>
>>>     Even with oauth specification, it provides a hint on what is to
>>>     come, e.g. grant_type refresh_token, indicates you want to
>>>     exchange a valid refresh_token to an access_token. There is
>>>     something in the payload which tell you what you need to do. In
>>>     this case, there is nothing in the payload which indicate what is
>>>     expected.
>>>
>>> These are functionality switches on the same kind of action, not
>>> dispatch to different actions. you still do
>>> authentication/authorization at the auth endpoint, you still get
>>> tokens from the token endpoint, etc.
>>>
>>>     If you standard that now (on the optional field), there is a
>>>     chance that companies can implement this according to what will
>>>     work best for them, and we actually have a chance to get this
>>>     working between different products.
>>>
>>> It's too late to standardize that field in the core, which is really
>>> where it would belong. But as it stands today, an OAuth client is
>>> going to need to be able to handle separate URLs for each defined
>>> endpoint already, so it can already handle the case where it happens
>>> to be the same base URL with different operations.
>>>
>>> For what it's worth, what I was trying to get discussion on was
>>> whether it made sense to make Dynamic Registration look like the rest
>>> of OAuth with separate endpoints, or not.
>>>
>>> -- Justin
>>>
>>>
>>>     On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer >>     > wrote:
>>>
>>>         I am very confused, and I need someone to explain to me what I
>>>         am missing. Why won't it work to just pick one? What are
>>>         people "already stuck with" that this would affect? It's not
>>>         like we're trying to unseat a well-established protocol with a
>>>         wide installation base here.
>>>
>>>         How will giving people the choice between:
>>>
>>>             /oauth/register?operation=client_register
>>>             /oauth/register?operation=client_update
>>>             /oauth/register?operation=rotate_secret
>>>
>>>
>>>         and:
>>>
>>>             /oauth/client_register
>>>             /oauth/client_update
>>>             /oauth/rotate_secret
>>>
>>>
>>>         help multitenancy? How does it even affect that use case?
>>>         Consider that the base URL for all of these is completely up
>>>         to the host environment (nothing is bound to the root URL).
>>>         Consider that clients still have to know what the URL (or
>>>         URLs) are, in either case. Consider that clients still need to
>>>         know how to manage all the parameters and responses.
>>>
>>>         If anything, keeping it the way that it is with a single URL
>>>         could be argued to help multitenancy because setting up
>>>         routing to multiple URL endpoints can sometimes be problematic
>>>         in hosted environments. However, OAuth already defines a bunch
>>>         of endpoints, and we have to define at least one more with
>>>         this extension, so I'm not convinced that having three with
>>>         specific functions is really any different from having one
>>>         with three functions from a development, deployment, and
>>>         implementation perspective. I can tell you from experience
>>>         that in our own server code, the difference is trivial. (And
>>>         from OAuth1 experience, you can always have a query parameter
>>>         as part of your endpoint URL if you need to. You might hate
>>>         yourself for doing it that way, but nothing says your base URL
>>>         can't already have parameters on it. A client just needs to
>>>         know how to appropriately tack its parameters onto an existing
>>>         URL, and any HTTP client worth its salt will know how to
>>>         augment a query parameter set with new items.)
>>>
>>>         The *real* difference between the two approaches is a
>>>         philosophical design one. The former overloads one URL with
>>>         multiple functions switched by a flag, the latter uses the URL
>>>         itself as an implicit flag. Under the hood, these could (and
>>>         in many cases will) be all served by the same chunks of code.
>>>         The only difference is how this switch in functionality is
>>>         presented.
>>>
>>>
>>>         With that said, can somebody please explain to me how allowing
>>>         *both* of these as options simultaneously (what I understand
>>>         Tony to be suggesting) is a good idea, or how multitenancy
>>>         even comes into play? Because I am completely not seeing how
>>>         these are related.
>>>
>>>         Thanks,
>>>         -- Justin
>>>
>>>
>>>
>>>         On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>
>>>             It will not work the way you have it, as people do 
>>> multi-tendency different and they are already stuck with the method 
>>> that they have chosen, so they need the flexability, to restrict 
>>> this is nuts as people won't use it.
>>>
>>>
>>>
>>>             -----Original Message-----
>>>
>>>             From: Justin Richer [mailto:jricher@mitre.org]
>>>
>>>             Sent: Wednesday, January 23, 2013 9:27 AM
>>>
>>>             To: Anthony Nadalin
>>>
>>>             Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org 
>>> 
>>>
>>>             Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>>
>>>
>>>             I completely disagree with this assessment. 
>>> Multi-tenancy will work just fine (or even better) if everyone uses 
>>> the same pattern. Telling someone "it might be three different urls 
>>> or it might be all one url with a parameter" is just asking for a 
>>> complete disaster. What does the flexibility of allowing two 
>>> approaches actually accomplish?
>>>
>>>
>>>
>>>             You can argue about the merits of either approach, but 
>>> having both as unspecified options for registration, which is meant 
>>> to help things get going in a cold-boot environment, is just plain 
>>> nuts.
>>>
>>>
>>>
>>>
>>>
>>>             -- Justin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>
>>>                 Registration has to work in a multi-tenant 
>>> environment    so flexibility
>>>
>>>                 is needed
>>>
>>>
>>>
>>>                 -----Original Message-----
>>>
>>>                 From: Justin Richer [mailto:jricher@mitre.org]
>>>
>>>                 Sent: Wednesday, January 23, 2013 9:18 AM
>>>
>>>                 To: Anthony Nadalin
>>>
>>>                 Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org  
>>> 
>>>
>>>                 Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>>
>>>
>>>                 Because then nobody would know how to actually use 
>>> the thing.
>>>
>>>
>>>
>>>                 In my opinion, this is a key place where this kind 
>>> of flexibility is a very bad thing. Registration needs to work one 
>>> fairly predictable way.
>>>
>>>
>>>
>>>                 -- Justin
>>>
>>>
>>>
>>>                 On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>
>>>                     Why not just have a physical and logical 
>>> endpoint options
>>>
>>>
>>>
>>>                     -----Original Message-----
>>>
>>>                     From:oauth-bounces@ietf.org 
>>>  [mailto:oauth-bounces@ietf.org] On
>>>
>>>                     Behalf Of Justin Richer
>>>
>>>                     Sent: Wednesday, January 23, 2013 7:47 AM
>>>
>>>                     To: Nat Sakimura
>>>
>>>                     Cc: Shiu Fun Poon;oauth@ietf.org 
>>> 
>>>
>>>                     Subject: Re: [OAUTH-WG] Concerning OAuth 
>>> introspection
>>>
>>>
>>>
>>>                     Which brings up an interesting question for the 
>>> Registration doc: right now, it's set up as a single endpoint with 
>>> three operations. We could instead define three endpoints for the 
>>> different operations.
>>>
>>>
>>>
>>>                     I've not been keen to make that deep of a 
>>> cutting change to it, but it would certainly be cleaner and more 
>>> RESTful API design. What do others think?
>>>
>>>
>>>
>>>                     -- Justin
>>>
>>>
>>>
>>>
>>>
>>>                     On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>
>>>                         "Action" goes against REST principle.
>>>
>>>                         I do not think it is a good idea.
>>>
>>>
>>>
>>>                         =nat via iPhone
>>>
>>>
>>>
>>>                         Jan 23, 2013 4:00Justin 
>>> Richer   :
>>>
>>>
>>>
>>>                             (CC'ing the working group)
>>>
>>>
>>>
>>>                             I'm not sure what the "action/operation" 
>>> flag would accomplish. The idea behind having different endpoints in 
>>> OAuth is that they each do different kinds of things. The only 
>>> "action/operation" that I had envisioned for the introspection 
>>> endpoint is introspection itself: "I have a token, what does it mean?"
>>>
>>>
>>>
>>>                             Note that client_id and client_secret 
>>> *can* already be used at this endpoint if the server supports that 
>>> as part of their client credentials setup. The examples use HTTP 
>>> Basic with client id and secret right now. Basically, the client can 
>>> authenticate however it wants, including any of the methods that 
>>> OAuth2 allows on the token endpoint. It could also authenticate with 
>>> an access token. At least, that's the intent of the introspection 
>>> draft -- if that's unclear, I'd be happy to accept suggested changes 
>>> to clarify this text.
>>>
>>>
>>>
>>>                               -- Justin
>>>
>>>
>>>
>>>                             On 01/22/2013 01:00 PM, Shiu Fun Poon 
>>> wrote:
>>>
>>>                                 Justin,
>>>
>>>
>>>
>>>                                 This spec is looking good..
>>>
>>>
>>>
>>>                                 One thing I would like to recommend 
>>> is to add "action"/"operation"
>>>
>>>                                 to the request.    (and potentially 
>>> add client_id and client_secret)
>>>
>>>
>>>
>>>                                 So the request will be like :
>>>
>>> token REQUIRED
>>>
>>>                                 operation (wording to be 
>>> determine)    OPTIONAL inquire (default) | revoke ...
>>>
>>> resource_id OPTIONAL
>>>
>>> client_id OPTIONAL
>>>
>>> client_secret OPTIONAL
>>>
>>>
>>>
>>>                                 And for the OAuth client 
>>> information, it should be an optional parameter (in case it is a 
>>> public client or client is authenticated with SSL mutual 
>>> authentication).
>>>
>>>
>>>
>>>                                 Please consider.
>>>
>>>
>>>
>>>                                 ShiuFun
>>>
>>> _______________________________________________
>>>
>>>                             OAuth mailing list
>>>
>>>                             OAuth@ietf.org 
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>>
>>>                     OAuth mailing list
>>>
>>>                     OAuth@ietf.org 
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From jricher@mitre.org  Wed Jan 30 14:29:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008A621F8521 for ; Wed, 30 Jan 2013 14:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBu5fFl4gNJm for ; Wed, 30 Jan 2013 14:29:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DC21F84E3 for ; Wed, 30 Jan 2013 14:29:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2191853112DD; Wed, 30 Jan 2013 17:29:46 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0C22753112D8; Wed, 30 Jan 2013 17:29:46 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 17:29:45 -0500
Message-ID: <51099EBD.5050204@mitre.org>
Date: Wed, 30 Jan 2013 17:29:17 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Todd W Lainhart 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050801000005020403060205"
X-Originating-IP: [129.83.31.58]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:29:49 -0000

--------------050801000005020403060205
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

It's not meant to follow the same syntax. Instead, it's making use of 
the JSON object structure to avoid additional parsing of the values on 
the client side.

We could fairly easily define it as the same space-delimited string if 
enough people want to keep the scope format consistent.

  -- Justin

On 01/30/2013 05:27 PM, Todd W Lainhart wrote:
> That the scope syntax in draft-richer-oauth-introspection-01 is 
> different than RFC 6749 Section 3.3, as in:
>
>
> "scope": ["read", "write", "dolphin"],
>
> vs.
>
>   scope = scope-token *( SP scope-token )
>      scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
>
> Should introspection-01 follow the 6749 syntax for scopes?
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------050801000005020403060205
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    It's not meant to follow the same syntax. Instead, it's making use
    of the JSON object structure to avoid additional parsing of the
    values on the client side.

    

    We could fairly easily define it as the same space-delimited string
    if enough people want to keep the scope format consistent.

    

     -- Justin

    

    
On 01/30/2013 05:27 PM, Todd W Lainhart
      wrote:

    

    

      
      That the scope syntax in
        draft-richer-oauth-introspection-01
        is different than RFC 6749 Section 3.3, as in:
      

      

      

         "scope":
["read",
          "write", "dolphin"],
      

      

      vs.
      

      

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

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

      

      Should introspection-01 follow
        the 6749
        syntax for scopes?

      
      

      

        
          

            

            		
          

        
      

      

      

      

      

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


    

    

  


--------------050801000005020403060205--

From sberyozkin@gmail.com  Wed Jan 30 14:31:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8623621F8521 for ; Wed, 30 Jan 2013 14:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.173
X-Spam-Level: 
X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZka7SeFUwcP for ; Wed, 30 Jan 2013 14:31:03 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8299121F84E3 for ; Wed, 30 Jan 2013 14:31:02 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id e12so1597201wge.10 for ; Wed, 30 Jan 2013 14:31:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yfI5jsQjWSmChgtqJqMbX4NCC0tAe8vaUKHkik/kvGQ=; b=VrYr4M+juSpU+GXVk3ETvnE1CiS14tZRZMff7k0VVSqXGfRLQJ/9Khp19KazO6lzha baX1ZP4xceNmX5mJpVT6DmAU1OcLkexDi7/JZApzP36V/g0gqjvV6sf+9wQFVdBo9yD+ FHs5U5H9BOEV3QowS1vzSCmLc2eZ/aOHGOLu5A5q5RV/739bVt42gjfwsZv+ySZkQCjJ 3Z2hXRU0jptzkpnA7L7e/ZQAUxuuZ6WkJtIo65NQolQEpNCdmL7eKtkL0Du4da/tK7t2 Nb+Byf6hUPRPbyUDAqlEpZ4yevytEpWs4Ws43klNMt4WEvKA3N8+6hBKYKTaOp40V0rk SGeQ==
X-Received: by 10.194.19.170 with SMTP id g10mr11736711wje.56.1359585061323; Wed, 30 Jan 2013 14:31:01 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id gz3sm11880804wib.2.2013.01.30.14.30.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 14:31:00 -0800 (PST)
Message-ID: <51099F23.6010306@gmail.com>
Date: Wed, 30 Jan 2013 22:30:59 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Justin Richer 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>  <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com> <510999D7.3000805@mitre.org> <51099D86.8070708@gmail.com> <51099E4C.9030403@mitre.org>
In-Reply-To: <51099E4C.9030403@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:31:04 -0000

On 30/01/13 22:27, Justin Richer wrote:
>
> On 01/30/2013 05:24 PM, Sergey Beryozkin wrote:
>> On 30/01/13 22:08, Justin Richer wrote:
>>> I completely agree that OAuth is not RESTful in any meaningful sense of
>>> the term (and have stated so several times in this thread).
>>
>> That is fine, this is not the issue, OAuth2 itself does not have to be
>> 'pure' but having individual bits from which the whole ecosystem is
>> build upon offering a RESTful interface when possible is very
>> important IMHO and in this case it is possible.
>>
>> What if the introspection endpoint would also offer an ability to
>> search ? Some query parameters will mean 'action', some - something
>> else, not cool really
>
> If a service were to offer other functionalities from the same URL as
> the token endpoint, and those other functionalities were switched by
> some kind of parameter, then this is well outside the definition of the
> introspection endpoint.
>
>>
>> Anyway, too much noise I guess from someone who is not even a member
>> of the working group, sorry :-)
>
> In the IETF, if you post to the list, you're in the working group.
> Welcome. :)

Nice :-), thanks

Cheers, Sergey

>
> -- Justin
>
>
>>
>> Thanks, Sergey
>>
>>> I'm not at
>>> all against using query parameters to change behaviors. That's why
>>> they're there. But I'll point out that the examples that you give are
>>> still *doing* the same thing qualitatively (returning a token, in this
>>> instance), even though the mechanisms for doing so are a bit different.
>>> They're still basically the same "action", and if there were a
>>> protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
>>> they would all have the same value for it. The client registration
>>> endpoint is different, because even though all the actions are *about*
>>> client registration, they're different actions. This is the whole
>>> purpose of the "operation=" parameter in the first place. That's the
>>> reason that I brought up this idea of defining them as separate
>>> endpoints.
>>>
>>> Regardless, the group seems about even split on one mode versus the
>>> other. As such, I'm inclined to leave the "operation=" parameter in
>>> place on the registration endpoint even though I don't prefer it.
>>>
>>> I still am very strongly against the idea of defining a protocol-wide
>>> "operation=" parameter for switching between all endpoints, even if it
>>> were possible to do such a thing.
>>>
>>> -- Justin
>>>
>>> On 01/30/2013 04:51 PM, Mike Jones wrote:
>>>>
>>>> Ill note that the OAuth token endpoint changes behaviors depending
>>>> upon the grant_type and whether code or refresh_token parameters are
>>>> present. The first case is described at
>>>> http://tools.ietf.org/html/rfc6749#section-4.1.3. The second case is
>>>> described at http://tools.ietf.org/html/rfc6749#section-6.
>>>>
>>>> There are already a bunch of ways in which OAuth is not RESTful in a
>>>> strict sense of the term. It doesnt seem to be a problem in practice.
>>>>
>>>> -- Mike
>>>>
>>>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>>>> Behalf Of *Anthony Nadalin
>>>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>>>> *To:* Justin Richer; Shiu Fun Poon
>>>> *Cc:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> I would not say that this is incompatible with OAUTH at all , as OAUTH
>>>> has a physical and logical endpoints. We had to live through the Web
>>>> Service endpoint nightmare were we had to have separate services, nuts
>>>>
>>>> *From:*Justin Richer [mailto:jricher@mitre.org]
>>>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>>>> *To:* Shiu Fun Poon
>>>> *Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
>>>> 
>>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> Hi.. Tony.. You are able to present this better than I do.
>>>>
>>>> Justin,
>>>>
>>>> Currently as it is, the spec is unflexible. So when I send a
>>>> request to an endpoint, the endpoint will need to have information
>>>> like /revoke, /introspection, and others. I can imagine the
>>>> documented usage of this will a pages long just to describe all
>>>> the endpoint that is needed to support an application. (so far,
>>>> /authz, /token, /introspection, /revoke, /.....), and this will be
>>>> painful in the multi-tenant environment.
>>>>
>>>> So why not allow the flexibility of using one endpoint /token
>>>> (example only), and make the caller to tell you want the caller
>>>> wants ? It can be an optional field, and a hint to the
>>>> authorization/token endpoint on what you want to do.
>>>>
>>>> This is incompatible with OAuth as it stands today, which defines the
>>>> auth endpoint and token endpoint as logically separate, and therefore
>>>> there is not a parameter defined that would allow for such
>>>> functionality switching.
>>>>
>>>> That said, an *installation* could implement it this way if they
>>>> wanted to, they'd just have to document the endpoints like this:
>>>>
>>>> token endpoint: /oauth?op=token
>>>> auth endpoint: /oauth?op=auth
>>>> introspection endpoint: /oauth?op=introspect
>>>> revocation endpoint: /oauth?op=revoke
>>>>
>>>> etc. The key difference here is that the "op=" parameter is *system
>>>> specific* and is *not* part of the spec itself. And I think that's a
>>>> good design to continue to follow.
>>>>
>>>> Right now, the registration endpoint is the only one that defines an
>>>> "operation" parameter, and I was positing the question of defining it
>>>> in terms of three different endpoints instead. Most of the time, these
>>>> endpoints will have different URLs, as outlined below, but specific
>>>> instances could use some kind of "operation" parameter if they
>>>> wanted to.
>>>>
>>>> Defining it as one endpoint with a switch parameter actually decreses
>>>> flexibility quite a lot, especially if you're talking about
>>>> dispatching to different kinds of functionality all together, which is
>>>> the use case you brought up. There are some places where that could
>>>> make sense, and the definition of different endpoints allows you to do
>>>> that in specific instances of a system without breaking the
>>>> assumptions of clients.
>>>>
>>>> What Tony was talking about was allowing something to be either three
>>>> different URLs *or* using a spec-defined "operation" parameter. That
>>>> suggestion is completely nuts, in my opinion.
>>>>
>>>> And it does not violate the rest/json guideline.
>>>>
>>>> Yes it absolutely does. The REST principle is that a URL represents
>>>> one entity and the HTTP verbs represent different actions on that
>>>> entity. Using a query parameter to switch is very much directly
>>>> against REST guidelines. Not to say that OAuth is RESTful -- it's not,
>>>> by a long shot. But it does follow many rest-like principles, the
>>>> endpoint definitions being one of them.
>>>>
>>>>
>>>> Even with oauth specification, it provides a hint on what is to
>>>> come, e.g. grant_type refresh_token, indicates you want to
>>>> exchange a valid refresh_token to an access_token. There is
>>>> something in the payload which tell you what you need to do. In
>>>> this case, there is nothing in the payload which indicate what is
>>>> expected.
>>>>
>>>> These are functionality switches on the same kind of action, not
>>>> dispatch to different actions. you still do
>>>> authentication/authorization at the auth endpoint, you still get
>>>> tokens from the token endpoint, etc.
>>>>
>>>> If you standard that now (on the optional field), there is a
>>>> chance that companies can implement this according to what will
>>>> work best for them, and we actually have a chance to get this
>>>> working between different products.
>>>>
>>>> It's too late to standardize that field in the core, which is really
>>>> where it would belong. But as it stands today, an OAuth client is
>>>> going to need to be able to handle separate URLs for each defined
>>>> endpoint already, so it can already handle the case where it happens
>>>> to be the same base URL with different operations.
>>>>
>>>> For what it's worth, what I was trying to get discussion on was
>>>> whether it made sense to make Dynamic Registration look like the rest
>>>> of OAuth with separate endpoints, or not.
>>>>
>>>> -- Justin
>>>>
>>>>
>>>> On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer >>> > wrote:
>>>>
>>>> I am very confused, and I need someone to explain to me what I
>>>> am missing. Why won't it work to just pick one? What are
>>>> people "already stuck with" that this would affect? It's not
>>>> like we're trying to unseat a well-established protocol with a
>>>> wide installation base here.
>>>>
>>>> How will giving people the choice between:
>>>>
>>>> /oauth/register?operation=client_register
>>>> /oauth/register?operation=client_update
>>>> /oauth/register?operation=rotate_secret
>>>>
>>>>
>>>> and:
>>>>
>>>> /oauth/client_register
>>>> /oauth/client_update
>>>> /oauth/rotate_secret
>>>>
>>>>
>>>> help multitenancy? How does it even affect that use case?
>>>> Consider that the base URL for all of these is completely up
>>>> to the host environment (nothing is bound to the root URL).
>>>> Consider that clients still have to know what the URL (or
>>>> URLs) are, in either case. Consider that clients still need to
>>>> know how to manage all the parameters and responses.
>>>>
>>>> If anything, keeping it the way that it is with a single URL
>>>> could be argued to help multitenancy because setting up
>>>> routing to multiple URL endpoints can sometimes be problematic
>>>> in hosted environments. However, OAuth already defines a bunch
>>>> of endpoints, and we have to define at least one more with
>>>> this extension, so I'm not convinced that having three with
>>>> specific functions is really any different from having one
>>>> with three functions from a development, deployment, and
>>>> implementation perspective. I can tell you from experience
>>>> that in our own server code, the difference is trivial. (And
>>>> from OAuth1 experience, you can always have a query parameter
>>>> as part of your endpoint URL if you need to. You might hate
>>>> yourself for doing it that way, but nothing says your base URL
>>>> can't already have parameters on it. A client just needs to
>>>> know how to appropriately tack its parameters onto an existing
>>>> URL, and any HTTP client worth its salt will know how to
>>>> augment a query parameter set with new items.)
>>>>
>>>> The *real* difference between the two approaches is a
>>>> philosophical design one. The former overloads one URL with
>>>> multiple functions switched by a flag, the latter uses the URL
>>>> itself as an implicit flag. Under the hood, these could (and
>>>> in many cases will) be all served by the same chunks of code.
>>>> The only difference is how this switch in functionality is
>>>> presented.
>>>>
>>>>
>>>> With that said, can somebody please explain to me how allowing
>>>> *both* of these as options simultaneously (what I understand
>>>> Tony to be suggesting) is a good idea, or how multitenancy
>>>> even comes into play? Because I am completely not seeing how
>>>> these are related.
>>>>
>>>> Thanks,
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>
>>>> It will not work the way you have it, as people do multi-tendency
>>>> different and they are already stuck with the method that they have
>>>> chosen, so they need the flexability, to restrict this is nuts as
>>>> people won't use it.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>
>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>
>>>> To: Anthony Nadalin
>>>>
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org 
>>>>
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>>
>>>>
>>>> I completely disagree with this assessment. Multi-tenancy will work
>>>> just fine (or even better) if everyone uses the same pattern.
>>>> Telling someone "it might be three different urls or it might be all
>>>> one url with a parameter" is just asking for a complete disaster.
>>>> What does the flexibility of allowing two approaches actually
>>>> accomplish?
>>>>
>>>>
>>>>
>>>> You can argue about the merits of either approach, but having both
>>>> as unspecified options for registration, which is meant to help
>>>> things get going in a cold-boot environment, is just plain nuts.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>
>>>> Registration has to work in a multi-tenant environment so flexibility
>>>>
>>>> is needed
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>
>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>
>>>> To: Anthony Nadalin
>>>>
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org 
>>>>
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>>
>>>>
>>>> Because then nobody would know how to actually use the thing.
>>>>
>>>>
>>>>
>>>> In my opinion, this is a key place where this kind of flexibility is
>>>> a very bad thing. Registration needs to work one fairly predictable
>>>> way.
>>>>
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>
>>>> Why not just have a physical and logical endpoint options
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From:oauth-bounces@ietf.org 
>>>> [mailto:oauth-bounces@ietf.org] On
>>>>
>>>> Behalf Of Justin Richer
>>>>
>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>
>>>> To: Nat Sakimura
>>>>
>>>> Cc: Shiu Fun Poon;oauth@ietf.org 
>>>>
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>>
>>>>
>>>> Which brings up an interesting question for the Registration doc:
>>>> right now, it's set up as a single endpoint with three operations.
>>>> We could instead define three endpoints for the different operations.
>>>>
>>>>
>>>>
>>>> I've not been keen to make that deep of a cutting change to it, but
>>>> it would certainly be cleaner and more RESTful API design. What do
>>>> others think?
>>>>
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>
>>>> "Action" goes against REST principle.
>>>>
>>>> I do not think it is a good idea.
>>>>
>>>>
>>>>
>>>> =nat via iPhone
>>>>
>>>>
>>>>
>>>> Jan 23, 2013 4:00Justin Richer
>>>>  :
>>>>
>>>>
>>>>
>>>> (CC'ing the working group)
>>>>
>>>>
>>>>
>>>> I'm not sure what the "action/operation" flag would accomplish. The
>>>> idea behind having different endpoints in OAuth is that they each do
>>>> different kinds of things. The only "action/operation" that I had
>>>> envisioned for the introspection endpoint is introspection itself:
>>>> "I have a token, what does it mean?"
>>>>
>>>>
>>>>
>>>> Note that client_id and client_secret *can* already be used at this
>>>> endpoint if the server supports that as part of their client
>>>> credentials setup. The examples use HTTP Basic with client id and
>>>> secret right now. Basically, the client can authenticate however it
>>>> wants, including any of the methods that OAuth2 allows on the token
>>>> endpoint. It could also authenticate with an access token. At least,
>>>> that's the intent of the introspection draft -- if that's unclear,
>>>> I'd be happy to accept suggested changes to clarify this text.
>>>>
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>
>>>> Justin,
>>>>
>>>>
>>>>
>>>> This spec is looking good..
>>>>
>>>>
>>>>
>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>
>>>> to the request. (and potentially add client_id and client_secret)
>>>>
>>>>
>>>>
>>>> So the request will be like :
>>>>
>>>> token REQUIRED
>>>>
>>>> operation (wording to be determine) OPTIONAL inquire (default) |
>>>> revoke ...
>>>>
>>>> resource_id OPTIONAL
>>>>
>>>> client_id OPTIONAL
>>>>
>>>> client_secret OPTIONAL
>>>>
>>>>
>>>>
>>>> And for the OAuth client information, it should be an optional
>>>> parameter (in case it is a public client or client is authenticated
>>>> with SSL mutual authentication).
>>>>
>>>>
>>>>
>>>> Please consider.
>>>>
>>>>
>>>>
>>>> ShiuFun
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org 
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org 
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

From Michael.Jones@microsoft.com  Wed Jan 30 14:31:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E885721F87E4 for ; Wed, 30 Jan 2013 14:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8ay7weHx8AE for ; Wed, 30 Jan 2013 14:31:39 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id D5EAD21F8521 for ; Wed, 30 Jan 2013 14:31:38 -0800 (PST)
Received: from BY2FFO11FD006.protection.gbl (10.1.15.201) by BY2FFO11HUB033.protection.gbl (10.1.14.117) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 22:31:29 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 22:31:29 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 22:31:02 +0000
From: Mike Jones 
To: Justin Richer , Todd W Lainhart 
Thread-Topic: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
Thread-Index: AQHN/zkLX95KBUoPG0yqjs/GXlBtLZhidAiAgAAAcsA=
Date: Wed, 30 Jan 2013 22:31:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673EC70B@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <51099EBD.5050204@mitre.org>
In-Reply-To: <51099EBD.5050204@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943673EC70BTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(24454001)(377454001)(189002)(199002)(63696002)(16406001)(49866001)(47976001)(512954001)(74502001)(550184003)(56816002)(44976002)(53806001)(55846006)(54356001)(5343655001)(47736001)(16236675001)(50986001)(33656001)(76482001)(77982001)(4396001)(15202345001)(20776003)(47446002)(59766001)(51856001)(74662001)(46102001)(54316002)(31966008)(5343635001)(56776001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB033; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:31:40 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943673EC70BTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Let JSON do the parsing for you

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Wednesday, January 30, 2013 2:29 PM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax

It's not meant to follow the same syntax. Instead, it's making use of the J=
SON object structure to avoid additional parsing of the values on the clien=
t side.

We could fairly easily define it as the same space-delimited string if enou=
gh people want to keep the scope format consistent.

 -- Justin
On 01/30/2013 05:27 PM, Todd W Lainhart wrote:
That the scope syntax in draft-richer-oauth-introspection-01 is different t=
han RFC 6749 Section 3.3, as in:


   "scope": ["read", "write", "dolphin"],

vs.

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

Should introspection-01 follow the 6749 syntax for scopes?






_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


--_000_4E1F6AAD24975D4BA5B1680429673943673EC70BTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Let JSON do the parsing f=
or you


 <=
/p>





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of Justin Richer

Sent: Wednesday, January 30, 2013 2:29 PM

To: Todd W Lainhart

Cc: IETF oauth WG

Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope sy=
ntax






 


It's not meant to fol=
low the same syntax. Instead, it's making use of the JSON object structure =
to avoid additional parsing of the values on the client side.



We could fairly easily define it as the same space-delimited string if enou=
gh people want to keep the scope format consistent.



 -- Justin




On 01/30/2013 05:27 PM, Todd W Lainhart wrote:<=
/o:p>






That the s=
cope syntax in draft-richer-oauth-introspection-01 is different than RFC 67=
49 Section 3.3, as in:






   "scope": ["read", &q=
uot;write", "dolphin"],




vs. 



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

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



Should introspection-01 follow the 6749 syntax for scopes?

























_______________________________________________


OAuth mailing list


OAuth@ietf.org


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




 






--_000_4E1F6AAD24975D4BA5B1680429673943673EC70BTK5EX14MBXC284r_--

From jricher@mitre.org  Wed Jan 30 14:33:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BF721F87A4 for ; Wed, 30 Jan 2013 14:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.553
X-Spam-Level: 
X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJqXWiQWaP3M for ; Wed, 30 Jan 2013 14:33:59 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F29D721F875F for ; Wed, 30 Jan 2013 14:33:58 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 76B591F0C43; Wed, 30 Jan 2013 17:33:58 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5D7CB1F0C36; Wed, 30 Jan 2013 17:33:58 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Jan 2013 17:33:58 -0500
Message-ID: <51099FBA.1060608@mitre.org>
Date: Wed, 30 Jan 2013 17:33:30 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Todd W Lainhart 
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090107050104060407020405"
X-Originating-IP: [129.83.31.58]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:33:59 -0000

--------------090107050104060407020405
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I should add that this is also a bit of an artifact of our 
implementation. Internally, we parse and store scopes as collections of 
discrete strings and process them that way. So serialization of that 
value naturally fell to a JSON list.

  -- Justin

On 01/30/2013 05:29 PM, Justin Richer wrote:
> It's not meant to follow the same syntax. Instead, it's making use of 
> the JSON object structure to avoid additional parsing of the values on 
> the client side.
>
> We could fairly easily define it as the same space-delimited string if 
> enough people want to keep the scope format consistent.
>
>  -- Justin
>
> On 01/30/2013 05:27 PM, Todd W Lainhart wrote:
>> That the scope syntax in draft-richer-oauth-introspection-01 is 
>> different than RFC 6749 Section 3.3, as in:
>>
>>
>> "scope": ["read", "write", "dolphin"],
>>
>> vs.
>>
>>   scope = scope-token *( SP scope-token )
>>      scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
>>
>> Should introspection-01 follow the 6749 syntax for scopes?
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------090107050104060407020405
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    I should add that this is also a bit of an artifact of our
    implementation. Internally, we parse and store scopes as collections
    of discrete strings and process them that way. So serialization of
    that value naturally fell to a JSON list.

    

     -- Justin

    

    
On 01/30/2013 05:29 PM, Justin Richer
      wrote:

    

    

      
      It's not meant to follow the same syntax. Instead, it's making use
      of the JSON object structure to avoid additional parsing of the
      values on the client side.

      

      We could fairly easily define it as the same space-delimited
      string if enough people want to keep the scope format consistent.

      

       -- Justin

      

      
On 01/30/2013 05:27 PM, Todd W
        Lainhart wrote:

      

      
 That the scope
          syntax in draft-richer-oauth-introspection-01 is different
          than RFC 6749 Section 3.3, as in: 

        

        

           "scope":
["read",

            "write", "dolphin"], 

        

        vs. 

        

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

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

        

        Should introspection-01 follow
          the 6749 syntax for scopes?

         

        

          
            

              

              		
            

          
        

        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------090107050104060407020405--

From craigmcc@gmail.com  Wed Jan 30 14:48:02 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9221F8702 for ; Wed, 30 Jan 2013 14:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ9je9CL855w for ; Wed, 30 Jan 2013 14:48:01 -0800 (PST)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D521F86F6 for ; Wed, 30 Jan 2013 14:48:00 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id s4so2730748lbc.35 for ; Wed, 30 Jan 2013 14:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GEYL1nuJE3gxhOOKRLCT3MT0XfO7+aXKuS3b270uGso=; b=SEt63S8zq/duybI/19snwD2GNQK1h5xHR0gPVMmAKB/GH3FuXFAEbcKLzxWWB8ned2 +T9vi8cY5qo22YtzEDhW8oDFI3vTLkxioH/i4K1aiPAzrzTNgkI+ZxiOx0LBlZq3B+cD MMQmfhv9LRwwNJt9HLYIk/IoBZdB76agM5Dp3nGlLqUeaalGnOqcYNgkjpQxPlfX13QM TTXNFNNuJKPBN+ysO4l4dtCpCqoT9P45utFxvnuzhBNKv04nu1Qh74xSRSgrjrXPRCLq aYrKBaibanEBTVhRy3uACPHF0tEOyKk2ImTLFcnQnz45vo7edehCKsXPmT3FfU53b9kj nonQ==
MIME-Version: 1.0
X-Received: by 10.152.147.103 with SMTP id tj7mr6024820lab.54.1359586074411; Wed, 30 Jan 2013 14:47:54 -0800 (PST)
Received: by 10.152.21.199 with HTTP; Wed, 30 Jan 2013 14:47:54 -0800 (PST)
In-Reply-To: <51099EBD.5050204@mitre.org>
References:  <51099EBD.5050204@mitre.org>
Date: Wed, 30 Jan 2013 14:47:54 -0800
Message-ID: 
From: Craig McClanahan 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=e89a8f234d2b01c36604d4894d73
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: craigmcc@gmail.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:48:02 -0000

--e89a8f234d2b01c36604d4894d73
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 30, 2013 at 2:29 PM, Justin Richer  wrote:

> We could fairly easily define it as the same space-delimited string if
> enough people want to keep the scope format consistent.
>
>
Can't we have our cake and eat it too, and accept either syntax?  JSON
makes it pretty easy to introspect what's there and deal with either
version appropriately.

I am one of those that finds the array version of things like this more
convenient, but for the folks who are used to dealing with the
space-delimited string version of scopes, we could easily support that too.


>  -- Justin
>
> Craig McClanahan

--e89a8f234d2b01c36604d4894d73
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 30, 2013 at 2:29 PM, Justin Richer <jricher@mitre.org><=
/span> wrote:


 =20
   =20
 =20
  
We could fairly easily define i=
t as the same space-delimited string
    if enough people want to keep the scope format consistent.

    

Can't we have our cake a=
nd eat it too, and accept either syntax? =A0JSON makes it pretty easy to in=
trospect what's there and deal with either version appropriately.



I am one of those that finds the array version of thing=
s like this more convenient, but for the folks who are used to dealing with=
 the space-delimited string version of scopes, we could easily support that=
 too.


=A0

    =A0-- Justin

<=
div>Craig McClanahan



--e89a8f234d2b01c36604d4894d73--

From Michael.Jones@microsoft.com  Wed Jan 30 14:51:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88021F87D4 for ; Wed, 30 Jan 2013 14:51:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euzMIfO3C11R for ; Wed, 30 Jan 2013 14:51:27 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id B179021F87CD for ; Wed, 30 Jan 2013 14:51:25 -0800 (PST)
Received: from BL2FFO11FD016.protection.gbl (10.173.161.203) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 22:51:22 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 22:51:22 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 22:50:56 +0000
From: Mike Jones 
To: "craigmcc@gmail.com" , Justin Richer 
Thread-Topic: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
Thread-Index: AQHN/zkLX95KBUoPG0yqjs/GXlBtLZhidAiAgAAFNACAAAC5MA==
Date: Wed, 30 Jan 2013 22:50:56 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673ED205@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <51099EBD.5050204@mitre.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943673ED205TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(199002)(189002)(15202345001)(77982001)(59766001)(74502001)(5343635001)(16406001)(51856001)(63696002)(4396001)(50986001)(54356001)(47976001)(53806001)(56816002)(512954001)(54316002)(55846006)(46102001)(44976002)(79102001)(20776003)(47446002)(16236675001)(47736001)(33656001)(74662001)(49866001)(550184003)(5343655001)(56776001)(76482001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 22:51:28 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943673ED205TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Having two ways to do something almost always hurts interop and always make=
s implementations bigger

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
raig McClanahan
Sent: Wednesday, January 30, 2013 2:48 PM
To: Justin Richer
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax

On Wed, Jan 30, 2013 at 2:29 PM, Justin Richer > wrote:
We could fairly easily define it as the same space-delimited string if enou=
gh people want to keep the scope format consistent.

Can't we have our cake and eat it too, and accept either syntax?  JSON make=
s it pretty easy to introspect what's there and deal with either version ap=
propriately.

I am one of those that finds the array version of things like this more con=
venient, but for the folks who are used to dealing with the space-delimited=
 string version of scopes, we could easily support that too.

 -- Justin

Craig McClanahan


--_000_4E1F6AAD24975D4BA5B1680429673943673ED205TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Having two ways to do som=
ething almost always hurts interop and always makes implementations bigger<=
o:p>


 <=
/p>

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Craig McClanahan

Sent: Wednesday, January 30, 2013 2:48 PM

To: Justin Richer

Cc: IETF oauth WG

Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope sy=
ntax


 


On Wed, Jan 30, 2013 at 2:29 PM, Justin Richer <<=
a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org=
> wrote:








We could fairly easil=
y define it as the same space-delimited string if enough people want to kee=
p the scope format consistent.








 






Can't we have our cake and eat it too, and accept ei=
ther syntax?  JSON makes it pretty easy to introspect what's there and=
 deal with either version appropriately.






 






I am one of those that finds the array version of th=
ings like this more convenient, but for the folks who are used to dealing w=
ith the space-delimited string version of scopes, we could easily support t=
hat too.






 








 -- Justin






 












Craig McClanahan






 










--_000_4E1F6AAD24975D4BA5B1680429673943673ED205TK5EX14MBXC284r_--

From ve7jtb@ve7jtb.com  Wed Jan 30 15:24:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3102021F8639 for ; Wed, 30 Jan 2013 15:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2bAU+gH6fMX for ; Wed, 30 Jan 2013 15:24:39 -0800 (PST)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id BABA521F8795 for ; Wed, 30 Jan 2013 15:24:38 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id j34so1018304qco.9 for ; Wed, 30 Jan 2013 15:24:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7quqd3YgJLMIy16JM1Xhu+plc4FJD7hOjnUSPlSbwgU=; b=XwfznB5FQlVuREab4MpCIWy377trrsWH3/OkT1B/O9k2Apq9pJ1VH4fzlFE7iLIcFc iDdZxX9zV9Kaa/GtBu5yTj8g2S2lcXQogYTzZefGXWrixPW/hmgrqo/r/a1SQtjTxKKt 97P0rUV1ObZiVRmvb7bAjDNY5DmchgNbdzNioOT4syeNT+4tAdg0OT1Abl+RD4XnzzEj b223XvtzJFski+iH5EFdNs7DJHlTF1dJNe1fzT05Jr+/kSSz72Q2QQV+A5O1dAV1vqWn WoBnUSSNwZg0ZbxMTETOYVlGb+iyHymCIz4zMQ10hHSPePM7oS74gDhqW6gyTucWQDWk hxEg==
X-Received: by 10.224.78.209 with SMTP id m17mr7025333qak.45.1359588275275; Wed, 30 Jan 2013 15:24:35 -0800 (PST)
Received: from [192.168.1.211] (190-20-20-78.baf.movistar.cl. [190.20.20.78]) by mx.google.com with ESMTPS id hr1sm2446967qeb.3.2013.01.30.15.24.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 15:24:34 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <510947A5.3000904@mitre.org>
Date: Wed, 30 Jan 2013 20:24:22 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <09B3A1D7-8C59-4A91-B9EA-4079124E4B50@ve7jtb.com>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org> <49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com> <510947A5.3000904@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQniF2n17Bd1dkvsqPUMBM9icX67LLj54bULfh8iIB7hblwd9S0z3gVkoimPRlaEVcncWTN+
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 23:24:40 -0000

That is better, but I don't see an advantage to that over using a query =
parameter.

They are equally restful or not as the case may be.

To be more restful I think you want a single endpoint using HTTP verbs.

POST /reg_endpoint?paramaters =E2=80=A6  -> register
PUT  /reg_endpoint?client_id=3D12345¶maters -> update
PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue

The downside is developers understanding=20

On 2013-01-30, at 1:17 PM, Justin Richer  wrote:

>=20
> On 01/30/2013 10:55 AM, John Bradley wrote:
>> My feeling was that letting the registration endpoint be a single URL =
(any url) and using query paramaters was easer for servers and clients.
>>=20
>> Saying take the base URI for the registration endpoint and append =
these paths to it to do different operations seems more likely to go =
wrong fro developers.
> Right, and to clarify, this isn't what I was saying. The spec wouldn't =
specify the path at all, just say that they're three different endpoint =
URLs. The same way that we specify that the auth endpoint and token =
endpoint are different URLs.
>=20
> I think my example might have been misleading. The URLs could just as =
easily be:
>=20
> client_register -> /register_a_new_client
> rotate_secret -> /client/go_get_a_secret_or_something
> client_update-> /maintenance/update_client_information
>=20
>=20
>=20
>>=20
>> Allowing both bath and query parameters is the worst option.
>>=20
>> I am sympathetic with using POST and PUT and perhaps GET but I worry =
about OAuth developers not getting it.
>>=20
>> I also don't get Tony's point about multi tenancy.  If each tenant =
can have there own registration endpoint I don't see a problem beyond =
finding the endpoint and that is what we have WF for.
> Exactly. And to Bill's point in another thread, we could also register =
a link type for each endpoint to help facilitate discovery: =
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
>=20
> -- Justin
>=20
>>=20
>> John B.
>>=20
>> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>>=20
>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>> I like this most, would rename it to say
>>>>=20
>>>> /oauth/client/registration
>>>> or
>>>> /oauth/client-registration
>>>>=20
>>>> etc
>>>>=20
>>>> and reword the spec such that it will let those who implement do it =
with one endpoint or many, whatever is preferred
>>>>=20
>>> That's the whole point of this discussion -- I don't believe you can =
have it both ways.
>>>=20
>>> In one way, you say there are three endpoints and, if you're keeping =
with the rest of OAuth, you don't give them official URL patterns that =
they must follow. How the client gets those endpoints is up to discovery =
or configuration, but the client has an internal map from each bit of =
functionality to a particular URL that's specific to the service, much =
in the same way that the client today has to map the authorization and =
token endpoints. In the other method, you've got one endpoint that the =
client sends a well-defined parameter to in order to accomplish the same =
goal.
>>>=20
>>> So if you allow both at once, does a client send the "operation" =
parameter or not? Is it looking for one url or three to store in its =
configuration? I don't think this level of flexibility buys you anything =
useful, and I strongly believe that it will deeply hurt the =
functionality of dynamic registration if it's allowed.
>>>=20
>>> As it stands today, you can still make the URL whatever you want. If =
we went with three endpoints you could also make those URLs whatever you =
wanted. Nobody has yet pointed out to me what the actual benefit is of =
making both valid.
>>>=20
>>> I personally prefer the method of three endpoint URLs because it's =
cleaner and semantically equivalent, but I am hesitant to change that =
behavior unless there's strong working group support for it. I haven't =
seen real support for it yet -- it's not a good call to make it fully =
RESTful, and it's not a good call to leave it undefined. A client MUST =
have a very clear recipe of what to do on startup for this to work in =
the wild.
>>>=20
>>> -- Justin
>>>=20
>>>>>=20
>>>>> help multitenancy? How does it even affect that use case? Consider =
that
>>>>> the base URL for all of these is completely up to the host =
environment
>>>>> (nothing is bound to the root URL). Consider that clients still =
have to
>>>>> know what the URL (or URLs) are, in either case. Consider that =
clients
>>>>> still need to know how to manage all the parameters and responses.
>>>>>=20
>>>>> If anything, keeping it the way that it is with a single URL could =
be
>>>>> argued to help multitenancy because setting up routing to multiple =
URL
>>>>> endpoints can sometimes be problematic in hosted environments. =
However,
>>>>> OAuth already defines a bunch of endpoints, and we have to define =
at
>>>>> least one more with this extension, so I'm not convinced that =
having
>>>>> three with specific functions is really any different from having =
one
>>>>> with three functions from a development, deployment, and =
implementation
>>>>> perspective. I can tell you from experience that in our own server =
code,
>>>>> the difference is trivial. (And from OAuth1 experience, you can =
always
>>>>> have a query parameter as part of your endpoint URL if you need =
to. You
>>>>> might hate yourself for doing it that way, but nothing says your =
base
>>>>> URL can't already have parameters on it. A client just needs to =
know how
>>>>> to appropriately tack its parameters onto an existing URL, and any =
HTTP
>>>>> client worth its salt will know how to augment a query parameter =
set
>>>>> with new items.)
>>>>>=20
>>>>> The *real* difference between the two approaches is a =
philosophical
>>>>> design one. The former overloads one URL with multiple functions
>>>>> switched by a flag, the latter uses the URL itself as an implicit =
flag.
>>>>> Under the hood, these could (and in many cases will) be all served =
by
>>>>> the same chunks of code. The only difference is how this switch in
>>>>> functionality is presented.
>>>>>=20
>>>>>=20
>>>>> With that said, can somebody please explain to me how allowing =
*both* of
>>>>> these as options simultaneously (what I understand Tony to be
>>>>> suggesting) is a good idea, or how multitenancy even comes into =
play?
>>>>> Because I am completely not seeing how these are related.
>>>>>=20
>>>>> Thanks,
>>>>> -- Justin
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>> It will not work the way you have it, as people do multi-tendency =
different and they are already stuck with the method that they have =
chosen, so they need the flexability, to restrict this is nuts as people =
won't use it.
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>=20
>>>>>> I completely disagree with this assessment. Multi-tenancy will =
work just fine (or even better) if everyone uses the same pattern. =
Telling someone "it might be three different urls or it might be all one =
url with a parameter" is just asking for a complete disaster. What does =
the flexibility of allowing two approaches actually accomplish?
>>>>>>=20
>>>>>> You can argue about the merits of either approach, but having =
both as unspecified options for registration, which is meant to help =
things get going in a cold-boot environment, is just plain nuts.
>>>>>>=20
>>>>>>=20
>>>>>> -- Justin
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>> Registration has to work in a multi-tenant environment  so =
flexibility
>>>>>>> is needed
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>=20
>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>=20
>>>>>>> In my opinion, this is a key place where this kind of =
flexibility is a very bad thing. Registration needs to work one fairly =
predictable way.
>>>>>>>=20
>>>>>>> -- Justin
>>>>>>>=20
>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura
>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>=20
>>>>>>>> Which brings up an interesting question for the Registration =
doc: right now, it's set up as a single endpoint with three operations. =
We could instead define three endpoints for the different operations.
>>>>>>>>=20
>>>>>>>> I've not been keen to make that deep of a cutting change to it, =
but it would certainly be cleaner and more RESTful API design. What do =
others think?
>>>>>>>>=20
>>>>>>>> -- Justin
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>=20
>>>>>>>>> =3Dnat via iPhone
>>>>>>>>>=20
>>>>>>>>> Jan 23, 2013 4:00=E3=80=81Justin Richer  =
=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>>>>>>>>>=20
>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>=20
>>>>>>>>>> I'm not sure what the "action/operation" flag would =
accomplish. The idea behind having different endpoints in OAuth is that =
they each do different kinds of things. The only "action/operation" that =
I had envisioned for the introspection endpoint is introspection itself: =
"I have a token, what does it mean?"
>>>>>>>>>>=20
>>>>>>>>>> Note that client_id and client_secret *can* already be used =
at this endpoint if the server supports that as part of their client =
credentials setup. The examples use HTTP Basic with client id and secret =
right now. Basically, the client can authenticate however it wants, =
including any of the methods that OAuth2 allows on the token endpoint. =
It could also authenticate with an access token. At least, that's the =
intent of the introspection draft -- if that's unclear, I'd be happy to =
accept suggested changes to clarify this text.
>>>>>>>>>>=20
>>>>>>>>>>  -- Justin
>>>>>>>>>>=20
>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>> Justin,
>>>>>>>>>>>=20
>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>=20
>>>>>>>>>>> One thing I would like to recommend is to add =
"action"/"operation"
>>>>>>>>>>> to the request.  (and potentially add client_id and =
client_secret)
>>>>>>>>>>>=20
>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED
>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire =
(default) | revoke ...
>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>=20
>>>>>>>>>>> And for the OAuth client information, it should be an =
optional parameter (in case it is a public client or client is =
authenticated with SSL mutual authentication).
>>>>>>>>>>>=20
>>>>>>>>>>> Please consider.
>>>>>>>>>>>=20
>>>>>>>>>>> ShiuFun
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing 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


From phil.hunt@oracle.com  Wed Jan 30 16:11:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16321F8801 for ; Wed, 30 Jan 2013 16:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.498
X-Spam-Level: 
X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIfpdWPz3ysF for ; Wed, 30 Jan 2013 16:11:13 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0486521F87F3 for ; Wed, 30 Jan 2013 16:11:12 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0V0BB4A023863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 00:11:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0V0B9Xp008232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 00:11:10 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0V0B9ut019170; Wed, 30 Jan 2013 18:11:09 -0600
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Jan 2013 16:11:09 -0800
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org> <49792F1F-929D-4086-813B-C7383BDEAD4E@ve7jtb.com> <510947A5.3000904@mitre.org> <09B3A1D7-8C59-4A91-B9EA-4079124E4B50@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <09B3A1D7-8C59-4A91-B9EA-4079124E4B50@ve7jtb.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <3509B3B2-4980-4E90-8DFA-31D6F6D437BC@oracle.com>
X-Mailer: iPhone Mail (10B142)
From: Phil Hunt 
Date: Wed, 30 Jan 2013 16:11:07 -0800
To: John Bradley 
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 00:11:19 -0000

I disagree at this point that making changes to make oauth more restful is a=
 good thing.  Doing so either means breaking changes or adding options that m=
ean unnecessary complication.

When oauth started rest was not the mandate. The current standard supports a=
ll kinds of http services and that marks success.=20

If it ain't broke don't fix it. =20

Phil

Sent from my phone.

On 2013-01-30, at 15:24, John Bradley  wrote:

> That is better, but I don't see an advantage to that over using a query pa=
rameter.
>=20
> They are equally restful or not as the case may be.
>=20
> To be more restful I think you want a single endpoint using HTTP verbs.
>=20
> POST /reg_endpoint?paramaters =E2=80=A6  -> register
> PUT  /reg_endpoint?client_id=3D12345¶maters -> update
> PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue
>=20
> The downside is developers understanding=20
>=20
> On 2013-01-30, at 1:17 PM, Justin Richer  wrote:
>=20
>>=20
>> On 01/30/2013 10:55 AM, John Bradley wrote:
>>> My feeling was that letting the registration endpoint be a single URL (a=
ny url) and using query paramaters was easer for servers and clients.
>>>=20
>>> Saying take the base URI for the registration endpoint and append these p=
aths to it to do different operations seems more likely to go wrong fro deve=
lopers.
>> Right, and to clarify, this isn't what I was saying. The spec wouldn't sp=
ecify the path at all, just say that they're three different endpoint URLs. T=
he same way that we specify that the auth endpoint and token endpoint are di=
fferent URLs.
>>=20
>> I think my example might have been misleading. The URLs could just as eas=
ily be:
>>=20
>> client_register -> /register_a_new_client
>> rotate_secret -> /client/go_get_a_secret_or_something
>> client_update-> /maintenance/update_client_information
>>=20
>>=20
>>=20
>>>=20
>>> Allowing both bath and query parameters is the worst option.
>>>=20
>>> I am sympathetic with using POST and PUT and perhaps GET but I worry abo=
ut OAuth developers not getting it.
>>>=20
>>> I also don't get Tony's point about multi tenancy.  If each tenant can h=
ave there own registration endpoint I don't see a problem beyond finding the=
 endpoint and that is what we have WF for.
>> Exactly. And to Bill's point in another thread, we could also register a l=
ink type for each endpoint to help facilitate discovery: http://tools.ietf.o=
rg/html/draft-wmills-oauth-lrdd-06
>>=20
>> -- Justin
>>=20
>>>=20
>>> John B.
>>>=20
>>> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>>>=20
>>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>>> I like this most, would rename it to say
>>>>>=20
>>>>> /oauth/client/registration
>>>>> or
>>>>> /oauth/client-registration
>>>>>=20
>>>>> etc
>>>>>=20
>>>>> and reword the spec such that it will let those who implement do it wi=
th one endpoint or many, whatever is preferred
>>>> That's the whole point of this discussion -- I don't believe you can ha=
ve it both ways.
>>>>=20
>>>> In one way, you say there are three endpoints and, if you're keeping wi=
th the rest of OAuth, you don't give them official URL patterns that they mu=
st follow. How the client gets those endpoints is up to discovery or configu=
ration, but the client has an internal map from each bit of functionality to=
 a particular URL that's specific to the service, much in the same way that t=
he client today has to map the authorization and token endpoints. In the oth=
er method, you've got one endpoint that the client sends a well-defined para=
meter to in order to accomplish the same goal.
>>>>=20
>>>> So if you allow both at once, does a client send the "operation" parame=
ter or not? Is it looking for one url or three to store in its configuration=
? I don't think this level of flexibility buys you anything useful, and I st=
rongly believe that it will deeply hurt the functionality of dynamic registr=
ation if it's allowed.
>>>>=20
>>>> As it stands today, you can still make the URL whatever you want. If we=
 went with three endpoints you could also make those URLs whatever you wante=
d. Nobody has yet pointed out to me what the actual benefit is of making bot=
h valid.
>>>>=20
>>>> I personally prefer the method of three endpoint URLs because it's clea=
ner and semantically equivalent, but I am hesitant to change that behavior u=
nless there's strong working group support for it. I haven't seen real suppo=
rt for it yet -- it's not a good call to make it fully RESTful, and it's not=
 a good call to leave it undefined. A client MUST have a very clear recipe o=
f what to do on startup for this to work in the wild.
>>>>=20
>>>> -- Justin
>>>>=20
>>>>>>=20
>>>>>> help multitenancy? How does it even affect that use case? Consider th=
at
>>>>>> the base URL for all of these is completely up to the host environmen=
t
>>>>>> (nothing is bound to the root URL). Consider that clients still have t=
o
>>>>>> know what the URL (or URLs) are, in either case. Consider that client=
s
>>>>>> still need to know how to manage all the parameters and responses.
>>>>>>=20
>>>>>> If anything, keeping it the way that it is with a single URL could be=

>>>>>> argued to help multitenancy because setting up routing to multiple UR=
L
>>>>>> endpoints can sometimes be problematic in hosted environments. Howeve=
r,
>>>>>> OAuth already defines a bunch of endpoints, and we have to define at
>>>>>> least one more with this extension, so I'm not convinced that having
>>>>>> three with specific functions is really any different from having one=

>>>>>> with three functions from a development, deployment, and implementati=
on
>>>>>> perspective. I can tell you from experience that in our own server co=
de,
>>>>>> the difference is trivial. (And from OAuth1 experience, you can alway=
s
>>>>>> have a query parameter as part of your endpoint URL if you need to. Y=
ou
>>>>>> might hate yourself for doing it that way, but nothing says your base=

>>>>>> URL can't already have parameters on it. A client just needs to know h=
ow
>>>>>> to appropriately tack its parameters onto an existing URL, and any HT=
TP
>>>>>> client worth its salt will know how to augment a query parameter set
>>>>>> with new items.)
>>>>>>=20
>>>>>> The *real* difference between the two approaches is a philosophical
>>>>>> design one. The former overloads one URL with multiple functions
>>>>>> switched by a flag, the latter uses the URL itself as an implicit fla=
g.
>>>>>> Under the hood, these could (and in many cases will) be all served by=

>>>>>> the same chunks of code. The only difference is how this switch in
>>>>>> functionality is presented.
>>>>>>=20
>>>>>>=20
>>>>>> With that said, can somebody please explain to me how allowing *both*=
 of
>>>>>> these as options simultaneously (what I understand Tony to be
>>>>>> suggesting) is a good idea, or how multitenancy even comes into play?=

>>>>>> Because I am completely not seeing how these are related.
>>>>>>=20
>>>>>> Thanks,
>>>>>> -- Justin
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>>> It will not work the way you have it, as people do multi-tendency di=
fferent and they are already stuck with the method that they have chosen, so=
 they need the flexability, to restrict this is nuts as people won't use it.=

>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>=20
>>>>>>> I completely disagree with this assessment. Multi-tenancy will work j=
ust fine (or even better) if everyone uses the same pattern. Telling someone=
 "it might be three different urls or it might be all one url with a paramet=
er" is just asking for a complete disaster. What does the flexibility of all=
owing two approaches actually accomplish?
>>>>>>>=20
>>>>>>> You can argue about the merits of either approach, but having both a=
s unspecified options for registration, which is meant to help things get go=
ing in a cold-boot environment, is just plain nuts.
>>>>>>>=20
>>>>>>>=20
>>>>>>> -- Justin
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>>> Registration has to work in a multi-tenant environment  so flexibil=
ity
>>>>>>>> is needed
>>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>>> To: Anthony Nadalin
>>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>=20
>>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>>=20
>>>>>>>> In my opinion, this is a key place where this kind of flexibility i=
s a very bad thing. Registration needs to work one fairly predictable way.
>>>>>>>>=20
>>>>>>>> -- Justin
>>>>>>>>=20
>>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>>>> Behalf Of Justin Richer
>>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>>> To: Nat Sakimura
>>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>>=20
>>>>>>>>> Which brings up an interesting question for the Registration doc: r=
ight now, it's set up as a single endpoint with three operations. We could i=
nstead define three endpoints for the different operations.
>>>>>>>>>=20
>>>>>>>>> I've not been keen to make that deep of a cutting change to it, bu=
t it would certainly be cleaner and more RESTful API design. What do others t=
hink?
>>>>>>>>>=20
>>>>>>>>> -- Justin
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>>=20
>>>>>>>>>> =3Dnat via iPhone
>>>>>>>>>>=20
>>>>>>>>>> Jan 23, 2013 4:00=E3=80=81Justin Richer =E3=81=
=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>>>>>>>>>>=20
>>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>>=20
>>>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. T=
he idea behind having different endpoints in OAuth is that they each do diff=
erent kinds of things. The only "action/operation" that I had envisioned for=
 the introspection endpoint is introspection itself: "I have a token, what d=
oes it mean?"
>>>>>>>>>>>=20
>>>>>>>>>>> Note that client_id and client_secret *can* already be used at t=
his endpoint if the server supports that as part of their client credentials=
 setup. The examples use HTTP Basic with client id and secret right now. Bas=
ically, the client can authenticate however it wants, including any of the m=
ethods that OAuth2 allows on the token endpoint. It could also authenticate w=
ith an access token. At least, that's the intent of the introspection draft -=
- if that's unclear, I'd be happy to accept suggested changes to clarify thi=
s text.
>>>>>>>>>>>=20
>>>>>>>>>>> -- Justin
>>>>>>>>>>>=20
>>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>>> Justin,
>>>>>>>>>>>>=20
>>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>>=20
>>>>>>>>>>>> One thing I would like to recommend is to add "action"/"operati=
on"
>>>>>>>>>>>> to the request.  (and potentially add client_id and client_secr=
et)
>>>>>>>>>>>>=20
>>>>>>>>>>>> So the request will be like :
>>>>>>>>>>>> token REQUIRED
>>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default)=
 | revoke ...
>>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>>=20
>>>>>>>>>>>> And for the OAuth client information, it should be an optional p=
arameter (in case it is a public client or client is authenticated with SSL m=
utual authentication).
>>>>>>>>>>>>=20
>>>>>>>>>>>> Please consider.
>>>>>>>>>>>>=20
>>>>>>>>>>>> ShiuFun
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing 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
>>>> _______________________________________________
>>>> 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 sakimura@gmail.com  Wed Jan 30 18:21:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C00C21F878F for ; Wed, 30 Jan 2013 18:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Level: 
X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXI1T8RAEkJs for ; Wed, 30 Jan 2013 18:21:50 -0800 (PST)
Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB821F87CD for ; Wed, 30 Jan 2013 18:21:36 -0800 (PST)
Received: by mail-ea0-f176.google.com with SMTP id a13so1012182eaa.35 for ; Wed, 30 Jan 2013 18:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=0/iXAj5/1flqPTTy4M5J+Vv4t1eKtW5/QHru7ML49SM=; b=ojoTrjzC2h6gmtqf3sh2ekXyk4iwQlslQiy2mD0r0/NSs+DMKJovNIIN7rkxn9+6/4 GfMFLI5mYG8TZGoyQcIpJi3mSj3075h9AJS+n8T1ZRJUCrwM9vvrxK4h61rnA6t6ubLA FOlR7sqsNQ++lXNMAwOzR+r4+tKEvBHyos47wYL8Aq+uakC4gpYuh36UU/KEQDG44znO HNcP0mfVtoeuXuteRInzOwOYM9BR/4wh6CtR/TRGm8DURbTwoPX5L6Ce/dO84qSpC89C 5FgpvCobbx/Zrs11kM3t4ZJTU9I3QosIE9nIp5oif3Trk0ayDkG2ylbdjs0vkXSXGEFf 4QHg==
MIME-Version: 1.0
X-Received: by 10.14.3.195 with SMTP id 43mr21425580eeh.36.1359598895271; Wed, 30 Jan 2013 18:21:35 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 30 Jan 2013 18:21:35 -0800 (PST)
Date: Thu, 31 Jan 2013 11:21:35 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: multipart/alternative; boundary=047d7b66f239308fcb04d48c496b
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Registration endpoints? (was: Re:  Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 02:21:53 -0000

--047d7b66f239308fcb04d48c496b
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

(I changed the subject to match the content.)

Right. It does not have to be three endpoints. One endpoint would do
(though it depends on how you count the URLs).

However, I would do it slightly differently than you (John B.) proposes.

As an example, let the registration endpoint be named /clients, which
represents the collection of registered clients.
(This is the registration endpoint.)

Then,

POST to the /clients would create the resource in question. (client
associate)
POST to /clients?client_id=12345 and post params (the resource URL) would
update the resource.
This is not an idempotent request, and could update any portion of the
resource.
In particular, client_secret=null or something could mean "rotate secret."

GET to /clients?client_id=12345 would return the client registration data.
It is idempotent.
DELETE to /clients?client_id=12345 would delete the resource.

PUT to /clients?client_id=12345 (the resource URL) would replace the
resource, and is idempotent.
 (I am not sure if we need this. Probably better not have one.)

For any of the above request except DELETE, the response should return the
entire object.

(For the purists: Right. This still could be improved by using URI
template.
The server could publish the server metadata including URI template for the
registration etc.
At that point, server is freed from forced to use the query parameters. For
example,
instead of /clients?client_id=12345, it could have instructed the client to
use /clients/12345/
or /clients/id/12345 etc. but I think that is going too far.)

Nat

2013/1/31 John Bradley 

> That is better, but I don't see an advantage to that over using a query
> parameter.
>
> They are equally restful or not as the case may be.
>
> To be more restful I think you want a single endpoint using HTTP verbs.
>
> POST /reg_endpoint?paramaters …  -> register
> PUT  /reg_endpoint?client_id=12345¶maters -> update
> PUT /reg_endpoint?client_id=12345&rotate_secret=true
>
> The downside is developers understanding
>
> On 2013-01-30, at 1:17 PM, Justin Richer  wrote:
>
> >
> > On 01/30/2013 10:55 AM, John Bradley wrote:
> >> My feeling was that letting the registration endpoint be a single URL
> (any url) and using query paramaters was easer for servers and clients.
> >>
> >> Saying take the base URI for the registration endpoint and append these
> paths to it to do different operations seems more likely to go wrong fro
> developers.
> > Right, and to clarify, this isn't what I was saying. The spec wouldn't
> specify the path at all, just say that they're three different endpoint
> URLs. The same way that we specify that the auth endpoint and token
> endpoint are different URLs.
> >
> > I think my example might have been misleading. The URLs could just as
> easily be:
> >
> > client_register -> /register_a_new_client
> > rotate_secret -> /client/go_get_a_secret_or_something
> > client_update-> /maintenance/update_client_information
> >
> >
> >
> >>
> >> Allowing both bath and query parameters is the worst option.
> >>
> >> I am sympathetic with using POST and PUT and perhaps GET but I worry
> about OAuth developers not getting it.
> >>
> >> I also don't get Tony's point about multi tenancy.  If each tenant can
> have there own registration endpoint I don't see a problem beyond finding
> the endpoint and that is what we have WF for.
> > Exactly. And to Bill's point in another thread, we could also register a
> link type for each endpoint to help facilitate discovery:
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
> >
> > -- Justin
> >
> >>
> >> John B.
> >>
> >> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
> >>
> >>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
> >>>> I like this most, would rename it to say
> >>>>
> >>>> /oauth/client/registration
> >>>> or
> >>>> /oauth/client-registration
> >>>>
> >>>> etc
> >>>>
> >>>> and reword the spec such that it will let those who implement do it
> with one endpoint or many, whatever is preferred
> >>>>
> >>> That's the whole point of this discussion -- I don't believe you can
> have it both ways.
> >>>
> >>> In one way, you say there are three endpoints and, if you're keeping
> with the rest of OAuth, you don't give them official URL patterns that they
> must follow. How the client gets those endpoints is up to discovery or
> configuration, but the client has an internal map from each bit of
> functionality to a particular URL that's specific to the service, much in
> the same way that the client today has to map the authorization and token
> endpoints. In the other method, you've got one endpoint that the client
> sends a well-defined parameter to in order to accomplish the same goal.
> >>>
> >>> So if you allow both at once, does a client send the "operation"
> parameter or not? Is it looking for one url or three to store in its
> configuration? I don't think this level of flexibility buys you anything
> useful, and I strongly believe that it will deeply hurt the functionality
> of dynamic registration if it's allowed.
> >>>
> >>> As it stands today, you can still make the URL whatever you want. If
> we went with three endpoints you could also make those URLs whatever you
> wanted. Nobody has yet pointed out to me what the actual benefit is of
> making both valid.
> >>>
> >>> I personally prefer the method of three endpoint URLs because it's
> cleaner and semantically equivalent, but I am hesitant to change that
> behavior unless there's strong working group support for it. I haven't seen
> real support for it yet -- it's not a good call to make it fully RESTful,
> and it's not a good call to leave it undefined. A client MUST have a very
> clear recipe of what to do on startup for this to work in the wild.
> >>>
> >>> -- Justin
> >>>
> >>>>>
> >>>>> help multitenancy? How does it even affect that use case? Consider
> that
> >>>>> the base URL for all of these is completely up to the host
> environment
> >>>>> (nothing is bound to the root URL). Consider that clients still have
> to
> >>>>> know what the URL (or URLs) are, in either case. Consider that
> clients
> >>>>> still need to know how to manage all the parameters and responses.
> >>>>>
> >>>>> If anything, keeping it the way that it is with a single URL could be
> >>>>> argued to help multitenancy because setting up routing to multiple
> URL
> >>>>> endpoints can sometimes be problematic in hosted environments.
> However,
> >>>>> OAuth already defines a bunch of endpoints, and we have to define at
> >>>>> least one more with this extension, so I'm not convinced that having
> >>>>> three with specific functions is really any different from having one
> >>>>> with three functions from a development, deployment, and
> implementation
> >>>>> perspective. I can tell you from experience that in our own server
> code,
> >>>>> the difference is trivial. (And from OAuth1 experience, you can
> always
> >>>>> have a query parameter as part of your endpoint URL if you need to.
> You
> >>>>> might hate yourself for doing it that way, but nothing says your base
> >>>>> URL can't already have parameters on it. A client just needs to know
> how
> >>>>> to appropriately tack its parameters onto an existing URL, and any
> HTTP
> >>>>> client worth its salt will know how to augment a query parameter set
> >>>>> with new items.)
> >>>>>
> >>>>> The *real* difference between the two approaches is a philosophical
> >>>>> design one. The former overloads one URL with multiple functions
> >>>>> switched by a flag, the latter uses the URL itself as an implicit
> flag.
> >>>>> Under the hood, these could (and in many cases will) be all served by
> >>>>> the same chunks of code. The only difference is how this switch in
> >>>>> functionality is presented.
> >>>>>
> >>>>>
> >>>>> With that said, can somebody please explain to me how allowing
> *both* of
> >>>>> these as options simultaneously (what I understand Tony to be
> >>>>> suggesting) is a good idea, or how multitenancy even comes into play?
> >>>>> Because I am completely not seeing how these are related.
> >>>>>
> >>>>> Thanks,
> >>>>> -- Justin
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
> >>>>>> It will not work the way you have it, as people do multi-tendency
> different and they are already stuck with the method that they have chosen,
> so they need the flexability, to restrict this is nuts as people won't use
> it.
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Justin Richer [mailto:jricher@mitre.org]
> >>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
> >>>>>> To: Anthony Nadalin
> >>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
> >>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>
> >>>>>> I completely disagree with this assessment. Multi-tenancy will work
> just fine (or even better) if everyone uses the same pattern. Telling
> someone "it might be three different urls or it might be all one url with a
> parameter" is just asking for a complete disaster. What does the
> flexibility of allowing two approaches actually accomplish?
> >>>>>>
> >>>>>> You can argue about the merits of either approach, but having both
> as unspecified options for registration, which is meant to help things get
> going in a cold-boot environment, is just plain nuts.
> >>>>>>
> >>>>>>
> >>>>>> -- Justin
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
> >>>>>>> Registration has to work in a multi-tenant environment  so
> flexibility
> >>>>>>> is needed
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
> >>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
> >>>>>>> To: Anthony Nadalin
> >>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
> >>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>>
> >>>>>>> Because then nobody would know how to actually use the thing.
> >>>>>>>
> >>>>>>> In my opinion, this is a key place where this kind of flexibility
> is a very bad thing. Registration needs to work one fairly predictable way.
> >>>>>>>
> >>>>>>> -- Justin
> >>>>>>>
> >>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
> >>>>>>>> Why not just have a physical and logical endpoint options
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>>>>>> Behalf Of Justin Richer
> >>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
> >>>>>>>> To: Nat Sakimura
> >>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
> >>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>>>
> >>>>>>>> Which brings up an interesting question for the Registration doc:
> right now, it's set up as a single endpoint with three operations. We could
> instead define three endpoints for the different operations.
> >>>>>>>>
> >>>>>>>> I've not been keen to make that deep of a cutting change to it,
> but it would certainly be cleaner and more RESTful API design. What do
> others think?
> >>>>>>>>
> >>>>>>>> -- Justin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
> >>>>>>>>> "Action" goes against REST principle.
> >>>>>>>>> I do not think it is a good idea.
> >>>>>>>>>
> >>>>>>>>> =nat via iPhone
> >>>>>>>>>
> >>>>>>>>> Jan 23, 2013 4:00、Justin Richer  のメッセージ:
> >>>>>>>>>
> >>>>>>>>>> (CC'ing the working group)
> >>>>>>>>>>
> >>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish.
> The idea behind having different endpoints in OAuth is that they each do
> different kinds of things. The only "action/operation" that I had
> envisioned for the introspection endpoint is introspection itself: "I have
> a token, what does it mean?"
> >>>>>>>>>>
> >>>>>>>>>> Note that client_id and client_secret *can* already be used at
> this endpoint if the server supports that as part of their client
> credentials setup. The examples use HTTP Basic with client id and secret
> right now. Basically, the client can authenticate however it wants,
> including any of the methods that OAuth2 allows on the token endpoint. It
> could also authenticate with an access token. At least, that's the intent
> of the introspection draft -- if that's unclear, I'd be happy to accept
> suggested changes to clarify this text.
> >>>>>>>>>>
> >>>>>>>>>>  -- Justin
> >>>>>>>>>>
> >>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
> >>>>>>>>>>> Justin,
> >>>>>>>>>>>
> >>>>>>>>>>> This spec is looking good..
> >>>>>>>>>>>
> >>>>>>>>>>> One thing I would like to recommend is to add
> "action"/"operation"
> >>>>>>>>>>> to the request.  (and potentially add client_id and
> client_secret)
> >>>>>>>>>>>
> >>>>>>>>>>> So the request will be like :
> >>>>>>>>>>> token REQUIRED
> >>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire
> (default) | revoke ...
> >>>>>>>>>>> resource_id OPTIONAL
> >>>>>>>>>>> client_id OPTIONAL
> >>>>>>>>>>> client_secret OPTIONAL
> >>>>>>>>>>>
> >>>>>>>>>>> And for the OAuth client information, it should be an optional
> parameter (in case it is a public client or client is authenticated with
> SSL mutual authentication).
> >>>>>>>>>>>
> >>>>>>>>>>> Please consider.
> >>>>>>>>>>>
> >>>>>>>>>>> ShiuFun
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> OAuth mailing list
> >>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>> _______________________________________________
> >>>>>>>> OAuth mailing list
> >>>>>>>> OAuth@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



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

--047d7b66f239308fcb04d48c496b
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

PGRpdj4oSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IHRvIG1hdGNoIHRoZSBjb250ZW50LikmbmJzcDs8
L2Rpdj48ZGl2Pjxicj48L2Rpdj5SaWdodC4gSXQgZG9lcyBub3QgaGF2ZSB0byBiZSB0aHJlZSBl
bmRwb2ludHMuIE9uZSBlbmRwb2ludCB3b3VsZCBkbyAodGhvdWdoIGl0IGRlcGVuZHMgb24gaG93
IHlvdSBjb3VudCB0aGUgVVJMcykuICZuYnNwOzxkaXY+PGJyPjwvZGl2PjxkaXY+SG93ZXZlciwg
SSB3b3VsZCBkbyBpdCBzbGlnaHRseSBkaWZmZXJlbnRseSB0aGFuIHlvdSAoSm9obiBCLikgcHJv
cG9zZXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PkFzIGFuIGV4YW1wbGUsIGxl
dCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50IGJlIG5hbWVkIC9jbGllbnRzLCB3aGljaCByZXBy
ZXNlbnRzIHRoZSBjb2xsZWN0aW9uIG9mIHJlZ2lzdGVyZWQgY2xpZW50cy4mbmJzcDs8L2Rpdj48
ZGl2PihUaGlzIGlzIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQuKSZuYnNwOzwvZGl2PjxkaXY+
PGJyPjxkaXY+VGhlbiwmbmJzcDs8L2Rpdj48ZGl2Pg0KPGJyPjwvZGl2PjxkaXY+UE9TVCB0byB0
aGUgL2NsaWVudHMgd291bGQgY3JlYXRlIHRoZSByZXNvdXJjZSBpbiBxdWVzdGlvbi4gKGNsaWVu
dCBhc3NvY2lhdGUpJm5ic3A7PC9kaXY+PGRpdj5QT1NUIHRvIC9jbGllbnRzP2NsaWVudF9pZD0x
MjM0NSBhbmQgcG9zdCBwYXJhbXMgKHRoZSByZXNvdXJjZSBVUkwpIHdvdWxkIHVwZGF0ZSB0aGUg
cmVzb3VyY2UuJm5ic3A7PC9kaXY+PGRpdj5UaGlzIGlzIG5vdCBhbiBpZGVtcG90ZW50IHJlcXVl
c3QsIGFuZCBjb3VsZCB1cGRhdGUgYW55IHBvcnRpb24gb2YgdGhlIHJlc291cmNlLiZuYnNwOzwv
ZGl2Pg0KPGRpdj5JbiBwYXJ0aWN1bGFyLCBjbGllbnRfc2VjcmV0PW51bGwgb3Igc29tZXRoaW5n
IGNvdWxkIG1lYW4gJnF1b3Q7cm90YXRlIHNlY3JldC4mcXVvdDs8L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2PkdFVCB0byAvY2xpZW50cz9jbGllbnRfaWQ9MTIzNDUgd291bGQgcmV0dXJuIHRoZSBj
bGllbnQgcmVnaXN0cmF0aW9uIGRhdGEuIEl0IGlzIGlkZW1wb3RlbnQuJm5ic3A7PC9kaXY+PGRp
dj5ERUxFVEUgdG8gL2NsaWVudHM/Y2xpZW50X2lkPTEyMzQ1IHdvdWxkIGRlbGV0ZSB0aGUgcmVz
b3VyY2UuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PlBVVCB0byZuYnNwOy9jbGll
bnRzP2NsaWVudF9pZD0xMjM0NSAodGhlIHJlc291cmNlIFVSTCkmbmJzcDt3b3VsZCByZXBsYWNl
IHRoZSByZXNvdXJjZSwgYW5kIGlzIGlkZW1wb3RlbnQuJm5ic3A7PC9kaXY+PGRpdj4mbmJzcDso
SSBhbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIHRoaXMuIFByb2JhYmx5IGJldHRlciBub3QgaGF2ZSBv
bmUuKSZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Rm9yIGFueSBvZiB0aGUgYWJvdmUg
cmVxdWVzdCBleGNlcHQgREVMRVRFLCB0aGUgcmVzcG9uc2Ugc2hvdWxkIHJldHVybiB0aGUgZW50
aXJlIG9iamVjdC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPjwvZGl2PjxkaXY+KEZvciB0aGUgcHVy
aXN0czogUmlnaHQuIFRoaXMgc3RpbGwgY291bGQgYmUgaW1wcm92ZWQgYnkgdXNpbmcgVVJJIHRl
bXBsYXRlLiZuYnNwOzwvZGl2PjxkaXY+VGhlIHNlcnZlciBjb3VsZCBwdWJsaXNoIHRoZSBzZXJ2
ZXIgbWV0YWRhdGEgaW5jbHVkaW5nIFVSSSB0ZW1wbGF0ZSBmb3IgdGhlIHJlZ2lzdHJhdGlvbiBl
dGMuJm5ic3A7PC9kaXY+PGRpdj5BdCB0aGF0IHBvaW50LCBzZXJ2ZXIgaXMgZnJlZWQgZnJvbSBm
b3JjZWQgdG8gdXNlIHRoZSBxdWVyeSBwYXJhbWV0ZXJzLiBGb3IgZXhhbXBsZSwmbmJzcDs8L2Rp
dj4NCjxkaXY+aW5zdGVhZCBvZiAvY2xpZW50cz9jbGllbnRfaWQ9MTIzNDUsIGl0IGNvdWxkIGhh
dmUgaW5zdHJ1Y3RlZCB0aGUgY2xpZW50IHRvIHVzZSAvY2xpZW50cy8xMjM0NS8mbmJzcDs8L2Rp
dj48ZGl2Pm9yIC9jbGllbnRzL2lkLzEyMzQ1IGV0Yy4gYnV0IEkgdGhpbmsgdGhhdCBpcyBnb2lu
ZyB0b28gZmFyLik8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk5hdDxicj48YnI+PGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPg0KMjAxMy8xLzMxIEpvaG4gQnJhZGxleSA8c3BhbiBkaXI9Imx0ciI+
Jmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZl
N2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8L3NwYW4+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp
bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv
bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KVGhhdCBpcyBiZXR0ZXIsIGJ1dCBJIGRvbiYjMzk7dCBz
ZWUgYW4gYWR2YW50YWdlIHRvIHRoYXQgb3ZlciB1c2luZyBhIHF1ZXJ5IHBhcmFtZXRlci48YnI+
DQo8YnI+DQpUaGV5IGFyZSBlcXVhbGx5IHJlc3RmdWwgb3Igbm90IGFzIHRoZSBjYXNlIG1heSBi
ZS48YnI+DQo8YnI+DQpUbyBiZSBtb3JlIHJlc3RmdWwgSSB0aGluayB5b3Ugd2FudCBhIHNpbmds
ZSBlbmRwb2ludCB1c2luZyBIVFRQIHZlcmJzLjxicj4NCjxicj4NClBPU1QgL3JlZ19lbmRwb2lu
dD9wYXJhbWF0ZXJzICZoZWxsaXA7ICZuYnNwOy0mZ3Q7IHJlZ2lzdGVyPGJyPg0KUFVUICZuYnNw
Oy9yZWdfZW5kcG9pbnQ/Y2xpZW50X2lkPTEyMzQ1JmFtcDtwYXJhbWF0ZXJzIC0mZ3Q7IHVwZGF0
ZTxicj4NClBVVCAvcmVnX2VuZHBvaW50P2NsaWVudF9pZD0xMjM0NSZhbXA7cm90YXRlX3NlY3Jl
dD10cnVlPGJyPg0KPGJyPg0KVGhlIGRvd25zaWRlIGlzIGRldmVsb3BlcnMgdW5kZXJzdGFuZGlu
Zzxicj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+PGRpdiBjbGFzcz0iaDUiPjxicj4NCk9uIDIwMTMt
MDEtMzAsIGF0IDE6MTcgUE0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlj
aGVyQG1pdHJlLm9yZyI+anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+
DQomZ3Q7PGJyPg0KJmd0OyBPbiAwMS8zMC8yMDEzIDEwOjU1IEFNLCBKb2huIEJyYWRsZXkgd3Jv
dGU6PGJyPg0KJmd0OyZndDsgTXkgZmVlbGluZyB3YXMgdGhhdCBsZXR0aW5nIHRoZSByZWdpc3Ry
YXRpb24gZW5kcG9pbnQgYmUgYSBzaW5nbGUgVVJMIChhbnkgdXJsKSBhbmQgdXNpbmcgcXVlcnkg
cGFyYW1hdGVycyB3YXMgZWFzZXIgZm9yIHNlcnZlcnMgYW5kIGNsaWVudHMuPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBTYXlpbmcgdGFrZSB0aGUgYmFzZSBVUkkgZm9yIHRoZSByZWdpc3Ry
YXRpb24gZW5kcG9pbnQgYW5kIGFwcGVuZCB0aGVzZSBwYXRocyB0byBpdCB0byBkbyBkaWZmZXJl
bnQgb3BlcmF0aW9ucyBzZWVtcyBtb3JlIGxpa2VseSB0byBnbyB3cm9uZyBmcm8gZGV2ZWxvcGVy
cy48YnI+DQomZ3Q7IFJpZ2h0LCBhbmQgdG8gY2xhcmlmeSwgdGhpcyBpc24mIzM5O3Qgd2hhdCBJ
IHdhcyBzYXlpbmcuIFRoZSBzcGVjIHdvdWxkbiYjMzk7dCBzcGVjaWZ5IHRoZSBwYXRoIGF0IGFs
bCwganVzdCBzYXkgdGhhdCB0aGV5JiMzOTtyZSB0aHJlZSBkaWZmZXJlbnQgZW5kcG9pbnQgVVJM
cy4gVGhlIHNhbWUgd2F5IHRoYXQgd2Ugc3BlY2lmeSB0aGF0IHRoZSBhdXRoIGVuZHBvaW50IGFu
ZCB0b2tlbiBlbmRwb2ludCBhcmUgZGlmZmVyZW50IFVSTHMuPGJyPg0KDQomZ3Q7PGJyPg0KJmd0
OyBJIHRoaW5rIG15IGV4YW1wbGUgbWlnaHQgaGF2ZSBiZWVuIG1pc2xlYWRpbmcuIFRoZSBVUkxz
IGNvdWxkIGp1c3QgYXMgZWFzaWx5IGJlOjxicj4NCiZndDs8YnI+DQomZ3Q7IGNsaWVudF9yZWdp
c3RlciAtJmd0OyAvcmVnaXN0ZXJfYV9uZXdfY2xpZW50PGJyPg0KJmd0OyByb3RhdGVfc2VjcmV0
IC0mZ3Q7IC9jbGllbnQvZ29fZ2V0X2Ffc2VjcmV0X29yX3NvbWV0aGluZzxicj4NCiZndDsgY2xp
ZW50X3VwZGF0ZS0mZ3Q7IC9tYWludGVuYW5jZS91cGRhdGVfY2xpZW50X2luZm9ybWF0aW9uPGJy
Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBB
bGxvd2luZyBib3RoIGJhdGggYW5kIHF1ZXJ5IHBhcmFtZXRlcnMgaXMgdGhlIHdvcnN0IG9wdGlv
bi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgYW0gc3ltcGF0aGV0aWMgd2l0aCB1c2lu
ZyBQT1NUIGFuZCBQVVQgYW5kIHBlcmhhcHMgR0VUIGJ1dCBJIHdvcnJ5IGFib3V0IE9BdXRoIGRl
dmVsb3BlcnMgbm90IGdldHRpbmcgaXQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGFs
c28gZG9uJiMzOTt0IGdldCBUb255JiMzOTtzIHBvaW50IGFib3V0IG11bHRpIHRlbmFuY3kuICZu
YnNwO0lmIGVhY2ggdGVuYW50IGNhbiBoYXZlIHRoZXJlIG93biByZWdpc3RyYXRpb24gZW5kcG9p
bnQgSSBkb24mIzM5O3Qgc2VlIGEgcHJvYmxlbSBiZXlvbmQgZmluZGluZyB0aGUgZW5kcG9pbnQg
YW5kIHRoYXQgaXMgd2hhdCB3ZSBoYXZlIFdGIGZvci48YnI+DQomZ3Q7IEV4YWN0bHkuIEFuZCB0
byBCaWxsJiMzOTtzIHBvaW50IGluIGFub3RoZXIgdGhyZWFkLCB3ZSBjb3VsZCBhbHNvIHJlZ2lz
dGVyIGEgbGluayB0eXBlIGZvciBlYWNoIGVuZHBvaW50IHRvIGhlbHAgZmFjaWxpdGF0ZSBkaXNj
b3Zlcnk6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdtaWxscy1v
YXV0aC1scmRkLTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtd21pbGxzLW9hdXRoLWxyZGQtMDY8L2E+PGJyPg0KDQomZ3Q7PGJyPg0KJmd0OyAtLSBK
dXN0aW48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2huIEIuPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAyMDEzLTAxLTI0LCBhdCAxMToyNiBBTSwgSnVzdGlu
IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIj5qcmljaGVyQG1p
dHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9u
IDAxLzI0LzIwMTMgMDU6NTYgQU0sIFNlcmdleSBCZXJ5b3praW4gd3JvdGU6PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyBJIGxpa2UgdGhpcyBtb3N0LCB3b3VsZCByZW5hbWUgaXQgdG8gc2F5PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgL29hdXRoL2NsaWVudC9yZWdp
c3RyYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAv
b2F1dGgvY2xpZW50LXJlZ2lzdHJhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7IGV0Yzxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IGFuZCByZXdvcmQgdGhlIHNwZWMgc3VjaCB0aGF0IGl0IHdpbGwgbGV0IHRob3NlIHdobyBp
bXBsZW1lbnQgZG8gaXQgd2l0aCBvbmUgZW5kcG9pbnQgb3IgbWFueSwgd2hhdGV2ZXIgaXMgcHJl
ZmVycmVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGF0JiMzOTtz
IHRoZSB3aG9sZSBwb2ludCBvZiB0aGlzIGRpc2N1c3Npb24gLS0gSSBkb24mIzM5O3QgYmVsaWV2
ZSB5b3UgY2FuIGhhdmUgaXQgYm90aCB3YXlzLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyBJbiBvbmUgd2F5LCB5b3Ugc2F5IHRoZXJlIGFyZSB0aHJlZSBlbmRwb2ludHMgYW5k
LCBpZiB5b3UmIzM5O3JlIGtlZXBpbmcgd2l0aCB0aGUgcmVzdCBvZiBPQXV0aCwgeW91IGRvbiYj
Mzk7dCBnaXZlIHRoZW0gb2ZmaWNpYWwgVVJMIHBhdHRlcm5zIHRoYXQgdGhleSBtdXN0IGZvbGxv
dy4gSG93IHRoZSBjbGllbnQgZ2V0cyB0aG9zZSBlbmRwb2ludHMgaXMgdXAgdG8gZGlzY292ZXJ5
IG9yIGNvbmZpZ3VyYXRpb24sIGJ1dCB0aGUgY2xpZW50IGhhcyBhbiBpbnRlcm5hbCBtYXAgZnJv
bSBlYWNoIGJpdCBvZiBmdW5jdGlvbmFsaXR5IHRvIGEgcGFydGljdWxhciBVUkwgdGhhdCYjMzk7
cyBzcGVjaWZpYyB0byB0aGUgc2VydmljZSwgbXVjaCBpbiB0aGUgc2FtZSB3YXkgdGhhdCB0aGUg
Y2xpZW50IHRvZGF5IGhhcyB0byBtYXAgdGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBv
aW50cy4gSW4gdGhlIG90aGVyIG1ldGhvZCwgeW91JiMzOTt2ZSBnb3Qgb25lIGVuZHBvaW50IHRo
YXQgdGhlIGNsaWVudCBzZW5kcyBhIHdlbGwtZGVmaW5lZCBwYXJhbWV0ZXIgdG8gaW4gb3JkZXIg
dG8gYWNjb21wbGlzaCB0aGUgc2FtZSBnb2FsLjxicj4NCg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7IFNvIGlmIHlvdSBhbGxvdyBib3RoIGF0IG9uY2UsIGRvZXMgYSBjbGllbnQgc2Vu
ZCB0aGUgJnF1b3Q7b3BlcmF0aW9uJnF1b3Q7IHBhcmFtZXRlciBvciBub3Q/IElzIGl0IGxvb2tp
bmcgZm9yIG9uZSB1cmwgb3IgdGhyZWUgdG8gc3RvcmUgaW4gaXRzIGNvbmZpZ3VyYXRpb24/IEkg
ZG9uJiMzOTt0IHRoaW5rIHRoaXMgbGV2ZWwgb2YgZmxleGliaWxpdHkgYnV5cyB5b3UgYW55dGhp
bmcgdXNlZnVsLCBhbmQgSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgaXQgd2lsbCBkZWVwbHkgaHVy
dCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBpZiBpdCYjMzk7cyBh
bGxvd2VkLjxicj4NCg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFzIGl0IHN0YW5k
cyB0b2RheSwgeW91IGNhbiBzdGlsbCBtYWtlIHRoZSBVUkwgd2hhdGV2ZXIgeW91IHdhbnQuIElm
IHdlIHdlbnQgd2l0aCB0aHJlZSBlbmRwb2ludHMgeW91IGNvdWxkIGFsc28gbWFrZSB0aG9zZSBV
UkxzIHdoYXRldmVyIHlvdSB3YW50ZWQuIE5vYm9keSBoYXMgeWV0IHBvaW50ZWQgb3V0IHRvIG1l
IHdoYXQgdGhlIGFjdHVhbCBiZW5lZml0IGlzIG9mIG1ha2luZyBib3RoIHZhbGlkLjxicj4NCg0K
Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgcGVyc29uYWxseSBwcmVmZXIgdGhlIG1l
dGhvZCBvZiB0aHJlZSBlbmRwb2ludCBVUkxzIGJlY2F1c2UgaXQmIzM5O3MgY2xlYW5lciBhbmQg
c2VtYW50aWNhbGx5IGVxdWl2YWxlbnQsIGJ1dCBJIGFtIGhlc2l0YW50IHRvIGNoYW5nZSB0aGF0
IGJlaGF2aW9yIHVubGVzcyB0aGVyZSYjMzk7cyBzdHJvbmcgd29ya2luZyBncm91cCBzdXBwb3J0
IGZvciBpdC4gSSBoYXZlbiYjMzk7dCBzZWVuIHJlYWwgc3VwcG9ydCBmb3IgaXQgeWV0IC0tIGl0
JiMzOTtzIG5vdCBhIGdvb2QgY2FsbCB0byBtYWtlIGl0IGZ1bGx5IFJFU1RmdWwsIGFuZCBpdCYj
Mzk7cyBub3QgYSBnb29kIGNhbGwgdG8gbGVhdmUgaXQgdW5kZWZpbmVkLiBBIGNsaWVudCBNVVNU
IGhhdmUgYSB2ZXJ5IGNsZWFyIHJlY2lwZSBvZiB3aGF0IHRvIGRvIG9uIHN0YXJ0dXAgZm9yIHRo
aXMgdG8gd29yayBpbiB0aGUgd2lsZC48YnI+DQoNCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0OyAtLSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhlbHAgbXVsdGl0ZW5hbmN5PyBIb3cgZG9lcyBp
dCBldmVuIGFmZmVjdCB0aGF0IHVzZSBjYXNlPyBDb25zaWRlciB0aGF0PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgdGhlIGJhc2UgVVJMIGZvciBhbGwgb2YgdGhlc2UgaXMgY29tcGxldGVseSB1
cCB0byB0aGUgaG9zdCBlbnZpcm9ubWVudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChub3Ro
aW5nIGlzIGJvdW5kIHRvIHRoZSByb290IFVSTCkuIENvbnNpZGVyIHRoYXQgY2xpZW50cyBzdGls
bCBoYXZlIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsga25vdyB3aGF0IHRoZSBVUkwgKG9y
IFVSTHMpIGFyZSwgaW4gZWl0aGVyIGNhc2UuIENvbnNpZGVyIHRoYXQgY2xpZW50czxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN0aWxsIG5lZWQgdG8ga25vdyBob3cgdG8gbWFuYWdlIGFsbCB0
aGUgcGFyYW1ldGVycyBhbmQgcmVzcG9uc2VzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgYW55dGhpbmcsIGtlZXBpbmcgaXQgdGhlIHdheSB0
aGF0IGl0IGlzIHdpdGggYSBzaW5nbGUgVVJMIGNvdWxkIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgYXJndWVkIHRvIGhlbHAgbXVsdGl0ZW5hbmN5IGJlY2F1c2Ugc2V0dGluZyB1cCByb3V0
aW5nIHRvIG11bHRpcGxlIFVSTDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuZHBvaW50cyBj
YW4gc29tZXRpbWVzIGJlIHByb2JsZW1hdGljIGluIGhvc3RlZCBlbnZpcm9ubWVudHMuIEhvd2V2
ZXIsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggYWxyZWFkeSBkZWZpbmVzIGEgYnVu
Y2ggb2YgZW5kcG9pbnRzLCBhbmQgd2UgaGF2ZSB0byBkZWZpbmUgYXQ8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBsZWFzdCBvbmUgbW9yZSB3aXRoIHRoaXMgZXh0ZW5zaW9uLCBzbyBJJiMzOTtt
IG5vdCBjb252aW5jZWQgdGhhdCBoYXZpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJl
ZSB3aXRoIHNwZWNpZmljIGZ1bmN0aW9ucyBpcyByZWFsbHkgYW55IGRpZmZlcmVudCBmcm9tIGhh
dmluZyBvbmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXRoIHRocmVlIGZ1bmN0aW9ucyBm
cm9tIGEgZGV2ZWxvcG1lbnQsIGRlcGxveW1lbnQsIGFuZCBpbXBsZW1lbnRhdGlvbjxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBlcnNwZWN0aXZlLiBJIGNhbiB0ZWxsIHlvdSBmcm9tIGV4cGVy
aWVuY2UgdGhhdCBpbiBvdXIgb3duIHNlcnZlciBjb2RlLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IHRoZSBkaWZmZXJlbmNlIGlzIHRyaXZpYWwuIChBbmQgZnJvbSBPQXV0aDEgZXhwZXJpZW5j
ZSwgeW91IGNhbiBhbHdheXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoYXZlIGEgcXVlcnkg
cGFyYW1ldGVyIGFzIHBhcnQgb2YgeW91ciBlbmRwb2ludCBVUkwgaWYgeW91IG5lZWQgdG8uIFlv
dTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1pZ2h0IGhhdGUgeW91cnNlbGYgZm9yIGRvaW5n
IGl0IHRoYXQgd2F5LCBidXQgbm90aGluZyBzYXlzIHlvdXIgYmFzZTxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IFVSTCBjYW4mIzM5O3QgYWxyZWFkeSBoYXZlIHBhcmFtZXRlcnMgb24gaXQuIEEg
Y2xpZW50IGp1c3QgbmVlZHMgdG8ga25vdyBob3c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0
byBhcHByb3ByaWF0ZWx5IHRhY2sgaXRzIHBhcmFtZXRlcnMgb250byBhbiBleGlzdGluZyBVUkws
IGFuZCBhbnkgSFRUUDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsaWVudCB3b3J0aCBpdHMg
c2FsdCB3aWxsIGtub3cgaG93IHRvIGF1Z21lbnQgYSBxdWVyeSBwYXJhbWV0ZXIgc2V0PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aCBuZXcgaXRlbXMuKTxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlICpyZWFsKiBkaWZmZXJlbmNlIGJl
dHdlZW4gdGhlIHR3byBhcHByb2FjaGVzIGlzIGEgcGhpbG9zb3BoaWNhbDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IGRlc2lnbiBvbmUuIFRoZSBmb3JtZXIgb3ZlcmxvYWRzIG9uZSBVUkwgd2l0
aCBtdWx0aXBsZSBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzd2l0Y2hlZCBi
eSBhIGZsYWcsIHRoZSBsYXR0ZXIgdXNlcyB0aGUgVVJMIGl0c2VsZiBhcyBhbiBpbXBsaWNpdCBm
bGFnLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVuZGVyIHRoZSBob29kLCB0aGVzZSBjb3Vs
ZCAoYW5kIGluIG1hbnkgY2FzZXMgd2lsbCkgYmUgYWxsIHNlcnZlZCBieTxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IHRoZSBzYW1lIGNodW5rcyBvZiBjb2RlLiBUaGUgb25seSBkaWZmZXJlbmNl
IGlzIGhvdyB0aGlzIHN3aXRjaCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9u
YWxpdHkgaXMgcHJlc2VudGVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaXRoIHRoYXQgc2FpZCwg
Y2FuIHNvbWVib2R5IHBsZWFzZSBleHBsYWluIHRvIG1lIGhvdyBhbGxvd2luZyAqYm90aCogb2Y8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVzZSBhcyBvcHRpb25zIHNpbXVsdGFuZW91c2x5
ICh3aGF0IEkgdW5kZXJzdGFuZCBUb255IHRvIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
c3VnZ2VzdGluZykgaXMgYSBnb29kIGlkZWEsIG9yIGhvdyBtdWx0aXRlbmFuY3kgZXZlbiBjb21l
cyBpbnRvIHBsYXk/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmVjYXVzZSBJIGFtIGNvbXBs
ZXRlbHkgbm90IHNlZWluZyBob3cgdGhlc2UgYXJlIHJlbGF0ZWQuPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgT24gMDEvMjMvMjAxMyAxMjo0NiBQTSwgQW50aG9ueSBOYWRhbGluIHdyb3Rl
Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCB3aWxsIG5vdCB3b3JrIHRoZSB3YXkg
eW91IGhhdmUgaXQsIGFzIHBlb3BsZSBkbyBtdWx0aS10ZW5kZW5jeSBkaWZmZXJlbnQgYW5kIHRo
ZXkgYXJlIGFscmVhZHkgc3R1Y2sgd2l0aCB0aGUgbWV0aG9kIHRoYXQgdGhleSBoYXZlIGNob3Nl
biwgc28gdGhleSBuZWVkIHRoZSBmbGV4YWJpbGl0eSwgdG8gcmVzdHJpY3QgdGhpcyBpcyBudXRz
IGFzIHBlb3BsZSB3b24mIzM5O3QgdXNlIGl0Ljxicj4NCg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEp1c3RpbiBSaWNoZXIgW21h
aWx0bzo8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3Jn
PC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBKYW51
YXJ5IDIzLCAyMDEzIDk6MjcgQU08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IEFu
dGhvbnkgTmFkYWxpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogTmF0IFNha2lt
dXJhOyBTaGl1IEZ1biA8YSBocmVmPSJtYWlsdG86UG9vbiUzQm9hdXRoQGlldGYub3JnIj5Qb29u
O29hdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBDb25jZXJuaW5nIE9BdXRoIGludHJvc3BlY3Rpb248YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBjb21w
bGV0ZWx5IGRpc2FncmVlIHdpdGggdGhpcyBhc3Nlc3NtZW50LiBNdWx0aS10ZW5hbmN5IHdpbGwg
d29yayBqdXN0IGZpbmUgKG9yIGV2ZW4gYmV0dGVyKSBpZiBldmVyeW9uZSB1c2VzIHRoZSBzYW1l
IHBhdHRlcm4uIFRlbGxpbmcgc29tZW9uZSAmcXVvdDtpdCBtaWdodCBiZSB0aHJlZSBkaWZmZXJl
bnQgdXJscyBvciBpdCBtaWdodCBiZSBhbGwgb25lIHVybCB3aXRoIGEgcGFyYW1ldGVyJnF1b3Q7
IGlzIGp1c3QgYXNraW5nIGZvciBhIGNvbXBsZXRlIGRpc2FzdGVyLiBXaGF0IGRvZXMgdGhlIGZs
ZXhpYmlsaXR5IG9mIGFsbG93aW5nIHR3byBhcHByb2FjaGVzIGFjdHVhbGx5IGFjY29tcGxpc2g/
PGJyPg0KDQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgWW91IGNhbiBhcmd1ZSBhYm91dCB0aGUgbWVyaXRzIG9mIGVpdGhlciBhcHByb2FjaCwg
YnV0IGhhdmluZyBib3RoIGFzIHVuc3BlY2lmaWVkIG9wdGlvbnMgZm9yIHJlZ2lzdHJhdGlvbiwg
d2hpY2ggaXMgbWVhbnQgdG8gaGVscCB0aGluZ3MgZ2V0IGdvaW5nIGluIGEgY29sZC1ib290IGVu
dmlyb25tZW50LCBpcyBqdXN0IHBsYWluIG51dHMuPGJyPg0KDQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzIzLzIwMTMgMTI6MjEgUE0sIEFudGhvbnkg
TmFkYWxpbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2lzdHJh
dGlvbiBoYXMgdG8gd29yayBpbiBhIG11bHRpLXRlbmFudCBlbnZpcm9ubWVudCAmbmJzcDtzbyBm
bGV4aWJpbGl0eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbmVlZGVkPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IEZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86
anJpY2hlckBtaXRyZS5vcmciPmpyaWNoZXJAbWl0cmUub3JnPC9hPl08YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyA5OjE4
IEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogQW50aG9ueSBOYWRhbGlu
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogTmF0IFNha2ltdXJhOyBTaGl1
IEZ1biA8YSBocmVmPSJtYWlsdG86UG9vbiUzQm9hdXRoQGlldGYub3JnIj5Qb29uO29hdXRoQGll
dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gQ29uY2VybmluZyBPQXV0aCBpbnRyb3NwZWN0aW9uPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmVj
YXVzZSB0aGVuIG5vYm9keSB3b3VsZCBrbm93IGhvdyB0byBhY3R1YWxseSB1c2UgdGhlIHRoaW5n
Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IEluIG15IG9waW5pb24sIHRoaXMgaXMgYSBrZXkgcGxhY2Ugd2hlcmUgdGhp
cyBraW5kIG9mIGZsZXhpYmlsaXR5IGlzIGEgdmVyeSBiYWQgdGhpbmcuIFJlZ2lzdHJhdGlvbiBu
ZWVkcyB0byB3b3JrIG9uZSBmYWlybHkgcHJlZGljdGFibGUgd2F5Ljxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tIEp1
c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzIzLzIwMTMgMTI6MTQgUE0sIEFudGhvbnkgTmFkYWxpbiB3
cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaHkgbm90IGp1c3Qg
aGF2ZSBhIHBoeXNpY2FsIGFuZCBsb2dpY2FsIGVuZHBvaW50IG9wdGlvbnM8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOkZyb20lM0FvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIj5Gcm9tOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP
bjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlaGFsZiBPZiBKdXN0aW4g
UmljaGVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogV2VkbmVz
ZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDc6NDcgQU08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBUbzogTmF0IFNha2ltdXJhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgQ2M6IFNoaXUgRnVuIDxhIGhyZWY9Im1haWx0bzpQb29uJTNCb2F1dGhAaWV0Zi5v
cmciPlBvb247b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ29uY2VybmluZyBPQXV0aCBpbnRyb3Nw
ZWN0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaGljaCBicmluZ3MgdXAgYW4gaW50ZXJlc3Rpbmcg
cXVlc3Rpb24gZm9yIHRoZSBSZWdpc3RyYXRpb24gZG9jOiByaWdodCBub3csIGl0JiMzOTtzIHNl
dCB1cCBhcyBhIHNpbmdsZSBlbmRwb2ludCB3aXRoIHRocmVlIG9wZXJhdGlvbnMuIFdlIGNvdWxk
IGluc3RlYWQgZGVmaW5lIHRocmVlIGVuZHBvaW50cyBmb3IgdGhlIGRpZmZlcmVudCBvcGVyYXRp
b25zLjxicj4NCg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJJiMzOTt2ZSBub3QgYmVlbiBrZWVuIHRvIG1ha2Ug
dGhhdCBkZWVwIG9mIGEgY3V0dGluZyBjaGFuZ2UgdG8gaXQsIGJ1dCBpdCB3b3VsZCBjZXJ0YWlu
bHkgYmUgY2xlYW5lciBhbmQgbW9yZSBSRVNUZnVsIEFQSSBkZXNpZ24uIFdoYXQgZG8gb3RoZXJz
IHRoaW5rPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzIyLzIwMTMgMDg6MDUg
UE0sIE5hdCBTYWtpbXVyYSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgJnF1b3Q7QWN0aW9uJnF1b3Q7IGdvZXMgYWdhaW5zdCBSRVNUIHByaW5jaXBsZS48
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkbyBub3QgdGhpbmsg
aXQgaXMgYSBnb29kIGlkZWEuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ID1uYXQgdmlhIGlQ
aG9uZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKYW4gMjMsIDIwMTMgNDowMBskQiEiGyhC
SnVzdGluIFJpY2hlciZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciPmpyaWNo
ZXJAbWl0cmUub3JnPC9hPiZndDsgJm5ic3A7GyRCJE4lYSVDJTshPCU4GyhCOjxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKENDJiMzOTtpbmcgdGhlIHdvcmtpbmcgZ3JvdXApPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSYjMzk7bSBub3Qgc3VyZSB3aGF0IHRoZSAm
cXVvdDthY3Rpb24vb3BlcmF0aW9uJnF1b3Q7IGZsYWcgd291bGQgYWNjb21wbGlzaC4gVGhlIGlk
ZWEgYmVoaW5kIGhhdmluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGluIE9BdXRoIGlzIHRoYXQgdGhl
eSBlYWNoIGRvIGRpZmZlcmVudCBraW5kcyBvZiB0aGluZ3MuIFRoZSBvbmx5ICZxdW90O2FjdGlv
bi9vcGVyYXRpb24mcXVvdDsgdGhhdCBJIGhhZCBlbnZpc2lvbmVkIGZvciB0aGUgaW50cm9zcGVj
dGlvbiBlbmRwb2ludCBpcyBpbnRyb3NwZWN0aW9uIGl0c2VsZjogJnF1b3Q7SSBoYXZlIGEgdG9r
ZW4sIHdoYXQgZG9lcyBpdCBtZWFuPyZxdW90Ozxicj4NCg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgTm90ZSB0aGF0IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCAqY2FuKiBhbHJl
YWR5IGJlIHVzZWQgYXQgdGhpcyBlbmRwb2ludCBpZiB0aGUgc2VydmVyIHN1cHBvcnRzIHRoYXQg
YXMgcGFydCBvZiB0aGVpciBjbGllbnQgY3JlZGVudGlhbHMgc2V0dXAuIFRoZSBleGFtcGxlcyB1
c2UgSFRUUCBCYXNpYyB3aXRoIGNsaWVudCBpZCBhbmQgc2VjcmV0IHJpZ2h0IG5vdy4gQmFzaWNh
bGx5LCB0aGUgY2xpZW50IGNhbiBhdXRoZW50aWNhdGUgaG93ZXZlciBpdCB3YW50cywgaW5jbHVk
aW5nIGFueSBvZiB0aGUgbWV0aG9kcyB0aGF0IE9BdXRoMiBhbGxvd3Mgb24gdGhlIHRva2VuIGVu
ZHBvaW50LiBJdCBjb3VsZCBhbHNvIGF1dGhlbnRpY2F0ZSB3aXRoIGFuIGFjY2VzcyB0b2tlbi4g
QXQgbGVhc3QsIHRoYXQmIzM5O3MgdGhlIGludGVudCBvZiB0aGUgaW50cm9zcGVjdGlvbiBkcmFm
dCAtLSBpZiB0aGF0JiMzOTtzIHVuY2xlYXIsIEkmIzM5O2QgYmUgaGFwcHkgdG8gYWNjZXB0IHN1
Z2dlc3RlZCBjaGFuZ2VzIHRvIGNsYXJpZnkgdGhpcyB0ZXh0Ljxicj4NCg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7LS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgT24gMDEvMjIvMjAxMyAwMTowMCBQTSwgU2hpdSBGdW4gUG9vbiB3cm90ZTo8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKdXN0aW4s
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIHNwZWMgaXMg
bG9va2luZyBnb29kLi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IE9uZSB0aGluZyBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIGlzIHRvIGFkZCAmcXVvdDthY3Rp
b24mcXVvdDsvJnF1b3Q7b3BlcmF0aW9uJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdGhlIHJlcXVlc3QuICZuYnNwOyhhbmQgcG90ZW50
aWFsbHkgYWRkIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCk8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvIHRoZSByZXF1ZXN0IHdpbGwgYmUgbGlrZSA6PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG9rZW4gUkVR
VUlSRUQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv
cGVyYXRpb24gKHdvcmRpbmcgdG8gYmUgZGV0ZXJtaW5lKSAmbmJzcDtPUFRJT05BTCBpbnF1aXJl
IChkZWZhdWx0KSB8IHJldm9rZSAuLi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyByZXNvdXJjZV9pZCBPUFRJT05BTDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsaWVudF9pZCBPUFRJT05BTDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsaWVudF9zZWNyZXQg
T1BUSU9OQUw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFuZCBm
b3IgdGhlIE9BdXRoIGNsaWVudCBpbmZvcm1hdGlvbiwgaXQgc2hvdWxkIGJlIGFuIG9wdGlvbmFs
IHBhcmFtZXRlciAoaW4gY2FzZSBpdCBpcyBhIHB1YmxpYyBjbGllbnQgb3IgY2xpZW50IGlzIGF1
dGhlbnRpY2F0ZWQgd2l0aCBTU0wgbXV0dWFsIGF1dGhlbnRpY2F0aW9uKS48YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBjb25zaWRlci48YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNoaXVGdW48YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxicj4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+
PGJyIGNsZWFyPSJhbGwiPjxkaXY+PGJyPjwvZGl2Pi0tIDxicj5OYXQgU2FraW11cmEgKD1uYXQp
PGRpdj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+PGEgaHJlZj0iaHR0cDovL25hdC5z
YWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9h
Pjxicj5AX25hdF9lbjwvZGl2Pg0KDQo8L2Rpdj48L2Rpdj4NCg==
--047d7b66f239308fcb04d48c496b--

From Michael.Jones@microsoft.com  Wed Jan 30 18:32:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5421F843F for ; Wed, 30 Jan 2013 18:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOKE8ruHT47f for ; Wed, 30 Jan 2013 18:32:06 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7449621F86C3 for ; Wed, 30 Jan 2013 18:32:05 -0800 (PST)
Received: from BL2FFO11FD015.protection.gbl (10.173.161.203) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 31 Jan 2013 02:31:51 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 31 Jan 2013 02:31:50 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 02:31:22 +0000
From: Mike Jones 
To: Nat Sakimura , John Bradley 
Thread-Topic: [OAUTH-WG] Registration endpoints? (was: Re:  Concerning OAuth )
Thread-Index: AQHN/1nMLfRUxGWVckqo/SmDoXBlF5hitwvA
Date: Thu, 31 Jan 2013 02:31:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673F3A6E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943673F3A6ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(51704002)(13464002)(377454001)(51444002)(377424002)(199002)(479174001)(24454001)(164054002)(31966008)(49866001)(44976002)(79102001)(47976001)(74662001)(54316002)(63696002)(47446002)(46102001)(47736001)(5343635001)(4396001)(74502001)(77982001)(59766001)(15202345001)(20776003)(5343655001)(50986001)(550184003)(56776001)(56816002)(55846006)(53806001)(33656001)(54356001)(16406001)(51856001)(16236675001)(76482001)(512904001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0743E8D0A6
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 02:32:10 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943673F3A6ETK5EX14MBXC284r_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

OAuth *never* makes a distinction between what GET and POST do.  (Yes, they=
 pass the input parameters differently.)  I *really* don=1B$B!G=1B(Bt think=
 we should start doing this now for new operations.  It will likely only co=
nfuse developers and make things harder for them - especially when using so=
ftware that may not always give them full access to all HTTP verbs and head=
er parameters.

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Wednesday, January 30, 2013 6:22 PM
To: John Bradley
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )

(I changed the subject to match the content.)

Right. It does not have to be three endpoints. One endpoint would do (thoug=
h it depends on how you count the URLs).

However, I would do it slightly differently than you (John B.) proposes.

As an example, let the registration endpoint be named /clients, which repre=
sents the collection of registered clients.
(This is the registration endpoint.)

Then,

POST to the /clients would create the resource in question. (client associa=
te)
POST to /clients?client_id=3D12345 and post params (the resource URL) would=
 update the resource.
This is not an idempotent request, and could update any portion of the reso=
urce.
In particular, client_secret=3Dnull or something could mean "rotate secret.=
"

GET to /clients?client_id=3D12345 would return the client registration data=
. It is idempotent.
DELETE to /clients?client_id=3D12345 would delete the resource.

PUT to /clients?client_id=3D12345 (the resource URL) would replace the reso=
urce, and is idempotent.
 (I am not sure if we need this. Probably better not have one.)

For any of the above request except DELETE, the response should return the =
entire object.

(For the purists: Right. This still could be improved by using URI template=
.
The server could publish the server metadata including URI template for the=
 registration etc.
At that point, server is freed from forced to use the query parameters. For=
 example,
instead of /clients?client_id=3D12345, it could have instructed the client =
to use /clients/12345/
or /clients/id/12345 etc. but I think that is going too far.)

Nat
2013/1/31 John Bradley >
That is better, but I don't see an advantage to that over using a query par=
ameter.

They are equally restful or not as the case may be.

To be more restful I think you want a single endpoint using HTTP verbs.

POST /reg_endpoint?paramaters =1B$B!D=1B(B  -> register
PUT  /reg_endpoint?client_id=3D12345¶maters -> update
PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue

The downside is developers understanding

On 2013-01-30, at 1:17 PM, Justin Richer > wrote:

>
> On 01/30/2013 10:55 AM, John Bradley wrote:
>> My feeling was that letting the registration endpoint be a single URL (a=
ny url) and using query paramaters was easer for servers and clients.
>>
>> Saying take the base URI for the registration endpoint and append these =
paths to it to do different operations seems more likely to go wrong fro de=
velopers.
> Right, and to clarify, this isn't what I was saying. The spec wouldn't sp=
ecify the path at all, just say that they're three different endpoint URLs.=
 The same way that we specify that the auth endpoint and token endpoint are=
 different URLs.
>
> I think my example might have been misleading. The URLs could just as eas=
ily be:
>
> client_register -> /register_a_new_client
> rotate_secret -> /client/go_get_a_secret_or_something
> client_update-> /maintenance/update_client_information
>
>
>
>>
>> Allowing both bath and query parameters is the worst option.
>>
>> I am sympathetic with using POST and PUT and perhaps GET but I worry abo=
ut OAuth developers not getting it.
>>
>> I also don't get Tony's point about multi tenancy.  If each tenant can h=
ave there own registration endpoint I don't see a problem beyond finding th=
e endpoint and that is what we have WF for.
> Exactly. And to Bill's point in another thread, we could also register a =
link type for each endpoint to help facilitate discovery: http://tools.ietf=
.org/html/draft-wmills-oauth-lrdd-06
>
> -- Justin
>
>>
>> John B.
>>
>> On 2013-01-24, at 11:26 AM, Justin Richer > wrote:
>>
>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>> I like this most, would rename it to say
>>>>
>>>> /oauth/client/registration
>>>> or
>>>> /oauth/client-registration
>>>>
>>>> etc
>>>>
>>>> and reword the spec such that it will let those who implement do it wi=
th one endpoint or many, whatever is preferred
>>>>
>>> That's the whole point of this discussion -- I don't believe you can ha=
ve it both ways.
>>>
>>> In one way, you say there are three endpoints and, if you're keeping wi=
th the rest of OAuth, you don't give them official URL patterns that they m=
ust follow. How the client gets those endpoints is up to discovery or confi=
guration, but the client has an internal map from each bit of functionality=
 to a particular URL that's specific to the service, much in the same way t=
hat the client today has to map the authorization and token endpoints. In t=
he other method, you've got one endpoint that the client sends a well-defin=
ed parameter to in order to accomplish the same goal.
>>>
>>> So if you allow both at once, does a client send the "operation" parame=
ter or not? Is it looking for one url or three to store in its configuratio=
n? I don't think this level of flexibility buys you anything useful, and I =
strongly believe that it will deeply hurt the functionality of dynamic regi=
stration if it's allowed.
>>>
>>> As it stands today, you can still make the URL whatever you want. If we=
 went with three endpoints you could also make those URLs whatever you want=
ed. Nobody has yet pointed out to me what the actual benefit is of making b=
oth valid.
>>>
>>> I personally prefer the method of three endpoint URLs because it's clea=
ner and semantically equivalent, but I am hesitant to change that behavior =
unless there's strong working group support for it. I haven't seen real sup=
port for it yet -- it's not a good call to make it fully RESTful, and it's =
not a good call to leave it undefined. A client MUST have a very clear reci=
pe of what to do on startup for this to work in the wild.
>>>
>>> -- Justin
>>>
>>>>>
>>>>> help multitenancy? How does it even affect that use case? Consider th=
at
>>>>> the base URL for all of these is completely up to the host environmen=
t
>>>>> (nothing is bound to the root URL). Consider that clients still have =
to
>>>>> know what the URL (or URLs) are, in either case. Consider that client=
s
>>>>> still need to know how to manage all the parameters and responses.
>>>>>
>>>>> If anything, keeping it the way that it is with a single URL could be
>>>>> argued to help multitenancy because setting up routing to multiple UR=
L
>>>>> endpoints can sometimes be problematic in hosted environments. Howeve=
r,
>>>>> OAuth already defines a bunch of endpoints, and we have to define at
>>>>> least one more with this extension, so I'm not convinced that having
>>>>> three with specific functions is really any different from having one
>>>>> with three functions from a development, deployment, and implementati=
on
>>>>> perspective. I can tell you from experience that in our own server co=
de,
>>>>> the difference is trivial. (And from OAuth1 experience, you can alway=
s
>>>>> have a query parameter as part of your endpoint URL if you need to. Y=
ou
>>>>> might hate yourself for doing it that way, but nothing says your base
>>>>> URL can't already have parameters on it. A client just needs to know =
how
>>>>> to appropriately tack its parameters onto an existing URL, and any HT=
TP
>>>>> client worth its salt will know how to augment a query parameter set
>>>>> with new items.)
>>>>>
>>>>> The *real* difference between the two approaches is a philosophical
>>>>> design one. The former overloads one URL with multiple functions
>>>>> switched by a flag, the latter uses the URL itself as an implicit fla=
g.
>>>>> Under the hood, these could (and in many cases will) be all served by
>>>>> the same chunks of code. The only difference is how this switch in
>>>>> functionality is presented.
>>>>>
>>>>>
>>>>> With that said, can somebody please explain to me how allowing *both*=
 of
>>>>> these as options simultaneously (what I understand Tony to be
>>>>> suggesting) is a good idea, or how multitenancy even comes into play?
>>>>> Because I am completely not seeing how these are related.
>>>>>
>>>>> Thanks,
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>> It will not work the way you have it, as people do multi-tendency di=
fferent and they are already stuck with the method that they have chosen, s=
o they need the flexability, to restrict this is nuts as people won't use i=
t.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> I completely disagree with this assessment. Multi-tenancy will work =
just fine (or even better) if everyone uses the same pattern. Telling someo=
ne "it might be three different urls or it might be all one url with a para=
meter" is just asking for a complete disaster. What does the flexibility of=
 allowing two approaches actually accomplish?
>>>>>>
>>>>>> You can argue about the merits of either approach, but having both a=
s unspecified options for registration, which is meant to help things get g=
oing in a cold-boot environment, is just plain nuts.
>>>>>>
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>> Registration has to work in a multi-tenant environment  so flexibil=
ity
>>>>>>> is needed
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>
>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>
>>>>>>> In my opinion, this is a key place where this kind of flexibility i=
s a very bad thing. Registration needs to work one fairly predictable way.
>>>>>>>
>>>>>>> -- Justin
>>>>>>>
>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura
>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>
>>>>>>>> Which brings up an interesting question for the Registration doc: =
right now, it's set up as a single endpoint with three operations. We could=
 instead define three endpoints for the different operations.
>>>>>>>>
>>>>>>>> I've not been keen to make that deep of a cutting change to it, bu=
t it would certainly be cleaner and more RESTful API design. What do others=
 think?
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>
>>>>>>>>> =3Dnat via iPhone
>>>>>>>>>
>>>>>>>>> Jan 23, 2013 4:00=1B$B!"=1B(BJustin Richer>  =1B$B$N%a%C%;!<%8=1B(B:
>>>>>>>>>
>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>
>>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. =
The idea behind having different endpoints in OAuth is that they each do di=
fferent kinds of things. The only "action/operation" that I had envisioned =
for the introspection endpoint is introspection itself: "I have a token, wh=
at does it mean?"
>>>>>>>>>>
>>>>>>>>>> Note that client_id and client_secret *can* already be used at t=
his endpoint if the server supports that as part of their client credential=
s setup. The examples use HTTP Basic with client id and secret right now. B=
asically, the client can authenticate however it wants, including any of th=
e methods that OAuth2 allows on the token endpoint. It could also authentic=
ate with an access token. At least, that's the intent of the introspection =
draft -- if that's unclear, I'd be happy to accept suggested changes to cla=
rify this text.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>> Justin,
>>>>>>>>>>>
>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>
>>>>>>>>>>> One thing I would like to recommend is to add "action"/"operati=
on"
>>>>>>>>>>> to the request.  (and potentially add client_id and client_secr=
et)
>>>>>>>>>>>
>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED
>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default)=
 | revoke ...
>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>
>>>>>>>>>>> And for the OAuth client information, it should be an optional =
parameter (in case it is a public client or client is authenticated with SS=
L mutual authentication).
>>>>>>>>>>>
>>>>>>>>>>> Please consider.
>>>>>>>>>>>
>>>>>>>>>>> ShiuFun
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>

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



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

--_000_4E1F6AAD24975D4BA5B1680429673943673F3A6ETK5EX14MBXC284r_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable











OAuth *never* make=
s a distinction between what GET and POST do.  (Yes, they pass the inp=
ut parameters differently.)  I *really* don=1B$B!G=1B(Bt think =
we
 should start doing this now for new operations.  It will likely only =
confuse developers and make things harder for them – especially when =
using software that may not always give them full access to all HTTP verbs =
and header parameters.


 <=
/p>

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


 <=
/p>

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, January 30, 2013 6:22 PM

To: John Bradley

Cc: oauth@ietf.org

Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAu=
th )


 




(I changed the subject to match the content.) <=
o:p>






 




Right. It does not have to be three endpoints. One e=
ndpoint would do (though it depends on how you count the URLs).  =





 






However, I would do it slightly differently than you=
 (John B.) proposes. 






 






As an example, let the registration endpoint be name=
d /clients, which represents the collection of registered clients. 






(This is the registration endpoint.) 






 




Then, 






 






POST to the /clients would create the resource in qu=
estion. (client associate) 






POST to /clients?client_id=3D12345 and post params (=
the resource URL) would update the resource. 






This is not an idempotent request, and could update =
any portion of the resource. 






In particular, client_secret=3Dnull or something cou=
ld mean "rotate secret."






 






GET to /clients?client_id=3D12345 would return the c=
lient registration data. It is idempotent. 






DELETE to /clients?client_id=3D12345 would delete th=
e resource. 






 






PUT to /clients?client_id=3D12345 (the resource=
 URL) would replace the resource, and is idempotent. <=
/p>





 (I am not sure if we need this. Probably bette=
r not have one.) 






 






For any of the above request except DELETE, the resp=
onse should return the entire object. 






 






(For the purists: Right. This still could be improve=
d by using URI template. 






The server could publish the server metadata includi=
ng URI template for the registration etc. 






At that point, server is freed from forced to use th=
e query parameters. For example, 






instead of /clients?client_id=3D12345, it could have=
 instructed the client to use /clients/12345/ 






or /clients/id/12345 etc. but I think that is going =
too far.)






 






Nat




2013/1/31 John Bradley <ve7jtb@ve7jtb.com>


That is better, but I don't see an advantage to that=
 over using a query parameter.



They are equally restful or not as the case may be.



To be more restful I think you want a single endpoint using HTTP verbs.



POST /reg_endpoint?paramaters =1B$B!D=1B(B  -> register

PUT  /reg_endpoint?client_id=3D12345&paramaters -> update

PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue



The downside is developers understanding








On 2013-01-30, at 1:17 PM, Justin Richer <jricher@mitre.org> wrote:



>

> On 01/30/2013 10:55 AM, John Bradley wrote:

>> My feeling was that letting the registration endpoint be a single =
URL (any url) and using query paramaters was easer for servers and clients.=


>>

>> Saying take the base URI for the registration endpoint and append =
these paths to it to do different operations seems more likely to go wrong =
fro developers.

> Right, and to clarify, this isn't what I was saying. The spec wouldn't=
 specify the path at all, just say that they're three different endpoint UR=
Ls. The same way that we specify that the auth endpoint and token endpoint =
are different URLs.

>

> I think my example might have been misleading. The URLs could just as =
easily be:

>

> client_register -> /register_a_new_client

> rotate_secret -> /client/go_get_a_secret_or_something

> client_update-> /maintenance/update_client_information

>

>

>

>>

>> Allowing both bath and query parameters is the worst option.

>>

>> I am sympathetic with using POST and PUT and perhaps GET but I wor=
ry about OAuth developers not getting it.

>>

>> I also don't get Tony's point about multi tenancy.  If each t=
enant can have there own registration endpoint I don't see a problem beyond=
 finding the endpoint and that is what we have WF for.

> Exactly. And to Bill's point in another thread, we could also register=
 a link type for each endpoint to help facilitate discovery:
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06

>

> -- Justin

>

>>

>> John B.

>>

>> On 2013-01-24, at 11:26 AM, Justin Richer <jricher@mitre.org> wrote:

>>

>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:

>>>> I like this most, would rename it to say

>>>>

>>>> /oauth/client/registration

>>>> or

>>>> /oauth/client-registration

>>>>

>>>> etc

>>>>

>>>> and reword the spec such that it will let those who implem=
ent do it with one endpoint or many, whatever is preferred

>>>>

>>> That's the whole point of this discussion -- I don't believe y=
ou can have it both ways.

>>>

>>> In one way, you say there are three endpoints and, if you're k=
eeping with the rest of OAuth, you don't give them official URL patterns th=
at they must follow. How the client gets those endpoints is up to discovery=
 or configuration, but the client has an
 internal map from each bit of functionality to a particular URL that's spe=
cific to the service, much in the same way that the client today has to map=
 the authorization and token endpoints. In the other method, you've got one=
 endpoint that the client sends
 a well-defined parameter to in order to accomplish the same goal.

>>>

>>> So if you allow both at once, does a client send the "ope=
ration" parameter or not? Is it looking for one url or three to store =
in its configuration? I don't think this level of flexibility buys you anyt=
hing useful, and I strongly believe that it will deeply
 hurt the functionality of dynamic registration if it's allowed.

>>>

>>> As it stands today, you can still make the URL whatever you wa=
nt. If we went with three endpoints you could also make those URLs whatever=
 you wanted. Nobody has yet pointed out to me what the actual benefit is of=
 making both valid.

>>>

>>> I personally prefer the method of three endpoint URLs because =
it's cleaner and semantically equivalent, but I am hesitant to change that =
behavior unless there's strong working group support for it. I haven't seen=
 real support for it yet -- it's not a good
 call to make it fully RESTful, and it's not a good call to leave it undefi=
ned. A client MUST have a very clear recipe of what to do on startup for th=
is to work in the wild.

>>>

>>> -- Justin

>>>

>>>>>

>>>>> help multitenancy? How does it even affect that use ca=
se? Consider that

>>>>> the base URL for all of these is completely up to the =
host environment

>>>>> (nothing is bound to the root URL). Consider that clie=
nts still have to

>>>>> know what the URL (or URLs) are, in either case. Consi=
der that clients

>>>>> still need to know how to manage all the parameters an=
d responses.

>>>>>

>>>>> If anything, keeping it the way that it is with a sing=
le URL could be

>>>>> argued to help multitenancy because setting up routing=
 to multiple URL

>>>>> endpoints can sometimes be problematic in hosted envir=
onments. However,

>>>>> OAuth already defines a bunch of endpoints, and we hav=
e to define at

>>>>> least one more with this extension, so I'm not convinc=
ed that having

>>>>> three with specific functions is really any different =
from having one

>>>>> with three functions from a development, deployment, a=
nd implementation

>>>>> perspective. I can tell you from experience that in ou=
r own server code,

>>>>> the difference is trivial. (And from OAuth1 experience=
, you can always

>>>>> have a query parameter as part of your endpoint URL if=
 you need to. You

>>>>> might hate yourself for doing it that way, but nothing=
 says your base

>>>>> URL can't already have parameters on it. A client just=
 needs to know how

>>>>> to appropriately tack its parameters onto an existing =
URL, and any HTTP

>>>>> client worth its salt will know how to augment a query=
 parameter set

>>>>> with new items.)

>>>>>

>>>>> The *real* difference between the two approaches is a =
philosophical

>>>>> design one. The former overloads one URL with multiple=
 functions

>>>>> switched by a flag, the latter uses the URL itself as =
an implicit flag.

>>>>> Under the hood, these could (and in many cases will) b=
e all served by

>>>>> the same chunks of code. The only difference is how th=
is switch in

>>>>> functionality is presented.

>>>>>

>>>>>

>>>>> With that said, can somebody please explain to me how =
allowing *both* of

>>>>> these as options simultaneously (what I understand Ton=
y to be

>>>>> suggesting) is a good idea, or how multitenancy even c=
omes into play?

>>>>> Because I am completely not seeing how these are relat=
ed.

>>>>>

>>>>> Thanks,

>>>>> -- Justin

>>>>>

>>>>>

>>>>>

>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

>>>>>> It will not work the way you have it, as people do=
 multi-tendency different and they are already stuck with the method that t=
hey have chosen, so they need the flexability, to restrict this is nuts as =
people won't use it.

>>>>>>

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

>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM

>>>>>> To: Anthony Nadalin

>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspec=
tion

>>>>>>

>>>>>> I completely disagree with this assessment. Multi-=
tenancy will work just fine (or even better) if everyone uses the same patt=
ern. Telling someone "it might be three different urls or it might be =
all one url with a parameter" is just asking for a complete
 disaster. What does the flexibility of allowing two approaches actually ac=
complish?

>>>>>>

>>>>>> You can argue about the merits of either approach,=
 but having both as unspecified options for registration, which is meant to=
 help things get going in a cold-boot environment, is just plain nuts.

>>>>>>

>>>>>>

>>>>>> -- Justin

>>>>>>

>>>>>>

>>>>>>

>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

>>>>>>> Registration has to work in a multi-tenant env=
ironment  so flexibility

>>>>>>> is needed

>>>>>>>

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

>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM

>>>>>>> To: Anthony Nadalin

>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth intro=
spection

>>>>>>>

>>>>>>> Because then nobody would know how to actually=
 use the thing.

>>>>>>>

>>>>>>> In my opinion, this is a key place where this =
kind of flexibility is a very bad thing. Registration needs to work one fai=
rly predictable way.

>>>>>>>

>>>>>>> -- Justin

>>>>>>>

>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:=


>>>>>>>> Why not just have a physical and logical e=
ndpoint options

>>>>>>>>

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

>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On

>>>>>>>> Behalf Of Justin Richer

>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM<=
br>
>>>>>>>> To: Nat Sakimura

>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org

>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth i=
ntrospection

>>>>>>>>

>>>>>>>> Which brings up an interesting question fo=
r the Registration doc: right now, it's set up as a single endpoint with th=
ree operations. We could instead define three endpoints for the different o=
perations.

>>>>>>>>

>>>>>>>> I've not been keen to make that deep of a =
cutting change to it, but it would certainly be cleaner and more RESTful AP=
I design. What do others think?

>>>>>>>>

>>>>>>>> -- Justin

>>>>>>>>

>>>>>>>>

>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote=
:

>>>>>>>>> "Action" goes against REST p=
rinciple.

>>>>>>>>> I do not think it is a good idea.

>>>>>>>>>

>>>>>>>>> =3Dnat via iPhone

>>>>>>>>>

>>>>>>>>> Jan 23, 2013 4:00=1B=
$B!"=1B(BJustin Richer<jrich=
er@mitre.org>  =1B$B$N%a%C%;!<%8=1B(B:=


>>>>>>>>>

>>>>>>>>>> (CC'ing the working group)

>>>>>>>>>>

>>>>>>>>>> I'm not sure what the "action=
/operation" flag would accomplish. The idea behind having different en=
dpoints in OAuth is that they each do different kinds of things. The only &=
quot;action/operation" that I had envisioned for the introspection end=
point is
 introspection itself: "I have a token, what does it mean?"

>>>>>>>>>>

>>>>>>>>>> Note that client_id and client_sec=
ret *can* already be used at this endpoint if the server supports that as p=
art of their client credentials setup. The examples use HTTP Basic with cli=
ent id and secret right now. Basically, the client can authenticate
 however it wants, including any of the methods that OAuth2 allows on the t=
oken endpoint. It could also authenticate with an access token. At least, t=
hat's the intent of the introspection draft -- if that's unclear, I'd be ha=
ppy to accept suggested changes
 to clarify this text.

>>>>>>>>>>

>>>>>>>>>>  -- Justin

>>>>>>>>>>

>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun P=
oon wrote:

>>>>>>>>>>> Justin,

>>>>>>>>>>>

>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>

>>>>>>>>>>> One thing I would like to reco=
mmend is to add "action"/"operation"

>>>>>>>>>>> to the request.  (and pot=
entially add client_id and client_secret)

>>>>>>>>>>>

>>>>>>>>>>> So the request will be like :<=
br>
>>>>>>>>>>> token REQUIRED

>>>>>>>>>>> operation (wording to be deter=
mine)  OPTIONAL inquire (default) | revoke ...

>>>>>>>>>>> resource_id OPTIONAL

>>>>>>>>>>> client_id OPTIONAL

>>>>>>>>>>> client_secret OPTIONAL

>>>>>>>>>>>

>>>>>>>>>>> And for the OAuth client infor=
mation, it should be an optional parameter (in case it is a public client o=
r client is authenticated with SSL mutual authentication).

>>>>>>>>>>>

>>>>>>>>>>> Please consider.

>>>>>>>>>>>

>>>>>>>>>>> ShiuFun

>>>>>>>>>> __________________________________=
_____________

>>>>>>>>>> OAuth mailing list

>>>>>>>>>> =
OAuth@ietf.org

>>>>>>>>>> 
https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>> __________________________________________=
_____

>>>>>>>> OAuth mailing list

>>>>>>>> OAuth@ie=
tf.org

>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=


>>>>>>>>

>>>>>>>>

>>>>>>>>

>>>>>>>

>>>>>>

>>>>>>

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

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

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oauth

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

>>> https://www.ietf.org/mailman/listinfo/oauth

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

















 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en












--_000_4E1F6AAD24975D4BA5B1680429673943673F3A6ETK5EX14MBXC284r_--

From sakimura@gmail.com  Wed Jan 30 18:59:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1068621F8757 for ; Wed, 30 Jan 2013 18:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level: 
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVMQDg7QFum7 for ; Wed, 30 Jan 2013 18:59:46 -0800 (PST)
Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 683A521F873E for ; Wed, 30 Jan 2013 18:59:45 -0800 (PST)
Received: by mail-ee0-f46.google.com with SMTP id e49so1176826eek.5 for ; Wed, 30 Jan 2013 18:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dxzSpmIZcc6kR3NVP4Tuzr0NcjljFFPHHExVy60DA0U=; b=lqbDaeqJPbKNLRRzr49j1LU3T/hm9w6ftUxOBWbWZAkuC2pMchOh6LyT0hXZtC/10U 2gaq8xiZP9VoPFkrhROOUaxuo6TJ0V/VvHeSsZ+bJR9rQcxq1gMouSjryyw82HcR6TF9 y/7iBVN07e69n05snjguYE/rQPNa1XFARTLGGN6i6n0rR6HpS7PXOZ1T1thegBx4ap8l wBj1Obl13MRpJwUAbhmqf+9Sm/zdC6A/RwNW8Wx/Uv6e4mbpXbpT92znO1KAmxeqhYZu uCnW731SrHJS17ZmCFww0DgLqXK5O/KFQ/Hp87RniwzHIvWgcFdioVK4HTchtDr6bEG8 cOAQ==
MIME-Version: 1.0
X-Received: by 10.14.178.196 with SMTP id f44mr22140745eem.14.1359601184367; Wed, 30 Jan 2013 18:59:44 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 30 Jan 2013 18:59:44 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943673F3A6E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References:  <4E1F6AAD24975D4BA5B1680429673943673F3A6E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Thu, 31 Jan 2013 11:59:44 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=047d7b622520a1632a04d48cd12e
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 02:59:50 -0000

--047d7b622520a1632a04d48cd12e
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

OAuth did not talk make distinctions or talk about HTTP methods because of
two reasons:

(1) Browser in the middle with HTTP redirect constraint.
(2) The protected resource is the party who decides what semantics is being
mapped to the HTTP methods.

The (1) above is just a work around for the constrained user agents.

Registration is server to server, so we do not need to be constrained by
this.

The (2) is a requirement to the framework because OAuth should not pollute
the space and should let the protected resource decide on their own.

Registration endpoint is a protected resource that should decide the
mapping.

We should not conflate with OAuth core framework requirements and protected
resource requirements.

Nat

2013/1/31 Mike Jones 

>  OAuth **never** makes a distinction between what GET and POST do.  (Yes,
> they pass the input parameters differently.)  I **really** don’t think we
> should start doing this now for new operations.  It will likely only
> confuse developers and make things harder for them - especially when using
> software that may not always give them full access to all HTTP verbs and
> header parameters.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, January 30, 2013 6:22 PM
> *To:* John Bradley
> *Cc:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
> ****
>
> ** **
>
> (I changed the subject to match the content.) ****
>
> ** **
>
> Right. It does not have to be three endpoints. One endpoint would do
> (though it depends on how you count the URLs).  ****
>
> ** **
>
> However, I would do it slightly differently than you (John B.) proposes. *
> ***
>
> ** **
>
> As an example, let the registration endpoint be named /clients, which
> represents the collection of registered clients. ****
>
> (This is the registration endpoint.) ****
>
> ** **
>
> Then, ****
>
> ** **
>
> POST to the /clients would create the resource in question. (client
> associate) ****
>
> POST to /clients?client_id=12345 and post params (the resource URL) would
> update the resource. ****
>
> This is not an idempotent request, and could update any portion of the
> resource. ****
>
> In particular, client_secret=null or something could mean "rotate secret."
> ****
>
> ** **
>
> GET to /clients?client_id=12345 would return the client registration data.
> It is idempotent. ****
>
> DELETE to /clients?client_id=12345 would delete the resource. ****
>
> ** **
>
> PUT to /clients?client_id=12345 (the resource URL) would replace the
> resource, and is idempotent. ****
>
>  (I am not sure if we need this. Probably better not have one.) ****
>
> ** **
>
> For any of the above request except DELETE, the response should return the
> entire object. ****
>
> ** **
>
> (For the purists: Right. This still could be improved by using URI
> template. ****
>
> The server could publish the server metadata including URI template for
> the registration etc. ****
>
> At that point, server is freed from forced to use the query parameters.
> For example, ****
>
> instead of /clients?client_id=12345, it could have instructed the client
> to use /clients/12345/ ****
>
> or /clients/id/12345 etc. but I think that is going too far.)****
>
> ** **
>
> Nat****
>
> 2013/1/31 John Bradley ****
>
> That is better, but I don't see an advantage to that over using a query
> parameter.
>
> They are equally restful or not as the case may be.
>
> To be more restful I think you want a single endpoint using HTTP verbs.
>
> POST /reg_endpoint?paramaters …  -> register
> PUT  /reg_endpoint?client_id=12345¶maters -> update
> PUT /reg_endpoint?client_id=12345&rotate_secret=true
>
> The downside is developers understanding****
>
>
> On 2013-01-30, at 1:17 PM, Justin Richer  wrote:
>
> >
> > On 01/30/2013 10:55 AM, John Bradley wrote:
> >> My feeling was that letting the registration endpoint be a single URL
> (any url) and using query paramaters was easer for servers and clients.
> >>
> >> Saying take the base URI for the registration endpoint and append these
> paths to it to do different operations seems more likely to go wrong fro
> developers.
> > Right, and to clarify, this isn't what I was saying. The spec wouldn't
> specify the path at all, just say that they're three different endpoint
> URLs. The same way that we specify that the auth endpoint and token
> endpoint are different URLs.
> >
> > I think my example might have been misleading. The URLs could just as
> easily be:
> >
> > client_register -> /register_a_new_client
> > rotate_secret -> /client/go_get_a_secret_or_something
> > client_update-> /maintenance/update_client_information
> >
> >
> >
> >>
> >> Allowing both bath and query parameters is the worst option.
> >>
> >> I am sympathetic with using POST and PUT and perhaps GET but I worry
> about OAuth developers not getting it.
> >>
> >> I also don't get Tony's point about multi tenancy.  If each tenant can
> have there own registration endpoint I don't see a problem beyond finding
> the endpoint and that is what we have WF for.
> > Exactly. And to Bill's point in another thread, we could also register a
> link type for each endpoint to help facilitate discovery:
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
> >
> > -- Justin
> >
> >>
> >> John B.
> >>
> >> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
> >>
> >>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
> >>>> I like this most, would rename it to say
> >>>>
> >>>> /oauth/client/registration
> >>>> or
> >>>> /oauth/client-registration
> >>>>
> >>>> etc
> >>>>
> >>>> and reword the spec such that it will let those who implement do it
> with one endpoint or many, whatever is preferred
> >>>>
> >>> That's the whole point of this discussion -- I don't believe you can
> have it both ways.
> >>>
> >>> In one way, you say there are three endpoints and, if you're keeping
> with the rest of OAuth, you don't give them official URL patterns that they
> must follow. How the client gets those endpoints is up to discovery or
> configuration, but the client has an internal map from each bit of
> functionality to a particular URL that's specific to the service, much in
> the same way that the client today has to map the authorization and token
> endpoints. In the other method, you've got one endpoint that the client
> sends a well-defined parameter to in order to accomplish the same goal.
> >>>
> >>> So if you allow both at once, does a client send the "operation"
> parameter or not? Is it looking for one url or three to store in its
> configuration? I don't think this level of flexibility buys you anything
> useful, and I strongly believe that it will deeply hurt the functionality
> of dynamic registration if it's allowed.
> >>>
> >>> As it stands today, you can still make the URL whatever you want. If
> we went with three endpoints you could also make those URLs whatever you
> wanted. Nobody has yet pointed out to me what the actual benefit is of
> making both valid.
> >>>
> >>> I personally prefer the method of three endpoint URLs because it's
> cleaner and semantically equivalent, but I am hesitant to change that
> behavior unless there's strong working group support for it. I haven't seen
> real support for it yet -- it's not a good call to make it fully RESTful,
> and it's not a good call to leave it undefined. A client MUST have a very
> clear recipe of what to do on startup for this to work in the wild.
> >>>
> >>> -- Justin
> >>>
> >>>>>
> >>>>> help multitenancy? How does it even affect that use case? Consider
> that
> >>>>> the base URL for all of these is completely up to the host
> environment
> >>>>> (nothing is bound to the root URL). Consider that clients still have
> to
> >>>>> know what the URL (or URLs) are, in either case. Consider that
> clients
> >>>>> still need to know how to manage all the parameters and responses.
> >>>>>
> >>>>> If anything, keeping it the way that it is with a single URL could be
> >>>>> argued to help multitenancy because setting up routing to multiple
> URL
> >>>>> endpoints can sometimes be problematic in hosted environments.
> However,
> >>>>> OAuth already defines a bunch of endpoints, and we have to define at
> >>>>> least one more with this extension, so I'm not convinced that having
> >>>>> three with specific functions is really any different from having one
> >>>>> with three functions from a development, deployment, and
> implementation
> >>>>> perspective. I can tell you from experience that in our own server
> code,
> >>>>> the difference is trivial. (And from OAuth1 experience, you can
> always
> >>>>> have a query parameter as part of your endpoint URL if you need to.
> You
> >>>>> might hate yourself for doing it that way, but nothing says your base
> >>>>> URL can't already have parameters on it. A client just needs to know
> how
> >>>>> to appropriately tack its parameters onto an existing URL, and any
> HTTP
> >>>>> client worth its salt will know how to augment a query parameter set
> >>>>> with new items.)
> >>>>>
> >>>>> The *real* difference between the two approaches is a philosophical
> >>>>> design one. The former overloads one URL with multiple functions
> >>>>> switched by a flag, the latter uses the URL itself as an implicit
> flag.
> >>>>> Under the hood, these could (and in many cases will) be all served by
> >>>>> the same chunks of code. The only difference is how this switch in
> >>>>> functionality is presented.
> >>>>>
> >>>>>
> >>>>> With that said, can somebody please explain to me how allowing
> *both* of
> >>>>> these as options simultaneously (what I understand Tony to be
> >>>>> suggesting) is a good idea, or how multitenancy even comes into play?
> >>>>> Because I am completely not seeing how these are related.
> >>>>>
> >>>>> Thanks,
> >>>>> -- Justin
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
> >>>>>> It will not work the way you have it, as people do multi-tendency
> different and they are already stuck with the method that they have chosen,
> so they need the flexability, to restrict this is nuts as people won't use
> it.
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Justin Richer [mailto:jricher@mitre.org]
> >>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
> >>>>>> To: Anthony Nadalin
> >>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
> >>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>
> >>>>>> I completely disagree with this assessment. Multi-tenancy will work
> just fine (or even better) if everyone uses the same pattern. Telling
> someone "it might be three different urls or it might be all one url with a
> parameter" is just asking for a complete disaster. What does the
> flexibility of allowing two approaches actually accomplish?
> >>>>>>
> >>>>>> You can argue about the merits of either approach, but having both
> as unspecified options for registration, which is meant to help things get
> going in a cold-boot environment, is just plain nuts.
> >>>>>>
> >>>>>>
> >>>>>> -- Justin
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
> >>>>>>> Registration has to work in a multi-tenant environment  so
> flexibility
> >>>>>>> is needed
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
> >>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
> >>>>>>> To: Anthony Nadalin
> >>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
> >>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>>
> >>>>>>> Because then nobody would know how to actually use the thing.
> >>>>>>>
> >>>>>>> In my opinion, this is a key place where this kind of flexibility
> is a very bad thing. Registration needs to work one fairly predictable way.
> >>>>>>>
> >>>>>>> -- Justin
> >>>>>>>
> >>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
> >>>>>>>> Why not just have a physical and logical endpoint options
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>>>>>> Behalf Of Justin Richer
> >>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
> >>>>>>>> To: Nat Sakimura
> >>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
> >>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> >>>>>>>>
> >>>>>>>> Which brings up an interesting question for the Registration doc:
> right now, it's set up as a single endpoint with three operations. We could
> instead define three endpoints for the different operations.
> >>>>>>>>
> >>>>>>>> I've not been keen to make that deep of a cutting change to it,
> but it would certainly be cleaner and more RESTful API design. What do
> others think?
> >>>>>>>>
> >>>>>>>> -- Justin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
> >>>>>>>>> "Action" goes against REST principle.
> >>>>>>>>> I do not think it is a good idea.
> >>>>>>>>>
> >>>>>>>>> =nat via iPhone
> >>>>>>>>>
> >>>>>>>>> Jan 23, 2013 4:00、Justin Richer  のメッセージ:
> >>>>>>>>>
> >>>>>>>>>> (CC'ing the working group)
> >>>>>>>>>>
> >>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish.
> The idea behind having different endpoints in OAuth is that they each do
> different kinds of things. The only "action/operation" that I had
> envisioned for the introspection endpoint is introspection itself: "I have
> a token, what does it mean?"
> >>>>>>>>>>
> >>>>>>>>>> Note that client_id and client_secret *can* already be used at
> this endpoint if the server supports that as part of their client
> credentials setup. The examples use HTTP Basic with client id and secret
> right now. Basically, the client can authenticate however it wants,
> including any of the methods that OAuth2 allows on the token endpoint. It
> could also authenticate with an access token. At least, that's the intent
> of the introspection draft -- if that's unclear, I'd be happy to accept
> suggested changes to clarify this text.
> >>>>>>>>>>
> >>>>>>>>>>  -- Justin
> >>>>>>>>>>
> >>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
> >>>>>>>>>>> Justin,
> >>>>>>>>>>>
> >>>>>>>>>>> This spec is looking good..
> >>>>>>>>>>>
> >>>>>>>>>>> One thing I would like to recommend is to add
> "action"/"operation"
> >>>>>>>>>>> to the request.  (and potentially add client_id and
> client_secret)
> >>>>>>>>>>>
> >>>>>>>>>>> So the request will be like :
> >>>>>>>>>>> token REQUIRED
> >>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire
> (default) | revoke ...
> >>>>>>>>>>> resource_id OPTIONAL
> >>>>>>>>>>> client_id OPTIONAL
> >>>>>>>>>>> client_secret OPTIONAL
> >>>>>>>>>>>
> >>>>>>>>>>> And for the OAuth client information, it should be an optional
> parameter (in case it is a public client or client is authenticated with
> SSL mutual authentication).
> >>>>>>>>>>>
> >>>>>>>>>>> Please consider.
> >>>>>>>>>>>
> >>>>>>>>>>> ShiuFun
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> OAuth mailing list
> >>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>> _______________________________________________
> >>>>>>>> OAuth mailing list
> >>>>>>>> OAuth@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>



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

--047d7b622520a1632a04d48cd12e
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNl
cmlmO2ZvbnQtc2l6ZToxOHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+T0F1
dGggZGlkIG5vdCB0YWxrIG1ha2UgZGlzdGluY3Rpb25zIG9yIHRhbGsgYWJvdXQgSFRUUCBtZXRo
b2RzIGJlY2F1c2Ugb2YgdHdvIHJlYXNvbnM6Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6
cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxOHB4
O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8YnI+PC9kaXY+PGRpdiBzdHls
ZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQt
c2l6ZToxOHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+KDEpIEJyb3dzZXIg
aW4gdGhlIG1pZGRsZSB3aXRoIEhUVFAgcmVkaXJlY3QgY29uc3RyYWludC4mbmJzcDs8L2Rpdj48
ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy
aWY7Zm9udC1zaXplOjE4cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCigy
KSBUaGUgcHJvdGVjdGVkIHJlc291cmNlIGlzIHRoZSBwYXJ0eSB3aG8gZGVjaWRlcyB3aGF0IHNl
bWFudGljcyBpcyBiZWluZyBtYXBwZWQgdG8gdGhlIEhUVFAgbWV0aG9kcy4mbmJzcDs8L2Rpdj48
ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy
aWY7Zm9udC1zaXplOjE4cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxi
cj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFs
LHNhbnMtc2VyaWY7Zm9udC1zaXplOjE4cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwy
NTUpIj5UaGUgKDEpIGFib3ZlIGlzIGp1c3QgYSB3b3JrIGFyb3VuZCBmb3IgdGhlIGNvbnN0cmFp
bmVkIHVzZXIgYWdlbnRzLiZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwz
NCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MThweDtiYWNrZ3JvdW5k
LWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJn
YigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MThweDti
YWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPlJlZ2lzdHJhdGlvbiBpcyBzZXJ2ZXIg
dG8gc2VydmVyLCBzbyB3ZSBkbyBub3QgbmVlZCB0byBiZSBjb25zdHJhaW5lZCBieSB0aGlzLiZu
YnNwOzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJp
YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MThweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1
LDI1NSkiPg0KPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1m
YW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MThweDtiYWNrZ3JvdW5kLWNvbG9yOnJn
YigyNTUsMjU1LDI1NSkiPlRoZSAoMikgaXMgYSByZXF1aXJlbWVudCB0byB0aGUgZnJhbWV3b3Jr
IGJlY2F1c2UgT0F1dGggc2hvdWxkIG5vdCBwb2xsdXRlIHRoZSBzcGFjZSBhbmQgc2hvdWxkIGxl
dCB0aGUgcHJvdGVjdGVkIHJlc291cmNlIGRlY2lkZSBvbiB0aGVpciBvd24uJm5ic3A7PC9kaXY+
DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMt
c2VyaWY7Zm9udC1zaXplOjE4cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48
YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlh
bCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxOHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs
MjU1KSI+DQpSZWdpc3RyYXRpb24gZW5kcG9pbnQgaXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgdGhh
dCBzaG91bGQgZGVjaWRlIHRoZSBtYXBwaW5nLiAmbmJzcDs8L2Rpdj48ZGl2IHN0eWxlPSJjb2xv
cjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE4
cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj48YnI+PC9kaXY+PGRpdiBzdHls
ZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQt
c2l6ZToxOHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQpXZSBzaG91bGQg
bm90IGNvbmZsYXRlIHdpdGggT0F1dGggY29yZSBmcmFtZXdvcmsgcmVxdWlyZW1lbnRzIGFuZCBw
cm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWlyZW1lbnRzLiZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9ImNv
bG9yOnJnYigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6
MThweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPjxicj48L2Rpdj4NCjxkaXYg
c3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtm
b250LXNpemU6MThweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPk5hdDwvZGl2
Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxMy8xLzMxIE1pa2UgSm9uZXMgPHNwYW4g
ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
IiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8L3Nw
YW4+PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg
MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQoN
Cg0KDQoNCg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxZjQ5N2QiPk9BdXRoICo8Yj5uZXZlcjwvYj4qIG1ha2VzIGEgZGlzdGluY3Rpb24gYmV0
d2VlbiB3aGF0IEdFVCBhbmQgUE9TVCBkby4mbmJzcDsgKFllcywgdGhleSBwYXNzIHRoZSBpbnB1
dCBwYXJhbWV0ZXJzIGRpZmZlcmVudGx5LikmbmJzcDsgSSAqPGI+cmVhbGx5PC9iPiogZG9uJnJz
cXVvO3QgdGhpbmsgd2UNCiBzaG91bGQgc3RhcnQgZG9pbmcgdGhpcyBub3cgZm9yIG5ldyBvcGVy
YXRpb25zLiZuYnNwOyBJdCB3aWxsIGxpa2VseSBvbmx5IGNvbmZ1c2UgZGV2ZWxvcGVycyBhbmQg
bWFrZSB0aGluZ3MgaGFyZGVyIGZvciB0aGVtICZuZGFzaDsgZXNwZWNpYWxseSB3aGVuIHVzaW5n
IHNvZnR3YXJlIHRoYXQgbWF5IG5vdCBhbHdheXMgZ2l2ZSB0aGVtIGZ1bGwgYWNjZXNzIHRvIGFs
bCBIVFRQIHZlcmJzIGFuZCBoZWFkZXIgcGFyYW1ldGVycy48dT48L3U+PHU+PC91Pjwvc3Bhbj48
L3A+DQo8ZGl2IGNsYXNzPSJpbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+
PHU+PC91Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gPGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPk5hdCBTYWtpbXVyYTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEph
bnVhcnkgMzAsIDIwMTMgNjoyMiBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5PGJyPg0K
PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBSZWdp
c3RyYXRpb24gZW5kcG9pbnRzPyAod2FzOiBSZTogQ29uY2VybmluZyBPQXV0aCApPHU+PC91Pjx1
PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3A+DQo8L2Rpdj48ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KEkgY2hhbmdlZCB0aGUg
c3ViamVjdCB0byBtYXRjaCB0aGUgY29udGVudC4pJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8
L2Rpdj48ZGl2PjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Umln
aHQuIEl0IGRvZXMgbm90IGhhdmUgdG8gYmUgdGhyZWUgZW5kcG9pbnRzLiBPbmUgZW5kcG9pbnQg
d291bGQgZG8gKHRob3VnaCBpdCBkZXBlbmRzIG9uIGhvdyB5b3UgY291bnQgdGhlIFVSTHMpLiAm
bmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48
L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pkhvd2V2ZXIsIEkgd291bGQgZG8gaXQgc2xpZ2h0bHkgZGlmZmVyZW50bHkgdGhhbiB5b3UgKEpv
aG4gQi4pIHByb3Bvc2VzLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBleGFtcGxlLCBsZXQgdGhlIHJlZ2lzdHJh
dGlvbiBlbmRwb2ludCBiZSBuYW1lZCAvY2xpZW50cywgd2hpY2ggcmVwcmVzZW50cyB0aGUgY29s
bGVjdGlvbiBvZiByZWdpc3RlcmVkIGNsaWVudHMuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oVGhpcyBpcyB0aGUgcmVnaXN0cmF0
aW9uIGVuZHBvaW50LikmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZW4sJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBPU1QgdG8gdGhlIC9jbGllbnRzIHdvdWxk
IGNyZWF0ZSB0aGUgcmVzb3VyY2UgaW4gcXVlc3Rpb24uIChjbGllbnQgYXNzb2NpYXRlKSZuYnNw
Ozx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UE9TVCB0byAvY2xpZW50cz9jbGllbnRfaWQ9MTIzNDUgYW5kIHBvc3QgcGFyYW1zICh0aGUgcmVz
b3VyY2UgVVJMKSB3b3VsZCB1cGRhdGUgdGhlIHJlc291cmNlLiZuYnNwOzx1PjwvdT48dT48L3U+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3QgYW4g
aWRlbXBvdGVudCByZXF1ZXN0LCBhbmQgY291bGQgdXBkYXRlIGFueSBwb3J0aW9uIG9mIHRoZSBy
ZXNvdXJjZS4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkluIHBhcnRpY3VsYXIsIGNsaWVudF9zZWNyZXQ9bnVsbCBvciBzb21ldGhp
bmcgY291bGQgbWVhbiAmcXVvdDtyb3RhdGUgc2VjcmV0LiZxdW90Ozx1PjwvdT48dT48L3U+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HRVQgdG8gL2NsaWVu
dHM/Y2xpZW50X2lkPTEyMzQ1IHdvdWxkIHJldHVybiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBk
YXRhLiBJdCBpcyBpZGVtcG90ZW50LiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+REVMRVRFIHRvIC9jbGllbnRzP2NsaWVudF9pZD0x
MjM0NSB3b3VsZCBkZWxldGUgdGhlIHJlc291cmNlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QVVQgdG8mbmJzcDsvY2xp
ZW50cz9jbGllbnRfaWQ9MTIzNDUgKHRoZSByZXNvdXJjZSBVUkwpJm5ic3A7d291bGQgcmVwbGFj
ZSB0aGUgcmVzb3VyY2UsIGFuZCBpcyBpZGVtcG90ZW50LiZuYnNwOzx1PjwvdT48dT48L3U+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7KEkgYW0gbm90IHN1
cmUgaWYgd2UgbmVlZCB0aGlzLiBQcm9iYWJseSBiZXR0ZXIgbm90IGhhdmUgb25lLikmbmJzcDs8
dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1
PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Rm9yIGFueSBvZiB0aGUgYWJvdmUgcmVxdWVzdCBleGNlcHQgREVMRVRFLCB0aGUgcmVzcG9u
c2Ugc2hvdWxkIHJldHVybiB0aGUgZW50aXJlIG9iamVjdC4mbmJzcDs8dT48L3U+PHU+PC91Pjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48
L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KEZvciB0aGUgcHVy
aXN0czogUmlnaHQuIFRoaXMgc3RpbGwgY291bGQgYmUgaW1wcm92ZWQgYnkgdXNpbmcgVVJJIHRl
bXBsYXRlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIHNlcnZlciBjb3VsZCBwdWJsaXNoIHRoZSBzZXJ2ZXIgbWV0YWRhdGEg
aW5jbHVkaW5nIFVSSSB0ZW1wbGF0ZSBmb3IgdGhlIHJlZ2lzdHJhdGlvbiBldGMuJm5ic3A7PHU+
PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0
aGF0IHBvaW50LCBzZXJ2ZXIgaXMgZnJlZWQgZnJvbSBmb3JjZWQgdG8gdXNlIHRoZSBxdWVyeSBw
YXJhbWV0ZXJzLiBGb3IgZXhhbXBsZSwmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluc3RlYWQgb2YgL2NsaWVudHM/Y2xpZW50X2lk
PTEyMzQ1LCBpdCBjb3VsZCBoYXZlIGluc3RydWN0ZWQgdGhlIGNsaWVudCB0byB1c2UgL2NsaWVu
dHMvMTIzNDUvJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5vciAvY2xpZW50cy9pZC8xMjM0NSBldGMuIGJ1dCBJIHRoaW5rIHRoYXQg
aXMgZ29pbmcgdG9vIGZhci4pPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TmF0PHU+
PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxMy8xLzMxIEpv
aG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9
Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozx1PjwvdT48dT48L3U+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBiZXR0ZXIsIGJ1dCBJIGRvbiYjMzk7dCBzZWUgYW4g
YWR2YW50YWdlIHRvIHRoYXQgb3ZlciB1c2luZyBhIHF1ZXJ5IHBhcmFtZXRlci48YnI+DQo8YnI+
DQpUaGV5IGFyZSBlcXVhbGx5IHJlc3RmdWwgb3Igbm90IGFzIHRoZSBjYXNlIG1heSBiZS48YnI+
DQo8YnI+DQpUbyBiZSBtb3JlIHJlc3RmdWwgSSB0aGluayB5b3Ugd2FudCBhIHNpbmdsZSBlbmRw
b2ludCB1c2luZyBIVFRQIHZlcmJzLjxicj4NCjxicj4NClBPU1QgL3JlZ19lbmRwb2ludD9wYXJh
bWF0ZXJzICZoZWxsaXA7ICZuYnNwOy0mZ3Q7IHJlZ2lzdGVyPGJyPg0KUFVUICZuYnNwOy9yZWdf
ZW5kcG9pbnQ/Y2xpZW50X2lkPTEyMzQ1JmFtcDtwYXJhbWF0ZXJzIC0mZ3Q7IHVwZGF0ZTxicj4N
ClBVVCAvcmVnX2VuZHBvaW50P2NsaWVudF9pZD0xMjM0NSZhbXA7cm90YXRlX3NlY3JldD10cnVl
PGJyPg0KPGJyPg0KVGhlIGRvd25zaWRlIGlzIGRldmVsb3BlcnMgdW5kZXJzdGFuZGluZzx1Pjwv
dT48dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpP
biAyMDEzLTAxLTMwLCBhdCAxOjE3IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls
dG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwv
YT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDAxLzMwLzIwMTMgMTA6
NTUgQU0sIEpvaG4gQnJhZGxleSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBNeSBmZWVsaW5nIHdhcyB0
aGF0IGxldHRpbmcgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCBiZSBhIHNpbmdsZSBVUkwgKGFu
eSB1cmwpIGFuZCB1c2luZyBxdWVyeSBwYXJhbWF0ZXJzIHdhcyBlYXNlciBmb3Igc2VydmVycyBh
bmQgY2xpZW50cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNheWluZyB0YWtlIHRoZSBi
YXNlIFVSSSBmb3IgdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCBhbmQgYXBwZW5kIHRoZXNlIHBh
dGhzIHRvIGl0IHRvIGRvIGRpZmZlcmVudCBvcGVyYXRpb25zIHNlZW1zIG1vcmUgbGlrZWx5IHRv
IGdvIHdyb25nIGZybyBkZXZlbG9wZXJzLjxicj4NCiZndDsgUmlnaHQsIGFuZCB0byBjbGFyaWZ5
LCB0aGlzIGlzbiYjMzk7dCB3aGF0IEkgd2FzIHNheWluZy4gVGhlIHNwZWMgd291bGRuJiMzOTt0
IHNwZWNpZnkgdGhlIHBhdGggYXQgYWxsLCBqdXN0IHNheSB0aGF0IHRoZXkmIzM5O3JlIHRocmVl
IGRpZmZlcmVudCBlbmRwb2ludCBVUkxzLiBUaGUgc2FtZSB3YXkgdGhhdCB3ZSBzcGVjaWZ5IHRo
YXQgdGhlIGF1dGggZW5kcG9pbnQgYW5kIHRva2VuIGVuZHBvaW50IGFyZSBkaWZmZXJlbnQgVVJM
cy48YnI+DQoNCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgbXkgZXhhbXBsZSBtaWdodCBoYXZlIGJl
ZW4gbWlzbGVhZGluZy4gVGhlIFVSTHMgY291bGQganVzdCBhcyBlYXNpbHkgYmU6PGJyPg0KJmd0
Ozxicj4NCiZndDsgY2xpZW50X3JlZ2lzdGVyIC0mZ3Q7IC9yZWdpc3Rlcl9hX25ld19jbGllbnQ8
YnI+DQomZ3Q7IHJvdGF0ZV9zZWNyZXQgLSZndDsgL2NsaWVudC9nb19nZXRfYV9zZWNyZXRfb3Jf
c29tZXRoaW5nPGJyPg0KJmd0OyBjbGllbnRfdXBkYXRlLSZndDsgL21haW50ZW5hbmNlL3VwZGF0
ZV9jbGllbnRfaW5mb3JtYXRpb248YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFsbG93aW5nIGJvdGggYmF0aCBhbmQgcXVlcnkgcGFyYW1l
dGVycyBpcyB0aGUgd29yc3Qgb3B0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBh
bSBzeW1wYXRoZXRpYyB3aXRoIHVzaW5nIFBPU1QgYW5kIFBVVCBhbmQgcGVyaGFwcyBHRVQgYnV0
IEkgd29ycnkgYWJvdXQgT0F1dGggZGV2ZWxvcGVycyBub3QgZ2V0dGluZyBpdC48YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgYWxzbyBkb24mIzM5O3QgZ2V0IFRvbnkmIzM5O3MgcG9pbnQg
YWJvdXQgbXVsdGkgdGVuYW5jeS4gJm5ic3A7SWYgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgdGhlcmUg
b3duIHJlZ2lzdHJhdGlvbiBlbmRwb2ludCBJIGRvbiYjMzk7dCBzZWUgYSBwcm9ibGVtIGJleW9u
ZCBmaW5kaW5nIHRoZSBlbmRwb2ludCBhbmQgdGhhdCBpcyB3aGF0IHdlIGhhdmUgV0YgZm9yLjxi
cj4NCiZndDsgRXhhY3RseS4gQW5kIHRvIEJpbGwmIzM5O3MgcG9pbnQgaW4gYW5vdGhlciB0aHJl
YWQsIHdlIGNvdWxkIGFsc28gcmVnaXN0ZXIgYSBsaW5rIHR5cGUgZm9yIGVhY2ggZW5kcG9pbnQg
dG8gaGVscCBmYWNpbGl0YXRlIGRpc2NvdmVyeToNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXdtaWxscy1vYXV0aC1scmRkLTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd21pbGxzLW9hdXRoLWxyZGQtMDY8L2E+PGJy
Pg0KJmd0Ozxicj4NCiZndDsgLS0gSnVzdGluPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgSm9obiBCLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gMjAxMy0wMS0y
NCwgYXQgMTE6MjYgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVy
QG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsgd3Jv
dGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gMDEvMjQvMjAxMyAwNTo1NiBB
TSwgU2VyZ2V5IEJlcnlvemtpbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkgbGlrZSB0
aGlzIG1vc3QsIHdvdWxkIHJlbmFtZSBpdCB0byBzYXk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyAvb2F1dGgvY2xpZW50L3JlZ2lzdHJhdGlvbjxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsgb3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC9vYXV0aC9jbGllbnQtcmVnaXN0
cmF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZXRjPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYW5kIHJld29yZCB0aGUg
c3BlYyBzdWNoIHRoYXQgaXQgd2lsbCBsZXQgdGhvc2Ugd2hvIGltcGxlbWVudCBkbyBpdCB3aXRo
IG9uZSBlbmRwb2ludCBvciBtYW55LCB3aGF0ZXZlciBpcyBwcmVmZXJyZWQ8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYXQmIzM5O3MgdGhlIHdob2xlIHBvaW50IG9m
IHRoaXMgZGlzY3Vzc2lvbiAtLSBJIGRvbiYjMzk7dCBiZWxpZXZlIHlvdSBjYW4gaGF2ZSBpdCBi
b3RoIHdheXMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluIG9uZSB3YXks
IHlvdSBzYXkgdGhlcmUgYXJlIHRocmVlIGVuZHBvaW50cyBhbmQsIGlmIHlvdSYjMzk7cmUga2Vl
cGluZyB3aXRoIHRoZSByZXN0IG9mIE9BdXRoLCB5b3UgZG9uJiMzOTt0IGdpdmUgdGhlbSBvZmZp
Y2lhbCBVUkwgcGF0dGVybnMgdGhhdCB0aGV5IG11c3QgZm9sbG93LiBIb3cgdGhlIGNsaWVudCBn
ZXRzIHRob3NlIGVuZHBvaW50cyBpcyB1cCB0byBkaXNjb3Zlcnkgb3IgY29uZmlndXJhdGlvbiwg
YnV0IHRoZSBjbGllbnQgaGFzIGFuDQogaW50ZXJuYWwgbWFwIGZyb20gZWFjaCBiaXQgb2YgZnVu
Y3Rpb25hbGl0eSB0byBhIHBhcnRpY3VsYXIgVVJMIHRoYXQmIzM5O3Mgc3BlY2lmaWMgdG8gdGhl
IHNlcnZpY2UsIG11Y2ggaW4gdGhlIHNhbWUgd2F5IHRoYXQgdGhlIGNsaWVudCB0b2RheSBoYXMg
dG8gbWFwIHRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMuIEluIHRoZSBvdGhl
ciBtZXRob2QsIHlvdSYjMzk7dmUgZ290IG9uZSBlbmRwb2ludCB0aGF0IHRoZSBjbGllbnQgc2Vu
ZHMNCiBhIHdlbGwtZGVmaW5lZCBwYXJhbWV0ZXIgdG8gaW4gb3JkZXIgdG8gYWNjb21wbGlzaCB0
aGUgc2FtZSBnb2FsLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBTbyBpZiB5
b3UgYWxsb3cgYm90aCBhdCBvbmNlLCBkb2VzIGEgY2xpZW50IHNlbmQgdGhlICZxdW90O29wZXJh
dGlvbiZxdW90OyBwYXJhbWV0ZXIgb3Igbm90PyBJcyBpdCBsb29raW5nIGZvciBvbmUgdXJsIG9y
IHRocmVlIHRvIHN0b3JlIGluIGl0cyBjb25maWd1cmF0aW9uPyBJIGRvbiYjMzk7dCB0aGluayB0
aGlzIGxldmVsIG9mIGZsZXhpYmlsaXR5IGJ1eXMgeW91IGFueXRoaW5nIHVzZWZ1bCwgYW5kIEkg
c3Ryb25nbHkgYmVsaWV2ZSB0aGF0IGl0IHdpbGwgZGVlcGx5DQogaHVydCB0aGUgZnVuY3Rpb25h
bGl0eSBvZiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBpZiBpdCYjMzk7cyBhbGxvd2VkLjxicj4NCiZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBcyBpdCBzdGFuZHMgdG9kYXksIHlvdSBjYW4g
c3RpbGwgbWFrZSB0aGUgVVJMIHdoYXRldmVyIHlvdSB3YW50LiBJZiB3ZSB3ZW50IHdpdGggdGhy
ZWUgZW5kcG9pbnRzIHlvdSBjb3VsZCBhbHNvIG1ha2UgdGhvc2UgVVJMcyB3aGF0ZXZlciB5b3Ug
d2FudGVkLiBOb2JvZHkgaGFzIHlldCBwb2ludGVkIG91dCB0byBtZSB3aGF0IHRoZSBhY3R1YWwg
YmVuZWZpdCBpcyBvZiBtYWtpbmcgYm90aCB2YWxpZC48YnI+DQoNCiZndDsmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyBJIHBlcnNvbmFsbHkgcHJlZmVyIHRoZSBtZXRob2Qgb2YgdGhyZWUgZW5k
cG9pbnQgVVJMcyBiZWNhdXNlIGl0JiMzOTtzIGNsZWFuZXIgYW5kIHNlbWFudGljYWxseSBlcXVp
dmFsZW50LCBidXQgSSBhbSBoZXNpdGFudCB0byBjaGFuZ2UgdGhhdCBiZWhhdmlvciB1bmxlc3Mg
dGhlcmUmIzM5O3Mgc3Ryb25nIHdvcmtpbmcgZ3JvdXAgc3VwcG9ydCBmb3IgaXQuIEkgaGF2ZW4m
IzM5O3Qgc2VlbiByZWFsIHN1cHBvcnQgZm9yIGl0IHlldCAtLSBpdCYjMzk7cyBub3QgYSBnb29k
DQogY2FsbCB0byBtYWtlIGl0IGZ1bGx5IFJFU1RmdWwsIGFuZCBpdCYjMzk7cyBub3QgYSBnb29k
IGNhbGwgdG8gbGVhdmUgaXQgdW5kZWZpbmVkLiBBIGNsaWVudCBNVVNUIGhhdmUgYSB2ZXJ5IGNs
ZWFyIHJlY2lwZSBvZiB3aGF0IHRvIGRvIG9uIHN0YXJ0dXAgZm9yIHRoaXMgdG8gd29yayBpbiB0
aGUgd2lsZC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJy
Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBoZWxwIG11bHRpdGVuYW5jeT8gSG93IGRvZXMgaXQgZXZlbiBhZmZlY3QgdGhh
dCB1c2UgY2FzZT8gQ29uc2lkZXIgdGhhdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBi
YXNlIFVSTCBmb3IgYWxsIG9mIHRoZXNlIGlzIGNvbXBsZXRlbHkgdXAgdG8gdGhlIGhvc3QgZW52
aXJvbm1lbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAobm90aGluZyBpcyBib3VuZCB0byB0
aGUgcm9vdCBVUkwpLiBDb25zaWRlciB0aGF0IGNsaWVudHMgc3RpbGwgaGF2ZSB0bzxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGtub3cgd2hhdCB0aGUgVVJMIChvciBVUkxzKSBhcmUsIGluIGVp
dGhlciBjYXNlLiBDb25zaWRlciB0aGF0IGNsaWVudHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBzdGlsbCBuZWVkIHRvIGtub3cgaG93IHRvIG1hbmFnZSBhbGwgdGhlIHBhcmFtZXRlcnMgYW5k
IHJlc3BvbnNlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IElmIGFueXRoaW5nLCBrZWVwaW5nIGl0IHRoZSB3YXkgdGhhdCBpdCBpcyB3aXRoIGEg
c2luZ2xlIFVSTCBjb3VsZCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZ3VlZCB0byBo
ZWxwIG11bHRpdGVuYW5jeSBiZWNhdXNlIHNldHRpbmcgdXAgcm91dGluZyB0byBtdWx0aXBsZSBV
Ukw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlbmRwb2ludHMgY2FuIHNvbWV0aW1lcyBiZSBw
cm9ibGVtYXRpYyBpbiBob3N0ZWQgZW52aXJvbm1lbnRzLiBIb3dldmVyLDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IE9BdXRoIGFscmVhZHkgZGVmaW5lcyBhIGJ1bmNoIG9mIGVuZHBvaW50cywg
YW5kIHdlIGhhdmUgdG8gZGVmaW5lIGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGVhc3Qg
b25lIG1vcmUgd2l0aCB0aGlzIGV4dGVuc2lvbiwgc28gSSYjMzk7bSBub3QgY29udmluY2VkIHRo
YXQgaGF2aW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWUgd2l0aCBzcGVjaWZpYyBm
dW5jdGlvbnMgaXMgcmVhbGx5IGFueSBkaWZmZXJlbnQgZnJvbSBoYXZpbmcgb25lPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aCB0aHJlZSBmdW5jdGlvbnMgZnJvbSBhIGRldmVsb3BtZW50
LCBkZXBsb3ltZW50LCBhbmQgaW1wbGVtZW50YXRpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBwZXJzcGVjdGl2ZS4gSSBjYW4gdGVsbCB5b3UgZnJvbSBleHBlcmllbmNlIHRoYXQgaW4gb3Vy
IG93biBzZXJ2ZXIgY29kZSw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgZGlmZmVyZW5j
ZSBpcyB0cml2aWFsLiAoQW5kIGZyb20gT0F1dGgxIGV4cGVyaWVuY2UsIHlvdSBjYW4gYWx3YXlz
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaGF2ZSBhIHF1ZXJ5IHBhcmFtZXRlciBhcyBwYXJ0
IG9mIHlvdXIgZW5kcG9pbnQgVVJMIGlmIHlvdSBuZWVkIHRvLiBZb3U8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBtaWdodCBoYXRlIHlvdXJzZWxmIGZvciBkb2luZyBpdCB0aGF0IHdheSwgYnV0
IG5vdGhpbmcgc2F5cyB5b3VyIGJhc2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBVUkwgY2Fu
JiMzOTt0IGFscmVhZHkgaGF2ZSBwYXJhbWV0ZXJzIG9uIGl0LiBBIGNsaWVudCBqdXN0IG5lZWRz
IHRvIGtub3cgaG93PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gYXBwcm9wcmlhdGVseSB0
YWNrIGl0cyBwYXJhbWV0ZXJzIG9udG8gYW4gZXhpc3RpbmcgVVJMLCBhbmQgYW55IEhUVFA8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGllbnQgd29ydGggaXRzIHNhbHQgd2lsbCBrbm93IGhv
dyB0byBhdWdtZW50IGEgcXVlcnkgcGFyYW1ldGVyIHNldDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IHdpdGggbmV3IGl0ZW1zLik8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSAqcmVhbCogZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gYXBw
cm9hY2hlcyBpcyBhIHBoaWxvc29waGljYWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXNp
Z24gb25lLiBUaGUgZm9ybWVyIG92ZXJsb2FkcyBvbmUgVVJMIHdpdGggbXVsdGlwbGUgZnVuY3Rp
b25zPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3dpdGNoZWQgYnkgYSBmbGFnLCB0aGUgbGF0
dGVyIHVzZXMgdGhlIFVSTCBpdHNlbGYgYXMgYW4gaW1wbGljaXQgZmxhZy48YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBVbmRlciB0aGUgaG9vZCwgdGhlc2UgY291bGQgKGFuZCBpbiBtYW55IGNh
c2VzIHdpbGwpIGJlIGFsbCBzZXJ2ZWQgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUg
c2FtZSBjaHVua3Mgb2YgY29kZS4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBob3cgdGhpcyBzd2l0
Y2ggaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5IGlzIHByZXNlbnRl
ZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2l0aCB0aGF0IHNhaWQsIGNhbiBzb21lYm9keSBwbGVh
c2UgZXhwbGFpbiB0byBtZSBob3cgYWxsb3dpbmcgKmJvdGgqIG9mPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgdGhlc2UgYXMgb3B0aW9ucyBzaW11bHRhbmVvdXNseSAod2hhdCBJIHVuZGVyc3Rh
bmQgVG9ueSB0byBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Z2dlc3RpbmcpIGlzIGEg
Z29vZCBpZGVhLCBvciBob3cgbXVsdGl0ZW5hbmN5IGV2ZW4gY29tZXMgaW50byBwbGF5Pzxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlY2F1c2UgSSBhbSBjb21wbGV0ZWx5IG5vdCBzZWVpbmcg
aG93IHRoZXNlIGFyZSByZWxhdGVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tIEp1
c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAx
LzIzLzIwMTMgMTI6NDYgUE0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgSXQgd2lsbCBub3Qgd29yayB0aGUgd2F5IHlvdSBoYXZlIGl0LCBhcyBw
ZW9wbGUgZG8gbXVsdGktdGVuZGVuY3kgZGlmZmVyZW50IGFuZCB0aGV5IGFyZSBhbHJlYWR5IHN0
dWNrIHdpdGggdGhlIG1ldGhvZCB0aGF0IHRoZXkgaGF2ZSBjaG9zZW4sIHNvIHRoZXkgbmVlZCB0
aGUgZmxleGFiaWxpdHksIHRvIHJlc3RyaWN0IHRoaXMgaXMgbnV0cyBhcyBwZW9wbGUgd29uJiMz
OTt0IHVzZSBpdC48YnI+DQoNCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86PGEgaHJlZj0ibWFp
bHRvOmpyaWNoZXJAbWl0cmUub3JnIiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXRyZS5vcmc8
L2E+XTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIEphbnVh
cnkgMjMsIDIwMTMgOToyNyBBTTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogQW50
aG9ueSBOYWRhbGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiBOYXQgU2FraW11
cmE7IFNoaXUgRnVuIDxhIGhyZWY9Im1haWx0bzpQb29uJTNCb2F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5Qb29uO29hdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDb25jZXJuaW5nIE9BdXRoIGludHJvc3Bl
Y3Rpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgSSBjb21wbGV0ZWx5IGRpc2FncmVlIHdpdGggdGhpcyBhc3Nlc3NtZW50LiBNdWx0
aS10ZW5hbmN5IHdpbGwgd29yayBqdXN0IGZpbmUgKG9yIGV2ZW4gYmV0dGVyKSBpZiBldmVyeW9u
ZSB1c2VzIHRoZSBzYW1lIHBhdHRlcm4uIFRlbGxpbmcgc29tZW9uZSAmcXVvdDtpdCBtaWdodCBi
ZSB0aHJlZSBkaWZmZXJlbnQgdXJscyBvciBpdCBtaWdodCBiZSBhbGwgb25lIHVybCB3aXRoIGEg
cGFyYW1ldGVyJnF1b3Q7IGlzIGp1c3QgYXNraW5nIGZvciBhIGNvbXBsZXRlDQogZGlzYXN0ZXIu
IFdoYXQgZG9lcyB0aGUgZmxleGliaWxpdHkgb2YgYWxsb3dpbmcgdHdvIGFwcHJvYWNoZXMgYWN0
dWFsbHkgYWNjb21wbGlzaD88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91IGNhbiBhcmd1ZSBhYm91dCB0aGUgbWVyaXRzIG9mIGVp
dGhlciBhcHByb2FjaCwgYnV0IGhhdmluZyBib3RoIGFzIHVuc3BlY2lmaWVkIG9wdGlvbnMgZm9y
IHJlZ2lzdHJhdGlvbiwgd2hpY2ggaXMgbWVhbnQgdG8gaGVscCB0aGluZ3MgZ2V0IGdvaW5nIGlu
IGEgY29sZC1ib290IGVudmlyb25tZW50LCBpcyBqdXN0IHBsYWluIG51dHMuPGJyPg0KDQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDAxLzIzLzIwMTMgMTI6
MjEgUE0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IFJlZ2lzdHJhdGlvbiBoYXMgdG8gd29yayBpbiBhIG11bHRpLXRlbmFudCBlbnZpcm9u
bWVudCAmbmJzcDtzbyBmbGV4aWJpbGl0eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgaXMgbmVlZGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzo8
YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmciIHRhcmdldD0iX2JsYW5rIj5qcmljaGVy
QG1pdHJlLm9yZzwvYT5dPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBX
ZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOToxOCBBTTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgVG86IEFudGhvbnkgTmFkYWxpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgQ2M6IE5hdCBTYWtpbXVyYTsgU2hpdSBGdW4gPGEgaHJlZj0ibWFpbHRvOlBvb24l
M0JvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlBvb247b2F1dGhAaWV0Zi5vcmc8L2E+
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBDb25jZXJuaW5nIE9BdXRoIGludHJvc3BlY3Rpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCZWNhdXNlIHRoZW4g
bm9ib2R5IHdvdWxkIGtub3cgaG93IHRvIGFjdHVhbGx5IHVzZSB0aGUgdGhpbmcuPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgSW4gbXkgb3BpbmlvbiwgdGhpcyBpcyBhIGtleSBwbGFjZSB3aGVyZSB0aGlzIGtpbmQgb2Yg
ZmxleGliaWxpdHkgaXMgYSB2ZXJ5IGJhZCB0aGluZy4gUmVnaXN0cmF0aW9uIG5lZWRzIHRvIHdv
cmsgb25lIGZhaXJseSBwcmVkaWN0YWJsZSB3YXkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0gSnVzdGluPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgT24gMDEvMjMvMjAxMyAxMjoxNCBQTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOjxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoeSBub3QganVzdCBoYXZlIGEgcGh5
c2ljYWwgYW5kIGxvZ2ljYWwgZW5kcG9pbnQgb3B0aW9uczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyA8YSBocmVmPSJtYWlsdG86RnJvbSUzQW9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5Gcm9tOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJl
Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1i
b3VuY2VzQGlldGYub3JnPC9hPl0gT248YnI+DQoNCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDc6NDcgQU08YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogTmF0IFNha2ltdXJhPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IFNoaXUgRnVuIDxhIGhyZWY9Im1h
aWx0bzpQb29uJTNCb2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Qb29uO29hdXRoQGll
dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIENvbmNlcm5pbmcgT0F1dGggaW50cm9zcGVjdGlvbjxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgV2hpY2ggYnJpbmdzIHVwIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGZvciB0aGUg
UmVnaXN0cmF0aW9uIGRvYzogcmlnaHQgbm93LCBpdCYjMzk7cyBzZXQgdXAgYXMgYSBzaW5nbGUg
ZW5kcG9pbnQgd2l0aCB0aHJlZSBvcGVyYXRpb25zLiBXZSBjb3VsZCBpbnN0ZWFkIGRlZmluZSB0
aHJlZSBlbmRwb2ludHMgZm9yIHRoZSBkaWZmZXJlbnQgb3BlcmF0aW9ucy48YnI+DQoNCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgSSYjMzk7dmUgbm90IGJlZW4ga2VlbiB0byBtYWtlIHRoYXQgZGVlcCBvZiBhIGN1
dHRpbmcgY2hhbmdlIHRvIGl0LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGJlIGNsZWFuZXIgYW5k
IG1vcmUgUkVTVGZ1bCBBUEkgZGVzaWduLiBXaGF0IGRvIG90aGVycyB0aGluaz88YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IC0tIEp1c3Rpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAwMS8yMi8yMDEzIDA4OjA1IFBNLCBOYXQgU2FraW11cmEg
d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O0Fj
dGlvbiZxdW90OyBnb2VzIGFnYWluc3QgUkVTVCBwcmluY2lwbGUuPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG8gbm90IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVh
Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA9bmF0IHZpYSBpUGhvbmU8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgSmFuIDIzLCAyMDEzIDQ6MDA8c3BhbiBsYW5nPSJKQSI+GyRCISIbKEI8
L3NwYW4+SnVzdGluIFJpY2hlciZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXRyZS5vcmci
IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7ICZuYnNwOzxzcGFuIGxh
bmc9IkpBIj4bJEIkTiVhJUMlOyE8JTgbKEI8L3NwYW4+Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgKENDJiMzOTtpbmcgdGhlIHdvcmtpbmcgZ3JvdXApPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsgSSYjMzk7bSBub3Qgc3VyZSB3aGF0IHRoZSAmcXVvdDthY3Rpb24v
b3BlcmF0aW9uJnF1b3Q7IGZsYWcgd291bGQgYWNjb21wbGlzaC4gVGhlIGlkZWEgYmVoaW5kIGhh
dmluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGluIE9BdXRoIGlzIHRoYXQgdGhleSBlYWNoIGRvIGRp
ZmZlcmVudCBraW5kcyBvZiB0aGluZ3MuIFRoZSBvbmx5ICZxdW90O2FjdGlvbi9vcGVyYXRpb24m
cXVvdDsgdGhhdCBJIGhhZCBlbnZpc2lvbmVkIGZvciB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2lu
dCBpcw0KIGludHJvc3BlY3Rpb24gaXRzZWxmOiAmcXVvdDtJIGhhdmUgYSB0b2tlbiwgd2hhdCBk
b2VzIGl0IG1lYW4/JnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm90
ZSB0aGF0IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCAqY2FuKiBhbHJlYWR5IGJlIHVzZWQg
YXQgdGhpcyBlbmRwb2ludCBpZiB0aGUgc2VydmVyIHN1cHBvcnRzIHRoYXQgYXMgcGFydCBvZiB0
aGVpciBjbGllbnQgY3JlZGVudGlhbHMgc2V0dXAuIFRoZSBleGFtcGxlcyB1c2UgSFRUUCBCYXNp
YyB3aXRoIGNsaWVudCBpZCBhbmQgc2VjcmV0IHJpZ2h0IG5vdy4gQmFzaWNhbGx5LCB0aGUgY2xp
ZW50IGNhbiBhdXRoZW50aWNhdGUNCiBob3dldmVyIGl0IHdhbnRzLCBpbmNsdWRpbmcgYW55IG9m
IHRoZSBtZXRob2RzIHRoYXQgT0F1dGgyIGFsbG93cyBvbiB0aGUgdG9rZW4gZW5kcG9pbnQuIEl0
IGNvdWxkIGFsc28gYXV0aGVudGljYXRlIHdpdGggYW4gYWNjZXNzIHRva2VuLiBBdCBsZWFzdCwg
dGhhdCYjMzk7cyB0aGUgaW50ZW50IG9mIHRoZSBpbnRyb3NwZWN0aW9uIGRyYWZ0IC0tIGlmIHRo
YXQmIzM5O3MgdW5jbGVhciwgSSYjMzk7ZCBiZSBoYXBweSB0byBhY2NlcHQgc3VnZ2VzdGVkIGNo
YW5nZXMNCiB0byBjbGFyaWZ5IHRoaXMgdGV4dC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyAmbmJzcDstLSBKdXN0aW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBPbiAwMS8yMi8yMDEzIDAxOjAwIFBNLCBTaGl1IEZ1biBQb29uIHdyb3RlOjxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEp1c3Rpbiw8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgc3BlYyBpcyBsb29raW5nIGdv
b2QuLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT25lIHRoaW5n
IEkgd291bGQgbGlrZSB0byByZWNvbW1lbmQgaXMgdG8gYWRkICZxdW90O2FjdGlvbiZxdW90Oy8m
cXVvdDtvcGVyYXRpb24mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyB0byB0aGUgcmVxdWVzdC4gJm5ic3A7KGFuZCBwb3RlbnRpYWxseSBhZGQg
Y2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0KTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgU28gdGhlIHJlcXVlc3Qgd2lsbCBiZSBsaWtlIDo8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0b2tlbiBSRVFVSVJFRDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdGlvbiAo
d29yZGluZyB0byBiZSBkZXRlcm1pbmUpICZuYnNwO09QVElPTkFMIGlucXVpcmUgKGRlZmF1bHQp
IHwgcmV2b2tlIC4uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IHJlc291cmNlX2lkIE9QVElPTkFMPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xpZW50X2lkIE9QVElPTkFMPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xpZW50X3NlY3JldCBPUFRJT05BTDxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW5kIGZvciB0aGUgT0F1
dGggY2xpZW50IGluZm9ybWF0aW9uLCBpdCBzaG91bGQgYmUgYW4gb3B0aW9uYWwgcGFyYW1ldGVy
IChpbiBjYXNlIGl0IGlzIGEgcHVibGljIGNsaWVudCBvciBjbGllbnQgaXMgYXV0aGVudGljYXRl
ZCB3aXRoIFNTTCBtdXR1YWwgYXV0aGVudGljYXRpb24pLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGxlYXNlIGNvbnNpZGVyLjxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2hpdUZ1bjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcg
bGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJy
Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48dT48L3U+PHU+
PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCjxiciBjbGVhcj0iYWxsIj4NCjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPHU+PC91Pjx1PjwvdT48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPHU+PC91Pjx1PjwvdT48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Rpdj4NCjwvZGl2Pg0K
DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48ZGl2Pjxicj48L2Rpdj4t
LSA8YnI+TmF0IFNha2ltdXJhICg9bmF0KTxkaXY+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+QF9uYXRfZW48L2Rpdj4NCg==
--047d7b622520a1632a04d48cd12e--

From phil.hunt@oracle.com  Wed Jan 30 20:11:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0221F8650 for ; Wed, 30 Jan 2013 20:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.35
X-Spam-Level: 
X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=-0.148,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WLXTKcq7XX2 for ; Wed, 30 Jan 2013 20:11:15 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5A21F856E for ; Wed, 30 Jan 2013 20:11:14 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r0V4BBWJ029416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 04:11:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0V4BBDC013963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 04:11:11 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0V4BAjt002122; Wed, 30 Jan 2013 22:11:10 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Jan 2013 20:11:10 -0800
References:  <4E1F6AAD24975D4BA5B1680429673943673F3A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-7C7A9741-6FD1-4BA7-A769-68C980892C9C
Content-Transfer-Encoding: 7bit
Message-Id: <9831A444-2AE4-4E02-99D2-2BEA959C58A5@oracle.com>
X-Mailer: iPhone Mail (10B142)
From: Phil Hunt 
Date: Wed, 30 Jan 2013 20:11:09 -0800
To: Nat Sakimura 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 04:11:18 -0000

--Apple-Mail-7C7A9741-6FD1-4BA7-A769-68C980892C9C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

Thanks Nat. These are important points.

Phil

Sent from my phone.

On 2013-01-30, at 18:59, Nat Sakimura  wrote:

> OAuth did not talk make distinctions or talk about HTTP methods because of=
 two reasons:=20
>=20
> (1) Browser in the middle with HTTP redirect constraint.=20
> (2) The protected resource is the party who decides what semantics is bein=
g mapped to the HTTP methods.=20
>=20
> The (1) above is just a work around for the constrained user agents.=20
>=20
> Registration is server to server, so we do not need to be constrained by t=
his.=20
>=20
> The (2) is a requirement to the framework because OAuth should not pollute=
 the space and should let the protected resource decide on their own.=20
>=20
> Registration endpoint is a protected resource that should decide the mappi=
ng. =20
>=20
> We should not conflate with OAuth core framework requirements and protecte=
d resource requirements.=20
>=20
> Nat
>=20
> 2013/1/31 Mike Jones 
>> OAuth *never* makes a distinction between what GET and POST do.  (Yes, th=
ey pass the input parameters differently.)  I *really* don=E2=80=99t think w=
e should start doing this now for new operations.  It will likely only confu=
se developers and make things harder for them =E2=80=93 especially when usin=
g software that may not always give them full access to all HTTP verbs and h=
eader parameters.
>>=20
>> =20
>>=20
>>                                                                 -- Mike
>>=20
>> =20
>>=20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Nat Sakimura
>> Sent: Wednesday, January 30, 2013 6:22 PM
>> To: John Bradley
>> Cc: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
>>=20
>> =20
>>=20
>> (I changed the subject to match the content.)=20
>>=20
>> =20
>>=20
>> Right. It does not have to be three endpoints. One endpoint would do (tho=
ugh it depends on how you count the URLs). =20
>>=20
>> =20
>>=20
>> However, I would do it slightly differently than you (John B.) proposes.=20=

>>=20
>> =20
>>=20
>> As an example, let the registration endpoint be named /clients, which rep=
resents the collection of registered clients.=20
>>=20
>> (This is the registration endpoint.)=20
>>=20
>> =20
>>=20
>> Then,=20
>>=20
>> =20
>>=20
>> POST to the /clients would create the resource in question. (client assoc=
iate)=20
>>=20
>> POST to /clients?client_id=3D12345 and post params (the resource URL) wou=
ld update the resource.=20
>>=20
>> This is not an idempotent request, and could update any portion of the re=
source.=20
>>=20
>> In particular, client_secret=3Dnull or something could mean "rotate secre=
t."
>>=20
>> =20
>>=20
>> GET to /clients?client_id=3D12345 would return the client registration da=
ta. It is idempotent.=20
>>=20
>> DELETE to /clients?client_id=3D12345 would delete the resource.=20
>>=20
>> =20
>>=20
>> PUT to /clients?client_id=3D12345 (the resource URL) would replace the re=
source, and is idempotent.=20
>>=20
>>  (I am not sure if we need this. Probably better not have one.)=20
>>=20
>> =20
>>=20
>> For any of the above request except DELETE, the response should return th=
e entire object.=20
>>=20
>> =20
>>=20
>> (For the purists: Right. This still could be improved by using URI templa=
te.=20
>>=20
>> The server could publish the server metadata including URI template for t=
he registration etc.=20
>>=20
>> At that point, server is freed from forced to use the query parameters. Fo=
r example,=20
>>=20
>> instead of /clients?client_id=3D12345, it could have instructed the clien=
t to use /clients/12345/=20
>>=20
>> or /clients/id/12345 etc. but I think that is going too far.)
>>=20
>> =20
>>=20
>> Nat
>>=20
>> 2013/1/31 John Bradley 
>>=20
>> That is better, but I don't see an advantage to that over using a query p=
arameter.
>>=20
>> They are equally restful or not as the case may be.
>>=20
>> To be more restful I think you want a single endpoint using HTTP verbs.
>>=20
>> POST /reg_endpoint?paramaters =E2=80=A6  -> register
>> PUT  /reg_endpoint?client_id=3D12345¶maters -> update
>> PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue
>>=20
>> The downside is developers understanding
>>=20
>>=20
>> On 2013-01-30, at 1:17 PM, Justin Richer  wrote:
>>=20
>> >
>> > On 01/30/2013 10:55 AM, John Bradley wrote:
>> >> My feeling was that letting the registration endpoint be a single URL (=
any url) and using query paramaters was easer for servers and clients.
>> >>
>> >> Saying take the base URI for the registration endpoint and append thes=
e paths to it to do different operations seems more likely to go wrong fro d=
evelopers.
>> > Right, and to clarify, this isn't what I was saying. The spec wouldn't s=
pecify the path at all, just say that they're three different endpoint URLs.=
 The same way that we specify that the auth endpoint and token endpoint are d=
ifferent URLs.
>> >
>> > I think my example might have been misleading. The URLs could just as e=
asily be:
>> >
>> > client_register -> /register_a_new_client
>> > rotate_secret -> /client/go_get_a_secret_or_something
>> > client_update-> /maintenance/update_client_information
>> >
>> >
>> >
>> >>
>> >> Allowing both bath and query parameters is the worst option.
>> >>
>> >> I am sympathetic with using POST and PUT and perhaps GET but I worry a=
bout OAuth developers not getting it.
>> >>
>> >> I also don't get Tony's point about multi tenancy.  If each tenant can=
 have there own registration endpoint I don't see a problem beyond finding t=
he endpoint and that is what we have WF for.
>> > Exactly. And to Bill's point in another thread, we could also register a=
 link type for each endpoint to help facilitate discovery: http://tools.ietf=
.org/html/draft-wmills-oauth-lrdd-06
>> >
>> > -- Justin
>> >
>> >>
>> >> John B.
>> >>
>> >> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>> >>
>> >>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>> >>>> I like this most, would rename it to say
>> >>>>
>> >>>> /oauth/client/registration
>> >>>> or
>> >>>> /oauth/client-registration
>> >>>>
>> >>>> etc
>> >>>>
>> >>>> and reword the spec such that it will let those who implement do it w=
ith one endpoint or many, whatever is preferred
>> >>>>
>> >>> That's the whole point of this discussion -- I don't believe you can h=
ave it both ways.
>> >>>
>> >>> In one way, you say there are three endpoints and, if you're keeping w=
ith the rest of OAuth, you don't give them official URL patterns that they m=
ust follow. How the client gets those endpoints is up to discovery or config=
uration, but the client has an internal map from each bit of functionality t=
o a particular URL that's specific to the service, much in the same way that=
 the client today has to map the authorization and token endpoints. In the o=
ther method, you've got one endpoint that the client sends a well-defined pa=
rameter to in order to accomplish the same goal.
>> >>>
>> >>> So if you allow both at once, does a client send the "operation" para=
meter or not? Is it looking for one url or three to store in its configurati=
on? I don't think this level of flexibility buys you anything useful, and I s=
trongly believe that it will deeply hurt the functionality of dynamic regist=
ration if it's allowed.
>> >>>
>> >>> As it stands today, you can still make the URL whatever you want. If w=
e went with three endpoints you could also make those URLs whatever you want=
ed. Nobody has yet pointed out to me what the actual benefit is of making bo=
th valid.
>> >>>
>> >>> I personally prefer the method of three endpoint URLs because it's cl=
eaner and semantically equivalent, but I am hesitant to change that behavior=
 unless there's strong working group support for it. I haven't seen real sup=
port for it yet -- it's not a good call to make it fully RESTful, and it's n=
ot a good call to leave it undefined. A client MUST have a very clear recipe=
 of what to do on startup for this to work in the wild.
>> >>>
>> >>> -- Justin
>> >>>
>> >>>>>
>> >>>>> help multitenancy? How does it even affect that use case? Consider t=
hat
>> >>>>> the base URL for all of these is completely up to the host environm=
ent
>> >>>>> (nothing is bound to the root URL). Consider that clients still hav=
e to
>> >>>>> know what the URL (or URLs) are, in either case. Consider that clie=
nts
>> >>>>> still need to know how to manage all the parameters and responses.
>> >>>>>
>> >>>>> If anything, keeping it the way that it is with a single URL could b=
e
>> >>>>> argued to help multitenancy because setting up routing to multiple U=
RL
>> >>>>> endpoints can sometimes be problematic in hosted environments. Howe=
ver,
>> >>>>> OAuth already defines a bunch of endpoints, and we have to define a=
t
>> >>>>> least one more with this extension, so I'm not convinced that havin=
g
>> >>>>> three with specific functions is really any different from having o=
ne
>> >>>>> with three functions from a development, deployment, and implementa=
tion
>> >>>>> perspective. I can tell you from experience that in our own server c=
ode,
>> >>>>> the difference is trivial. (And from OAuth1 experience, you can alw=
ays
>> >>>>> have a query parameter as part of your endpoint URL if you need to.=
 You
>> >>>>> might hate yourself for doing it that way, but nothing says your ba=
se
>> >>>>> URL can't already have parameters on it. A client just needs to kno=
w how
>> >>>>> to appropriately tack its parameters onto an existing URL, and any H=
TTP
>> >>>>> client worth its salt will know how to augment a query parameter se=
t
>> >>>>> with new items.)
>> >>>>>
>> >>>>> The *real* difference between the two approaches is a philosophical=

>> >>>>> design one. The former overloads one URL with multiple functions
>> >>>>> switched by a flag, the latter uses the URL itself as an implicit f=
lag.
>> >>>>> Under the hood, these could (and in many cases will) be all served b=
y
>> >>>>> the same chunks of code. The only difference is how this switch in
>> >>>>> functionality is presented.
>> >>>>>
>> >>>>>
>> >>>>> With that said, can somebody please explain to me how allowing *bot=
h* of
>> >>>>> these as options simultaneously (what I understand Tony to be
>> >>>>> suggesting) is a good idea, or how multitenancy even comes into pla=
y?
>> >>>>> Because I am completely not seeing how these are related.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> -- Justin
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>> >>>>>> It will not work the way you have it, as people do multi-tendency d=
ifferent and they are already stuck with the method that they have chosen, s=
o they need the flexability, to restrict this is nuts as people won't use it=
.
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>> >>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>> >>>>>> To: Anthony Nadalin
>> >>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>> >>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>> >>>>>>
>> >>>>>> I completely disagree with this assessment. Multi-tenancy will wor=
k just fine (or even better) if everyone uses the same pattern. Telling some=
one "it might be three different urls or it might be all one url with a para=
meter" is just asking for a complete disaster. What does the flexibility of a=
llowing two approaches actually accomplish?
>> >>>>>>
>> >>>>>> You can argue about the merits of either approach, but having both=
 as unspecified options for registration, which is meant to help things get g=
oing in a cold-boot environment, is just plain nuts.
>> >>>>>>
>> >>>>>>
>> >>>>>> -- Justin
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>> >>>>>>> Registration has to work in a multi-tenant environment  so flexib=
ility
>> >>>>>>> is needed
>> >>>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>> >>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>> >>>>>>> To: Anthony Nadalin
>> >>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>> >>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>> >>>>>>>
>> >>>>>>> Because then nobody would know how to actually use the thing.
>> >>>>>>>
>> >>>>>>> In my opinion, this is a key place where this kind of flexibility=
 is a very bad thing. Registration needs to work one fairly predictable way.=

>> >>>>>>>
>> >>>>>>> -- Justin
>> >>>>>>>
>> >>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>> >>>>>>>> Why not just have a physical and logical endpoint options
>> >>>>>>>>
>> >>>>>>>> -----Original Message-----
>> >>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >>>>>>>> Behalf Of Justin Richer
>> >>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>> >>>>>>>> To: Nat Sakimura
>> >>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>> >>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>> >>>>>>>>
>> >>>>>>>> Which brings up an interesting question for the Registration doc=
: right now, it's set up as a single endpoint with three operations. We coul=
d instead define three endpoints for the different operations.
>> >>>>>>>>
>> >>>>>>>> I've not been keen to make that deep of a cutting change to it, b=
ut it would certainly be cleaner and more RESTful API design. What do others=
 think?
>> >>>>>>>>
>> >>>>>>>> -- Justin
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>> >>>>>>>>> "Action" goes against REST principle.
>> >>>>>>>>> I do not think it is a good idea.
>> >>>>>>>>>
>> >>>>>>>>> =3Dnat via iPhone
>> >>>>>>>>>
>> >>>>>>>>> Jan 23, 2013 4:00=E3=80=81Justin Richer  =E3=
=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>> >>>>>>>>>
>> >>>>>>>>>> (CC'ing the working group)
>> >>>>>>>>>>
>> >>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish=
. The idea behind having different endpoints in OAuth is that they each do d=
ifferent kinds of things. The only "action/operation" that I had envisioned f=
or the introspection endpoint is introspection itself: "I have a token, what=
 does it mean?"
>> >>>>>>>>>>
>> >>>>>>>>>> Note that client_id and client_secret *can* already be used at=
 this endpoint if the server supports that as part of their client credentia=
ls setup. The examples use HTTP Basic with client id and secret right now. B=
asically, the client can authenticate however it wants, including any of the=
 methods that OAuth2 allows on the token endpoint. It could also authenticat=
e with an access token. At least, that's the intent of the introspection dra=
ft -- if that's unclear, I'd be happy to accept suggested changes to clarify=
 this text.
>> >>>>>>>>>>
>> >>>>>>>>>>  -- Justin
>> >>>>>>>>>>
>> >>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>> >>>>>>>>>>> Justin,
>> >>>>>>>>>>>
>> >>>>>>>>>>> This spec is looking good..
>> >>>>>>>>>>>
>> >>>>>>>>>>> One thing I would like to recommend is to add "action"/"opera=
tion"
>> >>>>>>>>>>> to the request.  (and potentially add client_id and client_se=
cret)
>> >>>>>>>>>>>
>> >>>>>>>>>>> So the request will be like :
>> >>>>>>>>>>> token REQUIRED
>> >>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (defaul=
t) | revoke ...
>> >>>>>>>>>>> resource_id OPTIONAL
>> >>>>>>>>>>> client_id OPTIONAL
>> >>>>>>>>>>> client_secret OPTIONAL
>> >>>>>>>>>>>
>> >>>>>>>>>>> And for the OAuth client information, it should be an optiona=
l parameter (in case it is a public client or client is authenticated with S=
SL mutual authentication).
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please consider.
>> >>>>>>>>>>>
>> >>>>>>>>>>> ShiuFun
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> OAuth mailing list
>> >>>>>>>>>> OAuth@ietf.org
>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>>> _______________________________________________
>> >>>>>>>> OAuth mailing list
>> >>>>>>>> OAuth@ietf.org
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OAuth mailing list
>> >>>>> OAuth@ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>> _______________________________________________
>> >>>> OAuth mailing list
>> >>>> OAuth@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> OAuth@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> =20
>>=20
>> --=20
>> Nat Sakimura (=3Dnat)
>>=20
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>=20
>=20
>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-7C7A9741-6FD1-4BA7-A769-68C980892C9C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


+1

Thanks Nat=
. These are important points.

Phil

Sent fro=
m my phone.

On 2013-01-30, at 18:59, Nat Sakimura <sakimura@gmail.com> wrote:
O=
Auth did not talk make distinctions or talk about HTTP methods because of tw=
o reasons: 


(1) Browser in the middle wit=
h HTTP redirect constraint. 
=

(2) The protected resource is the party who decides what semantics is being m=
apped to the HTTP methods. 


The (1) above is just a work a=
round for the constrained user agents. 


Registration is server to ser=
ver, so we do not need to be constrained by this. 


The (2) is a requirement to t=
he framework because OAuth should not pollute the space and should let the p=
rotected resource decide on their own. 




Registration endpoint is a protected resource that should decide the mapping=
.  


We should not conflate with OAuth core framework requirements and protected r=
esource requirements. 



Nat

2013/1/31 Mike Jones <Michael.Jones@microsoft.com><=
br>












OAuth *never* makes a=
 distinction between what GET and POST do.  (Yes, they pass the input p=
arameters differently.)  I *really* don=E2=80=99t think we
 should start doing this now for new operations.  It will likely only c=
onfuse developers and make things harder for them =E2=80=93 especially when u=
sing software that may not always give them full access to all HTTP verbs an=
d header parameters.




 =



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



 =



From: oauth-bounces@ietf.org [=
mailto:oauth-bou=
nces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, January 30, 2013 6:22 PM

To: John Bradley

Cc: oauth@ietf.or=
g

Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAut=
h )


 




(I changed the subject to match the content.) 






 




Right. It does not have to be three endpoints. One en=
dpoint would do (though it depends on how you count the URLs).  =





 






However, I would do it slightly differently than you (=
John B.) proposes. 






 






As an example, let the registration endpoint be named=
 /clients, which represents the collection of registered clients. 






(This is the registration endpoint.) <=
/u>






 




Then, 






 






POST to the /clients would create the resource in que=
stion. (client associate) 






POST to /clients?client_id=3D12345 and post params (t=
he resource URL) would update the resource. 






This is not an idempotent request, and could update a=
ny portion of the resource. 






In particular, client_secret=3Dnull or something coul=
d mean "rotate secret."






 






GET to /clients?client_id=3D12345 would return the cl=
ient registration data. It is idempotent. 






DELETE to /clients?client_id=3D12345 would delete the=
 resource. 






 






PUT to /clients?client_id=3D12345 (the resource U=
RL) would replace the resource, and is idempotent. <=
/p>





 (I am not sure if we need this. Probably better=
 not have one.) 






 






For any of the above request except DELETE, the respo=
nse should return the entire object. 






 






(For the purists: Right. This still could be improved=
 by using URI template. 






The server could publish the server metadata includin=
g URI template for the registration etc. 






At that point, server is freed from forced to use the=
 query parameters. For example, 






instead of /clients?client_id=3D12345, it could have i=
nstructed the client to use /clients/12345/ 






or /clients/id/12345 etc. but I think that is going t=
oo far.)






 






Nat




2013/1/31 John Bradley <ve7jtb@ve7jtb.com>


That is better, but I don't see an advantage to that o=
ver using a query parameter.



They are equally restful or not as the case may be.



To be more restful I think you want a single endpoint using HTTP verbs.



POST /reg_endpoint?paramaters =E2=80=A6  -> register

PUT  /reg_endpoint?client_id=3D12345&paramaters -> update

PUT /reg_endpoint?client_id=3D12345&rotate_secret=3Dtrue



The downside is developers understanding








On 2013-01-30, at 1:17 PM, Justin Richer <jricher@mitre.org> wrote:



>

> On 01/30/2013 10:55 AM, John Bradley wrote:

>> My feeling was that letting the registration endpoint be a single U=
RL (any url) and using query paramaters was easer for servers and clients.
>>

>> Saying take the base URI for the registration endpoint and append t=
hese paths to it to do different operations seems more likely to go wrong fr=
o developers.

> Right, and to clarify, this isn't what I was saying. The spec wouldn't s=
pecify the path at all, just say that they're three different endpoint URLs.=
 The same way that we specify that the auth endpoint and token endpoint are d=
ifferent URLs.


>

> I think my example might have been misleading. The URLs could just as e=
asily be:

>

> client_register -> /register_a_new_client

> rotate_secret -> /client/go_get_a_secret_or_something

> client_update-> /maintenance/update_client_information

>

>

>

>>

>> Allowing both bath and query parameters is the worst option.

>>

>> I am sympathetic with using POST and PUT and perhaps GET but I worr=
y about OAuth developers not getting it.

>>

>> I also don't get Tony's point about multi tenancy.  If each te=
nant can have there own registration endpoint I don't see a problem beyond f=
inding the endpoint and that is what we have WF for.

> Exactly. And to Bill's point in another thread, we could also register a=
 link type for each endpoint to help facilitate discovery:
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06

>

> -- Justin

>

>>

>> John B.

>>

>> On 2013-01-24, at 11:26 AM, Justin Richer <jricher@mitre.org> wrote:

>>

>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:

>>>> I like this most, would rename it to say

>>>>

>>>> /oauth/client/registration

>>>> or

>>>> /oauth/client-registration

>>>>

>>>> etc

>>>>

>>>> and reword the spec such that it will let those who impleme=
nt do it with one endpoint or many, whatever is preferred

>>>>

>>> That's the whole point of this discussion -- I don't believe yo=
u can have it both ways.

>>>

>>> In one way, you say there are three endpoints and, if you're ke=
eping with the rest of OAuth, you don't give them official URL patterns that=
 they must follow. How the client gets those endpoints is up to discovery or=
 configuration, but the client has an
 internal map from each bit of functionality to a particular URL that's spec=
ific to the service, much in the same way that the client today has to map t=
he authorization and token endpoints. In the other method, you've got one en=
dpoint that the client sends
 a well-defined parameter to in order to accomplish the same goal.

>>>

>>> So if you allow both at once, does a client send the "operation=
" parameter or not? Is it looking for one url or three to store in its confi=
guration? I don't think this level of flexibility buys you anything useful, a=
nd I strongly believe that it will deeply
 hurt the functionality of dynamic registration if it's allowed.

>>>

>>> As it stands today, you can still make the URL whatever you wan=
t. If we went with three endpoints you could also make those URLs whatever y=
ou wanted. Nobody has yet pointed out to me what the actual benefit is of ma=
king both valid.


>>>

>>> I personally prefer the method of three endpoint URLs because i=
t's cleaner and semantically equivalent, but I am hesitant to change that be=
havior unless there's strong working group support for it. I haven't seen re=
al support for it yet -- it's not a good
 call to make it fully RESTful, and it's not a good call to leave it undefin=
ed. A client MUST have a very clear recipe of what to do on startup for this=
 to work in the wild.

>>>

>>> -- Justin

>>>

>>>>>

>>>>> help multitenancy? How does it even affect that use cas=
e? Consider that

>>>>> the base URL for all of these is completely up to the h=
ost environment

>>>>> (nothing is bound to the root URL). Consider that clien=
ts still have to

>>>>> know what the URL (or URLs) are, in either case. Consid=
er that clients

>>>>> still need to know how to manage all the parameters and=
 responses.

>>>>>

>>>>> If anything, keeping it the way that it is with a singl=
e URL could be

>>>>> argued to help multitenancy because setting up routing t=
o multiple URL

>>>>> endpoints can sometimes be problematic in hosted enviro=
nments. However,

>>>>> OAuth already defines a bunch of endpoints, and we have=
 to define at

>>>>> least one more with this extension, so I'm not convince=
d that having

>>>>> three with specific functions is really any different f=
rom having one

>>>>> with three functions from a development, deployment, an=
d implementation

>>>>> perspective. I can tell you from experience that in our=
 own server code,

>>>>> the difference is trivial. (And from OAuth1 experience,=
 you can always

>>>>> have a query parameter as part of your endpoint URL if y=
ou need to. You

>>>>> might hate yourself for doing it that way, but nothing s=
ays your base

>>>>> URL can't already have parameters on it. A client just n=
eeds to know how

>>>>> to appropriately tack its parameters onto an existing U=
RL, and any HTTP

>>>>> client worth its salt will know how to augment a query p=
arameter set

>>>>> with new items.)

>>>>>

>>>>> The *real* difference between the two approaches is a p=
hilosophical

>>>>> design one. The former overloads one URL with multiple f=
unctions

>>>>> switched by a flag, the latter uses the URL itself as a=
n implicit flag.

>>>>> Under the hood, these could (and in many cases will) be=
 all served by

>>>>> the same chunks of code. The only difference is how thi=
s switch in

>>>>> functionality is presented.

>>>>>

>>>>>

>>>>> With that said, can somebody please explain to me how a=
llowing *both* of

>>>>> these as options simultaneously (what I understand Tony=
 to be

>>>>> suggesting) is a good idea, or how multitenancy even co=
mes into play?

>>>>> Because I am completely not seeing how these are relate=
d.

>>>>>

>>>>> Thanks,

>>>>> -- Justin

>>>>>

>>>>>

>>>>>

>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

>>>>>> It will not work the way you have it, as people do m=
ulti-tendency different and they are already stuck with the method that they=
 have chosen, so they need the flexability, to restrict this is nuts as peop=
le won't use it.


>>>>>>

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

>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM

>>>>>> To: Anthony Nadalin

>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspect=
ion

>>>>>>

>>>>>> I completely disagree with this assessment. Multi-t=
enancy will work just fine (or even better) if everyone uses the same patter=
n. Telling someone "it might be three different urls or it might be all one u=
rl with a parameter" is just asking for a complete
 disaster. What does the flexibility of allowing two approaches actually acc=
omplish?

>>>>>>

>>>>>> You can argue about the merits of either approach, b=
ut having both as unspecified options for registration, which is meant to he=
lp things get going in a cold-boot environment, is just plain nuts.


>>>>>>

>>>>>>

>>>>>> -- Justin

>>>>>>

>>>>>>

>>>>>>

>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

>>>>>>> Registration has to work in a multi-tenant envi=
ronment  so flexibility

>>>>>>> is needed

>>>>>>>

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

>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM

>>>>>>> To: Anthony Nadalin

>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth intros=
pection

>>>>>>>

>>>>>>> Because then nobody would know how to actually u=
se the thing.

>>>>>>>

>>>>>>> In my opinion, this is a key place where this k=
ind of flexibility is a very bad thing. Registration needs to work one fairl=
y predictable way.

>>>>>>>

>>>>>>> -- Justin

>>>>>>>

>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:<=
br>
>>>>>>>> Why not just have a physical and logical en=
dpoint options

>>>>>>>>

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

>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] O=
n


>>>>>>>> Behalf Of Justin Richer

>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura

>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org

>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth in=
trospection

>>>>>>>>

>>>>>>>> Which brings up an interesting question for=
 the Registration doc: right now, it's set up as a single endpoint with thre=
e operations. We could instead define three endpoints for the different oper=
ations.


>>>>>>>>

>>>>>>>> I've not been keen to make that deep of a c=
utting change to it, but it would certainly be cleaner and more RESTful API d=
esign. What do others think?

>>>>>>>>

>>>>>>>> -- Justin

>>>>>>>>

>>>>>>>>

>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:=


>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.

>>>>>>>>>

>>>>>>>>> =3Dnat via iPhone

>>>>>>>>>

>>>>>>>>> Jan 23, 2013 4:00=E3=80=
=81Justin Richer<jricher@mitre.org>  =E3=81=AE=E3=83=A1=E3=
=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

>>>>>>>>>

>>>>>>>>>> (CC'ing the working group)

>>>>>>>>>>

>>>>>>>>>> I'm not sure what the "action/opera=
tion" flag would accomplish. The idea behind having different endpoints in O=
Auth is that they each do different kinds of things. The only "action/operat=
ion" that I had envisioned for the introspection endpoint is
 introspection itself: "I have a token, what does it mean?"

>>>>>>>>>>

>>>>>>>>>> Note that client_id and client_secr=
et *can* already be used at this endpoint if the server supports that as par=
t of their client credentials setup. The examples use HTTP Basic with client=
 id and secret right now. Basically, the client can authenticate
 however it wants, including any of the methods that OAuth2 allows on the to=
ken endpoint. It could also authenticate with an access token. At least, tha=
t's the intent of the introspection draft -- if that's unclear, I'd be happy=
 to accept suggested changes
 to clarify this text.

>>>>>>>>>>

>>>>>>>>>>  -- Justin

>>>>>>>>>>

>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Po=
on wrote:

>>>>>>>>>>> Justin,

>>>>>>>>>>>

>>>>>>>>>>> This spec is looking good..
=

>>>>>>>>>>>

>>>>>>>>>>> One thing I would like to recom=
mend is to add "action"/"operation"

>>>>>>>>>>> to the request.  (and pote=
ntially add client_id and client_secret)

>>>>>>>>>>>

>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED

>>>>>>>>>>> operation (wording to be determ=
ine)  OPTIONAL inquire (default) | revoke ...

>>>>>>>>>>> resource_id OPTIONAL

>>>>>>>>>>> client_id OPTIONAL

>>>>>>>>>>> client_secret OPTIONAL

>>>>>>>>>>>

>>>>>>>>>>> And for the OAuth client inform=
ation, it should be an optional parameter (in case it is a public client or c=
lient is authenticated with SSL mutual authentication).

>>>>>>>>>>>

>>>>>>>>>>> Please consider.

>>>>>>>>>>>

>>>>>>>>>>> ShiuFun

>>>>>>>>>> ___________________________________=
____________

>>>>>>>>>> OAuth mailing list

>>>>>>>>>> OAuth@ietf.org

>>>>>>>>>> 
https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>> ___________________________________________=
____

>>>>>>>> OAuth mailing list

>>>>>>>> OAuth@ietf.org

>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>>

>>>>>>>>

>>>>>>>>

>>>>>>>

>>>>>>

>>>>>>

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OAu=
th@ietf.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.=
org

>>> https://www.ietf.org/mailman/listinfo/oauth

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/oauth

















 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.o=
rg/

@_nat_en
















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


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

--Apple-Mail-7C7A9741-6FD1-4BA7-A769-68C980892C9C--

From donald.coffin@reminetworks.com  Wed Jan 30 22:43:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882721F854B for ; Wed, 30 Jan 2013 22:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.749
X-Spam-Level: 
X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=1.849,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDSHlccn9OnQ for ; Wed, 30 Jan 2013 22:43:02 -0800 (PST)
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 4039121F84E8 for ; Wed, 30 Jan 2013 22:43:01 -0800 (PST)
Received: (qmail 31158 invoked by uid 0); 31 Jan 2013 06:42:36 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy1.bluehost.com with SMTP; 31 Jan 2013 06:42:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=8Finb9tU+rwR7P5ZHOAzSLhBMM3ewpwdKjM/1nSf6AA=;  b=fL32Ziqi7ICZgg//x70uBxgUTDEHqtEaxLHmr+uWxQYmEYhiX4ay12qvnlQs9gPE0d3eHdFWxqBSH5axkpFRvTRdyeTMPCfHgKLY9qtan5WCZoN577YosuENOvB7Nbe5;
Received: from [68.4.207.246] (port=2611 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0nr2-00010s-1Y; Wed, 30 Jan 2013 23:42:36 -0700
From: "Donald F Coffin" 
To: "'Justin Richer'" , "'Todd W Lainhart'" 
References:  <51099EBD.5050204@mitre.org>
In-Reply-To: <51099EBD.5050204@mitre.org>
Date: Wed, 30 Jan 2013 22:41:08 -0800
Message-ID: <008501cdff7d$f3e35810$dbaa0830$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01CDFF3A.E5C1C5C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHayEWWF0dQwkH9jF/aixGg/SYQlwHYgysVmDqXlNA=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: John Adkins , Marty Burns , Scott Crowder , Dave Robin , John Teeter , pmadsen@pingidentity.com, Edward Denson , Uday Verma , Ray Perlner , Anne Hendry , Lynne Rodoni , 'IETF oauth WG' 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 06:43:03 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0086_01CDFF3A.E5C1C5C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Justin,

 

>From a purely implementation view, since RFC 6749 has already defined Scope,
I think it will only confuse implementers if the format of Scope is not
consistent.  In defining how to merge RFC 6749 with the ESPI Standard, I
have found the Scope parameter to be one of hardest concepts to describe how
to implement and evaluate its contents.  To begin using multiple formats to
define the same parameter will only lead to confusion and chaos.

 

While I understand the end result of parsing the Scope parameter naturally
leads to an array.  I view that as an implementation issue and not relevant
to a specification, especially since RFC 6749 has already set a
documentation precedent..

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

 

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Wednesday, January 30, 2013 2:29 PM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax

 

It's not meant to follow the same syntax. Instead, it's making use of the
JSON object structure to avoid additional parsing of the values on the
client side.

We could fairly easily define it as the same space-delimited string if
enough people want to keep the scope format consistent.

 -- Justin

On 01/30/2013 05:27 PM, Todd W Lainhart wrote:

That the scope syntax in draft-richer-oauth-introspection-01 is different
than RFC 6749 Section 3.3, as in: 


   "scope": ["read", "write", "dolphin"], 

vs. 

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

Should introspection-01 follow the 6749 syntax for scopes?

	







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

 


------=_NextPart_000_0086_01CDFF3A.E5C1C5C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Justin,
 
From a purely =
implementation view, since RFC 6749 has already defined Scope, I think =
it will only confuse implementers if the format of Scope is not =
consistent.  In defining how to merge RFC 6749 with the ESPI =
Standard, I have found the Scope parameter to be one of hardest concepts =
to describe how to implement and evaluate its contents.  To begin =
using multiple formats to define the same parameter will only lead to =
confusion and chaos.
 
While I =
understand the end result of parsing the Scope parameter naturally leads =
to an array.  I view that as an implementation issue and not =
relevant to a specification, especially since RFC 6749 has already set a =
documentation precedent..
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=

 =

REMI =
Networks
22751 El =
Prado Suite 6216
Rancho =
Santa Margarita, CA  92688-3836
 =

Phone: =
;     (949) 636-8571
Email: =
;      donald.coffin@reminetworks.com=

 
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: =
Wednesday, January 30, 2013 2:29 PM
To: Todd W =
Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] =
draft-richer-oauth-introspection-01 scope =
syntax
 
It's not meant to follow the same syntax. =
Instead, it's making use of the JSON object structure to avoid =
additional parsing of the values on the client side.

We could =
fairly easily define it as the same space-delimited string if enough =
people want to keep the scope format consistent.

 -- =
Justin
On 01/30/2013 05:27 PM, =
Todd W Lainhart wrote:
That the =
scope syntax in draft-richer-oauth-introspection-01 is different than =
RFC 6749 Section 3.3, as in: 


  =
 "scope": ["read", =
"write", "dolphin"], 

vs. =


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


Should =
introspection-01 follow the 6749 syntax for =
scopes?




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

------=_NextPart_000_0086_01CDFF3A.E5C1C5C0--


From sberyozkin@gmail.com  Thu Jan 31 01:57:00 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525A21F868D for ; Thu, 31 Jan 2013 01:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GYJwsavHFbA for ; Thu, 31 Jan 2013 01:57:00 -0800 (PST)
Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3A21F868B for ; Thu, 31 Jan 2013 01:56:59 -0800 (PST)
Received: by mail-ee0-f49.google.com with SMTP id d4so1328574eek.22 for ; Thu, 31 Jan 2013 01:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7WQMwbvuoOr7lUSdJ0Olw2i2fheS0NSGwH4eNplSESg=; b=OEZj590iLH/+IWborQPRFwdX0vCKkZV+qaxDbQa0X8fA3ooSw7Hrx6MniiGXvFVrsQ syvqIwNBRewp6oiTnlawGIYZ57h2w9XxmURA6LecWrCin054iwGp8+56GQJUsI0gxY+0 Lvor3yDtLds8CparxSVA4shaL9GZskV1adpCXCNlRzQGIMoCG5plJXur/WVh//ovGiWt DHa+wNuMbG4B58wKH2sPNcetQakPttaiSHK4teySDD3FNGwUi7jvRv87ESIxscM0XsJ0 O5R73IBPDZNMm6Q5tV2EBBw2IYc2l153w0rdf+wbblJIsABrHJul65z69U/uiaYffxce F5nA==
X-Received: by 10.14.176.66 with SMTP id a42mr25406105eem.34.1359626219175; Thu, 31 Jan 2013 01:56:59 -0800 (PST)
Received: from [10.36.224.150] ([217.173.99.61]) by mx.google.com with ESMTPS id j46sm3172042eeo.3.2013.01.31.01.56.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 01:56:58 -0800 (PST)
Message-ID: <510A3FCA.7070804@gmail.com>
Date: Thu, 31 Jan 2013 09:56:26 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <51099EBD.5050204@mitre.org>
In-Reply-To: <51099EBD.5050204@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 09:57:00 -0000

Hi Justin
On 30/01/13 22:29, Justin Richer wrote:
> It's not meant to follow the same syntax. Instead, it's making use of
> the JSON object structure to avoid additional parsing of the values on
> the client side.
>
> We could fairly easily define it as the same space-delimited string if
> enough people want to keep the scope format consistent.
>
IMHO the consistency in representing such a high-visibility parameter as 
'scope' is more important than providing for an option to immediately 
feed it into a JSON parser

thanks, Sergey


> -- Justin
>
> On 01/30/2013 05:27 PM, Todd W Lainhart wrote:
>> That the scope syntax in draft-richer-oauth-introspection-01 is
>> different than RFC 6749 Section 3.3, as in:
>>
>>
>> "scope": ["read", "write", "dolphin"],
>>
>> vs.
>>
>> scope = scope-token *( SP scope-token )
>> scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
>>
>> Should introspection-01 follow the 6749 syntax for scopes?
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing 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 lainhart@us.ibm.com  Thu Jan 31 06:38:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA09021F87DF for ; Thu, 31 Jan 2013 06:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.464
X-Spam-Level: 
X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qWEs+FAjWhr for ; Thu, 31 Jan 2013 06:38:40 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 86EF321F84E9 for ; Thu, 31 Jan 2013 06:38:40 -0800 (PST)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 31 Jan 2013 09:38:39 -0500
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 31 Jan 2013 09:38:38 -0500
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 8C1DFC9003C for ; Thu, 31 Jan 2013 09:38:37 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0VEcbVg135414 for ; Thu, 31 Jan 2013 09:38:37 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0VEcZZC030080 for ; Thu, 31 Jan 2013 09:38:35 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0VEcZ0D030071; Thu, 31 Jan 2013 09:38:35 -0500
In-Reply-To: <51099EBD.5050204@mitre.org>
References:  <51099EBD.5050204@mitre.org>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: 2328A016:B0DF92F0-85257B04:004F4780; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Thu, 31 Jan 2013 09:38:34 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/31/2013 09:38:35, Serialize complete at 01/31/2013 09:38:35
Content-Type: multipart/alternative; boundary="=_alternative 00506F6C85257B04_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13013114-9360-0000-0000-00000FF3E72A
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 14:38:42 -0000

This is a multipart message in MIME format.
--=_alternative 00506F6C85257B04_=
Content-Type: text/plain; charset="US-ASCII"

I would vote for consistency with 6749 - string tokenizing doesn't seem 
like a big deal, esp. since clients are going to have to deal with it when 
scopes are returned from the token endpoint.  It was raised here when I 
realized that we would have to give clients two types of guidance when 
dealing with scopes in the introspection response and 6749 endpoints.

If the thinking is that 6749 got it wrong (didn't use JSON syntax 
appropriately), and this is getting it right, that's fine.  I'm more 
interested in knowing if the community thinks it's going to change.





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




From:   Justin Richer 
To:     Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc:     IETF oauth WG 
Date:   01/30/2013 05:29 PM
Subject:        Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope 
syntax



It's not meant to follow the same syntax. Instead, it's making use of the 
JSON object structure to avoid additional parsing of the values on the 
client side.

We could fairly easily define it as the same space-delimited string if 
enough people want to keep the scope format consistent.

 -- Justin

On 01/30/2013 05:27 PM, Todd W Lainhart wrote:
That the scope syntax in draft-richer-oauth-introspection-01 is different 
than RFC 6749 Section 3.3, as in: 


   "scope": ["read", "write", "dolphin"], 

vs. 

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

Should introspection-01 follow the 6749 syntax for scopes?





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



--=_alternative 00506F6C85257B04_=
Content-Type: text/html; charset="US-ASCII"

I would vote for consistency with 6749
- string tokenizing doesn't seem like a big deal, esp. since clients are
going to have to deal with it when scopes are returned from the token endpoint.
 It was raised here when I realized that we would have to give clients
two types of guidance when dealing with scopes in the introspection response
and 6749 endpoints.



If the thinking is that 6749 got it
wrong (didn't use JSON syntax appropriately), and this is getting it right,
that's fine.  I'm more interested in knowing if the community thinks
it's going to change.














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:      
 Justin Richer <jricher@mitre.org>

To:      
 Todd W Lainhart/Lexington/IBM@IBMUS,


Cc:      
 IETF oauth WG <oauth@ietf.org>

Date:      
 01/30/2013 05:29 PM

Subject:    
   Re: [OAUTH-WG]
draft-richer-oauth-introspection-01 scope syntax









It's not meant to follow the same syntax. Instead, it's
making use of the JSON object structure to avoid additional parsing of
the values on the client side.



We could fairly easily define it as the same space-delimited string if
enough people want to keep the scope format consistent.



 -- Justin



On 01/30/2013 05:27 PM, Todd W Lainhart wrote:

That the scope syntax in draft-richer-oauth-introspection-01
is different than RFC 6749 Section 3.3, as in: 





   "scope": ["read", "write",
"dolphin"], 



vs. 



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

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




Should introspection-01 follow the 6749 syntax for scopes?















_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--=_alternative 00506F6C85257B04_=--


From lainhart@us.ibm.com  Thu Jan 31 06:59:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400021F86AE for ; Thu, 31 Jan 2013 06:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.497
X-Spam-Level: 
X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR4tUygzB9dF for ; Thu, 31 Jan 2013 06:59:10 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 331C721F866F for ; Thu, 31 Jan 2013 06:59:10 -0800 (PST)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 31 Jan 2013 09:59:08 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 31 Jan 2013 09:58:50 -0500
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9DDE86E803C; Thu, 31 Jan 2013 09:58:48 -0500 (EST)
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0VEwnkd324310; Thu, 31 Jan 2013 09:58:49 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0VEwnTu023327; Thu, 31 Jan 2013 09:58:49 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0VEwnrC023317; Thu, 31 Jan 2013 09:58:49 -0500
In-Reply-To: 
References: 
To: Nat Sakimura 
MIME-Version: 1.0
X-KeepSent: 93B4AD2D:37A50156-85257B04:0050D88E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Thu, 31 Jan 2013 09:58:48 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/31/2013 09:58:48, Serialize complete at 01/31/2013 09:58:48
Content-Type: multipart/alternative; boundary="=_alternative 0052499085257B04_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13013114-9360-0000-0000-00000FF42E2F
Cc: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 14:59:15 -0000

This is a multipart message in MIME format.
--=_alternative 0052499085257B04_=
Content-Type: text/plain; charset="ISO-2022-JP"

We implemented our dynamic client registration along the lines that Nat 
describes, except that the resource segment and not the query parm 
identifies the client.  The POST and the GET on the collection return the 
resource identifiers (HATEOS).  Query parms on the collection GET works as 
you might imagine. 

There's a lot of precedent for this style of CRUD programming - I'd be 
surprised if developers didn't get the pattern, and expected consistency 
with OAuth authz programming.  I'm not manipulating resources when I'm 
hitting OAuth endpoints.

Create a client:
---------
POST /example/clients HTTP/1.1
Host: example.com:9443
Content-Length: 494
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 
client_name=My%20App&...
 

Fetch a single client:
----------
GET /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1 


Fetch all clients:
----------
GET /example/clients HTTP/1.1 


Modify a client:
------
PUT /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1
Host: example.ibm.com:9443
Content-Type: application/json;charset=UTF-8
If-Match: "osQf9mPplNvituLylwpDmQ=="
Content-Length: 217

 
Delete a client:
--------
DELETE /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1
Host: example.ibm.com:9443
If-Match: "osQf9mPplNvituLylwpDmQ==" 






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




From:   Nat Sakimura 
To:     John Bradley , 
Cc:     oauth@ietf.org
Date:   01/30/2013 09:22 PM
Subject:        [OAUTH-WG] Registration endpoints? (was: Re:  Concerning 
OAuth )
Sent by:        oauth-bounces@ietf.org



(I changed the subject to match the content.) 

Right. It does not have to be three endpoints. One endpoint would do 
(though it depends on how you count the URLs). 

However, I would do it slightly differently than you (John B.) proposes. 

As an example, let the registration endpoint be named /clients, which 
represents the collection of registered clients. 
(This is the registration endpoint.) 

Then, 

POST to the /clients would create the resource in question. (client 
associate) 
POST to /clients?client_id=12345 and post params (the resource URL) would 
update the resource. 
This is not an idempotent request, and could update any portion of the 
resource. 
In particular, client_secret=null or something could mean "rotate secret."

GET to /clients?client_id=12345 would return the client registration data. 
It is idempotent. 
DELETE to /clients?client_id=12345 would delete the resource. 

PUT to /clients?client_id=12345 (the resource URL) would replace the 
resource, and is idempotent. 
 (I am not sure if we need this. Probably better not have one.) 

For any of the above request except DELETE, the response should return the 
entire object. 

(For the purists: Right. This still could be improved by using URI 
template. 
The server could publish the server metadata including URI template for 
the registration etc. 
At that point, server is freed from forced to use the query parameters. 
For example, 
instead of /clients?client_id=12345, it could have instructed the client 
to use /clients/12345/ 
or /clients/id/12345 etc. but I think that is going too far.)

Nat

2013/1/31 John Bradley 
That is better, but I don't see an advantage to that over using a query 
parameter.

They are equally restful or not as the case may be.

To be more restful I think you want a single endpoint using HTTP verbs.

POST /reg_endpoint?paramaters ?  -> register
PUT  /reg_endpoint?client_id=12345¶maters -> update
PUT /reg_endpoint?client_id=12345&rotate_secret=true

The downside is developers understanding

On 2013-01-30, at 1:17 PM, Justin Richer  wrote:

>
> On 01/30/2013 10:55 AM, John Bradley wrote:
>> My feeling was that letting the registration endpoint be a single URL 
(any url) and using query paramaters was easer for servers and clients.
>>
>> Saying take the base URI for the registration endpoint and append these 
paths to it to do different operations seems more likely to go wrong fro 
developers.
> Right, and to clarify, this isn't what I was saying. The spec wouldn't 
specify the path at all, just say that they're three different endpoint 
URLs. The same way that we specify that the auth endpoint and token 
endpoint are different URLs.
>
> I think my example might have been misleading. The URLs could just as 
easily be:
>
> client_register -> /register_a_new_client
> rotate_secret -> /client/go_get_a_secret_or_something
> client_update-> /maintenance/update_client_information
>
>
>
>>
>> Allowing both bath and query parameters is the worst option.
>>
>> I am sympathetic with using POST and PUT and perhaps GET but I worry 
about OAuth developers not getting it.
>>
>> I also don't get Tony's point about multi tenancy.  If each tenant can 
have there own registration endpoint I don't see a problem beyond finding 
the endpoint and that is what we have WF for.
> Exactly. And to Bill's point in another thread, we could also register a 
link type for each endpoint to help facilitate discovery: 
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
>
> -- Justin
>
>>
>> John B.
>>
>> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>>
>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>> I like this most, would rename it to say
>>>>
>>>> /oauth/client/registration
>>>> or
>>>> /oauth/client-registration
>>>>
>>>> etc
>>>>
>>>> and reword the spec such that it will let those who implement do it 
with one endpoint or many, whatever is preferred
>>>>
>>> That's the whole point of this discussion -- I don't believe you can 
have it both ways.
>>>
>>> In one way, you say there are three endpoints and, if you're keeping 
with the rest of OAuth, you don't give them official URL patterns that 
they must follow. How the client gets those endpoints is up to discovery 
or configuration, but the client has an internal map from each bit of 
functionality to a particular URL that's specific to the service, much in 
the same way that the client today has to map the authorization and token 
endpoints. In the other method, you've got one endpoint that the client 
sends a well-defined parameter to in order to accomplish the same goal.
>>>
>>> So if you allow both at once, does a client send the "operation" 
parameter or not? Is it looking for one url or three to store in its 
configuration? I don't think this level of flexibility buys you anything 
useful, and I strongly believe that it will deeply hurt the functionality 
of dynamic registration if it's allowed.
>>>
>>> As it stands today, you can still make the URL whatever you want. If 
we went with three endpoints you could also make those URLs whatever you 
wanted. Nobody has yet pointed out to me what the actual benefit is of 
making both valid.
>>>
>>> I personally prefer the method of three endpoint URLs because it's 
cleaner and semantically equivalent, but I am hesitant to change that 
behavior unless there's strong working group support for it. I haven't 
seen real support for it yet -- it's not a good call to make it fully 
RESTful, and it's not a good call to leave it undefined. A client MUST 
have a very clear recipe of what to do on startup for this to work in the 
wild.
>>>
>>> -- Justin
>>>
>>>>>
>>>>> help multitenancy? How does it even affect that use case? Consider 
that
>>>>> the base URL for all of these is completely up to the host 
environment
>>>>> (nothing is bound to the root URL). Consider that clients still have 
to
>>>>> know what the URL (or URLs) are, in either case. Consider that 
clients
>>>>> still need to know how to manage all the parameters and responses.
>>>>>
>>>>> If anything, keeping it the way that it is with a single URL could 
be
>>>>> argued to help multitenancy because setting up routing to multiple 
URL
>>>>> endpoints can sometimes be problematic in hosted environments. 
However,
>>>>> OAuth already defines a bunch of endpoints, and we have to define at
>>>>> least one more with this extension, so I'm not convinced that having
>>>>> three with specific functions is really any different from having 
one
>>>>> with three functions from a development, deployment, and 
implementation
>>>>> perspective. I can tell you from experience that in our own server 
code,
>>>>> the difference is trivial. (And from OAuth1 experience, you can 
always
>>>>> have a query parameter as part of your endpoint URL if you need to. 
You
>>>>> might hate yourself for doing it that way, but nothing says your 
base
>>>>> URL can't already have parameters on it. A client just needs to know 
how
>>>>> to appropriately tack its parameters onto an existing URL, and any 
HTTP
>>>>> client worth its salt will know how to augment a query parameter set
>>>>> with new items.)
>>>>>
>>>>> The *real* difference between the two approaches is a philosophical
>>>>> design one. The former overloads one URL with multiple functions
>>>>> switched by a flag, the latter uses the URL itself as an implicit 
flag.
>>>>> Under the hood, these could (and in many cases will) be all served 
by
>>>>> the same chunks of code. The only difference is how this switch in
>>>>> functionality is presented.
>>>>>
>>>>>
>>>>> With that said, can somebody please explain to me how allowing 
*both* of
>>>>> these as options simultaneously (what I understand Tony to be
>>>>> suggesting) is a good idea, or how multitenancy even comes into 
play?
>>>>> Because I am completely not seeing how these are related.
>>>>>
>>>>> Thanks,
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>> It will not work the way you have it, as people do multi-tendency 
different and they are already stuck with the method that they have 
chosen, so they need the flexability, to restrict this is nuts as people 
won't use it.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> I completely disagree with this assessment. Multi-tenancy will work 
just fine (or even better) if everyone uses the same pattern. Telling 
someone "it might be three different urls or it might be all one url with 
a parameter" is just asking for a complete disaster. What does the 
flexibility of allowing two approaches actually accomplish?
>>>>>>
>>>>>> You can argue about the merits of either approach, but having both 
as unspecified options for registration, which is meant to help things get 
going in a cold-boot environment, is just plain nuts.
>>>>>>
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>> Registration has to work in a multi-tenant environment  so 
flexibility
>>>>>>> is needed
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>
>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>
>>>>>>> In my opinion, this is a key place where this kind of flexibility 
is a very bad thing. Registration needs to work one fairly predictable 
way.
>>>>>>>
>>>>>>> -- Justin
>>>>>>>
>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura
>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>
>>>>>>>> Which brings up an interesting question for the Registration doc: 
right now, it's set up as a single endpoint with three operations. We 
could instead define three endpoints for the different operations.
>>>>>>>>
>>>>>>>> I've not been keen to make that deep of a cutting change to it, 
but it would certainly be cleaner and more RESTful API design. What do 
others think?
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>
>>>>>>>>> =nat via iPhone
>>>>>>>>>
>>>>>>>>> Jan 23, 2013 4:00、Justin Richer  のメッセー
ジ:
>>>>>>>>>
>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>
>>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. 
The idea behind having different endpoints in OAuth is that they each do 
different kinds of things. The only "action/operation" that I had 
envisioned for the introspection endpoint is introspection itself: "I have 
a token, what does it mean?"
>>>>>>>>>>
>>>>>>>>>> Note that client_id and client_secret *can* already be used at 
this endpoint if the server supports that as part of their client 
credentials setup. The examples use HTTP Basic with client id and secret 
right now. Basically, the client can authenticate however it wants, 
including any of the methods that OAuth2 allows on the token endpoint. It 
could also authenticate with an access token. At least, that's the intent 
of the introspection draft -- if that's unclear, I'd be happy to accept 
suggested changes to clarify this text.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>> Justin,
>>>>>>>>>>>
>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>
>>>>>>>>>>> One thing I would like to recommend is to add 
"action"/"operation"
>>>>>>>>>>> to the request.  (and potentially add client_id and 
client_secret)
>>>>>>>>>>>
>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED
>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire 
(default) | revoke ...
>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>
>>>>>>>>>>> And for the OAuth client information, it should be an optional 
parameter (in case it is a public client or client is authenticated with 
SSL mutual authentication).
>>>>>>>>>>>
>>>>>>>>>>> Please consider.
>>>>>>>>>>>
>>>>>>>>>>> ShiuFun
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>

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



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


--=_alternative 0052499085257B04_=
Content-Type: text/html; charset="ISO-2022-JP"

We implemented our dynamic client registration
along the lines that Nat describes, except that the resource segment and
not the query parm identifies the client.  The POST and the GET on
the collection return the resource identifiers (HATEOS).  Query parms
on the collection GET works as you might imagine.  



There's a lot of precedent for this
style of CRUD programming - I'd be surprised if developers didn't get the
pattern, and expected consistency with OAuth authz programming.  I'm
not manipulating resources when I'm hitting OAuth endpoints.



Create a client:

---------

POST /example/clients
HTTP/1.1

Host: example.com:9443

Content-Length: 494

Content-Type: application/x-www-form-urlencoded;
charset=UTF-8

 

client_name=My%20App&...

 



Fetch a single client:

----------

GET /example/clients/6b4333771e1a409c90dd2062dd9e266e
HTTP/1.1 





Fetch all clients:

----------

GET /example/clients
HTTP/1.1 





Modify a client:

------

PUT /example/clients/6b4333771e1a409c90dd2062dd9e266e
HTTP/1.1

Host: example.ibm.com:9443

Content-Type: application/json;charset=UTF-8

If-Match: "osQf9mPplNvituLylwpDmQ=="

Content-Length: 217



 

Delete a client:

--------

DELETE /example/clients/6b4333771e1a409c90dd2062dd9e266e
HTTP/1.1

Host: example.ibm.com:9443

If-Match: "osQf9mPplNvituLylwpDmQ==" 
















Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:      
 Nat Sakimura <sakimura@gmail.com>

To:      
 John Bradley <ve7jtb@ve7jtb.com>,


Cc:      
 oauth@ietf.org

Date:      
 01/30/2013 09:22 PM

Subject:    
   [OAUTH-WG] Registration
endpoints? (was: Re:  Concerning OAuth )

Sent by:    
   oauth-bounces@ietf.org









(I changed the subject to match the
content.) 



Right. It does not have to be three
endpoints. One endpoint would do (though it depends on how you count the
URLs).  



However, I would do it slightly differently
than you (John B.) proposes. 



As an example, let the registration
endpoint be named /clients, which represents the collection of registered
clients. 

(This is the registration endpoint.)




Then, 



POST to the /clients would create the
resource in question. (client associate) 

POST to /clients?client_id=12345 and
post params (the resource URL) would update the resource. 

This is not an idempotent request, and
could update any portion of the resource. 

In particular, client_secret=null or
something could mean "rotate secret."



GET to /clients?client_id=12345 would
return the client registration data. It is idempotent. 

DELETE to /clients?client_id=12345 would
delete the resource. 



PUT to /clients?client_id=12345 (the
resource URL) would replace the resource, and is idempotent. 

 (I am not sure if we need this.
Probably better not have one.) 



For any of the above request except
DELETE, the response should return the entire object. 



(For the purists: Right. This still
could be improved by using URI template. 

The server could publish the server
metadata including URI template for the registration etc. 

At that point, server is freed from
forced to use the query parameters. For example, 

instead of /clients?client_id=12345,
it could have instructed the client to use /clients/12345/ 

or /clients/id/12345 etc. but I think
that is going too far.)



Nat



2013/1/31 John Bradley <ve7jtb@ve7jtb.com>

That is better, but I don't see an advantage
to that over using a query parameter.



They are equally restful or not as the case may be.



To be more restful I think you want a single endpoint using HTTP verbs.



POST /reg_endpoint?paramaters …  -> register

PUT  /reg_endpoint?client_id=12345&paramaters -> update

PUT /reg_endpoint?client_id=12345&rotate_secret=true



The downside is developers understanding



On 2013-01-30, at 1:17 PM, Justin Richer <jricher@mitre.org>
wrote:



>

> On 01/30/2013 10:55 AM, John Bradley wrote:

>> My feeling was that letting the registration endpoint be a single
URL (any url) and using query paramaters was easer for servers and clients.

>>

>> Saying take the base URI for the registration endpoint and append
these paths to it to do different operations seems more likely to go wrong
fro developers.

> Right, and to clarify, this isn't what I was saying. The spec wouldn't
specify the path at all, just say that they're three different endpoint
URLs. The same way that we specify that the auth endpoint and token endpoint
are different URLs.

>

> I think my example might have been misleading. The URLs could just
as easily be:

>

> client_register -> /register_a_new_client

> rotate_secret -> /client/go_get_a_secret_or_something

> client_update-> /maintenance/update_client_information

>

>

>

>>

>> Allowing both bath and query parameters is the worst option.

>>

>> I am sympathetic with using POST and PUT and perhaps GET but I
worry about OAuth developers not getting it.

>>

>> I also don't get Tony's point about multi tenancy.  If each
tenant can have there own registration endpoint I don't see a problem beyond
finding the endpoint and that is what we have WF for.

> Exactly. And to Bill's point in another thread, we could also register
a link type for each endpoint to help facilitate discovery: http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06

>

> -- Justin

>

>>

>> John B.

>>

>> On 2013-01-24, at 11:26 AM, Justin Richer <jricher@mitre.org>
wrote:

>>

>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:

>>>> I like this most, would rename it to say

>>>>

>>>> /oauth/client/registration

>>>> or

>>>> /oauth/client-registration

>>>>

>>>> etc

>>>>

>>>> and reword the spec such that it will let those who implement
do it with one endpoint or many, whatever is preferred

>>>>

>>> That's the whole point of this discussion -- I don't believe
you can have it both ways.

>>>

>>> In one way, you say there are three endpoints and, if you're
keeping with the rest of OAuth, you don't give them official URL patterns
that they must follow. How the client gets those endpoints is up to discovery
or configuration, but the client has an internal map from each bit of functionality
to a particular URL that's specific to the service, much in the same way
that the client today has to map the authorization and token endpoints.
In the other method, you've got one endpoint that the client sends a well-defined
parameter to in order to accomplish the same goal.

>>>

>>> So if you allow both at once, does a client send the "operation"
parameter or not? Is it looking for one url or three to store in its configuration?
I don't think this level of flexibility buys you anything useful, and I
strongly believe that it will deeply hurt the functionality of dynamic
registration if it's allowed.

>>>

>>> As it stands today, you can still make the URL whatever you
want. If we went with three endpoints you could also make those URLs whatever
you wanted. Nobody has yet pointed out to me what the actual benefit is
of making both valid.

>>>

>>> I personally prefer the method of three endpoint URLs because
it's cleaner and semantically equivalent, but I am hesitant to change that
behavior unless there's strong working group support for it. I haven't
seen real support for it yet -- it's not a good call to make it fully RESTful,
and it's not a good call to leave it undefined. A client MUST have a very
clear recipe of what to do on startup for this to work in the wild.

>>>

>>> -- Justin

>>>

>>>>>

>>>>> help multitenancy? How does it even affect that use
case? Consider that

>>>>> the base URL for all of these is completely up to
the host environment

>>>>> (nothing is bound to the root URL). Consider that
clients still have to

>>>>> know what the URL (or URLs) are, in either case. Consider
that clients

>>>>> still need to know how to manage all the parameters
and responses.

>>>>>

>>>>> If anything, keeping it the way that it is with a
single URL could be

>>>>> argued to help multitenancy because setting up routing
to multiple URL

>>>>> endpoints can sometimes be problematic in hosted environments.
However,

>>>>> OAuth already defines a bunch of endpoints, and we
have to define at

>>>>> least one more with this extension, so I'm not convinced
that having

>>>>> three with specific functions is really any different
from having one

>>>>> with three functions from a development, deployment,
and implementation

>>>>> perspective. I can tell you from experience that in
our own server code,

>>>>> the difference is trivial. (And from OAuth1 experience,
you can always

>>>>> have a query parameter as part of your endpoint URL
if you need to. You

>>>>> might hate yourself for doing it that way, but nothing
says your base

>>>>> URL can't already have parameters on it. A client
just needs to know how

>>>>> to appropriately tack its parameters onto an existing
URL, and any HTTP

>>>>> client worth its salt will know how to augment a query
parameter set

>>>>> with new items.)

>>>>>

>>>>> The *real* difference between the two approaches is
a philosophical

>>>>> design one. The former overloads one URL with multiple
functions

>>>>> switched by a flag, the latter uses the URL itself
as an implicit flag.

>>>>> Under the hood, these could (and in many cases will)
be all served by

>>>>> the same chunks of code. The only difference is how
this switch in

>>>>> functionality is presented.

>>>>>

>>>>>

>>>>> With that said, can somebody please explain to me
how allowing *both* of

>>>>> these as options simultaneously (what I understand
Tony to be

>>>>> suggesting) is a good idea, or how multitenancy even
comes into play?

>>>>> Because I am completely not seeing how these are related.

>>>>>

>>>>> Thanks,

>>>>> -- Justin

>>>>>

>>>>>

>>>>>

>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

>>>>>> It will not work the way you have it, as people
do multi-tendency different and they are already stuck with the method
that they have chosen, so they need the flexability, to restrict this is
nuts as people won't use it.

>>>>>>

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

>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM

>>>>>> To: Anthony Nadalin

>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection

>>>>>>

>>>>>> I completely disagree with this assessment. Multi-tenancy
will work just fine (or even better) if everyone uses the same pattern.
Telling someone "it might be three different urls or it might be all
one url with a parameter" is just asking for a complete disaster.
What does the flexibility of allowing two approaches actually accomplish?

>>>>>>

>>>>>> You can argue about the merits of either approach,
but having both as unspecified options for registration, which is meant
to help things get going in a cold-boot environment, is just plain nuts.

>>>>>>

>>>>>>

>>>>>> -- Justin

>>>>>>

>>>>>>

>>>>>>

>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

>>>>>>> Registration has to work in a multi-tenant
environment  so flexibility

>>>>>>> is needed

>>>>>>>

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

>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM

>>>>>>> To: Anthony Nadalin

>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection

>>>>>>>

>>>>>>> Because then nobody would know how to actually
use the thing.

>>>>>>>

>>>>>>> In my opinion, this is a key place where this
kind of flexibility is a very bad thing. Registration needs to work one
fairly predictable way.

>>>>>>>

>>>>>>> -- Justin

>>>>>>>

>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

>>>>>>>> Why not just have a physical and logical
endpoint options

>>>>>>>>

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

>>>>>>>> From:oauth-bounces@ietf.org
[mailto:oauth-bounces@ietf.org]
On

>>>>>>>> Behalf Of Justin Richer

>>>>>>>> Sent: Wednesday, January 23, 2013 7:47
AM

>>>>>>>> To: Nat Sakimura

>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org

>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth
introspection

>>>>>>>>

>>>>>>>> Which brings up an interesting question
for the Registration doc: right now, it's set up as a single endpoint with
three operations. We could instead define three endpoints for the different
operations.

>>>>>>>>

>>>>>>>> I've not been keen to make that deep of
a cutting change to it, but it would certainly be cleaner and more RESTful
API design. What do others think?

>>>>>>>>

>>>>>>>> -- Justin

>>>>>>>>

>>>>>>>>

>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:

>>>>>>>>> "Action" goes against REST
principle.

>>>>>>>>> I do not think it is a good idea.

>>>>>>>>>

>>>>>>>>> =nat via iPhone

>>>>>>>>>

>>>>>>>>> Jan 23, 2013 4:00、Justin Richer<jricher@mitre.org>
 のメッセージ:

>>>>>>>>>

>>>>>>>>>> (CC'ing the working group)

>>>>>>>>>>

>>>>>>>>>> I'm not sure what the "action/operation"
flag would accomplish. The idea behind having different endpoints in OAuth
is that they each do different kinds of things. The only "action/operation"
that I had envisioned for the introspection endpoint is introspection itself:
"I have a token, what does it mean?"

>>>>>>>>>>

>>>>>>>>>> Note that client_id and client_secret
*can* already be used at this endpoint if the server supports that as part
of their client credentials setup. The examples use HTTP Basic with client
id and secret right now. Basically, the client can authenticate however
it wants, including any of the methods that OAuth2 allows on the token
endpoint. It could also authenticate with an access token. At least, that's
the intent of the introspection draft -- if that's unclear, I'd be happy
to accept suggested changes to clarify this text.

>>>>>>>>>>

>>>>>>>>>>  -- Justin

>>>>>>>>>>

>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun
Poon wrote:

>>>>>>>>>>> Justin,

>>>>>>>>>>>

>>>>>>>>>>> This spec is looking good..

>>>>>>>>>>>

>>>>>>>>>>> One thing I would like to
recommend is to add "action"/"operation"

>>>>>>>>>>> to the request.  (and
potentially add client_id and client_secret)

>>>>>>>>>>>

>>>>>>>>>>> So the request will be like
:

>>>>>>>>>>> token REQUIRED

>>>>>>>>>>> operation (wording to be determine)
 OPTIONAL inquire (default) | revoke ...

>>>>>>>>>>> resource_id OPTIONAL

>>>>>>>>>>> client_id OPTIONAL

>>>>>>>>>>> client_secret OPTIONAL

>>>>>>>>>>>

>>>>>>>>>>> And for the OAuth client information,
it should be an optional parameter (in case it is a public client or client
is authenticated with SSL mutual authentication).

>>>>>>>>>>>

>>>>>>>>>>> Please consider.

>>>>>>>>>>>

>>>>>>>>>>> ShiuFun

>>>>>>>>>> _______________________________________________

>>>>>>>>>> OAuth mailing list

>>>>>>>>>> OAuth@ietf.org

>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>> _______________________________________________

>>>>>>>> OAuth mailing list

>>>>>>>> OAuth@ietf.org

>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>>

>>>>>>>>

>>>>>>>>

>>>>>>>

>>>>>>

>>>>>>

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OAuth@ietf.org

>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oauth

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

>>> https://www.ietf.org/mailman/listinfo/oauth

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth







-- 

Nat Sakimura (=nat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--=_alternative 0052499085257B04_=--


From lainhart@us.ibm.com  Thu Jan 31 07:01:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135DB21F8503 for ; Thu, 31 Jan 2013 07:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.208
X-Spam-Level: 
X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrf-WbDFqPqy for ; Thu, 31 Jan 2013 07:01:21 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 551B321F858E for ; Thu, 31 Jan 2013 07:01:15 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 31 Jan 2013 10:01:14 -0500
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 31 Jan 2013 10:01:11 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 96924C90049; Thu, 31 Jan 2013 10:01:10 -0500 (EST)
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0VF19RV170880; Thu, 31 Jan 2013 10:01:09 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0VF0l5x029887; Thu, 31 Jan 2013 10:00:47 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0VF0l2l029842; Thu, 31 Jan 2013 10:00:47 -0500
In-Reply-To: 
References: 	<4E1F6AAD24975D4BA5B1680429673943673F3A6E@TK5EX14MBXC284.redmond.corp.microsoft.com> 
To: Nat Sakimura 
MIME-Version: 1.0
X-KeepSent: 950F8371:A6DB203F-85257B04:0052634D; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Thu, 31 Jan 2013 10:00:31 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/31/2013 10:00:47, Serialize complete at 01/31/2013 10:00:47
Content-Type: multipart/alternative; boundary="=_alternative 005271D085257B04_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13013115-7182-0000-0000-000004D6FF09
Cc: "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 15:01:26 -0000

This is a multipart message in MIME format.
--=_alternative 005271D085257B04_=
Content-Type: text/plain; charset="ISO-2022-JP"

> We should not conflate with OAuth core framework requirements and 
protected resource requirements. 

+1





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




From:   Nat Sakimura 
To:     Mike Jones , 
Cc:     "oauth@ietf.org" 
Date:   01/30/2013 10:00 PM
Subject:        Re: [OAUTH-WG] Registration endpoints? (was: Re: 
Concerning OAuth )
Sent by:        oauth-bounces@ietf.org



OAuth did not talk make distinctions or talk about HTTP methods because of 
two reasons: 

(1) Browser in the middle with HTTP redirect constraint. 
(2) The protected resource is the party who decides what semantics is 
being mapped to the HTTP methods. 

The (1) above is just a work around for the constrained user agents. 

Registration is server to server, so we do not need to be constrained by 
this. 

The (2) is a requirement to the framework because OAuth should not pollute 
the space and should let the protected resource decide on their own. 

Registration endpoint is a protected resource that should decide the 
mapping. 

We should not conflate with OAuth core framework requirements and 
protected resource requirements. 

Nat

2013/1/31 Mike Jones 
OAuth *never* makes a distinction between what GET and POST do.  (Yes, 
they pass the input parameters differently.)  I *really* don?t think we 
should start doing this now for new operations.  It will likely only 
confuse developers and make things harder for them ? especially when using 
software that may not always give them full access to all HTTP verbs and 
header parameters.
 
                                                                -- Mike
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of 
Nat Sakimura
Sent: Wednesday, January 30, 2013 6:22 PM
To: John Bradley
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
 
(I changed the subject to match the content.) 
 
Right. It does not have to be three endpoints. One endpoint would do 
(though it depends on how you count the URLs). 
 
However, I would do it slightly differently than you (John B.) proposes. 
 
As an example, let the registration endpoint be named /clients, which 
represents the collection of registered clients. 
(This is the registration endpoint.) 
 
Then, 
 
POST to the /clients would create the resource in question. (client 
associate) 
POST to /clients?client_id=12345 and post params (the resource URL) would 
update the resource. 
This is not an idempotent request, and could update any portion of the 
resource. 
In particular, client_secret=null or something could mean "rotate secret."
 
GET to /clients?client_id=12345 would return the client registration data. 
It is idempotent. 
DELETE to /clients?client_id=12345 would delete the resource. 
 
PUT to /clients?client_id=12345 (the resource URL) would replace the 
resource, and is idempotent. 
 (I am not sure if we need this. Probably better not have one.) 
 
For any of the above request except DELETE, the response should return the 
entire object. 
 
(For the purists: Right. This still could be improved by using URI 
template. 
The server could publish the server metadata including URI template for 
the registration etc. 
At that point, server is freed from forced to use the query parameters. 
For example, 
instead of /clients?client_id=12345, it could have instructed the client 
to use /clients/12345/ 
or /clients/id/12345 etc. but I think that is going too far.)
 
Nat
2013/1/31 John Bradley 
That is better, but I don't see an advantage to that over using a query 
parameter.

They are equally restful or not as the case may be.

To be more restful I think you want a single endpoint using HTTP verbs.

POST /reg_endpoint?paramaters ?  -> register
PUT  /reg_endpoint?client_id=12345¶maters -> update
PUT /reg_endpoint?client_id=12345&rotate_secret=true

The downside is developers understanding

On 2013-01-30, at 1:17 PM, Justin Richer  wrote:

>
> On 01/30/2013 10:55 AM, John Bradley wrote:
>> My feeling was that letting the registration endpoint be a single URL 
(any url) and using query paramaters was easer for servers and clients.
>>
>> Saying take the base URI for the registration endpoint and append these 
paths to it to do different operations seems more likely to go wrong fro 
developers.
> Right, and to clarify, this isn't what I was saying. The spec wouldn't 
specify the path at all, just say that they're three different endpoint 
URLs. The same way that we specify that the auth endpoint and token 
endpoint are different URLs.
>
> I think my example might have been misleading. The URLs could just as 
easily be:
>
> client_register -> /register_a_new_client
> rotate_secret -> /client/go_get_a_secret_or_something
> client_update-> /maintenance/update_client_information
>
>
>
>>
>> Allowing both bath and query parameters is the worst option.
>>
>> I am sympathetic with using POST and PUT and perhaps GET but I worry 
about OAuth developers not getting it.
>>
>> I also don't get Tony's point about multi tenancy.  If each tenant can 
have there own registration endpoint I don't see a problem beyond finding 
the endpoint and that is what we have WF for.
> Exactly. And to Bill's point in another thread, we could also register a 
link type for each endpoint to help facilitate discovery: 
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06
>
> -- Justin
>
>>
>> John B.
>>
>> On 2013-01-24, at 11:26 AM, Justin Richer  wrote:
>>
>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>>> I like this most, would rename it to say
>>>>
>>>> /oauth/client/registration
>>>> or
>>>> /oauth/client-registration
>>>>
>>>> etc
>>>>
>>>> and reword the spec such that it will let those who implement do it 
with one endpoint or many, whatever is preferred
>>>>
>>> That's the whole point of this discussion -- I don't believe you can 
have it both ways.
>>>
>>> In one way, you say there are three endpoints and, if you're keeping 
with the rest of OAuth, you don't give them official URL patterns that 
they must follow. How the client gets those endpoints is up to discovery 
or configuration, but the client has an internal map from each bit of 
functionality to a particular URL that's specific to the service, much in 
the same way that the client today has to map the authorization and token 
endpoints. In the other method, you've got one endpoint that the client 
sends a well-defined parameter to in order to accomplish the same goal.
>>>
>>> So if you allow both at once, does a client send the "operation" 
parameter or not? Is it looking for one url or three to store in its 
configuration? I don't think this level of flexibility buys you anything 
useful, and I strongly believe that it will deeply hurt the functionality 
of dynamic registration if it's allowed.
>>>
>>> As it stands today, you can still make the URL whatever you want. If 
we went with three endpoints you could also make those URLs whatever you 
wanted. Nobody has yet pointed out to me what the actual benefit is of 
making both valid.
>>>
>>> I personally prefer the method of three endpoint URLs because it's 
cleaner and semantically equivalent, but I am hesitant to change that 
behavior unless there's strong working group support for it. I haven't 
seen real support for it yet -- it's not a good call to make it fully 
RESTful, and it's not a good call to leave it undefined. A client MUST 
have a very clear recipe of what to do on startup for this to work in the 
wild.
>>>
>>> -- Justin
>>>
>>>>>
>>>>> help multitenancy? How does it even affect that use case? Consider 
that
>>>>> the base URL for all of these is completely up to the host 
environment
>>>>> (nothing is bound to the root URL). Consider that clients still have 
to
>>>>> know what the URL (or URLs) are, in either case. Consider that 
clients
>>>>> still need to know how to manage all the parameters and responses.
>>>>>
>>>>> If anything, keeping it the way that it is with a single URL could 
be
>>>>> argued to help multitenancy because setting up routing to multiple 
URL
>>>>> endpoints can sometimes be problematic in hosted environments. 
However,
>>>>> OAuth already defines a bunch of endpoints, and we have to define at
>>>>> least one more with this extension, so I'm not convinced that having
>>>>> three with specific functions is really any different from having 
one
>>>>> with three functions from a development, deployment, and 
implementation
>>>>> perspective. I can tell you from experience that in our own server 
code,
>>>>> the difference is trivial. (And from OAuth1 experience, you can 
always
>>>>> have a query parameter as part of your endpoint URL if you need to. 
You
>>>>> might hate yourself for doing it that way, but nothing says your 
base
>>>>> URL can't already have parameters on it. A client just needs to know 
how
>>>>> to appropriately tack its parameters onto an existing URL, and any 
HTTP
>>>>> client worth its salt will know how to augment a query parameter set
>>>>> with new items.)
>>>>>
>>>>> The *real* difference between the two approaches is a philosophical
>>>>> design one. The former overloads one URL with multiple functions
>>>>> switched by a flag, the latter uses the URL itself as an implicit 
flag.
>>>>> Under the hood, these could (and in many cases will) be all served 
by
>>>>> the same chunks of code. The only difference is how this switch in
>>>>> functionality is presented.
>>>>>
>>>>>
>>>>> With that said, can somebody please explain to me how allowing 
*both* of
>>>>> these as options simultaneously (what I understand Tony to be
>>>>> suggesting) is a good idea, or how multitenancy even comes into 
play?
>>>>> Because I am completely not seeing how these are related.
>>>>>
>>>>> Thanks,
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>>> It will not work the way you have it, as people do multi-tendency 
different and they are already stuck with the method that they have 
chosen, so they need the flexability, to restrict this is nuts as people 
won't use it.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> I completely disagree with this assessment. Multi-tenancy will work 
just fine (or even better) if everyone uses the same pattern. Telling 
someone "it might be three different urls or it might be all one url with 
a parameter" is just asking for a complete disaster. What does the 
flexibility of allowing two approaches actually accomplish?
>>>>>>
>>>>>> You can argue about the merits of either approach, but having both 
as unspecified options for registration, which is meant to help things get 
going in a cold-boot environment, is just plain nuts.
>>>>>>
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>>>> Registration has to work in a multi-tenant environment  so 
flexibility
>>>>>>> is needed
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>>>> To: Anthony Nadalin
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>
>>>>>>> Because then nobody would know how to actually use the thing.
>>>>>>>
>>>>>>> In my opinion, this is a key place where this kind of flexibility 
is a very bad thing. Registration needs to work one fairly predictable 
way.
>>>>>>>
>>>>>>> -- Justin
>>>>>>>
>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>>>> Why not just have a physical and logical endpoint options
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>>>> To: Nat Sakimura
>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>>>
>>>>>>>> Which brings up an interesting question for the Registration doc: 
right now, it's set up as a single endpoint with three operations. We 
could instead define three endpoints for the different operations.
>>>>>>>>
>>>>>>>> I've not been keen to make that deep of a cutting change to it, 
but it would certainly be cleaner and more RESTful API design. What do 
others think?
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>>>> "Action" goes against REST principle.
>>>>>>>>> I do not think it is a good idea.
>>>>>>>>>
>>>>>>>>> =nat via iPhone
>>>>>>>>>
>>>>>>>>> Jan 23, 2013 4:00、Justin Richer  のメッセー
ジ:
>>>>>>>>>
>>>>>>>>>> (CC'ing the working group)
>>>>>>>>>>
>>>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. 
The idea behind having different endpoints in OAuth is that they each do 
different kinds of things. The only "action/operation" that I had 
envisioned for the introspection endpoint is introspection itself: "I have 
a token, what does it mean?"
>>>>>>>>>>
>>>>>>>>>> Note that client_id and client_secret *can* already be used at 
this endpoint if the server supports that as part of their client 
credentials setup. The examples use HTTP Basic with client id and secret 
right now. Basically, the client can authenticate however it wants, 
including any of the methods that OAuth2 allows on the token endpoint. It 
could also authenticate with an access token. At least, that's the intent 
of the introspection draft -- if that's unclear, I'd be happy to accept 
suggested changes to clarify this text.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>>>> Justin,
>>>>>>>>>>>
>>>>>>>>>>> This spec is looking good..
>>>>>>>>>>>
>>>>>>>>>>> One thing I would like to recommend is to add 
"action"/"operation"
>>>>>>>>>>> to the request.  (and potentially add client_id and 
client_secret)
>>>>>>>>>>>
>>>>>>>>>>> So the request will be like :
>>>>>>>>>>> token REQUIRED
>>>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire 
(default) | revoke ...
>>>>>>>>>>> resource_id OPTIONAL
>>>>>>>>>>> client_id OPTIONAL
>>>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>>>
>>>>>>>>>>> And for the OAuth client information, it should be an optional 
parameter (in case it is a public client or client is authenticated with 
SSL mutual authentication).
>>>>>>>>>>>
>>>>>>>>>>> Please consider.
>>>>>>>>>>>
>>>>>>>>>>> ShiuFun
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>

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


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



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


--=_alternative 005271D085257B04_=
Content-Type: text/html; charset="ISO-2022-JP"

> We
should not conflate with OAuth core framework requirements and protected
resource requirements. 



+1














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:      
 Nat Sakimura <sakimura@gmail.com>

To:      
 Mike Jones <Michael.Jones@microsoft.com>,


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

Date:      
 01/30/2013 10:00 PM

Subject:    
   Re: [OAUTH-WG]
Registration endpoints? (was: Re: Concerning OAuth )

Sent by:    
   oauth-bounces@ietf.org









OAuth did not talk make distinctions
or talk about HTTP methods because of two reasons: 



(1) Browser in the middle with
HTTP redirect constraint. 

(2) The protected resource
is the party who decides what semantics is being mapped to the HTTP methods.




The (1) above is just a work
around for the constrained user agents. 



Registration is server to server,
so we do not need to be constrained by this. 



The (2) is a requirement to
the framework because OAuth should not pollute the space and should let
the protected resource decide on their own. 



Registration endpoint is a
protected resource that should decide the mapping.  



We should not conflate with
OAuth core framework requirements and protected resource requirements.




Nat



2013/1/31 Mike Jones <Michael.Jones@microsoft.com>

OAuth *never* makes
a distinction between what GET and POST do.  (Yes, they pass the input
parameters differently.)  I *really* don’t think we should
start doing this now for new operations.  It will likely only confuse
developers and make things harder for them – especially when using software
that may not always give them full access to all HTTP verbs and header
parameters.

 

       
                     
                     
            -- Mike

 

From: oauth-bounces@ietf.org
[mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, January 30, 2013 6:22 PM

To: John Bradley

Cc: oauth@ietf.org

Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth
)

 

(I changed the subject to match the content.)


 

Right. It does not have to be three endpoints.
One endpoint would do (though it depends on how you count the URLs).  

 

However, I would do it slightly differently
than you (John B.) proposes. 

 

As an example, let the registration endpoint
be named /clients, which represents the collection of registered clients.


(This is the registration endpoint.)


 

Then, 

 

POST to the /clients would create the
resource in question. (client associate) 

POST to /clients?client_id=12345 and
post params (the resource URL) would update the resource. 

This is not an idempotent request, and
could update any portion of the resource. 

In particular, client_secret=null or
something could mean "rotate secret."

 

GET to /clients?client_id=12345 would
return the client registration data. It is idempotent. 

DELETE to /clients?client_id=12345 would
delete the resource. 

 

PUT to /clients?client_id=12345 (the
resource URL) would replace the resource, and is idempotent. 

 (I am not sure if we need this.
Probably better not have one.) 

 

For any of the above request except DELETE,
the response should return the entire object. 

 

(For the purists: Right. This still could
be improved by using URI template. 

The server could publish the server metadata
including URI template for the registration etc. 

At that point, server is freed from forced
to use the query parameters. For example, 

instead of /clients?client_id=12345,
it could have instructed the client to use /clients/12345/ 

or /clients/id/12345 etc. but I think
that is going too far.)

 

Nat

2013/1/31 John Bradley <ve7jtb@ve7jtb.com>

That is better, but I don't see an advantage
to that over using a query parameter.



They are equally restful or not as the case may be.



To be more restful I think you want a single endpoint using HTTP verbs.



POST /reg_endpoint?paramaters …  -> register

PUT  /reg_endpoint?client_id=12345&paramaters -> update

PUT /reg_endpoint?client_id=12345&rotate_secret=true



The downside is developers understanding



On 2013-01-30, at 1:17 PM, Justin Richer <jricher@mitre.org>
wrote:



>

> On 01/30/2013 10:55 AM, John Bradley wrote:

>> My feeling was that letting the registration endpoint be a single
URL (any url) and using query paramaters was easer for servers and clients.

>>

>> Saying take the base URI for the registration endpoint and append
these paths to it to do different operations seems more likely to go wrong
fro developers.

> Right, and to clarify, this isn't what I was saying. The spec wouldn't
specify the path at all, just say that they're three different endpoint
URLs. The same way that we specify that the auth endpoint and token endpoint
are different URLs.

>

> I think my example might have been misleading. The URLs could just
as easily be:

>

> client_register -> /register_a_new_client

> rotate_secret -> /client/go_get_a_secret_or_something

> client_update-> /maintenance/update_client_information

>

>

>

>>

>> Allowing both bath and query parameters is the worst option.

>>

>> I am sympathetic with using POST and PUT and perhaps GET but I
worry about OAuth developers not getting it.

>>

>> I also don't get Tony's point about multi tenancy.  If each
tenant can have there own registration endpoint I don't see a problem beyond
finding the endpoint and that is what we have WF for.

> Exactly. And to Bill's point in another thread, we could also register
a link type for each endpoint to help facilitate discovery: http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06

>

> -- Justin

>

>>

>> John B.

>>

>> On 2013-01-24, at 11:26 AM, Justin Richer <jricher@mitre.org>
wrote:

>>

>>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:

>>>> I like this most, would rename it to say

>>>>

>>>> /oauth/client/registration

>>>> or

>>>> /oauth/client-registration

>>>>

>>>> etc

>>>>

>>>> and reword the spec such that it will let those who implement
do it with one endpoint or many, whatever is preferred

>>>>

>>> That's the whole point of this discussion -- I don't believe
you can have it both ways.

>>>

>>> In one way, you say there are three endpoints and, if you're
keeping with the rest of OAuth, you don't give them official URL patterns
that they must follow. How the client gets those endpoints is up to discovery
or configuration, but the client has an internal map from each bit of functionality
to a particular URL that's specific to the service, much in the same way
that the client today has to map the authorization and token endpoints.
In the other method, you've got one endpoint that the client sends a well-defined
parameter to in order to accomplish the same goal.

>>>

>>> So if you allow both at once, does a client send the "operation"
parameter or not? Is it looking for one url or three to store in its configuration?
I don't think this level of flexibility buys you anything useful, and I
strongly believe that it will deeply hurt the functionality of dynamic
registration if it's allowed.

>>>

>>> As it stands today, you can still make the URL whatever you
want. If we went with three endpoints you could also make those URLs whatever
you wanted. Nobody has yet pointed out to me what the actual benefit is
of making both valid.

>>>

>>> I personally prefer the method of three endpoint URLs because
it's cleaner and semantically equivalent, but I am hesitant to change that
behavior unless there's strong working group support for it. I haven't
seen real support for it yet -- it's not a good call to make it fully RESTful,
and it's not a good call to leave it undefined. A client MUST have a very
clear recipe of what to do on startup for this to work in the wild.

>>>

>>> -- Justin

>>>

>>>>>

>>>>> help multitenancy? How does it even affect that use
case? Consider that

>>>>> the base URL for all of these is completely up to
the host environment

>>>>> (nothing is bound to the root URL). Consider that
clients still have to

>>>>> know what the URL (or URLs) are, in either case. Consider
that clients

>>>>> still need to know how to manage all the parameters
and responses.

>>>>>

>>>>> If anything, keeping it the way that it is with a
single URL could be

>>>>> argued to help multitenancy because setting up routing
to multiple URL

>>>>> endpoints can sometimes be problematic in hosted environments.
However,

>>>>> OAuth already defines a bunch of endpoints, and we
have to define at

>>>>> least one more with this extension, so I'm not convinced
that having

>>>>> three with specific functions is really any different
from having one

>>>>> with three functions from a development, deployment,
and implementation

>>>>> perspective. I can tell you from experience that in
our own server code,

>>>>> the difference is trivial. (And from OAuth1 experience,
you can always

>>>>> have a query parameter as part of your endpoint URL
if you need to. You

>>>>> might hate yourself for doing it that way, but nothing
says your base

>>>>> URL can't already have parameters on it. A client
just needs to know how

>>>>> to appropriately tack its parameters onto an existing
URL, and any HTTP

>>>>> client worth its salt will know how to augment a query
parameter set

>>>>> with new items.)

>>>>>

>>>>> The *real* difference between the two approaches is
a philosophical

>>>>> design one. The former overloads one URL with multiple
functions

>>>>> switched by a flag, the latter uses the URL itself
as an implicit flag.

>>>>> Under the hood, these could (and in many cases will)
be all served by

>>>>> the same chunks of code. The only difference is how
this switch in

>>>>> functionality is presented.

>>>>>

>>>>>

>>>>> With that said, can somebody please explain to me
how allowing *both* of

>>>>> these as options simultaneously (what I understand
Tony to be

>>>>> suggesting) is a good idea, or how multitenancy even
comes into play?

>>>>> Because I am completely not seeing how these are related.

>>>>>

>>>>> Thanks,

>>>>> -- Justin

>>>>>

>>>>>

>>>>>

>>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:

>>>>>> It will not work the way you have it, as people
do multi-tendency different and they are already stuck with the method
that they have chosen, so they need the flexability, to restrict this is
nuts as people won't use it.

>>>>>>

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

>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>> Sent: Wednesday, January 23, 2013 9:27 AM

>>>>>> To: Anthony Nadalin

>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection

>>>>>>

>>>>>> I completely disagree with this assessment. Multi-tenancy
will work just fine (or even better) if everyone uses the same pattern.
Telling someone "it might be three different urls or it might be all
one url with a parameter" is just asking for a complete disaster.
What does the flexibility of allowing two approaches actually accomplish?

>>>>>>

>>>>>> You can argue about the merits of either approach,
but having both as unspecified options for registration, which is meant
to help things get going in a cold-boot environment, is just plain nuts.

>>>>>>

>>>>>>

>>>>>> -- Justin

>>>>>>

>>>>>>

>>>>>>

>>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:

>>>>>>> Registration has to work in a multi-tenant
environment  so flexibility

>>>>>>> is needed

>>>>>>>

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

>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]

>>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM

>>>>>>> To: Anthony Nadalin

>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org

>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection

>>>>>>>

>>>>>>> Because then nobody would know how to actually
use the thing.

>>>>>>>

>>>>>>> In my opinion, this is a key place where this
kind of flexibility is a very bad thing. Registration needs to work one
fairly predictable way.

>>>>>>>

>>>>>>> -- Justin

>>>>>>>

>>>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:

>>>>>>>> Why not just have a physical and logical
endpoint options

>>>>>>>>

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

>>>>>>>> From:oauth-bounces@ietf.org
[mailto:oauth-bounces@ietf.org]
On

>>>>>>>> Behalf Of Justin Richer

>>>>>>>> Sent: Wednesday, January 23, 2013 7:47
AM

>>>>>>>> To: Nat Sakimura

>>>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org

>>>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth
introspection

>>>>>>>>

>>>>>>>> Which brings up an interesting question
for the Registration doc: right now, it's set up as a single endpoint with
three operations. We could instead define three endpoints for the different
operations.

>>>>>>>>

>>>>>>>> I've not been keen to make that deep of
a cutting change to it, but it would certainly be cleaner and more RESTful
API design. What do others think?

>>>>>>>>

>>>>>>>> -- Justin

>>>>>>>>

>>>>>>>>

>>>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:

>>>>>>>>> "Action" goes against REST
principle.

>>>>>>>>> I do not think it is a good idea.

>>>>>>>>>

>>>>>>>>> =nat via iPhone

>>>>>>>>>

>>>>>>>>> Jan 23, 2013 4:00、Justin Richer<jricher@mitre.org>
 のメッセージ:

>>>>>>>>>

>>>>>>>>>> (CC'ing the working group)

>>>>>>>>>>

>>>>>>>>>> I'm not sure what the "action/operation"
flag would accomplish. The idea behind having different endpoints in OAuth
is that they each do different kinds of things. The only "action/operation"
that I had envisioned for the introspection endpoint is introspection itself:
"I have a token, what does it mean?"

>>>>>>>>>>

>>>>>>>>>> Note that client_id and client_secret
*can* already be used at this endpoint if the server supports that as part
of their client credentials setup. The examples use HTTP Basic with client
id and secret right now. Basically, the client can authenticate however
it wants, including any of the methods that OAuth2 allows on the token
endpoint. It could also authenticate with an access token. At least, that's
the intent of the introspection draft -- if that's unclear, I'd be happy
to accept suggested changes to clarify this text.

>>>>>>>>>>

>>>>>>>>>>  -- Justin

>>>>>>>>>>

>>>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun
Poon wrote:

>>>>>>>>>>> Justin,

>>>>>>>>>>>

>>>>>>>>>>> This spec is looking good..

>>>>>>>>>>>

>>>>>>>>>>> One thing I would like to
recommend is to add "action"/"operation"

>>>>>>>>>>> to the request.  (and
potentially add client_id and client_secret)

>>>>>>>>>>>

>>>>>>>>>>> So the request will be like
:

>>>>>>>>>>> token REQUIRED

>>>>>>>>>>> operation (wording to be determine)
 OPTIONAL inquire (default) | revoke ...

>>>>>>>>>>> resource_id OPTIONAL

>>>>>>>>>>> client_id OPTIONAL

>>>>>>>>>>> client_secret OPTIONAL

>>>>>>>>>>>

>>>>>>>>>>> And for the OAuth client information,
it should be an optional parameter (in case it is a public client or client
is authenticated with SSL mutual authentication).

>>>>>>>>>>>

>>>>>>>>>>> Please consider.

>>>>>>>>>>>

>>>>>>>>>>> ShiuFun

>>>>>>>>>> _______________________________________________

>>>>>>>>>> OAuth mailing list

>>>>>>>>>> OAuth@ietf.org

>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>> _______________________________________________

>>>>>>>> OAuth mailing list

>>>>>>>> OAuth@ietf.org

>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>>>>>>

>>>>>>>>

>>>>>>>>

>>>>>>>

>>>>>>

>>>>>>

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OAuth@ietf.org

>>>>> https://www.ietf.org/mailman/listinfo/oauth

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oauth

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

>>> https://www.ietf.org/mailman/listinfo/oauth

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





 

-- 

Nat Sakimura (=nat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en







-- 

Nat Sakimura (=nat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--=_alternative 005271D085257B04_=--





On 2013-01-23, at 10:40 AM, Todd W Lainhart =
wrote:

> On the other
hand, it's a useful exercise to imagine how much more benefit could =
potentially
be gotten "for free" if we look at it through a pure-REST lens,
not just with what's already been specified but the whole =
picture.



+1



  -- Todd



















From:   =
   
 Eve Maler <eve@xmlgrrl.com>

To:   =
   
 Sergey Beryozkin =
<sberyozkin@gmail.com>,


Cc:   =
   
 Paul Bryan <email@pbryan.net>,
"oauth@ietf.org WG" <oauth@ietf.org>

Date:   =
   
 01/23/2013 12:18 =
PM

Subject: =
   
   Re: [OAUTH-WG]
Concerning OAuth introspection

Sent by: =
   
   oauth-bounces@ietf.org









Agreed that REST purity may come at a cost =
that's
too high. On the other hand, it's a useful exercise to imagine how much
more benefit could potentially be gotten "for free" if we look
at it through a pure-REST lens, not just with what's already been =
specified
but the whole picture.



If what you're registering is a client descriptor, then creating a new
one, updating an existing one, deleting, and even patching could come =
for
free if something like the following framework is used:



http://tools.ietf.org/html/draft-pbryan-http-json-resource-03



With standard libraries possibly floating around to support this =
framework
(I think Paul B wrote one; maybe he open-sourced it?), it starts to =
become
a lot cheaper to support client registration on both sides of the =
interaction.



                
Eve



On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <sberyozkin@gmail.com>
wrote:



> On 23/01/13 15:47, Justin Richer wrote:

>> Which brings up an interesting question for the Registration =
doc:
right

>> now, it's set up as a single endpoint with three operations. We
could

>> instead define three endpoints for the different =
operations.

>> 

>> I've not been keen to make that deep of a cutting change to it,
but it

>> would certainly be cleaner and more RESTful API design. What do
others

>> think?

>> 

> IMHO the purity should be balanced against the =
practicality/simplicity

> of the implementation.

> Talking about 3 endpoints at the spec level may be treated as the
exact

> requirement to have 3 separate application endpoints for the single
type

> of activity, the registration. Can the spec be re-worded such =
that

> "resources" are used instead of endpoints or similar, example,
"resource

> available at /a will support the following, at /b - something =
else",
or

> may be something similar,  thus it will read better too from
the design

> point of view, and let implementers to use 1 endpoint or 3 =
ones,

> whichever way they prefer it

> 

> Thanks, Sergey

> 

>> -- Justin

>> 

>> 

>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:

>>> "Action" goes against REST principle.

>>> I do not think it is a good idea.

>>> 

>>> =3Dnat via iPhone

>>> 

>>> Jan 23, 2013 4:00=E3=80=81Justin Richer<jricher@mitre.org>
 =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

>>> 

>>>> (CC'ing the working group)

>>>> 

>>>> I'm not sure what the "action/operation" flag
would accomplish. The idea behind having different endpoints in OAuth is
that they each do different kinds of things. The only "action/operation"
that I had envisioned for the introspection endpoint is introspection =
itself:
"I have a token, what does it mean?"

>>>> 

>>>> Note that client_id and client_secret *can* already be
used at this endpoint if the server supports that as part of their =
client
credentials setup. The examples use HTTP Basic with client id and secret
right now. Basically, the client can authenticate however it wants, =
including
any of the methods that OAuth2 allows on the token endpoint. It could =
also
authenticate with an access token. At least, that's the intent of the =
introspection
draft -- if that's unclear, I'd be happy to accept suggested changes to
clarify this text.

>>>> 

>>>>  -- Justin

>>>> 

>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

>>>>> Justin,

>>>>> 

>>>>> This spec is looking good..

>>>>> 

>>>>> One thing I would like to recommend is to add =
"action"/"operation"
to the request.  (and potentially add client_id and =
client_secret)

>>>>> 

>>>>> So the request will be like :

>>>>> token             =
 
                    =
 
        REQUIRED

>>>>> operation (wording to be determine)  OPTIONAL
inquire (default) | revoke ...

>>>>> resource_id           =
 
                    =
 
 OPTIONAL

>>>>> client_id            
                    =
 
      OPTIONAL

>>>>> client_secret           =
 
                    =
 
OPTIONAL

>>>>> 

>>>>> And for the OAuth client information, it should be
an optional parameter (in case it is a public client or client is =
authenticated
with SSL mutual authentication).

>>>>> 

>>>>> Please consider.

>>>>> 

>>>>> ShiuFun

> 





Eve Maler                  
               http://www.xmlgrrl.com/blog

+1 425 345 6756                
        http://www.twitter.com/xmlgrrl



_______________________________________________

OAuth mailing 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=_46D4A055-32FC-4C49-A8B9-03514F999ACF--

From lainhart@us.ibm.com  Wed Jan 23 12:07:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF77821F84C2 for ; Wed, 23 Jan 2013 12:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.195
X-Spam-Level: 
X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h1ZN7bHai1F for ; Wed, 23 Jan 2013 12:07:51 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 30DBD21F84BC for ; Wed, 23 Jan 2013 12:07:50 -0800 (PST)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 23 Jan 2013 15:07:49 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 23 Jan 2013 15:07:38 -0500
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 5E8516E8060 for ; Wed, 23 Jan 2013 15:07:36 -0500 (EST)
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0NK7bM0247836 for ; Wed, 23 Jan 2013 15:07:37 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0NK7b0S018349 for ; Wed, 23 Jan 2013 15:07:37 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0NK7a7h018320 for ; Wed, 23 Jan 2013 15:07:36 -0500
To: "IETF oauth WG" 
MIME-Version: 1.0
X-KeepSent: EB0736FF:A067B6C7-85257AFC:006DAB2F; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Wed, 23 Jan 2013 15:07:35 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/23/2013 15:07:36, Serialize complete at 01/23/2013 15:07:36
Content-Type: multipart/alternative; boundary="=_alternative 006E8EE685257AFC_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13012320-9360-0000-0000-00000F9B87FB
Subject: [OAUTH-WG] Question on the definition of an authorization endpoint response_type extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jan 2013 20:07:51 -0000

This is a multipart message in MIME format.
--=_alternative 006E8EE685257AFC_=
Content-Type: text/plain; charset="US-ASCII"

I've defined a new response_type for the authorization endpoint for 
dealing with sessions - call it "urn:example:session_code".  Am I required 
to also include that value in the response as the code identifier, as in 
(unencoded):

 
https://client.example.com/cb?urn:example:session_code=SplxlOBeZQQYbYS6WxSbIA

               &state=xyz

I can see arguments either way (returning "code" or 
"urn:example:session_code" as a response parameter) but I'm not finding 
guidance in 6749.

Also, I'm unsure if questions like this are appropriate for this mailing 
list's charter, or are best directed to stackoverflow.

thanks -- Todd




--=_alternative 006E8EE685257AFC_=
Content-Type: text/html; charset="US-ASCII"

I've defined a new response_type for the
authorization endpoint for dealing with sessions - call it "urn:example:session_code".
 Am I required to also include that value in the response as the code
identifier, as in (unencoded):



 https://client.example.com/cb?urn:example:session_code=SplxlOBeZQQYbYS6WxSbIA

               &state=xyz



I can see arguments either way (returning
"code" or "urn:example:session_code" as a response
parameter) but I'm not finding guidance in 6749.



Also, I'm unsure if questions like this
are appropriate for this mailing list's charter, or are best directed to
stackoverflow.



thanks -- Todd












--=_alternative 006E8EE685257AFC_=--


From eve@xmlgrrl.com  Wed Jan 23 12:12:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9B21F87AC; Wed, 23 Jan 2013 12:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.986
X-Spam-Level: 
X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqT81Q9Zy+VY; Wed, 23 Jan 2013 12:12:55 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id F082821F87AB; Wed, 23 Jan 2013 12:12:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 80DEA9A9E14; Wed, 23 Jan 2013 12:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_BLmNMUb4QA; Wed, 23 Jan 2013 12:12:50 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 195449A9DF9; Wed, 23 Jan 2013 12:12:50 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_9FCEA664-2373-46F4-8299-1FA578036A1A"
From: Eve Maler 
In-Reply-To: 
Date: Wed, 23 Jan 2013 12:12:49 -0800
Message-Id: <255D2C5E-22CF-43BD-9789-0E6D25B5B7D8@xmlgrrl.com>
References: 	<50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com>  
To: Phil Hunt 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" , Paul Bryan , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jan 2013 20:12:56 -0000

--Apple-Mail=_9FCEA664-2373-46F4-8299-1FA578036A1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot =
view). To the extent that it, or its constituent parts, defines =
endpoints, it also is a security API or set of APIs (10,000-foot view). =
Since its endpoints use HTTP, this gives the opportunity to ask the =
question: how RESTful should its APIs be? I'm hearing one firm design =
principle:

- Make new constituent parts be consonant with the rest of OAuth design

And a couple of competing soft design principles:

- Make it easy to develop endpoints (especially but not exclusively =
client-side)
- Make it flexible to accommodate lots of situations

I'm suggesting considering another one, possibly ranking it lower than =
others:

- Make its endpoints operate in a RESTful, resource-oriented way

(While OAuth hasn't gone through this exercise, UMA has, and we included =
a DP about RESTfulness; you can see the results here: =
http://kantarainitiative.org/confluence/display/uma/UMA+Requirements =
That's why we defined draft-hardjono-oauth-resource-reg the way we did.)

The dyn reg spec is a kind of bootstrapping spec, so one can expect that =
it would be out of the REST mainstream in any case -- its credential =
provisioning function is sui generis. But the functions to create and =
update metadata look like pretty ordinary CRUD functions that usually =
correspond to various POST or PUT patterns in REST. If the client =
metadata were conceived of as a true web resource, it's not wildly out =
of left field to consider defining their creation and management in =
high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and =
GET might mean, even if not allowed in the spec today.

(Justin, I promise I'm not trying to give you a hard time. :-)

	Eve

On 23 Jan 2013, at 10:54 AM, Phil Hunt  wrote:

> My understanding is OAuth is an HTTP protocol.  It is not intended to =
be REST specific or by implication be RESTful.
>=20
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:
>=20
>> > On the other hand, it's a useful exercise to imagine how much more =
benefit could potentially be gotten "for free" if we look at it through =
a pure-REST lens, not just with what's already been specified but the =
whole picture.=20
>>=20
>> +1
>>=20
>>   -- Todd
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> From:        Eve Maler =20
>> To:        Sergey Beryozkin ,=20
>> Cc:        Paul Bryan , "oauth@ietf.org WG" =
=20
>> Date:        01/23/2013 12:18 PM=20
>> Subject:        Re: [OAUTH-WG] Concerning OAuth introspection=20
>> Sent by:        oauth-bounces@ietf.org=20
>>=20
>>=20
>>=20
>> Agreed that REST purity may come at a cost that's too high. On the =
other hand, it's a useful exercise to imagine how much more benefit =
could potentially be gotten "for free" if we look at it through a =
pure-REST lens, not just with what's already been specified but the =
whole picture.
>>=20
>> If what you're registering is a client descriptor, then creating a =
new one, updating an existing one, deleting, and even patching could =
come for free if something like the following framework is used:
>>=20
>> http://tools.ietf.org/html/draft-pbryan-http-json-resource-03
>>=20
>> With standard libraries possibly floating around to support this =
framework (I think Paul B wrote one; maybe he open-sourced it?), it =
starts to become a lot cheaper to support client registration on both =
sides of the interaction.
>>=20
>>                 Eve
>>=20
>> On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin  =
wrote:
>>=20
>> > On 23/01/13 15:47, Justin Richer wrote:
>> >> Which brings up an interesting question for the Registration doc: =
right
>> >> now, it's set up as a single endpoint with three operations. We =
could
>> >> instead define three endpoints for the different operations.
>> >>=20
>> >> I've not been keen to make that deep of a cutting change to it, =
but it
>> >> would certainly be cleaner and more RESTful API design. What do =
others
>> >> think?
>> >>=20
>> > IMHO the purity should be balanced against the =
practicality/simplicity
>> > of the implementation.
>> > Talking about 3 endpoints at the spec level may be treated as the =
exact
>> > requirement to have 3 separate application endpoints for the single =
type
>> > of activity, the registration. Can the spec be re-worded such that
>> > "resources" are used instead of endpoints or similar, example, =
"resource
>> > available at /a will support the following, at /b - something =
else", or
>> > may be something similar,  thus it will read better too from the =
design
>> > point of view, and let implementers to use 1 endpoint or 3 ones,
>> > whichever way they prefer it
>> >=20
>> > Thanks, Sergey
>> >=20
>> >> -- Justin
>> >>=20
>> >>=20
>> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>> >>> "Action" goes against REST principle.
>> >>> I do not think it is a good idea.
>> >>>=20
>> >>> =3Dnat via iPhone
>> >>>=20
>> >>> Jan 23, 2013 4:00=E3=80=81Justin Richer  =
=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>> >>>=20
>> >>>> (CC'ing the working group)
>> >>>>=20
>> >>>> I'm not sure what the "action/operation" flag would accomplish. =
The idea behind having different endpoints in OAuth is that they each do =
different kinds of things. The only "action/operation" that I had =
envisioned for the introspection endpoint is introspection itself: "I =
have a token, what does it mean?"
>> >>>>=20
>> >>>> Note that client_id and client_secret *can* already be used at =
this endpoint if the server supports that as part of their client =
credentials setup. The examples use HTTP Basic with client id and secret =
right now. Basically, the client can authenticate however it wants, =
including any of the methods that OAuth2 allows on the token endpoint. =
It could also authenticate with an access token. At least, that's the =
intent of the introspection draft -- if that's unclear, I'd be happy to =
accept suggested changes to clarify this text.
>> >>>>=20
>> >>>>  -- Justin
>> >>>>=20
>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>> >>>>> Justin,
>> >>>>>=20
>> >>>>> This spec is looking good..
>> >>>>>=20
>> >>>>> One thing I would like to recommend is to add =
"action"/"operation" to the request.  (and potentially add client_id and =
client_secret)
>> >>>>>=20
>> >>>>> So the request will be like :
>> >>>>> token                                             REQUIRED
>> >>>>> operation (wording to be determine)  OPTIONAL inquire (default) =
| revoke ...
>> >>>>> resource_id                                    OPTIONAL
>> >>>>> client_id                                         OPTIONAL
>> >>>>> client_secret                                   OPTIONAL
>> >>>>>=20
>> >>>>> And for the OAuth client information, it should be an optional =
parameter (in case it is a public client or client is authenticated with =
SSL mutual authentication).
>> >>>>>=20
>> >>>>> Please consider.
>> >>>>>=20
>> >>>>> ShiuFun
>> >=20
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=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


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


--Apple-Mail=_9FCEA664-2373-46F4-8299-1FA578036A1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

http://kantarainitiative.org/confluence/display/uma/UMA+Requirements That's why we defined draft-hardjono-oauth-resource-reg the way we =
did.)

The dyn reg spec is a kind of =
bootstrapping spec, so one can expect that it would be out of the REST =
mainstream in any case -- its credential provisioning function is sui =
generis. But the functions to create and update metadata look like =
pretty ordinary CRUD functions that usually correspond to various POST =
or PUT patterns in REST. If the client metadata were conceived of as a =
true web resource, it's not wildly out of left field to consider =
defining their creation and management in high-REST-maturity ways, and =
even imagine what (say) DELETE, PATCH, and GET might mean, even if not =
allowed in the spec today.

(Justin, I promise =
I'm not trying to give you a hard time. =
:-)

	Eve

On 23 Jan =
2013, at 10:54 AM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

My understanding is =
OAuth is an HTTP protocol.  It is not intended to be REST specific =
or by implication be RESTful.

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








On 2013-01-23, at 10:40 AM, Todd W Lainhart =
wrote:

> On the other
hand, it's a useful exercise to imagine how much more benefit could =
potentially
be gotten "for free" if we look at it through a pure-REST lens,
not just with what's already been specified but the whole =
picture.



+1



  -- Todd



















From:   =
   
 Eve Maler <eve@xmlgrrl.com>

To:   =
   
 Sergey Beryozkin =
<sberyozkin@gmail.com>,


Cc:   =
   
 Paul Bryan <email@pbryan.net>,
"oauth@ietf.org WG" <oauth@ietf.org>

Date:   =
   
 01/23/2013 12:18 =
PM

Subject: =
   
   Re: [OAUTH-WG]
Concerning OAuth introspection

Sent by: =
   
   oauth-bounces@ietf.org









Agreed that REST purity may come at a cost =
that's
too high. On the other hand, it's a useful exercise to imagine how much
more benefit could potentially be gotten "for free" if we look
at it through a pure-REST lens, not just with what's already been =
specified
but the whole picture.



If what you're registering is a client descriptor, then creating a new
one, updating an existing one, deleting, and even patching could come =
for
free if something like the following framework is used:



http://tools.ietf.org/html/draft-pbryan-http-json-resource-03



With standard libraries possibly floating around to support this =
framework
(I think Paul B wrote one; maybe he open-sourced it?), it starts to =
become
a lot cheaper to support client registration on both sides of the =
interaction.



                
Eve



On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <sberyozkin@gmail.com>
wrote:



> On 23/01/13 15:47, Justin Richer wrote:

>> Which brings up an interesting question for the Registration =
doc:
right

>> now, it's set up as a single endpoint with three operations. We
could

>> instead define three endpoints for the different =
operations.

>> 

>> I've not been keen to make that deep of a cutting change to it,
but it

>> would certainly be cleaner and more RESTful API design. What do
others

>> think?

>> 

> IMHO the purity should be balanced against the =
practicality/simplicity

> of the implementation.

> Talking about 3 endpoints at the spec level may be treated as the
exact

> requirement to have 3 separate application endpoints for the single
type

> of activity, the registration. Can the spec be re-worded such =
that

> "resources" are used instead of endpoints or similar, example,
"resource

> available at /a will support the following, at /b - something =
else",
or

> may be something similar,  thus it will read better too from
the design

> point of view, and let implementers to use 1 endpoint or 3 =
ones,

> whichever way they prefer it

> 

> Thanks, Sergey

> 

>> -- Justin

>> 

>> 

>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:

>>> "Action" goes against REST principle.

>>> I do not think it is a good idea.

>>> 

>>> =3Dnat via iPhone

>>> 

>>> Jan 23, 2013 4:00=E3=80=81Justin Richer<jricher@mitre.org>
 =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

>>> 

>>>> (CC'ing the working group)

>>>> 

>>>> I'm not sure what the "action/operation" flag
would accomplish. The idea behind having different endpoints in OAuth is
that they each do different kinds of things. The only "action/operation"
that I had envisioned for the introspection endpoint is introspection =
itself:
"I have a token, what does it mean?"

>>>> 

>>>> Note that client_id and client_secret *can* already be
used at this endpoint if the server supports that as part of their =
client
credentials setup. The examples use HTTP Basic with client id and secret
right now. Basically, the client can authenticate however it wants, =
including
any of the methods that OAuth2 allows on the token endpoint. It could =
also
authenticate with an access token. At least, that's the intent of the =
introspection
draft -- if that's unclear, I'd be happy to accept suggested changes to
clarify this text.

>>>> 

>>>>  -- Justin

>>>> 

>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:

>>>>> Justin,

>>>>> 

>>>>> This spec is looking good..

>>>>> 

>>>>> One thing I would like to recommend is to add =
"action"/"operation"
to the request.  (and potentially add client_id and =
client_secret)

>>>>> 

>>>>> So the request will be like :

>>>>> token             =
 
                    =
 
        REQUIRED

>>>>> operation (wording to be determine)  OPTIONAL
inquire (default) | revoke ...

>>>>> resource_id           =
 
                    =
 
 OPTIONAL

>>>>> client_id            
                    =
 
      OPTIONAL

>>>>> client_secret           =
 
                    =
 
OPTIONAL

>>>>> 

>>>>> And for the OAuth client information, it should be
an optional parameter (in case it is a public client or client is =
authenticated
with SSL mutual authentication).

>>>>> 

>>>>> Please consider.

>>>>> 

>>>>> ShiuFun

> 





Eve Maler                  
               http://www.xmlgrrl.com/blog

+1 425 345 6756                
        http://www.twitter.com/xmlgrrl



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






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





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





=

--Apple-Mail=_9FCEA664-2373-46F4-8299-1FA578036A1A--

From jricher@mitre.org  Wed Jan 23 12:22:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1119821F8542; Wed, 23 Jan 2013 12:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.138
X-Spam-Level: 
X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mpDv7ithdzx; Wed, 23 Jan 2013 12:22:28 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38721F84C2; Wed, 23 Jan 2013 12:22:28 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B26C65310A21; Wed, 23 Jan 2013 15:22:27 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9E96D1F1F6C; Wed, 23 Jan 2013 15:22:27 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 15:22:27 -0500
Message-ID: <5100466F.3030506@mitre.org>
Date: Wed, 23 Jan 2013 15:22:07 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Eve Maler 
References: 	<50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com>   <255D2C5E-22CF-43BD-9789-0E6D25B5B7D8@xmlgrrl.com>
In-Reply-To: <255D2C5E-22CF-43BD-9789-0E6D25B5B7D8@xmlgrrl.com>
Content-Type: multipart/alternative; boundary="------------060806010801010200060207"
X-Originating-IP: [129.83.31.58]
Cc: oauth-bounces@ietf.org, Paul Bryan , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jan 2013 20:22:33 -0000

--------------060806010801010200060207
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

While Eve is right in principle, I think it's better for everyone if 
things remain consistent across different endpoints where possible. This 
is why registration now does form input and json output, for instance. 
Still simple, not as RESTy, but ultimately REST-friendly, which is all 
OAuth ever sought to be.

  -- Justin

On 01/23/2013 03:12 PM, Eve Maler wrote:
> I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To the extent that it, or its constituent parts, defines endpoints, it also is a security API or set of APIs (10,000-foot view). Since its endpoints use HTTP, this gives the opportunity to ask the question: how RESTful should its APIs be? I'm hearing one firm design principle:
>
> - Make new constituent parts be consonant with the rest of OAuth design
>
> And a couple of competing soft design principles:
>
> - Make it easy to develop endpoints (especially but not exclusively client-side)
> - Make it flexible to accommodate lots of situations
>
> I'm suggesting considering another one, possibly ranking it lower than others:
>
> - Make its endpoints operate in a RESTful, resource-oriented way
>
> (While OAuth hasn't gone through this exercise, UMA has, and we included a DP about RESTfulness; you can see the results here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements That's why we defined draft-hardjono-oauth-resource-reg the way we did.)
>
> The dyn reg spec is a kind of bootstrapping spec, so one can expect that it would be out of the REST mainstream in any case -- its credential provisioning function is sui generis. But the functions to create and update metadata look like pretty ordinary CRUD functions that usually correspond to various POST or PUT patterns in REST. If the client metadata were conceived of as a true web resource, it's not wildly out of left field to consider defining their creation and management in high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and GET might mean, even if not allowed in the spec today.
>
> (Justin, I promise I'm not trying to give you a hard time. :-)
>
> 	Eve
>
> On 23 Jan 2013, at 10:54 AM, Phil Hunt  wrote:
>
>> My understanding is OAuth is an HTTP protocol.  It is not intended to be REST specific or by implication be RESTful.
>>
>>
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>
>>
>>
>>
>>
>> On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:
>>
>>>> On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>> +1
>>>
>>>    -- Todd
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From:        Eve Maler 
>>> To:        Sergey Beryozkin ,
>>> Cc:        Paul Bryan , "oauth@ietf.org WG" 
>>> Date:        01/23/2013 12:18 PM
>>> Subject:        Re: [OAUTH-WG] Concerning OAuth introspection
>>> Sent by:        oauth-bounces@ietf.org
>>>
>>>
>>>
>>> Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>>
>>> If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used:
>>>
>>> http://tools.ietf.org/html/draft-pbryan-http-json-resource-03
>>>
>>> With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction.
>>>
>>>                  Eve
>>>
>>> On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin  wrote:
>>>
>>>> On 23/01/13 15:47, Justin Richer wrote:
>>>>> Which brings up an interesting question for the Registration doc: right
>>>>> now, it's set up as a single endpoint with three operations. We could
>>>>> instead define three endpoints for the different operations.
>>>>>
>>>>> I've not been keen to make that deep of a cutting change to it, but it
>>>>> would certainly be cleaner and more RESTful API design. What do others
>>>>> think?
>>>>>
>>>> IMHO the purity should be balanced against the practicality/simplicity
>>>> of the implementation.
>>>> Talking about 3 endpoints at the spec level may be treated as the exact
>>>> requirement to have 3 separate application endpoints for the single type
>>>> of activity, the registration. Can the spec be re-worded such that
>>>> "resources" are used instead of endpoints or similar, example, "resource
>>>> available at /a will support the following, at /b - something else", or
>>>> may be something similar,  thus it will read better too from the design
>>>> point of view, and let implementers to use 1 endpoint or 3 ones,
>>>> whichever way they prefer it
>>>>
>>>> Thanks, Sergey
>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>> "Action" goes against REST principle.
>>>>>> I do not think it is a good idea.
>>>>>>
>>>>>> =nat via iPhone
>>>>>>
>>>>>> Jan 23, 2013 4:00?Justin Richer  ??????:
>>>>>>
>>>>>>> (CC'ing the working group)
>>>>>>>
>>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>>
>>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>>
>>>>>>>   -- Justin
>>>>>>>
>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>> Justin,
>>>>>>>>
>>>>>>>> This spec is looking good..
>>>>>>>>
>>>>>>>> One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)
>>>>>>>>
>>>>>>>> So the request will be like :
>>>>>>>> token                                             REQUIRED
>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>>> resource_id                                    OPTIONAL
>>>>>>>> client_id                                         OPTIONAL
>>>>>>>> client_secret                                   OPTIONAL
>>>>>>>>
>>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>>
>>>>>>>> Please consider.
>>>>>>>>
>>>>>>>> ShiuFun
>>>
>>> Eve Maler                                  http://www.xmlgrrl.com/blog
>>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------060806010801010200060207
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    While Eve is right in principle, I think it's better for everyone if
    things remain consistent across different endpoints where possible.
    This is why registration now does form input and json output, for
    instance. Still simple, not as RESTy, but ultimately REST-friendly,
    which is all OAuth ever sought to be.

    

     -- Justin

    

    
On 01/23/2013 03:12 PM, Eve Maler
      wrote:

    

    

      
I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To the extent that it, or its constituent parts, defines endpoints, it also is a security API or set of APIs (10,000-foot view). Since its endpoints use HTTP, this gives the opportunity to ask the question: how RESTful should its APIs be? I'm hearing one firm design principle:

- Make new constituent parts be consonant with the rest of OAuth design

And a couple of competing soft design principles:

- Make it easy to develop endpoints (especially but not exclusively client-side)
- Make it flexible to accommodate lots of situations

I'm suggesting considering another one, possibly ranking it lower than others:

- Make its endpoints operate in a RESTful, resource-oriented way

(While OAuth hasn't gone through this exercise, UMA has, and we included a DP about RESTfulness; you can see the results here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements That's why we defined draft-hardjono-oauth-resource-reg the way we did.)

The dyn reg spec is a kind of bootstrapping spec, so one can expect that it would be out of the REST mainstream in any case -- its credential provisioning function is sui generis. But the functions to create and update metadata look like pretty ordinary CRUD functions that usually correspond to various POST or PUT patterns in REST. If the client metadata were conceived of as a true web resource, it's not wildly out of left field to consider defining their creation and management in high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and GET might mean, even if not allowed in the spec today.

(Justin, I promise I'm not trying to give you a hard time. :-)

	Eve

On 23 Jan 2013, at 10:54 AM, Phil Hunt <phil.hunt@oracle.com> wrote:



      

        
My understanding is OAuth is an HTTP protocol.  It is not intended to be REST specific or by implication be RESTful.


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





On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:



        

          

            
On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture. 


          

          
+1

  -- Todd







From:        Eve Maler <eve@xmlgrrl.com> 
To:        Sergey Beryozkin <sberyozkin@gmail.com>, 
Cc:        Paul Bryan <email@pbryan.net>, "oauth@ietf.org WG" <oauth@ietf.org> 
Date:        01/23/2013 12:18 PM 
Subject:        Re: [OAUTH-WG] Concerning OAuth introspection 
Sent by:        oauth-bounces@ietf.org 



Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.

If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used:

http://tools.ietf.org/html/draft-pbryan-http-json-resource-03

With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction.

                Eve

On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:



          

            
On 23/01/13 15:47, Justin Richer wrote:


            

              
Which brings up an interesting question for the Registration doc: right
now, it's set up as a single endpoint with three operations. We could
instead define three endpoints for the different operations.

I've not been keen to make that deep of a cutting change to it, but it
would certainly be cleaner and more RESTful API design. What do others
think?



            

            
IMHO the purity should be balanced against the practicality/simplicity
of the implementation.
Talking about 3 endpoints at the spec level may be treated as the exact
requirement to have 3 separate application endpoints for the single type
of activity, the registration. Can the spec be re-worded such that
"resources" are used instead of endpoints or similar, example, "resource
available at /a will support the following, at /b - something else", or
may be something similar,  thus it will read better too from the design
point of view, and let implementers to use 1 endpoint or 3 ones,
whichever way they prefer it

Thanks, Sergey



            

              
-- Justin


On 01/22/2013 08:05 PM, Nat Sakimura wrote:


              

                
"Action" goes against REST principle.
I do not think it is a good idea.

=nat via iPhone

Jan 23, 2013 4:00、Justin Richer<jricher@mitre.org>  のメッセージ:



                

                  
(CC'ing the working group)

I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"

Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.

 -- Justin

On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:


                  

                    
Justin,

This spec is looking good..

One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)

So the request will be like :
token                                             REQUIRED
operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
resource_id                                    OPTIONAL
client_id                                         OPTIONAL
client_secret                                   OPTIONAL

And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).

Please consider.

ShiuFun


                  

                

              

            

            

          

          

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

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


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


        

        

      

      

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




      

      

      

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


    

    

  


--------------060806010801010200060207--

From eve@xmlgrrl.com  Wed Jan 23 12:23:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6421F866E for ; Wed, 23 Jan 2013 12:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.047
X-Spam-Level: 
X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.245,  BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdFJclq9E53T for ; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8394321F8542 for ; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 549D39AA17C; Wed, 23 Jan 2013 12:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7moGDXlJQg-o; Wed, 23 Jan 2013 12:23:06 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id D4E529AA15B; Wed, 23 Jan 2013 12:23:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_863224A2-1BA7-409F-9460-BA929BF04B70"
From: Eve Maler 
In-Reply-To: <5100267C.1010400@aol.com>
Date: Wed, 23 Jan 2013 12:23:06 -0800
Message-Id: 
References: <1358744919.12881.YahooMailNeo@web31811.mail.mud.yahoo.com>   <9034B9E7-B35F-4647-AF59-0DD222A3C60C@xmlgrrl.com> <5100267C.1010400@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jan 2013 20:23:12 -0000

--Apple-Mail=_863224A2-1BA7-409F-9460-BA929BF04B70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Nice suggestion! Good point that both the RS and the client, =
respectively, have ways (illustrated by a combination of dyn-client-reg =
and resource-set-reg) to review/indicate abilities and preferences in =
engaging with the AS.

	Eve

On 23 Jan 2013, at 10:05 AM, George Fletcher  wrote:

> In addition, UMA also defines a was for the RS to instruct the client =
on what to present to the AS in order to receive a token that will work =
at the RS. At the moment this flow is UMA specific but could probably be =
abstracted into a general pattern.
>=20
> Also, there are really three parties that have to agree in order for =
the client to get access to the protected resource.
>    a. the client -- it may only support bearer tokens and not =
holder-of-key
>    b. the RS -- it may only allow bearer tokens from trusted clients
>    c. the AS -- it may only issue bearer tokens
>=20
> Developing generic negotiation amongst these parties may be overkill =
since in most cases the client know what RS it will be talking to and =
potentially even the authorizations server(s) as well.  Given that some =
pre-knowledge is probably in play, a simple solution may be to allow the =
client to register via the dynamic registration proposal the token types =
it supports and then the AS can use that data as a filtering mechanism =
when the client asks for a token.
>=20
> Thanks,
> George
>=20
> On 1/23/13 12:23 PM, Eve Maler wrote:
>> FWIW, some of us have made a proposal for exactly this type of =
standardized AS/RS communication:
>>=20
>> http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
>>=20
>> The UMA profile refers normatively to this spec, and at that higher =
profile-specific level, it has an extensive set of AS configuration data =
that includes a way to declare token types supported. It could make =
sense for an RS to register its preferences for token types supported =
among those declared in the AS config data. Should this "preferred token =
type" semantic should be sedimented down to the =
"draft-hardjono-oauth-resource-reg" level?
>>=20
>>  Eve
>>=20
>> On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena  =
wrote:
>>=20
>>> Think about a distributed setup. You have single Authorization =
Server and multiple Resource Servers.
>>>=20
>>> Although OAuth nicely decouples AS from RS - AFAIK there is no =
standard established for communication betweens AS and RS - how to =
declare metadata between those.
>>>=20
>>> Also there can be Resource Servers which support multiple token =
types. It could vary on APIs hosted in a given RS.
>>>=20
>>> Thanks & regards,
>>> -Prabath
>>>=20
>>>=20
>>> On Mon, Jan 21, 2013 at 10:48 AM,  wrote:
>>>=20
>>> The token type shoulbe decided by resource server, which consumes =
access token.=20
>>> Client just re-tell the requested token type to AS.=20
>>> Client should not specify the token type.=20
>>>=20
>>>=20
>>> oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-01-21 13:08:39:
>>>=20
>>>=20
>>> > This is true.  It's possible for the AS to vary it's behavior on=20=

>>> > scope name, but it's presumed the AS and RS have an agreement of=20=

>>> > what token type is in play.  Likely a good extension to the spec.
>>>=20
>>> >=20
>>> > From: Prabath Siriwardena 
>>> > To: "oauth@ietf.org WG" =20
>>> > Sent: Sunday, January 20, 2013 7:28 PM
>>> > Subject: [OAUTH-WG] Client cannot specify the token type it needs
>>>=20
>>> >=20
>>> > Although token type is extensible according to the OAuth core=20
>>> > specification - it is fully governed by the Authorization Server.=20=

>>> >=20
>>> > There can be a case where a single AS supports multiple token =
types=20
>>> > based on client request.=20
>>> >=20
>>> > But currently we don't have a way the client can specify (or at=20
>>> > least suggest) which token type it needs in the OAuth access token =
request ?=20
>>> >=20
>>> > Is this behavior intentional ? or am I missing something...=20
>>> >=20
>>> > Thanks & Regards,
>>> > Prabath=20
>>> >=20
>>> > Mobile : +94 71 809 6732=20
>>> >=20
>>> > http://blog.facilelogin.com
>>> > http://RampartFAQ.com=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
>>> Thanks & Regards,
>>> Prabath
>>>=20
>>> Mobile : +94 71 809 6732=20
>>>=20
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> --=20
> 


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


--Apple-Mail=_863224A2-1BA7-409F-9460-BA929BF04B70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

	=
Eve

On 23 Jan 2013, at 10:05 AM, George =
Fletcher <gffletch@aol.com> =
wrote:


 =20
    
 =20
  

    In addition, UMA also
      defines a was for the RS to instruct the client on what to present
      to the AS in order to receive a token that will work at the RS. At
      the moment this flow is UMA specific but could probably be
      abstracted into a general pattern.

      

      Also, there are really three parties that have to agree in order
      for the client to get access to the protected resource.

         a. the client -- it may only support bearer tokens =
and not
      holder-of-key

         b. the RS -- it may only allow bearer tokens from =
trusted
      clients

         c. the AS -- it may only issue bearer tokens

      

      Developing generic negotiation amongst these parties may be
      overkill since in most cases the client know what RS it will be
      talking to and potentially even the authorizations server(s) as
      well.  Given that some pre-knowledge is probably in play, a =
simple
      solution may be to allow the client to register via the dynamic
      registration proposal the token types it supports and then the AS
      can use that data as a filtering mechanism when the client asks
      for a token.

      

      Thanks,

      George

      

    
    
On 1/23/13 12:23 PM, Eve Maler =
wrote:

    

    

      
      
FWIW, some of us have made a proposal for exactly this type
        of standardized AS/RS communication:

      


      

      
      


      

      
The UMA profile refers normatively to this spec, and at that
        higher profile-specific level, it has an extensive set of AS
        configuration data that includes a way to declare token types
        supported. It could make sense for an RS to register its
        preferences for token types supported among those declared in
        the AS config data. Should this "preferred token type" semantic
        should be sedimented down to the
        "draft-hardjono-oauth-resource-reg" level?

      


      

      
 =
Eve

      

      

        
On 20 Jan 2013, at 9:29 PM, Prabath Siriwardena <prabath@wso2.com>
          wrote:

        

        
Think about a distributed setup. You
          have single Authorization Server and multiple Resource
          Servers.
          


          

          
Although OAuth nicely decouples AS from RS - AFAIK there
            is no standard established for communication betweens AS and
            RS - how to declare metadata between those.

          


          

          
Also there can be Resource Servers which support multiple
            token types. It could vary on APIs hosted in a given =
RS.

          


          

          
Thanks & regards,

          
-Prabath

          


          

          


            
On Mon, Jan 21, 2013 at 10:48 AM, =
<zhou.sujing@zte.com.cn>
              wrote:

              

                

                The token type shoulbe decided
                  by resource
                  server, which consumes access token.
                

                Client just re-tell the
                  requested token
                  type to AS. 
                

                Client should not specify the
                  token
                  type.
                

                

                

                oauth-bounces@ietf.org =E5=86=99=E4=BA=8E
                    2013-01-21 13:08:39:
                    


                      

                      > This is true.  It's possible for the AS =
to
                      vary it's behavior
                      on 

                      > scope name, but it's presumed the AS and RS
                      have an agreement of 

                      > what token type is in play.  Likely a =
good
                      extension to the spec.

                  
                

                > 

                  

                    > From: Prabath Siriwardena <prabath@wso2.com>

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

                    > Sent: Sunday, January 20, 2013 7:28 PM

                    > Subject: [OAUTH-WG] Client cannot specify the
                    token type it needs

                
                

                

                  
> 

                      > Although token type is extensible according
                      to the OAuth core 

                      > specification - it is fully governed by the
                      Authorization Server.
                    

                    > 

                      > There can be a case where a single AS
                      supports multiple token types
                      

                      > based on client request.
                    

                    > 

                      > But currently we don't have a way the client
                      can specify (or at 

                      > least suggest) which token type it needs in
                      the OAuth access token
                      request ?
                    

                    > 

                      > Is this behavior intentional ? or am I
                      missing something...
                    

                    > 

                      > Thanks & Regards,

                      > Prabath
                    

                    > 

                      > Mobile : +94 71 809
                        6732 

                      > 

                      > http://blog.facilelogin.com

                      > http://RampartFAQ.com
                    

                    > 

                      >
                      =
_______________________________________________

                      > OAuth mailing list

                      > OAuth@ietf.org

                      > https://www.ietf.org/mailman/listinfo/oauth

                      > 

                      >
                      =
_______________________________________________

                      > OAuth mailing list

                      > OAuth@ietf.org

                      > https://www.ietf.org/mailman/listinfo/oauth

                    
                  

                

              

            

            

            

            


            

            -- 

            Thanks & Regards,

            Prabath
            


            

            
          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

        

      

      

      

        


              Eve Maler               =
                   http://www.xmlgrrl.com/blog

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


      

      

      

      

      

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


    

    

    
-- 

      <XeC.png>

  







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





=

--Apple-Mail=_863224A2-1BA7-409F-9460-BA929BF04B70--

From tonynad@microsoft.com  Wed Jan 23 15:56:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4C21F8555 for ; Wed, 23 Jan 2013 15:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=-0.001,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38vuUp+leVyb for ; Wed, 23 Jan 2013 15:56:52 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id E314421F8549 for ; Wed, 23 Jan 2013 15:56:51 -0800 (PST)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.204) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 23 Jan 2013 23:56:48 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 23 Jan 2013 23:56:47 +0000
Received: from co1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 23 Jan 2013 23:56:08 +0000
Received: from mail137-co1-R.bigfish.com (10.243.78.215) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 23:54:39 +0000
Received: from mail137-co1 (localhost [127.0.0.1])	by mail137-co1-R.bigfish.com (Postfix) with ESMTP id 33A0D3800D6	for ; Wed, 23 Jan 2013 23:54:39 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: 5
X-BigFish: PS5(zzc85fhzz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz17326ah8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h)
Received-SPF: softfail (mail137-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail137-co1 (localhost.localdomain [127.0.0.1]) by mail137-co1 (MessageSwitch) id 1358985276342476_31989; Wed, 23 Jan 2013 23:54:36 +0000 (UTC)
Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.209])	by mail137-co1.bigfish.com (Postfix) with ESMTP id 476E044020A	for ; Wed, 23 Jan 2013 23:54:36 +0000 (UTC)
Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 23:54:36 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.257.4; Wed, 23 Jan 2013 23:54:35 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.601.3; Wed, 23 Jan 2013 23:54:22 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Wed, 23 Jan 2013 23:54:03 +0000
From: Anthony Nadalin 
To: "oauth@ietf.org" 
Thread-Topic: draft-ietf-oauth-revocation-04 Review
Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQ
Date: Wed, 23 Jan 2013 23:54:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.132]
Content-Type: multipart/alternative; boundary="_000_a7b55ec383284cee83ff199f0057acbbBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(63696002)(56776001)(31966008)(76482001)(44976002)(56816002)(5343635001)(33646001)(74502001)(15202345001)(5343655001)(54356001)(512954001)(74662001)(53806001)(47446002)(54316002)(59766001)(49866001)(4396001)(6806001)(77982001)(47736001)(51856001)(47976001)(79102001)(50986001)(16236675001)(46102001)(16676001)(6816006)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB026; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:; A:1; MX:3; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 073515755F
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jan 2013 23:56:53 -0000

--_000_a7b55ec383284cee83ff199f0057acbbBY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Review:


1.       Since not stated I assume that the Revocation Endpoint can exist o=
n a different server from the Authorization server (or is it assumed that t=
hey are 1), if so how is the Revocation Endpoint found?

2.       Any token type that is supported can be revoked, including refresh=
 token ?

3.       Why does one have to send the token, can't this just be an auth_co=
de ?

4.       Says CORS SHOULD be supported, I think a MAY be better here since =
a site may have issues supporting CORS

5.       Does not say but is the revocation to be immediate upon the return=
 of the request ?

6.       Does the revocation of the access token also revoke the refresh to=
ken (if it was provided) ? Or is this a revocation policy decision ?

7.       Section 2 says "the client MUST NOT use this token again", well th=
at seems odd, not sure this should be here as the client could try to use i=
t gain, there is no need to put support in client to prevent this.

--_000_a7b55ec383284cee83ff199f0057acbbBY2PR03MB041namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Review:


 


1.     &=
nbsp;
Since not stated I assume that the Revocation Endpo=
int can exist on a different server from the Authorization server (or is it=
 assumed that they are 1), if so how is the Revocation Endpoint found?=



2.     &=
nbsp;
Any token type that is supported can be revoked, in=
cluding refresh token ?


3.     &=
nbsp;
Why does one have to send the token, can’t th=
is just be an auth_code ?


4.     &=
nbsp;
Says CORS SHOULD be supported, I think a MAY be bet=
ter here since a site may have issues supporting CORS


5.     &=
nbsp;
Does not say but is the revocation to be immediate =
upon the return of the request ?


6.     &=
nbsp;
Does the revocation of the access token also revoke=
 the refresh token (if it was provided) ? Or is this a revocation policy de=
cision ?


7.     &=
nbsp;
Section 2 says “the client MUST NOT use this =
token again”, well that seems odd, not sure this should be here as th=
e client could try to use it gain, there is no need to put support in clien=
t to prevent this.






--_000_a7b55ec383284cee83ff199f0057acbbBY2PR03MB041namprd03pro_--

From sberyozkin@gmail.com  Thu Jan 24 02:56:37 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2D21F84D7 for ; Thu, 24 Jan 2013 02:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6+drGswjmvF for ; Thu, 24 Jan 2013 02:56:36 -0800 (PST)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id C362121F84CA for ; Thu, 24 Jan 2013 02:56:35 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id s4so3743374lbc.21 for ; Thu, 24 Jan 2013 02:56:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VxgL4Tmc8nRIsh6f43uRw6L4K+lNjAjTScj7+P4NJjs=; b=wyyrt6auDJu2axz/Z3wJsH9NnE7mbIvrXbuX3vwSVsHFWCMOMPtvQnnx3s6P6NZIJh oLUW+tDbbW2aavlgOVs/NOH8nCILjSb884YyQ45zXviS4qzcSpNV7QhFrtXwfw1B9P+2 dhl4LbVhqjFkNWMxa/4W0K7QfkzovCzMPUHpmZiv6ZhF404zPLr5bU2m7GGlsC6AdJcd lwcxPDIotp7bmpSOnWAlWvV2fRRzjpYM8UEohJxYhHSWfpvjpoFth9Y66D+3q1P0MPFt r3qKbf5/k1bSl5BrZasehHj56KNue0HTLo5m4YUXuFlu/c+FoCU0lD/UJkA7ZPVCUGK0 9sfQ==
X-Received: by 10.152.109.176 with SMTP id ht16mr1473503lab.2.1359024994473; Thu, 24 Jan 2013 02:56:34 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id td1sm9449007lab.17.2013.01.24.02.56.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 02:56:33 -0800 (PST)
Message-ID: <5101135F.5060000@gmail.com>
Date: Thu, 24 Jan 2013 10:56:31 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org>
In-Reply-To: <51002656.2050900@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 10:56:37 -0000

On 23/01/13 18:05, Justin Richer wrote:
> I am very confused, and I need someone to explain to me what I am
> missing. Why won't it work to just pick one? What are people "already
> stuck with" that this would affect? It's not like we're trying to unseat
> a well-established protocol with a wide installation base here.
>
> How will giving people the choice between:
>
>     /oauth/register?operation=client_register
>     /oauth/register?operation=client_update
>     /oauth/register?operation=rotate_secret
>
>
> and:
>
>     /oauth/client_register
>     /oauth/client_update
>     /oauth/rotate_secret

I like this most, would rename it to say

/oauth/client/registration
or
/oauth/client-registration

etc

and reword the spec such that it will let those who implement do it with 
one endpoint or many, whatever is preferred

Cheers, Sergey

>
>
> help multitenancy? How does it even affect that use case? Consider that
> the base URL for all of these is completely up to the host environment
> (nothing is bound to the root URL). Consider that clients still have to
> know what the URL (or URLs) are, in either case. Consider that clients
> still need to know how to manage all the parameters and responses.
>
> If anything, keeping it the way that it is with a single URL could be
> argued to help multitenancy because setting up routing to multiple URL
> endpoints can sometimes be problematic in hosted environments. However,
> OAuth already defines a bunch of endpoints, and we have to define at
> least one more with this extension, so I'm not convinced that having
> three with specific functions is really any different from having one
> with three functions from a development, deployment, and implementation
> perspective. I can tell you from experience that in our own server code,
> the difference is trivial. (And from OAuth1 experience, you can always
> have a query parameter as part of your endpoint URL if you need to. You
> might hate yourself for doing it that way, but nothing says your base
> URL can't already have parameters on it. A client just needs to know how
> to appropriately tack its parameters onto an existing URL, and any HTTP
> client worth its salt will know how to augment a query parameter set
> with new items.)
>
> The *real* difference between the two approaches is a philosophical
> design one. The former overloads one URL with multiple functions
> switched by a flag, the latter uses the URL itself as an implicit flag.
> Under the hood, these could (and in many cases will) be all served by
> the same chunks of code. The only difference is how this switch in
> functionality is presented.
>
>
> With that said, can somebody please explain to me how allowing *both* of
> these as options simultaneously (what I understand Tony to be
> suggesting) is a good idea, or how multitenancy even comes into play?
> Because I am completely not seeing how these are related.
>
> Thanks,
> -- Justin
>
>
>
> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>> It will not work the way you have it, as people do multi-tendency different and they are already stuck with the method that they have chosen, so they need the flexability, to restrict this is nuts as people won't use it.
>>
>> -----Original Message-----
>> From: Justin Richer [mailto:jricher@mitre.org]
>> Sent: Wednesday, January 23, 2013 9:27 AM
>> To: Anthony Nadalin
>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>
>> I completely disagree with this assessment. Multi-tenancy will work just fine (or even better) if everyone uses the same pattern. Telling someone "it might be three different urls or it might be all one url with a parameter" is just asking for a complete disaster. What does the flexibility of allowing two approaches actually accomplish?
>>
>> You can argue about the merits of either approach, but having both as unspecified options for registration, which is meant to help things get going in a cold-boot environment, is just plain nuts.
>>
>>
>> -- Justin
>>
>>
>>
>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>> Registration has to work in a multi-tenant environment  so flexibility
>>> is needed
>>>
>>> -----Original Message-----
>>> From: Justin Richer [mailto:jricher@mitre.org]
>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>> To: Anthony Nadalin
>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>> Because then nobody would know how to actually use the thing.
>>>
>>> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
>>>
>>> -- Justin
>>>
>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>> Why not just have a physical and logical endpoint options
>>>>
>>>> -----Original Message-----
>>>> From:oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of Justin Richer
>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>> To: Nat Sakimura
>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> Which brings up an interesting question for the Registration doc: right now, it's set up as a single endpoint with three operations. We could instead define three endpoints for the different operations.
>>>>
>>>> I've not been keen to make that deep of a cutting change to it, but it would certainly be cleaner and more RESTful API design. What do others think?
>>>>
>>>> -- Justin
>>>>
>>>>
>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>> "Action" goes against REST principle.
>>>>> I do not think it is a good idea.
>>>>>
>>>>> =nat via iPhone
>>>>>
>>>>> Jan 23, 2013 4:00Justin Richer  :
>>>>>
>>>>>> (CC'ing the working group)
>>>>>>
>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>
>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>
>>>>>>   -- Justin
>>>>>>
>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>> Justin,
>>>>>>>
>>>>>>> This spec is looking good..
>>>>>>>
>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>> to the request.  (and potentially add client_id and client_secret)
>>>>>>>
>>>>>>> So the request will be like :
>>>>>>> token                                             REQUIRED
>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>> resource_id                                    OPTIONAL
>>>>>>> client_id                                         OPTIONAL
>>>>>>> client_secret                                   OPTIONAL
>>>>>>>
>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>
>>>>>>> Please consider.
>>>>>>>
>>>>>>> ShiuFun
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Thu Jan 24 03:02:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4121F856D for ; Thu, 24 Jan 2013 03:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level: 
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15f+kask-rly for ; Thu, 24 Jan 2013 03:02:09 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3678021F85C0 for ; Thu, 24 Jan 2013 03:02:09 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id fo13so2838203lab.24 for ; Thu, 24 Jan 2013 03:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NGFlyRZ6zHtdkrbeCgQsbgUu+mNrTl1NmPJ/BXHOlH4=; b=JJgVX7VIn3eGhGdNPuSZ/dCYTTnKY4qzZ4u4NzlM8T4A+HwhHcTqjET/V3dPdLrWov Eg//JccysnYPDxbN2m0FgMvGY/RG7eHeJbSbOSIT/bKdmy/nB3SEWurlHM+3nlqltxzu ei/Y8y5IoNxqPAFMH4/i0/7nNftRegZPzOoJfVvqelmTuMVtknIFisqpq1oBBI5x53qm RCwKn/+rBtD0olMehHCsFfAYcRiGQhkrtM5ZEgTa196Lt4U8UgiVpUUJBL7ujYOPSiEs 1E8u5tmZSTSlIH0w9i14Dq2E4rsxC9Peufayriiw1zE3b6bxQMJC6D4/YTJ9GwPytbOd Z+aw==
X-Received: by 10.112.17.3 with SMTP id k3mr630444lbd.42.1359025328030; Thu, 24 Jan 2013 03:02:08 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id bf3sm9460476lbb.16.2013.01.24.03.02.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 03:02:07 -0800 (PST)
Message-ID: <510114AD.1080708@gmail.com>
Date: Thu, 24 Jan 2013 11:02:05 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: 	<50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com>   <255D2C5E-22CF-43BD-9789-0E6D25B5B7D8@xmlgrrl.com> <5100466F.3030506@mitre.org>
In-Reply-To: <5100466F.3030506@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 11:02:11 -0000

On 23/01/13 20:22, Justin Richer wrote:
> While Eve is right in principle, I think it's better for everyone if
> things remain consistent across different endpoints where possible. This
> is why registration now does form input and json output, for instance.
> Still simple, not as RESTy, but ultimately REST-friendly, which is all
> OAuth ever sought to be.

+1; personally I've no problems for example working with production 
quality WS services supporting a higher-level RS application/services,
but indeed it is important to attempt to keep it as close as possible to 
the original idea of OAuth being REST friendly

thanks, Sergey

>
> -- Justin
>
> On 01/23/2013 03:12 PM, Eve Maler wrote:
>> I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To the extent that it, or its constituent parts, defines endpoints, it also is a security API or set of APIs (10,000-foot view). Since its endpoints use HTTP, this gives the opportunity to ask the question: how RESTful should its APIs be? I'm hearing one firm design principle:
>>
>> - Make new constituent parts be consonant with the rest of OAuth design
>>
>> And a couple of competing soft design principles:
>>
>> - Make it easy to develop endpoints (especially but not exclusively client-side)
>> - Make it flexible to accommodate lots of situations
>>
>> I'm suggesting considering another one, possibly ranking it lower than others:
>>
>> - Make its endpoints operate in a RESTful, resource-oriented way
>>
>> (While OAuth hasn't gone through this exercise, UMA has, and we included a DP about RESTfulness; you can see the results here:http://kantarainitiative.org/confluence/display/uma/UMA+Requirements  That's why we defined draft-hardjono-oauth-resource-reg the way we did.)
>>
>> The dyn reg spec is a kind of bootstrapping spec, so one can expect that it would be out of the REST mainstream in any case -- its credential provisioning function is sui generis. But the functions to create and update metadata look like pretty ordinary CRUD functions that usually correspond to various POST or PUT patterns in REST. If the client metadata were conceived of as a true web resource, it's not wildly out of left field to consider defining their creation and management in high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and GET might mean, even if not allowed in the spec today.
>>
>> (Justin, I promise I'm not trying to give you a hard time. :-)
>>
>> 	Eve
>>
>> On 23 Jan 2013, at 10:54 AM, Phil Hunt  wrote:
>>
>>> My understanding is OAuth is an HTTP protocol.  It is not intended to be REST specific or by implication be RESTful.
>>>
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:
>>>
>>>>> On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>>> +1
>>>>
>>>>    -- Todd
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From:        Eve Maler
>>>> To:        Sergey Beryozkin,
>>>> Cc:        Paul Bryan,"oauth@ietf.org WG"  
>>>> Date:        01/23/2013 12:18 PM
>>>> Subject:        Re: [OAUTH-WG] Concerning OAuth introspection
>>>> Sent by:oauth-bounces@ietf.org
>>>>
>>>>
>>>>
>>>> Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>>>
>>>> If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used:
>>>>
>>>> http://tools.ietf.org/html/draft-pbryan-http-json-resource-03
>>>>
>>>> With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction.
>>>>
>>>>                  Eve
>>>>
>>>> On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin  wrote:
>>>>
>>>>> On 23/01/13 15:47, Justin Richer wrote:
>>>>>> Which brings up an interesting question for the Registration doc: right
>>>>>> now, it's set up as a single endpoint with three operations. We could
>>>>>> instead define three endpoints for the different operations.
>>>>>>
>>>>>> I've not been keen to make that deep of a cutting change to it, but it
>>>>>> would certainly be cleaner and more RESTful API design. What do others
>>>>>> think?
>>>>>>
>>>>> IMHO the purity should be balanced against the practicality/simplicity
>>>>> of the implementation.
>>>>> Talking about 3 endpoints at the spec level may be treated as the exact
>>>>> requirement to have 3 separate application endpoints for the single type
>>>>> of activity, the registration. Can the spec be re-worded such that
>>>>> "resources" are used instead of endpoints or similar, example, "resource
>>>>> available at /a will support the following, at /b - something else", or
>>>>> may be something similar,  thus it will read better too from the design
>>>>> point of view, and let implementers to use 1 endpoint or 3 ones,
>>>>> whichever way they prefer it
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>> "Action" goes against REST principle.
>>>>>>> I do not think it is a good idea.
>>>>>>>
>>>>>>> =nat via iPhone
>>>>>>>
>>>>>>> Jan 23, 2013 4:00Justin Richer   :
>>>>>>>
>>>>>>>> (CC'ing the working group)
>>>>>>>>
>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>>>
>>>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>>>
>>>>>>>>   -- Justin
>>>>>>>>
>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>> Justin,
>>>>>>>>>
>>>>>>>>> This spec is looking good..
>>>>>>>>>
>>>>>>>>> One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)
>>>>>>>>>
>>>>>>>>> So the request will be like :
>>>>>>>>> token                                             REQUIRED
>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>>>> resource_id                                    OPTIONAL
>>>>>>>>> client_id                                         OPTIONAL
>>>>>>>>> client_secret                                   OPTIONAL
>>>>>>>>>
>>>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>>>
>>>>>>>>> Please consider.
>>>>>>>>>
>>>>>>>>> ShiuFun
>>>>
>>>> Eve Malerhttp://www.xmlgrrl.com/blog
>>>> +1 425 345 6756http://www.twitter.com/xmlgrrl
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> Eve Malerhttp://www.xmlgrrl.com/blog
>> +1 425 345 6756http://www.twitter.com/xmlgrrl
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From jricher@mitre.org  Thu Jan 24 06:17:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487A721F8A79 for ; Thu, 24 Jan 2013 06:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level: 
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEKniqCoiXiz for ; Thu, 24 Jan 2013 06:17:19 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9F01821F8A56 for ; Thu, 24 Jan 2013 06:17:19 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B06C1F22BE; Thu, 24 Jan 2013 09:17:19 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EC9301F22FA; Thu, 24 Jan 2013 09:17:18 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 09:17:18 -0500
Message-ID: <5101425A.6080905@mitre.org>
Date: Thu, 24 Jan 2013 09:16:58 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Anthony Nadalin 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 14:17:20 -0000

Not to jump in and answer for Torsten, but I thought I'd  offer at least 
my understanding of the document:

On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
> 1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?
It could be separate if your architecture can support that. It gets 
found the same way other OAuth endpoints get found -- configuration 
documents, some kind of discovery mechanism, or magic. Which is to say, 
that's not currently OAuth's problem.

> 2.       Any token type that is supported can be revoked, including refresh token ?
That's the idea. We've implemented this on our OIDC server so that you 
can also revoke ID Tokens for session management purposes.

> 3.       Why does one have to send the token, can't this just be an auth_code ?
You don't always use an auth code to get a token (think implicit, client 
credentials, assertion, or resource owner credentials flows), and auth 
codes are supposed to be thrown away after use anyway.

> 4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
If they have issues, which is to say "A good reason not to", then they 
don't have to support it. That's the semantics behind "SHOULD", and so 
it is fine here.

> 5.       Does not say but is the revocation to be immediate upon the return of the request ?
This is implementation dependent. Large scale distributed 
implementations could have trouble making this "immediate", but small 
systems are more likely to be quick. From the client's perspective, if 
they get back a success response, they shouldn't count on that token 
being good anymore (see section 2 note about client behavior).

> 6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
That's a policy decision.

> 7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.
Why would a client want to use a token that they just revoked? This is 
prescribing the desired correct behavior to a client so that client 
developers will do the right thing when they implement it. Isn't that 
the point of the spec?

  -- Justin

From jricher@mitre.org  Thu Jan 24 06:26:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F38621F8A27 for ; Thu, 24 Jan 2013 06:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level: 
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf1EWZ48mWpZ for ; Thu, 24 Jan 2013 06:26:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A190821F8834 for ; Thu, 24 Jan 2013 06:26:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 303AE5310D34; Thu, 24 Jan 2013 09:26:33 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 238781F22EE; Thu, 24 Jan 2013 09:26:33 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 09:26:32 -0500
Message-ID: <51014484.50001@mitre.org>
Date: Thu, 24 Jan 2013 09:26:12 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Sergey Beryozkin 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com>
In-Reply-To: <5101135F.5060000@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 14:26:35 -0000

On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>
> I like this most, would rename it to say
>
> /oauth/client/registration
> or
> /oauth/client-registration
>
> etc
>
> and reword the spec such that it will let those who implement do it 
> with one endpoint or many, whatever is preferred
>

That's the whole point of this discussion -- I don't believe you can 
have it both ways.

In one way, you say there are three endpoints and, if you're keeping 
with the rest of OAuth, you don't give them official URL patterns that 
they must follow. How the client gets those endpoints is up to discovery 
or configuration, but the client has an internal map from each bit of 
functionality to a particular URL that's specific to the service, much 
in the same way that the client today has to map the authorization and 
token endpoints. In the other method, you've got one endpoint that the 
client sends a well-defined parameter to in order to accomplish the same 
goal.

So if you allow both at once, does a client send the "operation" 
parameter or not? Is it looking for one url or three to store in its 
configuration? I don't think this level of flexibility buys you anything 
useful, and I strongly believe that it will deeply hurt the 
functionality of dynamic registration if it's allowed.

As it stands today, you can still make the URL whatever you want. If we 
went with three endpoints you could also make those URLs whatever you 
wanted. Nobody has yet pointed out to me what the actual benefit is of 
making both valid.

I personally prefer the method of three endpoint URLs because it's 
cleaner and semantically equivalent, but I am hesitant to change that 
behavior unless there's strong working group support for it. I haven't 
seen real support for it yet -- it's not a good call to make it fully 
RESTful, and it's not a good call to leave it undefined. A client MUST 
have a very clear recipe of what to do on startup for this to work in 
the wild.

  -- Justin

>
>>
>>
>> help multitenancy? How does it even affect that use case? Consider that
>> the base URL for all of these is completely up to the host environment
>> (nothing is bound to the root URL). Consider that clients still have to
>> know what the URL (or URLs) are, in either case. Consider that clients
>> still need to know how to manage all the parameters and responses.
>>
>> If anything, keeping it the way that it is with a single URL could be
>> argued to help multitenancy because setting up routing to multiple URL
>> endpoints can sometimes be problematic in hosted environments. However,
>> OAuth already defines a bunch of endpoints, and we have to define at
>> least one more with this extension, so I'm not convinced that having
>> three with specific functions is really any different from having one
>> with three functions from a development, deployment, and implementation
>> perspective. I can tell you from experience that in our own server code,
>> the difference is trivial. (And from OAuth1 experience, you can always
>> have a query parameter as part of your endpoint URL if you need to. You
>> might hate yourself for doing it that way, but nothing says your base
>> URL can't already have parameters on it. A client just needs to know how
>> to appropriately tack its parameters onto an existing URL, and any HTTP
>> client worth its salt will know how to augment a query parameter set
>> with new items.)
>>
>> The *real* difference between the two approaches is a philosophical
>> design one. The former overloads one URL with multiple functions
>> switched by a flag, the latter uses the URL itself as an implicit flag.
>> Under the hood, these could (and in many cases will) be all served by
>> the same chunks of code. The only difference is how this switch in
>> functionality is presented.
>>
>>
>> With that said, can somebody please explain to me how allowing *both* of
>> these as options simultaneously (what I understand Tony to be
>> suggesting) is a good idea, or how multitenancy even comes into play?
>> Because I am completely not seeing how these are related.
>>
>> Thanks,
>> -- Justin
>>
>>
>>
>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>> It will not work the way you have it, as people do multi-tendency 
>>> different and they are already stuck with the method that they have 
>>> chosen, so they need the flexability, to restrict this is nuts as 
>>> people won't use it.
>>>
>>> -----Original Message-----
>>> From: Justin Richer [mailto:jricher@mitre.org]
>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>> To: Anthony Nadalin
>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>
>>> I completely disagree with this assessment. Multi-tenancy will work 
>>> just fine (or even better) if everyone uses the same pattern. 
>>> Telling someone "it might be three different urls or it might be all 
>>> one url with a parameter" is just asking for a complete disaster. 
>>> What does the flexibility of allowing two approaches actually 
>>> accomplish?
>>>
>>> You can argue about the merits of either approach, but having both 
>>> as unspecified options for registration, which is meant to help 
>>> things get going in a cold-boot environment, is just plain nuts.
>>>
>>>
>>> -- Justin
>>>
>>>
>>>
>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>> Registration has to work in a multi-tenant environment  so flexibility
>>>> is needed
>>>>
>>>> -----Original Message-----
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>> To: Anthony Nadalin
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> Because then nobody would know how to actually use the thing.
>>>>
>>>> In my opinion, this is a key place where this kind of flexibility 
>>>> is a very bad thing. Registration needs to work one fairly 
>>>> predictable way.
>>>>
>>>> -- Justin
>>>>
>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>> Why not just have a physical and logical endpoint options
>>>>>
>>>>> -----Original Message-----
>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>> Behalf Of Justin Richer
>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>> To: Nat Sakimura
>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>
>>>>> Which brings up an interesting question for the Registration doc: 
>>>>> right now, it's set up as a single endpoint with three operations. 
>>>>> We could instead define three endpoints for the different operations.
>>>>>
>>>>> I've not been keen to make that deep of a cutting change to it, 
>>>>> but it would certainly be cleaner and more RESTful API design. 
>>>>> What do others think?
>>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>> "Action" goes against REST principle.
>>>>>> I do not think it is a good idea.
>>>>>>
>>>>>> =nat via iPhone
>>>>>>
>>>>>> Jan 23, 2013 4:00Justin Richer  :
>>>>>>
>>>>>>> (CC'ing the working group)
>>>>>>>
>>>>>>> I'm not sure what the "action/operation" flag would accomplish. 
>>>>>>> The idea behind having different endpoints in OAuth is that they 
>>>>>>> each do different kinds of things. The only "action/operation" 
>>>>>>> that I had envisioned for the introspection endpoint is 
>>>>>>> introspection itself: "I have a token, what does it mean?"
>>>>>>>
>>>>>>> Note that client_id and client_secret *can* already be used at 
>>>>>>> this endpoint if the server supports that as part of their 
>>>>>>> client credentials setup. The examples use HTTP Basic with 
>>>>>>> client id and secret right now. Basically, the client can 
>>>>>>> authenticate however it wants, including any of the methods that 
>>>>>>> OAuth2 allows on the token endpoint. It could also authenticate 
>>>>>>> with an access token. At least, that's the intent of the 
>>>>>>> introspection draft -- if that's unclear, I'd be happy to accept 
>>>>>>> suggested changes to clarify this text.
>>>>>>>
>>>>>>>   -- Justin
>>>>>>>
>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>> Justin,
>>>>>>>>
>>>>>>>> This spec is looking good..
>>>>>>>>
>>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>>> to the request.  (and potentially add client_id and client_secret)
>>>>>>>>
>>>>>>>> So the request will be like :
>>>>>>>> token REQUIRED
>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) 
>>>>>>>> | revoke ...
>>>>>>>> resource_id OPTIONAL
>>>>>>>> client_id OPTIONAL
>>>>>>>> client_secret OPTIONAL
>>>>>>>>
>>>>>>>> And for the OAuth client information, it should be an optional 
>>>>>>>> parameter (in case it is a public client or client is 
>>>>>>>> authenticated with SSL mutual authentication).
>>>>>>>>
>>>>>>>> Please consider.
>>>>>>>>
>>>>>>>> ShiuFun
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From bcampbell@pingidentity.com  Thu Jan 24 07:01:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92A21F8A64 for ; Thu, 24 Jan 2013 07:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B41XQ2GWKy5 for ; Thu, 24 Jan 2013 07:01:39 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 717EB21F8A56 for ; Thu, 24 Jan 2013 07:01:39 -0800 (PST)
Received: from mail-oa0-f69.google.com ([209.85.219.69]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUQFM0op9FQm80azMLutajl6u5cZ/kAhj@postini.com; Thu, 24 Jan 2013 07:01:39 PST
Received: by mail-oa0-f69.google.com with SMTP id l10so9904880oag.4 for ; Thu, 24 Jan 2013 07:01:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=hCKOs5RZ6gAJ3/cz13m+GJxnxUvodD8GG2PyvQyH/ro=; b=PyYneSLuIn/vvHpnOPmJxv9iR8uc3srKEmrJCNrC46gXdJtSIsEPMfM89O/AS2aE7b zVgqiLl6kzk+SYjHUqzbh8R1aGzpqLUdz9IpRnrl1hWXZm3e9MYjoW6ymA+cgcm663Y+ pEC/27aaXKavFUZNl7zS52KTQUDCJ0BrftKuC9KwBhqJC4mNkMrlSgjl5/ZWfw6iPw6A 8gCe8risWmfDXfdgrd1Pu0EPYI86q9b9XEvGsCM7/iZlBmCvHsMN6pVEoqSugv/uYm2g upuFwRvzMWdInma7KJZWp7dBn39KJU8UOqaeJJ5IuQUyTX02PRC8Y/SRReiB3nWWt+UM bZTA==
X-Received: by 10.50.169.106 with SMTP id ad10mr1594474igc.88.1359039698339; Thu, 24 Jan 2013 07:01:38 -0800 (PST)
X-Received: by 10.50.169.106 with SMTP id ad10mr1594468igc.88.1359039698246; Thu, 24 Jan 2013 07:01:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Thu, 24 Jan 2013 07:01:08 -0800 (PST)
In-Reply-To: <51014484.50001@mitre.org>
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org>
From: Brian Campbell 
Date: Thu, 24 Jan 2013 08:01:08 -0700
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=e89a8f2346bb731bb004d40a16ff
X-Gm-Message-State: ALoCoQmcqQNM8+WFsQUwj+68rwBblaM1H748Fb8Wxfp2e7PQ1IrAeYIPNa6zD4rlnKpcTNVZ+cGcSUAIImObrOEeFsAXg7vzqeN+uRxdMXn5kxppJbAPkUOjywFrO/SxccdrttToeAKV
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 15:01:40 -0000

--e89a8f2346bb731bb004d40a16ff
Content-Type: text/plain; charset=ISO-8859-1

Well, you *can* have it both ways. But to your point Justin - what's the
value in it? Allowing for both adds a bunch of unnecessary complexity while
only adding flexibility for the sake of flexibility with no tangible
benefit.

On Thu, Jan 24, 2013 at 7:26 AM, Justin Richer  wrote:

>
> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>
>>
>> and reword the spec such that it will let those who implement do it with
>> one endpoint or many, whatever is preferred
>>
>>
> That's the whole point of this discussion -- I don't believe you can have
> it both ways.
>

--e89a8f2346bb731bb004d40a16ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Well, you *can* have it both ways. But to your point Justin - what's th=
e
 value in it? Allowing for both adds a bunch of unnecessary complexity whil=
e only adding flexibility for the sake of flexibility with no tangible bene=
fit.=A0 

On Thu, Jan 24, 2013 at 7:26 AM,=
 Justin Richer <jricher@mitre.org> wrote:






On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:





and reword the spec such that it will let those who implement do it with on=
e endpoint or many, whatever is preferred







That's the whole point of this discussion -- I don't believe you ca=
n have it both ways.




--e89a8f2346bb731bb004d40a16ff--

From sberyozkin@gmail.com  Thu Jan 24 07:38:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11721F873D for ; Thu, 24 Jan 2013 07:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.202,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO1X8zwd56Fh for ; Thu, 24 Jan 2013 07:38:29 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0021F86FB for ; Thu, 24 Jan 2013 07:38:28 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id gf7so6582605lbb.32 for ; Thu, 24 Jan 2013 07:38:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IG4N962r/J+riYVWM5ht50GGMLsfe6UACf3zI0o6RaY=; b=wglEEjbg0R4t6tKH0xe0SJHWO1844nVBHXoKyAaNFYsog5VugvZCtJ2UgUJp73to2N XNIctBjjpV+9TXoCSJOWf9T2bYtjvc9J11jWWgldEWk3P/JAG73BYkCAexj9evilEaMX P4LISg+YAyNaiYMxCkaZlckxxiNygZLsypIgNBSYTNPD8Zg0v0OEpPlJmtgWCf/6f4JR tEyTVply3cBPmBXipgpC2VOENaeZsuNFsvXiLIQpYV1sA73nX+RPkNEMJR2s8Gzbs1su 7gZIY3fzzRyvoADjthHM+gJgBvK68vwWZfWfQhWscuFDZ46nnMN31Qt1YaCNpqWe1FlZ wpzQ==
X-Received: by 10.112.50.201 with SMTP id e9mr981583lbo.82.1359041907202; Thu, 24 Jan 2013 07:38:27 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id oy10sm2254139lab.8.2013.01.24.07.38.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 07:38:26 -0800 (PST)
Message-ID: <51015560.3030607@gmail.com>
Date: Thu, 24 Jan 2013 15:38:08 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Justin Richer 
References:  <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <5101135F.5060000@gmail.com> <51014484.50001@mitre.org>
In-Reply-To: <51014484.50001@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 15:38:30 -0000

On 24/01/13 14:26, Justin Richer wrote:
>
> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
>>
>> I like this most, would rename it to say
>>
>> /oauth/client/registration
>> or
>> /oauth/client-registration
>>
>> etc
>>
>> and reword the spec such that it will let those who implement do it
>> with one endpoint or many, whatever is preferred
>>
>
> That's the whole point of this discussion -- I don't believe you can
> have it both ways.
>
> In one way, you say there are three endpoints and, if you're keeping
> with the rest of OAuth, you don't give them official URL patterns that
> they must follow. How the client gets those endpoints is up to discovery
> or configuration, but the client has an internal map from each bit of
> functionality to a particular URL that's specific to the service, much
> in the same way that the client today has to map the authorization and
> token endpoints. In the other method, you've got one endpoint that the
> client sends a well-defined parameter to in order to accomplish the same
> goal.
>
> So if you allow both at once, does a client send the "operation"
> parameter or not? Is it looking for one url or three to store in its
> configuration? I don't think this level of flexibility buys you anything
> useful, and I strongly believe that it will deeply hurt the
> functionality of dynamic registration if it's allowed.
>
> As it stands today, you can still make the URL whatever you want. If we
> went with three endpoints you could also make those URLs whatever you
> wanted. Nobody has yet pointed out to me what the actual benefit is of
> making both valid.
>
> I personally prefer the method of three endpoint URLs because it's
> cleaner and semantically equivalent, but I am hesitant to change that
> behavior unless there's strong working group support for it. I haven't
> seen real support for it yet -- it's not a good call to make it fully
> RESTful, and it's not a good call to leave it undefined. A client MUST
> have a very clear recipe of what to do on startup for this to work in
> the wild.

Basically, I haven't thought deeply about it. What I meant was that with

/oauth/client/registration
/oauth/client/somethingelse

I can implement easily by having a single endpoint or 2 ones (with the 
endpoint not necessarily meaning it runs in its own container), but the 
client won't know, I'm assuming 'the endpoint' does not mean its URI 
will need to have a unique port.
Sorry if I've missed the point :-)

Sergey



>
> -- Justin
>
>>
>>>
>>>
>>> help multitenancy? How does it even affect that use case? Consider that
>>> the base URL for all of these is completely up to the host environment
>>> (nothing is bound to the root URL). Consider that clients still have to
>>> know what the URL (or URLs) are, in either case. Consider that clients
>>> still need to know how to manage all the parameters and responses.
>>>
>>> If anything, keeping it the way that it is with a single URL could be
>>> argued to help multitenancy because setting up routing to multiple URL
>>> endpoints can sometimes be problematic in hosted environments. However,
>>> OAuth already defines a bunch of endpoints, and we have to define at
>>> least one more with this extension, so I'm not convinced that having
>>> three with specific functions is really any different from having one
>>> with three functions from a development, deployment, and implementation
>>> perspective. I can tell you from experience that in our own server code,
>>> the difference is trivial. (And from OAuth1 experience, you can always
>>> have a query parameter as part of your endpoint URL if you need to. You
>>> might hate yourself for doing it that way, but nothing says your base
>>> URL can't already have parameters on it. A client just needs to know how
>>> to appropriately tack its parameters onto an existing URL, and any HTTP
>>> client worth its salt will know how to augment a query parameter set
>>> with new items.)
>>>
>>> The *real* difference between the two approaches is a philosophical
>>> design one. The former overloads one URL with multiple functions
>>> switched by a flag, the latter uses the URL itself as an implicit flag.
>>> Under the hood, these could (and in many cases will) be all served by
>>> the same chunks of code. The only difference is how this switch in
>>> functionality is presented.
>>>
>>>
>>> With that said, can somebody please explain to me how allowing *both* of
>>> these as options simultaneously (what I understand Tony to be
>>> suggesting) is a good idea, or how multitenancy even comes into play?
>>> Because I am completely not seeing how these are related.
>>>
>>> Thanks,
>>> -- Justin
>>>
>>>
>>>
>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>> It will not work the way you have it, as people do multi-tendency
>>>> different and they are already stuck with the method that they have
>>>> chosen, so they need the flexability, to restrict this is nuts as
>>>> people won't use it.
>>>>
>>>> -----Original Message-----
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>> To: Anthony Nadalin
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> I completely disagree with this assessment. Multi-tenancy will work
>>>> just fine (or even better) if everyone uses the same pattern.
>>>> Telling someone "it might be three different urls or it might be all
>>>> one url with a parameter" is just asking for a complete disaster.
>>>> What does the flexibility of allowing two approaches actually
>>>> accomplish?
>>>>
>>>> You can argue about the merits of either approach, but having both
>>>> as unspecified options for registration, which is meant to help
>>>> things get going in a cold-boot environment, is just plain nuts.
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
>>>>> Registration has to work in a multi-tenant environment so flexibility
>>>>> is needed
>>>>>
>>>>> -----Original Message-----
>>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>> To: Anthony Nadalin
>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>
>>>>> Because then nobody would know how to actually use the thing.
>>>>>
>>>>> In my opinion, this is a key place where this kind of flexibility
>>>>> is a very bad thing. Registration needs to work one fairly
>>>>> predictable way.
>>>>>
>>>>> -- Justin
>>>>>
>>>>> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>>>>>> Why not just have a physical and logical endpoint options
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>>> Behalf Of Justin Richer
>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>>> To: Nat Sakimura
>>>>>> Cc: Shiu Fun Poon;oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>>>
>>>>>> Which brings up an interesting question for the Registration doc:
>>>>>> right now, it's set up as a single endpoint with three operations.
>>>>>> We could instead define three endpoints for the different operations.
>>>>>>
>>>>>> I've not been keen to make that deep of a cutting change to it,
>>>>>> but it would certainly be cleaner and more RESTful API design.
>>>>>> What do others think?
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>> "Action" goes against REST principle.
>>>>>>> I do not think it is a good idea.
>>>>>>>
>>>>>>> =nat via iPhone
>>>>>>>
>>>>>>> Jan 23, 2013 4:00Justin Richer :
>>>>>>>
>>>>>>>> (CC'ing the working group)
>>>>>>>>
>>>>>>>> I'm not sure what the "action/operation" flag would accomplish.
>>>>>>>> The idea behind having different endpoints in OAuth is that they
>>>>>>>> each do different kinds of things. The only "action/operation"
>>>>>>>> that I had envisioned for the introspection endpoint is
>>>>>>>> introspection itself: "I have a token, what does it mean?"
>>>>>>>>
>>>>>>>> Note that client_id and client_secret *can* already be used at
>>>>>>>> this endpoint if the server supports that as part of their
>>>>>>>> client credentials setup. The examples use HTTP Basic with
>>>>>>>> client id and secret right now. Basically, the client can
>>>>>>>> authenticate however it wants, including any of the methods that
>>>>>>>> OAuth2 allows on the token endpoint. It could also authenticate
>>>>>>>> with an access token. At least, that's the intent of the
>>>>>>>> introspection draft -- if that's unclear, I'd be happy to accept
>>>>>>>> suggested changes to clarify this text.
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>> Justin,
>>>>>>>>>
>>>>>>>>> This spec is looking good..
>>>>>>>>>
>>>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>>>> to the request. (and potentially add client_id and client_secret)
>>>>>>>>>
>>>>>>>>> So the request will be like :
>>>>>>>>> token REQUIRED
>>>>>>>>> operation (wording to be determine) OPTIONAL inquire (default)
>>>>>>>>> | revoke ...
>>>>>>>>> resource_id OPTIONAL
>>>>>>>>> client_id OPTIONAL
>>>>>>>>> client_secret OPTIONAL
>>>>>>>>>
>>>>>>>>> And for the OAuth client information, it should be an optional
>>>>>>>>> parameter (in case it is a public client or client is
>>>>>>>>> authenticated with SSL mutual authentication).
>>>>>>>>>
>>>>>>>>> Please consider.
>>>>>>>>>
>>>>>>>>> ShiuFun
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing 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 tonynad@microsoft.com  Thu Jan 24 08:03:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EC821F8951 for ; Thu, 24 Jan 2013 08:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYTi8r2mNBvu for ; Thu, 24 Jan 2013 08:03:42 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 362C421F8942 for ; Thu, 24 Jan 2013 08:03:41 -0800 (PST)
Received: from BL2FFO11FD004.protection.gbl (10.173.161.203) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 24 Jan 2013 16:03:39 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 24 Jan 2013 16:03:39 +0000
Received: from co1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 24 Jan 2013 16:03:13 +0000
Received: from mail220-co1-R.bigfish.com (10.243.78.216) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 Jan 2013 15:59:53 +0000
Received: from mail220-co1 (localhost [127.0.0.1])	by mail220-co1-R.bigfish.com (Postfix) with ESMTP id 9C87780396	for ; Thu, 24 Jan 2013 15:59:53 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -19
X-BigFish: PS-19(zzbb2dI98dI9371Id6eah542Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h)
Received-SPF: softfail (mail220-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail220-co1 (localhost.localdomain [127.0.0.1]) by mail220-co1 (MessageSwitch) id 1359043126812105_4073; Thu, 24 Jan 2013 15:58:46 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.215])	by mail220-co1.bigfish.com (Postfix) with ESMTP id B9D6724056B; Thu, 24 Jan 2013 15:58:46 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 Jan 2013 15:58:40 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.257.4; Thu, 24 Jan 2013 15:58:40 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.601.3; Thu, 24 Jan 2013 15:58:38 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Thu, 24 Jan 2013 15:58:37 +0000
From: Anthony Nadalin 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQAB4kyAAAA1FVAA==
Date: Thu, 24 Jan 2013 15:58:36 +0000
Message-ID: <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com>
References:  <5101425A.6080905@mitre.org>
In-Reply-To: <5101425A.6080905@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.168]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(479174001)(13464002)(377454001)(24454001)(189002)(16676001)(5343655001)(53806001)(23726001)(47736001)(6806001)(4396001)(550184003)(50466001)(49866001)(47976001)(50986001)(51856001)(56776001)(79102001)(33646001)(63696002)(54356001)(54316002)(76482001)(46406002)(31966008)(46102001)(74502001)(56816002)(74662001)(44976002)(47446002)(77982001)(59766001)(47776003)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 073631BD3D
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 16:03:44 -0000

Ugggg uggg

1. we keep punting on discovery, this has an impact on security of where I =
send my credentials and token, can't see punting yet again here
2. OK, make this explicit in specification
3. if you have an auth_code you should be able to use it, agree not all wil=
l have it but some will
4. MAY seems a better choice
5. Make it explicit in the spec one way or the other, too vague now
6. How does one find the policy, as this has an impact on #7
7. There is a big difference here in enforcement, the client should not hav=
e to enforce this rule, the client may not know due to policy that revoking=
 1 token revokes other tokens thus the client would have to know the server=
s policy. This should be a SHOULD not MUST

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]=20
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

Not to jump in and answer for Torsten, but I thought I'd  offer at least my=
 understanding of the document:

On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
> 1.       Since not stated I assume that the Revocation Endpoint can exist=
 on a different server from the Authorization server (or is it assumed that=
 they are 1), if so how is the Revocation Endpoint found?
It could be separate if your architecture can support that. It gets found t=
he same way other OAuth endpoints get found -- configuration documents, som=
e kind of discovery mechanism, or magic. Which is to say, that's not curren=
tly OAuth's problem.

> 2.       Any token type that is supported can be revoked, including refre=
sh token ?
That's the idea. We've implemented this on our OIDC server so that you can =
also revoke ID Tokens for session management purposes.

> 3.       Why does one have to send the token, can't this just be an auth_=
code ?
You don't always use an auth code to get a token (think implicit, client cr=
edentials, assertion, or resource owner credentials flows), and auth codes =
are supposed to be thrown away after use anyway.

> 4.       Says CORS SHOULD be supported, I think a MAY be better here sinc=
e a site may have issues supporting CORS
If they have issues, which is to say "A good reason not to", then they don'=
t have to support it. That's the semantics behind "SHOULD", and so it is fi=
ne here.

> 5.       Does not say but is the revocation to be immediate upon the retu=
rn of the request ?
This is implementation dependent. Large scale distributed implementations c=
ould have trouble making this "immediate", but small systems are more likel=
y to be quick. From the client's perspective, if they get back a success re=
sponse, they shouldn't count on that token being good anymore (see section =
2 note about client behavior).

> 6.       Does the revocation of the access token also revoke the refresh =
token (if it was provided) ? Or is this a revocation policy decision ?
That's a policy decision.

> 7.       Section 2 says "the client MUST NOT use this token again", well =
that seems odd, not sure this should be here as the client could try to use=
 it gain, there is no need to put support in client to prevent this.
Why would a client want to use a token that they just revoked? This is pres=
cribing the desired correct behavior to a client so that client developers =
will do the right thing when they implement it. Isn't that the point of the=
 spec?

  -- Justin




From jricher@mitre.org  Thu Jan 24 08:13:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5921F8A42 for ; Thu, 24 Jan 2013 08:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.518
X-Spam-Level: 
X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAaCd3DG635E for ; Thu, 24 Jan 2013 08:13:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 001B421F89EE for ; Thu, 24 Jan 2013 08:13:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 79C381F237B; Thu, 24 Jan 2013 11:13:06 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6BC941F2353; Thu, 24 Jan 2013 11:13:06 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 11:13:06 -0500
Message-ID: <51015D7D.3010600@mitre.org>
Date: Thu, 24 Jan 2013 11:12:45 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Anthony Nadalin 
References:  <5101425A.6080905@mitre.org> <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 16:13:09 -0000

On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
> 1. we keep punting on discovery, this has an impact on security of where I send my credentials and token, can't see punting yet again here
It doesn't make any sense to solve discovery *just* for revocation, 
which you seem to be advocating. Of course it has an impact on security 
-- this is a security protocol we're talking about, that goes without 
saying. It also impacts security where I send the user for 
authorization, and everything else that you do.

I would rather see discovery solved properly for all of OAuth including 
all of its endpoints. UMA has taken a crack at this, there's a draft 
defining XRD link types, OIDC has a solution for this as well (in the 
provider configuration .well-known doc).

> 2. OK, make this explicit in specification
Fair enough. Got specific language to suggest?

> 3. if you have an auth_code you should be able to use it, agree not all will have it but some will
You shouldn't have an auth code anymore -- you're supposed to throw it 
away since it's single use (per 10.5 of RFC6749). Why wouldn't you just 
use the token? You're guaranteed to have the token in all cases. I see 
no value in sometimes sending an auth code and sometimes sending a token 
when I am guaranteed to always have the token.

> 4. MAY seems a better choice
Possibly -- I think SHOULD is fine here but I'm curious what others say.

> 5. Make it explicit in the spec one way or the other, too vague now
Explicit how? It can explicitly go either way. From the client's 
perspective, it's supposed to be immediate. From the server's 
perspective, it could take a while to actually enforce that.

> 6. How does one find the policy, as this has an impact on #7
How does one find any other implementation specific policy? There was 
already a big discussion about this a while ago. It used to be a MUST to 
cascade, then as I recall, Google objected to it because their access 
tokens in the wild can't be revoked at all, so revoking a refresh token 
revokes only that token. The current language allows the server to 
decide what it has to do.

> 7. There is a big difference here in enforcement, the client should not have to enforce this rule, the client may not know due to policy that revoking 1 token revokes other tokens thus the client would have to know the servers policy. This should be a SHOULD not MUST
You're conflating things here. If the client revokes the refresh token, 
they must not use that refresh token again. They can try to use any 
access or other tokens if they want to, but that refresh token is off 
the table. The server is allowed to also nuke any access tokens that it 
wants to, but if the client wants to be really, really sure, it can 
revoke all of its access tokens separately.

  -- Justin

> -----Original Message-----
> From: Justin Richer [mailto:jricher@mitre.org]
> Sent: Thursday, January 24, 2013 6:17 AM
> To: Anthony Nadalin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
> Not to jump in and answer for Torsten, but I thought I'd  offer at least my understanding of the document:
>
> On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
>> 1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?
> It could be separate if your architecture can support that. It gets found the same way other OAuth endpoints get found -- configuration documents, some kind of discovery mechanism, or magic. Which is to say, that's not currently OAuth's problem.
>
>> 2.       Any token type that is supported can be revoked, including refresh token ?
> That's the idea. We've implemented this on our OIDC server so that you can also revoke ID Tokens for session management purposes.
>
>> 3.       Why does one have to send the token, can't this just be an auth_code ?
> You don't always use an auth code to get a token (think implicit, client credentials, assertion, or resource owner credentials flows), and auth codes are supposed to be thrown away after use anyway.
>
>> 4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
> If they have issues, which is to say "A good reason not to", then they don't have to support it. That's the semantics behind "SHOULD", and so it is fine here.
>
>> 5.       Does not say but is the revocation to be immediate upon the return of the request ?
> This is implementation dependent. Large scale distributed implementations could have trouble making this "immediate", but small systems are more likely to be quick. From the client's perspective, if they get back a success response, they shouldn't count on that token being good anymore (see section 2 note about client behavior).
>
>> 6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
> That's a policy decision.
>
>> 7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.
> Why would a client want to use a token that they just revoked? This is prescribing the desired correct behavior to a client so that client developers will do the right thing when they implement it. Isn't that the point of the spec?
>
>    -- Justin
>
>
>


From tonynad@microsoft.com  Thu Jan 24 08:31:42 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6902A21F89CB for ; Thu, 24 Jan 2013 08:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtEw3Xna8mYN for ; Thu, 24 Jan 2013 08:31:24 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 127A821F8A4E for ; Thu, 24 Jan 2013 08:31:16 -0800 (PST)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.201) by BL2FFO11HUB025.protection.gbl (10.173.161.49) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 24 Jan 2013 16:31:06 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 24 Jan 2013 16:31:05 +0000
Received: from db3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 24 Jan 2013 16:30:27 +0000
Received: from mail49-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 Jan 2013 16:29:12 +0000
Received: from mail49-db3 (localhost [127.0.0.1])	by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 9B34A3002F6	for ; Thu, 24 Jan 2013 16:29:12 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -20
X-BigFish: PS-20(zzbb2dI98dI9371Id6eah542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h)
Received-SPF: softfail (mail49-db3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1359044950651959_13890; Thu, 24 Jan 2013 16:29:10 +0000 (UTC)
Received: from DB3EHSMHS021.bigfish.com (unknown [10.3.81.245])	by mail49-db3.bigfish.com (Postfix) with ESMTP id 92E5D3401F9; Thu, 24 Jan 2013 16:29:10 +0000 (UTC)
Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS021.bigfish.com (10.3.87.157) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 Jan 2013 16:29:08 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.257.4; Thu, 24 Jan 2013 16:29:08 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.601.3; Thu, 24 Jan 2013 16:29:06 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Thu, 24 Jan 2013 16:28:59 +0000
From: Anthony Nadalin 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQAB4kyAAAA1FVAAAAudqAAAAhbLA=
Date: Thu, 24 Jan 2013 16:28:59 +0000
Message-ID: <2d27b0f214104811a659c12336ce7865@BY2PR03MB041.namprd03.prod.outlook.com>
References:  <5101425A.6080905@mitre.org> <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com> <51015D7D.3010600@mitre.org>
In-Reply-To: <51015D7D.3010600@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.168]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(51704002)(377454001)(199002)(479174001)(13464002)(24454001)(54356001)(54316002)(33646001)(76482001)(63696002)(74662001)(44976002)(47446002)(74502001)(56816002)(47776003)(59766001)(77982001)(31966008)(46406002)(46102001)(47736001)(6806001)(4396001)(550184003)(5343655001)(16676001)(23726001)(53806001)(51856001)(56776001)(79102001)(47976001)(50986001)(49866001)(50466001)(455564002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB025; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 073631BD3D
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 16:31:42 -0000

1. We have WebFinger lets use that as we have already been through the disc=
overy issues, point being there are security issues at stake here w/o prope=
r knowledge, next thing we know some rouge sever has signed up as a revocat=
ion sever.
3. you can still have one if you have not used it and want to revoke it, I =
may not want to redeem the auth_code to get a token to revoke it, I may jus=
t not want to send the token
5. That is just the point, how does one know that the token id revoked
6. very poor choice, as no one know what is going on
7. No I'm not conflating things here at all, please read the text. If I sen=
d a access_token and the server's policy says that the refresh_token associ=
ated with the access_token is also to be revoked then I have no way to know=
 that "The client MUST NOT use this token again after revocation". What is =
"this" mean in the sentence, only the token I sent or any revoked token. Al=
so how do I know when the token is actually revoked, could take a week or m=
ore given policy?=20

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]=20
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review


On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
> 1. we keep punting on discovery, this has an impact on security of=20
> where I send my credentials and token, can't see punting yet again=20
> here
It doesn't make any sense to solve discovery *just* for revocation, which y=
ou seem to be advocating. Of course it has an impact on security
-- this is a security protocol we're talking about, that goes without sayin=
g. It also impacts security where I send the user for authorization, and ev=
erything else that you do.

I would rather see discovery solved properly for all of OAuth including all=
 of its endpoints. UMA has taken a crack at this, there's a draft defining =
XRD link types, OIDC has a solution for this as well (in the provider confi=
guration .well-known doc).

> 2. OK, make this explicit in specification
Fair enough. Got specific language to suggest?

> 3. if you have an auth_code you should be able to use it, agree not=20
> all will have it but some will
You shouldn't have an auth code anymore -- you're supposed to throw it away=
 since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the=
 token? You're guaranteed to have the token in all cases. I see no value in=
 sometimes sending an auth code and sometimes sending a token when I am gua=
ranteed to always have the token.

> 4. MAY seems a better choice
Possibly -- I think SHOULD is fine here but I'm curious what others say.

> 5. Make it explicit in the spec one way or the other, too vague now
Explicit how? It can explicitly go either way. From the client's perspectiv=
e, it's supposed to be immediate. From the server's perspective, it could t=
ake a while to actually enforce that.

> 6. How does one find the policy, as this has an impact on #7
How does one find any other implementation specific policy? There was alrea=
dy a big discussion about this a while ago. It used to be a MUST to cascade=
, then as I recall, Google objected to it because their access tokens in th=
e wild can't be revoked at all, so revoking a refresh token revokes only th=
at token. The current language allows the server to decide what it has to d=
o.

> 7. There is a big difference here in enforcement, the client should=20
> not have to enforce this rule, the client may not know due to policy=20
> that revoking 1 token revokes other tokens thus the client would have=20
> to know the servers policy. This should be a SHOULD not MUST
You're conflating things here. If the client revokes the refresh token, the=
y must not use that refresh token again. They can try to use any access or =
other tokens if they want to, but that refresh token is off the table. The =
server is allowed to also nuke any access tokens that it wants to, but if t=
he client wants to be really, really sure, it can revoke all of its access =
tokens separately.

  -- Justin

> -----Original Message-----
> From: Justin Richer [mailto:jricher@mitre.org]
> Sent: Thursday, January 24, 2013 6:17 AM
> To: Anthony Nadalin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
> Not to jump in and answer for Torsten, but I thought I'd  offer at least =
my understanding of the document:
>
> On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
>> 1.       Since not stated I assume that the Revocation Endpoint can exis=
t on a different server from the Authorization server (or is it assumed tha=
t they are 1), if so how is the Revocation Endpoint found?
> It could be separate if your architecture can support that. It gets found=
 the same way other OAuth endpoints get found -- configuration documents, s=
ome kind of discovery mechanism, or magic. Which is to say, that's not curr=
ently OAuth's problem.
>
>> 2.       Any token type that is supported can be revoked, including refr=
esh token ?
> That's the idea. We've implemented this on our OIDC server so that you ca=
n also revoke ID Tokens for session management purposes.
>
>> 3.       Why does one have to send the token, can't this just be an auth=
_code ?
> You don't always use an auth code to get a token (think implicit, client =
credentials, assertion, or resource owner credentials flows), and auth code=
s are supposed to be thrown away after use anyway.
>
>> 4.       Says CORS SHOULD be supported, I think a MAY be better here sin=
ce a site may have issues supporting CORS
> If they have issues, which is to say "A good reason not to", then they do=
n't have to support it. That's the semantics behind "SHOULD", and so it is =
fine here.
>
>> 5.       Does not say but is the revocation to be immediate upon the ret=
urn of the request ?
> This is implementation dependent. Large scale distributed implementations=
 could have trouble making this "immediate", but small systems are more lik=
ely to be quick. From the client's perspective, if they get back a success =
response, they shouldn't count on that token being good anymore (see sectio=
n 2 note about client behavior).
>
>> 6.       Does the revocation of the access token also revoke the refresh=
 token (if it was provided) ? Or is this a revocation policy decision ?
> That's a policy decision.
>
>> 7.       Section 2 says "the client MUST NOT use this token again", well=
 that seems odd, not sure this should be here as the client could try to us=
e it gain, there is no need to put support in client to prevent this.
> Why would a client want to use a token that they just revoked? This is pr=
escribing the desired correct behavior to a client so that client developer=
s will do the right thing when they implement it. Isn't that the point of t=
he spec?
>
>    -- Justin
>
>
>





From jricher@mitre.org  Thu Jan 24 08:55:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFFD21F89C0 for ; Thu, 24 Jan 2013 08:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level: 
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwNviUkCT8yG for ; Thu, 24 Jan 2013 08:55:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E801721F89A4 for ; Thu, 24 Jan 2013 08:55:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6BE3A1F09B1; Thu, 24 Jan 2013 11:55:32 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 58C7F1F23E3; Thu, 24 Jan 2013 11:55:32 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 11:55:31 -0500
Message-ID: <5101676F.40006@mitre.org>
Date: Thu, 24 Jan 2013 11:55:11 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Anthony Nadalin 
References:  <5101425A.6080905@mitre.org> <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com> <51015D7D.3010600@mitre.org> <2d27b0f214104811a659c12336ce7865@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <2d27b0f214104811a659c12336ce7865@BY2PR03MB041.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------060304030003060108000002"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 16:55:35 -0000

--------------060304030003060108000002
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


> 1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.
Tony, I think you're misunderstanding what I'm saying. I completely 
agree that we should solve discovery and that we should use webfinger -- 
but this is a bigger problem than just revocation. Let's solve discovery 
for all of OAuth consistently. How would your rogue server "sign up" as 
it is? Get its URL into the documentation for a service? I think it's 
just as big of a problem for someone to say "hey I'm the token endpoint" 
and get clients to believe it, isn't it? And it's an even bigger 
problem, especially with bearer tokens, for someone to show up and say 
"I'm a protected resource!". Which is exactly why I say this needs to be 
solved for everything together, not just for revocation. Would you like 
to volunteer to draft a webfinger profile for all extant OAuth endpoints?

> 3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token
What you describe here is no longer token revocation, that's auth code 
revocation. That's a different operation and shouldn't be enabled by 
this endpoint. The auth code is supposed to eventually expire anyway, 
and that after a fairly short period of time. If you haven't gotten a 
token, you have to no token to revoke so you don't need to call the 
token revocation endpoint. If you just don't want to send your token, 
you just don't get to revoke it. What are you actually trying to 
accomplish by this added complexity?

In any case, it's impractical to implement. It's a big -- and novel -- 
burden for servers to keep around auth codes and tie them to the tokens 
that they represent anyway. I know our implementation doesn't track that 
link, and I doubt that many others do either. The auth codes are meant 
to be ephemeral.

> 5. That is just the point, how does one know that the token id revoked
The server will return if it's revoked the token. The effects of that 
revocation may take time to propagate to all PR's, so calling it 
"immediate" here could be misleading. As far as the client's concerned, 
it's immediate as soon as the server returns. This is why the client 
must throw the token out.

> 6. very poor choice, as no one know what is going on
> 7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy?
... no, you've got it backwards. Revoking an *access token* doesn't 
revoke the *refresh token* (that wouldn't make much sense), but revoking 
a *refresh token* SHOULD revoke all *associated access tokens*. That's 
the what the implementor's note (section 3) says. As far as the client 
is concerned, that token is dead the moment it gets back a positive 
response from the revocation endpoint. The "this token" in that sentence 
above is the token that was sent in with the request, there's no 
guarantee of what happens with "related" tokens. However, it's a good 
idea for the server to also throw out active access tokens associated 
with a refresh token, thus the implementor's note.

Sure, the token could be good for another week, but the client won't 
care because it's thrown things out. It's not the client's problem 
anymore. An immediacy requirement at the server is unimplementable in 
distributed systems. Any related tokens that happened to be revoked that 
the client tries to use (such as an access token tied to a refresh token 
that the client just revoked) might fail if the client uses them again.

But the thing is, failed token requests aren't a big deal, because you 
just start doing OAuth again. The code path is very simple and 
straightforward and is exactly the same whether or not you're using the 
revocation endpoint.

  -- Justin

>
> -----Original Message-----
> From: Justin Richer [mailto:jricher@mitre.org]
> Sent: Thursday, January 24, 2013 8:13 AM
> To: Anthony Nadalin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
>
> On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
>> 1. we keep punting on discovery, this has an impact on security of
>> where I send my credentials and token, can't see punting yet again
>> here
> It doesn't make any sense to solve discovery *just* for revocation, which you seem to be advocating. Of course it has an impact on security
> -- this is a security protocol we're talking about, that goes without saying. It also impacts security where I send the user for authorization, and everything else that you do.
>
> I would rather see discovery solved properly for all of OAuth including all of its endpoints. UMA has taken a crack at this, there's a draft defining XRD link types, OIDC has a solution for this as well (in the provider configuration .well-known doc).
>
>> 2. OK, make this explicit in specification
> Fair enough. Got specific language to suggest?
>
>> 3. if you have an auth_code you should be able to use it, agree not
>> all will have it but some will
> You shouldn't have an auth code anymore -- you're supposed to throw it away since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the token? You're guaranteed to have the token in all cases. I see no value in sometimes sending an auth code and sometimes sending a token when I am guaranteed to always have the token.
>
>> 4. MAY seems a better choice
> Possibly -- I think SHOULD is fine here but I'm curious what others say.
>
>> 5. Make it explicit in the spec one way or the other, too vague now
> Explicit how? It can explicitly go either way. From the client's perspective, it's supposed to be immediate. From the server's perspective, it could take a while to actually enforce that.
>
>> 6. How does one find the policy, as this has an impact on #7
> How does one find any other implementation specific policy? There was already a big discussion about this a while ago. It used to be a MUST to cascade, then as I recall, Google objected to it because their access tokens in the wild can't be revoked at all, so revoking a refresh token revokes only that token. The current language allows the server to decide what it has to do.
>
>> 7. There is a big difference here in enforcement, the client should
>> not have to enforce this rule, the client may not know due to policy
>> that revoking 1 token revokes other tokens thus the client would have
>> to know the servers policy. This should be a SHOULD not MUST
> You're conflating things here. If the client revokes the refresh token, they must not use that refresh token again. They can try to use any access or other tokens if they want to, but that refresh token is off the table. The server is allowed to also nuke any access tokens that it wants to, but if the client wants to be really, really sure, it can revoke all of its access tokens separately.
>
>    -- Justin
>
>> -----Original Message-----
>> From: Justin Richer [mailto:jricher@mitre.org]
>> Sent: Thursday, January 24, 2013 6:17 AM
>> To: Anthony Nadalin
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>>
>> Not to jump in and answer for Torsten, but I thought I'd  offer at least my understanding of the document:
>>
>> On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
>>> 1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?
>> It could be separate if your architecture can support that. It gets found the same way other OAuth endpoints get found -- configuration documents, some kind of discovery mechanism, or magic. Which is to say, that's not currently OAuth's problem.
>>
>>> 2.       Any token type that is supported can be revoked, including refresh token ?
>> That's the idea. We've implemented this on our OIDC server so that you can also revoke ID Tokens for session management purposes.
>>
>>> 3.       Why does one have to send the token, can't this just be an auth_code ?
>> You don't always use an auth code to get a token (think implicit, client credentials, assertion, or resource owner credentials flows), and auth codes are supposed to be thrown away after use anyway.
>>
>>> 4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
>> If they have issues, which is to say "A good reason not to", then they don't have to support it. That's the semantics behind "SHOULD", and so it is fine here.
>>
>>> 5.       Does not say but is the revocation to be immediate upon the return of the request ?
>> This is implementation dependent. Large scale distributed implementations could have trouble making this "immediate", but small systems are more likely to be quick. From the client's perspective, if they get back a success response, they shouldn't count on that token being good anymore (see section 2 note about client behavior).
>>
>>> 6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
>> That's a policy decision.
>>
>>> 7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.
>> Why would a client want to use a token that they just revoked? This is prescribing the desired correct behavior to a client so that client developers will do the right thing when they implement it. Isn't that the point of the spec?
>>
>>     -- Justin
>>
>>
>>
>
>
>


--------------060304030003060108000002
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

      
1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.

    

    Tony, I think you're misunderstanding what I'm saying. I completely
    agree that we should solve discovery and that we should use
    webfinger -- but this is a bigger problem than just revocation.
    Let's solve discovery for all of OAuth consistently. How would your
    rogue server "sign up" as it is? Get its URL into the documentation
    for a service? I think it's just as big of a problem for someone to
    say "hey I'm the token endpoint" and get clients to believe it,
    isn't it? And it's an even bigger problem, especially with bearer
    tokens, for someone to show up and say "I'm a protected resource!".
    Which is exactly why I say this needs to be solved for everything
    together, not just for revocation. Would you like to volunteer to
    draft a webfinger profile for all extant OAuth endpoints?

    

    

      
3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token

    

    What you describe here is no longer token revocation, that's auth
    code revocation. That's a different operation and shouldn't be
    enabled by this endpoint. The auth code is supposed to eventually
    expire anyway, and that after a fairly short period of time. If you
    haven't gotten a token, you have to no token to revoke so you don't
    need to call the token revocation endpoint. If you just don't want
    to send your token, you just don't get to revoke it. What are you
    actually trying to accomplish by this added complexity?

    

    In any case, it's impractical to implement. It's a big -- and novel
    -- burden for servers to keep around auth codes and tie them to the
    tokens that they represent anyway. I know our implementation doesn't
    track that link, and I doubt that many others do either. The auth
    codes are meant to be ephemeral.

    

    

      
5. That is just the point, how does one know that the token id revoked

    

    The server will return if it's revoked the token. The effects of
    that revocation may take time to propagate to all PR's, so calling
    it "immediate" here could be misleading. As far as the client's
    concerned, it's immediate as soon as the server returns. This is why
    the client must throw the token out. 

    

    

      
6. very poor choice, as no one know what is going on

    

    

      
7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy? 

    

    ... no, you've got it backwards. Revoking an access token
    doesn't revoke the refresh token (that wouldn't make much
    sense), but revoking a refresh token SHOULD revoke all associated
      access tokens. That's the what the implementor's note (section
    3) says. As far as the client is concerned, that token is dead the
    moment it gets back a positive response from the revocation
    endpoint. The "this token" in that sentence above is the token that
    was sent in with the request, there's no guarantee of what happens
    with "related" tokens. However, it's a good idea for the server to
    also throw out active access tokens associated with a refresh token,
    thus the implementor's note.

    

    Sure, the token could be good for another week, but the client won't
    care because it's thrown things out. It's not the client's problem
    anymore. An immediacy requirement at the server is unimplementable
    in distributed systems. Any related tokens that happened to be
    revoked that the client tries to use (such as an access token tied
    to a refresh token that the client just revoked) might fail if the
    client uses them again. 

    

    But the thing is, failed token requests aren't a big deal, because
    you just start doing OAuth again. The code path is very simple and
    straightforward and is exactly the same whether or not you're using
    the revocation endpoint.

    

     -- Justin

    

    

      

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review


On 01/24/2013 10:58 AM, Anthony Nadalin wrote:


      

        
1. we keep punting on discovery, this has an impact on security of 
where I send my credentials and token, can't see punting yet again 
here


      

      
It doesn't make any sense to solve discovery *just* for revocation, which you seem to be advocating. Of course it has an impact on security
-- this is a security protocol we're talking about, that goes without saying. It also impacts security where I send the user for authorization, and everything else that you do.

I would rather see discovery solved properly for all of OAuth including all of its endpoints. UMA has taken a crack at this, there's a draft defining XRD link types, OIDC has a solution for this as well (in the provider configuration .well-known doc).



      

        
2. OK, make this explicit in specification


      

      
Fair enough. Got specific language to suggest?



      

        
3. if you have an auth_code you should be able to use it, agree not 
all will have it but some will


      

      
You shouldn't have an auth code anymore -- you're supposed to throw it away since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the token? You're guaranteed to have the token in all cases. I see no value in sometimes sending an auth code and sometimes sending a token when I am guaranteed to always have the token.



      

        
4. MAY seems a better choice


      

      
Possibly -- I think SHOULD is fine here but I'm curious what others say.



      

        
5. Make it explicit in the spec one way or the other, too vague now


      

      
Explicit how? It can explicitly go either way. From the client's perspective, it's supposed to be immediate. From the server's perspective, it could take a while to actually enforce that.



      

        
6. How does one find the policy, as this has an impact on #7


      

      
How does one find any other implementation specific policy? There was already a big discussion about this a while ago. It used to be a MUST to cascade, then as I recall, Google objected to it because their access tokens in the wild can't be revoked at all, so revoking a refresh token revokes only that token. The current language allows the server to decide what it has to do.



      

        
7. There is a big difference here in enforcement, the client should 
not have to enforce this rule, the client may not know due to policy 
that revoking 1 token revokes other tokens thus the client would have 
to know the servers policy. This should be a SHOULD not MUST


      

      
You're conflating things here. If the client revokes the refresh token, they must not use that refresh token again. They can try to use any access or other tokens if they want to, but that refresh token is off the table. The server is allowed to also nuke any access tokens that it wants to, but if the client wants to be really, really sure, it can revoke all of its access tokens separately.

  -- Justin



      

        
-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

Not to jump in and answer for Torsten, but I thought I'd  offer at least my understanding of the document:

On 01/23/2013 06:54 PM, Anthony Nadalin wrote:


        

          
1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?


        

        
It could be separate if your architecture can support that. It gets found the same way other OAuth endpoints get found -- configuration documents, some kind of discovery mechanism, or magic. Which is to say, that's not currently OAuth's problem.



        

          
2.       Any token type that is supported can be revoked, including refresh token ?


        

        
That's the idea. We've implemented this on our OIDC server so that you can also revoke ID Tokens for session management purposes.



        

          
3.       Why does one have to send the token, can't this just be an auth_code ?


        

        
You don't always use an auth code to get a token (think implicit, client credentials, assertion, or resource owner credentials flows), and auth codes are supposed to be thrown away after use anyway.



        

          
4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS


        

        
If they have issues, which is to say "A good reason not to", then they don't have to support it. That's the semantics behind "SHOULD", and so it is fine here.



        

          
5.       Does not say but is the revocation to be immediate upon the return of the request ?


        

        
This is implementation dependent. Large scale distributed implementations could have trouble making this "immediate", but small systems are more likely to be quick. From the client's perspective, if they get back a success response, they shouldn't count on that token being good anymore (see section 2 note about client behavior).



        

          
6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?


        

        
That's a policy decision.



        

          
7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.


        

        
Why would a client want to use a token that they just revoked? This is prescribing the desired correct behavior to a client so that client developers will do the right thing when they implement it. Isn't that the point of the spec?

   -- Justin





      

      





    

    

  


--------------060304030003060108000002--

From tonynad@microsoft.com  Thu Jan 24 09:21:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7C421F8706 for ; Thu, 24 Jan 2013 09:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=-0.001,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBRm0HjfdCXl for ; Thu, 24 Jan 2013 09:21:30 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id AEB9321F86D9 for ; Thu, 24 Jan 2013 09:21:24 -0800 (PST)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.202) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 24 Jan 2013 17:21:15 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 24 Jan 2013 17:21:15 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 24 Jan 2013 17:20:38 +0000
Received: from mail63-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 24 Jan 2013 17:17:12 +0000
Received: from mail63-va3 (localhost [127.0.0.1])	by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 9631C4A011F	for ; Thu, 24 Jan 2013 17:17:12 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -20
X-BigFish: PS-20(zzbb2dI98dI9371Id6eahc85fh146fI542Izz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h9a9j1155h)
Received-SPF: softfail (mail63-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB044; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1359047829445618_2153; Thu, 24 Jan 2013 17:17:09 +0000 (UTC)
Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.237])	by mail63-va3.bigfish.com (Postfix) with ESMTP id 5A03730059B; Thu, 24 Jan 2013 17:17:09 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 24 Jan 2013 17:17:07 +0000
Received: from BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.257.4; Thu, 24 Jan 2013 17:17:06 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) with Microsoft SMTP Server (TLS) id 15.0.601.3; Thu, 24 Jan 2013 17:17:04 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.9.209]) with mapi id 15.00.0601.000; Thu, 24 Jan 2013 17:16:52 +0000
From: Anthony Nadalin 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQAB4kyAAAA1FVAAAAudqAAAAhbLAAAVn2gAAAe9Ow
Date: Thu, 24 Jan 2013 17:16:51 +0000
Message-ID: <5c414d08c1ac4db3aaf2b8eee9adc1c6@BY2PR03MB041.namprd03.prod.outlook.com>
References:  <5101425A.6080905@mitre.org> <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com> <51015D7D.3010600@mitre.org> <2d27b0f214104811a659c12336ce7865@BY2PR03MB041.namprd03.prod.outlook.com> <5101676F.40006@mitre.org>
In-Reply-To: <5101676F.40006@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.168]
Content-Type: multipart/alternative; boundary="_000_5c414d08c1ac4db3aaf2b8eee9adc1c6BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB044.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(479174001)(199002)(189002)(24454001)(13464002)(52314002)(56776001)(31966008)(76482001)(44976002)(63696002)(59766001)(56816002)(74502001)(5343655001)(15202345001)(512954001)(33646001)(54356001)(74662001)(47446002)(53806001)(4396001)(5343635001)(49866001)(54316002)(550184003)(6806001)(47736001)(16236675001)(47976001)(51856001)(79102001)(50986001)(77982001)(46102001)(16676001)(455564002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 073631BD3D
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 17:21:38 -0000

--_000_5c414d08c1ac4db3aaf2b8eee9adc1c6BY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Basically the spec has a lot of underspecified behaviors which will lead to=
 issues, in security and in expectations of the client.

3. no, as I can't do anything with an auth_code except get a access_token
5. The client does not know what to throw out as it does not know the serve=
r's policy
7." no, you've got it backwards. Revoking an access token doesn't revoke th=
e refresh token (that wouldn't make much sense), but revoking a refresh tok=
en SHOULD revoke all associated access tokens."  Don't agree, the specifica=
tion is not clear, currently it's a policy choice in the specification  and=
 thus the issues that this creates. Basically revocation is not well define=
d in this specification which leads to many issues

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Thursday, January 24, 2013 8:55 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review




1. We have WebFinger lets use that as we have already been through the disc=
overy issues, point being there are security issues at stake here w/o prope=
r knowledge, next thing we know some rouge sever has signed up as a revocat=
ion sever.
Tony, I think you're misunderstanding what I'm saying. I completely agree t=
hat we should solve discovery and that we should use webfinger -- but this =
is a bigger problem than just revocation. Let's solve discovery for all of =
OAuth consistently. How would your rogue server "sign up" as it is? Get its=
 URL into the documentation for a service? I think it's just as big of a pr=
oblem for someone to say "hey I'm the token endpoint" and get clients to be=
lieve it, isn't it? And it's an even bigger problem, especially with bearer=
 tokens, for someone to show up and say "I'm a protected resource!". Which =
is exactly why I say this needs to be solved for everything together, not j=
ust for revocation. Would you like to volunteer to draft a webfinger profil=
e for all extant OAuth endpoints?



3. you can still have one if you have not used it and want to revoke it, I =
may not want to redeem the auth_code to get a token to revoke it, I may jus=
t not want to send the token
What you describe here is no longer token revocation, that's auth code revo=
cation. That's a different operation and shouldn't be enabled by this endpo=
int. The auth code is supposed to eventually expire anyway, and that after =
a fairly short period of time. If you haven't gotten a token, you have to n=
o token to revoke so you don't need to call the token revocation endpoint. =
If you just don't want to send your token, you just don't get to revoke it.=
 What are you actually trying to accomplish by this added complexity?

In any case, it's impractical to implement. It's a big -- and novel -- burd=
en for servers to keep around auth codes and tie them to the tokens that th=
ey represent anyway. I know our implementation doesn't track that link, and=
 I doubt that many others do either. The auth codes are meant to be ephemer=
al.



5. That is just the point, how does one know that the token id revoked
The server will return if it's revoked the token. The effects of that revoc=
ation may take time to propagate to all PR's, so calling it "immediate" her=
e could be misleading. As far as the client's concerned, it's immediate as =
soon as the server returns. This is why the client must throw the token out=
.





6. very poor choice, as no one know what is going on

7. No I'm not conflating things here at all, please read the text. If I sen=
d a access_token and the server's policy says that the refresh_token associ=
ated with the access_token is also to be revoked then I have no way to know=
 that "The client MUST NOT use this token again after revocation". What is =
"this" mean in the sentence, only the token I sent or any revoked token. Al=
so how do I know when the token is actually revoked, could take a week or m=
ore given policy?
... no, you've got it backwards. Revoking an access token doesn't revoke th=
e refresh token (that wouldn't make much sense), but revoking a refresh tok=
en SHOULD revoke all associated access tokens. That's the what the implemen=
tor's note (section 3) says. As far as the client is concerned, that token =
is dead the moment it gets back a positive response from the revocation end=
point. The "this token" in that sentence above is the token that was sent i=
n with the request, there's no guarantee of what happens with "related" tok=
ens. However, it's a good idea for the server to also throw out active acce=
ss tokens associated with a refresh token, thus the implementor's note.

Sure, the token could be good for another week, but the client won't care b=
ecause it's thrown things out. It's not the client's problem anymore. An im=
mediacy requirement at the server is unimplementable in distributed systems=
. Any related tokens that happened to be revoked that the client tries to u=
se (such as an access token tied to a refresh token that the client just re=
voked) might fail if the client uses them again.

But the thing is, failed token requests aren't a big deal, because you just=
 start doing OAuth again. The code path is very simple and straightforward =
and is exactly the same whether or not you're using the revocation endpoint=
.

 -- Justin







-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Thursday, January 24, 2013 8:13 AM

To: Anthony Nadalin

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review





On 01/24/2013 10:58 AM, Anthony Nadalin wrote:

1. we keep punting on discovery, this has an impact on security of

where I send my credentials and token, can't see punting yet again

here

It doesn't make any sense to solve discovery *just* for revocation, which y=
ou seem to be advocating. Of course it has an impact on security

-- this is a security protocol we're talking about, that goes without sayin=
g. It also impacts security where I send the user for authorization, and ev=
erything else that you do.



I would rather see discovery solved properly for all of OAuth including all=
 of its endpoints. UMA has taken a crack at this, there's a draft defining =
XRD link types, OIDC has a solution for this as well (in the provider confi=
guration .well-known doc).



2. OK, make this explicit in specification

Fair enough. Got specific language to suggest?



3. if you have an auth_code you should be able to use it, agree not

all will have it but some will

You shouldn't have an auth code anymore -- you're supposed to throw it away=
 since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the=
 token? You're guaranteed to have the token in all cases. I see no value in=
 sometimes sending an auth code and sometimes sending a token when I am gua=
ranteed to always have the token.



4. MAY seems a better choice

Possibly -- I think SHOULD is fine here but I'm curious what others say.



5. Make it explicit in the spec one way or the other, too vague now

Explicit how? It can explicitly go either way. From the client's perspectiv=
e, it's supposed to be immediate. From the server's perspective, it could t=
ake a while to actually enforce that.



6. How does one find the policy, as this has an impact on #7

How does one find any other implementation specific policy? There was alrea=
dy a big discussion about this a while ago. It used to be a MUST to cascade=
, then as I recall, Google objected to it because their access tokens in th=
e wild can't be revoked at all, so revoking a refresh token revokes only th=
at token. The current language allows the server to decide what it has to d=
o.



7. There is a big difference here in enforcement, the client should

not have to enforce this rule, the client may not know due to policy

that revoking 1 token revokes other tokens thus the client would have

to know the servers policy. This should be a SHOULD not MUST

You're conflating things here. If the client revokes the refresh token, the=
y must not use that refresh token again. They can try to use any access or =
other tokens if they want to, but that refresh token is off the table. The =
server is allowed to also nuke any access tokens that it wants to, but if t=
he client wants to be really, really sure, it can revoke all of its access =
tokens separately.



  -- Justin



-----Original Message-----

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Thursday, January 24, 2013 6:17 AM

To: Anthony Nadalin

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review



Not to jump in and answer for Torsten, but I thought I'd  offer at least my=
 understanding of the document:



On 01/23/2013 06:54 PM, Anthony Nadalin wrote:

1.       Since not stated I assume that the Revocation Endpoint can exist o=
n a different server from the Authorization server (or is it assumed that t=
hey are 1), if so how is the Revocation Endpoint found?

It could be separate if your architecture can support that. It gets found t=
he same way other OAuth endpoints get found -- configuration documents, som=
e kind of discovery mechanism, or magic. Which is to say, that's not curren=
tly OAuth's problem.



2.       Any token type that is supported can be revoked, including refresh=
 token ?

That's the idea. We've implemented this on our OIDC server so that you can =
also revoke ID Tokens for session management purposes.



3.       Why does one have to send the token, can't this just be an auth_co=
de ?

You don't always use an auth code to get a token (think implicit, client cr=
edentials, assertion, or resource owner credentials flows), and auth codes =
are supposed to be thrown away after use anyway.



4.       Says CORS SHOULD be supported, I think a MAY be better here since =
a site may have issues supporting CORS

If they have issues, which is to say "A good reason not to", then they don'=
t have to support it. That's the semantics behind "SHOULD", and so it is fi=
ne here.



5.       Does not say but is the revocation to be immediate upon the return=
 of the request ?

This is implementation dependent. Large scale distributed implementations c=
ould have trouble making this "immediate", but small systems are more likel=
y to be quick. From the client's perspective, if they get back a success re=
sponse, they shouldn't count on that token being good anymore (see section =
2 note about client behavior).



6.       Does the revocation of the access token also revoke the refresh to=
ken (if it was provided) ? Or is this a revocation policy decision ?

That's a policy decision.



7.       Section 2 says "the client MUST NOT use this token again", well th=
at seems odd, not sure this should be here as the client could try to use i=
t gain, there is no need to put support in client to prevent this.

Why would a client want to use a token that they just revoked? This is pres=
cribing the desired correct behavior to a client so that client developers =
will do the right thing when they implement it. Isn't that the point of the=
 spec?



   -- Justin
















--_000_5c414d08c1ac4db3aaf2b8eee9adc1c6BY2PR03MB041namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Basically the spec has a =
lot of underspecified behaviors which will lead to issues, in security and =
in expectations of the client.


 <=
/p>

3. no, as I can’t d=
o anything with an auth_code except get a access_token

5. The client does not kn=
ow what to throw out as it does not know the server’s policy


7.”
no, you've got it backwards. Revoking an access token doesn't=
 revoke the
refresh token (that wouldn't make much sense), but revoking a ref=
resh token SHOULD revoke all
associated access tokens.”  Don’t agree, the specif=
ication is not clear, currently it’s a policy choice in the specifica=
tion  and thus the issues that this creates. Basically revocation is n=
ot well defined in this specification which leads to many issues



 






From: Justin Richer [mailto:jricher@mitre.org]


Sent: Thursday, January 24, 2013 8:55 AM

To: Anthony Nadalin

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review






 











1. We have WebFinger lets use that as we have already been through the=
 discovery issues, point being there are security issues at stake here w/o =
proper knowledge, next thing we know some rouge sever has signed up as a re=
vocation sever.




Tony, I think you're misunderstanding what I'm sayin=
g. I completely agree that we should solve discovery and that we should use=
 webfinger -- but this is a bigger problem than just revocation. Let's solv=
e discovery for all of OAuth consistently.
 How would your rogue server "sign up" as it is? Get its URL into=
 the documentation for a service? I think it's just as big of a problem for=
 someone to say "hey I'm the token endpoint" and get clients to b=
elieve it, isn't it? And it's an even bigger problem,
 especially with bearer tokens, for someone to show up and say "I'm a =
protected resource!". Which is exactly why I say this needs to be solv=
ed for everything together, not just for revocation. Would you like to volu=
nteer to draft a webfinger profile for all
 extant OAuth endpoints?










3. you can still have one if you have not used it and want to revoke i=
t, I may not want to redeem the auth_code to get a token to revoke it, I ma=
y just not want to send the token




What you describe here is no longer token revocation=
, that's auth code revocation. That's a different operation and shouldn't b=
e enabled by this endpoint. The auth code is supposed to eventually expire =
anyway, and that after a fairly short
 period of time. If you haven't gotten a token, you have to no token to rev=
oke so you don't need to call the token revocation endpoint. If you just do=
n't want to send your token, you just don't get to revoke it. What are you =
actually trying to accomplish by
 this added complexity?



In any case, it's impractical to implement. It's a big -- and novel -- burd=
en for servers to keep around auth codes and tie them to the tokens that th=
ey represent anyway. I know our implementation doesn't track that link, and=
 I doubt that many others do either.
 The auth codes are meant to be ephemeral.










5. That is just the point, how does one know that the token id revoked=





The server will return if it's revoked the token. Th=
e effects of that revocation may take time to propagate to all PR's, so cal=
ling it "immediate" here could be misleading. As far as the clien=
t's concerned, it's immediate as soon as the
 server returns. This is why the client must throw the token out. 










 


6. very poor choice, as no one know what is going on






7. No I'm not conflating things here at all, please read the text. If =
I send a access_token and the server's policy says that the refresh_token a=
ssociated with the access_token is also to be revoked then I have no way to=
 know that "The client MUST NOT use this token again after revocation&=
quot;. What is "this" mean in the sentence, only the token I sent=
 or any revoked token. Also how do I know when the token is actually revoke=
d, could take a week or more given policy? 




... no, you've got it backwards. Revoking an acce=
ss token doesn't revoke the
refresh token (that wouldn't make much sense), but revoking a ref=
resh token SHOULD revoke all
associated access tokens. That's the what the implementor's note (se=
ction 3) says. As far as the client is concerned, that token is dead the mo=
ment it gets back a positive response from the revocation endpoint. The &qu=
ot;this token" in that sentence above
 is the token that was sent in with the request, there's no guarantee of wh=
at happens with "related" tokens. However, it's a good idea for t=
he server to also throw out active access tokens associated with a refresh =
token, thus the implementor's note.



Sure, the token could be good for another week, but the client won't care b=
ecause it's thrown things out. It's not the client's problem anymore. An im=
mediacy requirement at the server is unimplementable in distributed systems=
. Any related tokens that happened
 to be revoked that the client tries to use (such as an access token tied t=
o a refresh token that the client just revoked) might fail if the client us=
es them again.




But the thing is, failed token requests aren't a big deal, because you just=
 start doing OAuth again. The code path is very simple and straightforward =
and is exactly the same whether or not you're using the revocation endpoint=
.



 -- Justin










 


 


-----Original Message-----


From: Justin Richer [mailto:jrich=
er@mitre.org] 


Sent: Thursday, January 24, 2013 8:13 AM


To: Anthony Nadalin


Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review


 


 


On 01/24/2013 10:58 AM, Anthony Nadalin wrote:




1. we keep punting on discovery, this has an impact on security of 


where I send my credentials and token, can't see punting yet again 


here




It doesn't make any sense to solve discovery *just* for revocation, wh=
ich you seem to be advocating. Of course it has an impact on security<=
/o:p>


-- this is a security protocol we're talking about, that goes without =
saying. It also impacts security where I send the user for authorization, a=
nd everything else that you do.


 


I would rather see discovery solved properly for all of OAuth includin=
g all of its endpoints. UMA has taken a crack at this, there's a draft defi=
ning XRD link types, OIDC has a solution for this as well (in the provider =
configuration .well-known doc).


 




2. OK, make this explicit in specification




Fair enough. Got specific language to suggest?


 




3. if you have an auth_code you should be able to use it, agree not 


all will have it but some will




You shouldn't have an auth code anymore -- you're supposed to throw it=
 away since it's single use (per 10.5 of RFC6749). Why wouldn't you just us=
e the token? You're guaranteed to have the token in all cases. I see no val=
ue in sometimes sending an auth code and sometimes sending a token when I a=
m guaranteed to always have the token.


 




4. MAY seems a better choice




Possibly -- I think SHOULD is fine here but I'm curious what others sa=
y.


 




5. Make it explicit in the spec one way or the other, too vague now




Explicit how? It can explicitly go either way. From the client's persp=
ective, it's supposed to be immediate. From the server's perspective, it co=
uld take a while to actually enforce that.


 




6. How does one find the policy, as this has an impact on #7




How does one find any other implementation specific policy? There was =
already a big discussion about this a while ago. It used to be a MUST to ca=
scade, then as I recall, Google objected to it because their access tokens =
in the wild can't be revoked at all, so revoking a refresh token revokes on=
ly that token. The current language allows the server to decide what it has=
 to do.


 




7. There is a big difference here in enforcement, the client should 


not have to enforce this rule, the client may not know due to policy <=
o:p>


that revoking 1 token revokes other tokens thus the client would have =



to know the servers policy. This should be a SHOULD not MUST




You're conflating things here. If the client revokes the refresh token=
, they must not use that refresh token again. They can try to use any acces=
s or other tokens if they want to, but that refresh token is off the table.=
 The server is allowed to also nuke any access tokens that it wants to, but=
 if the client wants to be really, really sure, it can revoke all of its ac=
cess tokens separately.


 


  -- Justin


 




-----Original Message-----


From: Justin Richer [mailto:jrich=
er@mitre.org]


Sent: Thursday, January 24, 2013 6:17 AM


To: Anthony Nadalin


Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review


 


Not to jump in and answer for Torsten, but I thought I'd  offer a=
t least my understanding of the document:


 


On 01/23/2013 06:54 PM, Anthony Nadalin wrote:




1.       Since not stated I assume that =
the Revocation Endpoint can exist on a different server from the Authorizat=
ion server (or is it assumed that they are 1), if so how is the Revocation =
Endpoint found?




It could be separate if your architecture can support that. It gets fo=
und the same way other OAuth endpoints get found -- configuration documents=
, some kind of discovery mechanism, or magic. Which is to say, that's not c=
urrently OAuth's problem.


 




2.       Any token type that is supporte=
d can be revoked, including refresh token ?




That's the idea. We've implemented this on our OIDC server so that you=
 can also revoke ID Tokens for session management purposes.

 




3.       Why does one have to send the t=
oken, can't this just be an auth_code ?




You don't always use an auth code to get a token (think implicit, clie=
nt credentials, assertion, or resource owner credentials flows), and auth c=
odes are supposed to be thrown away after use anyway.


 




4.       Says CORS SHOULD be supported, =
I think a MAY be better here since a site may have issues supporting CORS




If they have issues, which is to say "A good reason not to",=
 then they don't have to support it. That's the semantics behind "SHOU=
LD", and so it is fine here.


 




5.       Does not say but is the revocat=
ion to be immediate upon the return of the request ?




This is implementation dependent. Large scale distributed implementati=
ons could have trouble making this "immediate", but small systems=
 are more likely to be quick. From the client's perspective, if they get ba=
ck a success response, they shouldn't count on that token being good anymor=
e (see section 2 note about client behavior).


 




6.       Does the revocation of the acce=
ss token also revoke the refresh token (if it was provided) ? Or is this a =
revocation policy decision ?




That's a policy decision.


 




7.       Section 2 says "the client=
 MUST NOT use this token again", well that seems odd, not sure this sh=
ould be here as the client could try to use it gain, there is no need to pu=
t support in client to prevent this.




Why would a client want to use a token that they just revoked? This is=
 prescribing the desired correct behavior to a client so that client develo=
pers will do the right thing when they implement it. Isn't that the point o=
f the spec?


 


   -- Justin


 


 


 




 


 


 


 




 






--_000_5c414d08c1ac4db3aaf2b8eee9adc1c6BY2PR03MB041namprd03pro_--

From jricher@mitre.org  Thu Jan 24 10:03:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53221F88EE for ; Thu, 24 Jan 2013 10:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.531
X-Spam-Level: 
X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9ryGcp7Q+Hp for ; Thu, 24 Jan 2013 10:03:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B921F8801 for ; Thu, 24 Jan 2013 10:03:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20A8A1F046B; Thu, 24 Jan 2013 13:03:17 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 065671F244F; Thu, 24 Jan 2013 13:03:17 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 24 Jan 2013 13:03:16 -0500
Message-ID: <51017750.4070009@mitre.org>
Date: Thu, 24 Jan 2013 13:02:56 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Anthony Nadalin 
References:  <5101425A.6080905@mitre.org> <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com> <51015D7D.3010600@mitre.org> <2d27b0f214104811a659c12336ce7865@BY2PR03MB041.namprd03.prod.outlook.com> <5101676F.40006@mitre.org> <5c414d08c1ac4db3aaf2b8eee9adc1c6@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <5c414d08c1ac4db3aaf2b8eee9adc1c6@BY2PR03MB041.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------060208010307050700030006"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jan 2013 18:03:30 -0000

--------------060208010307050700030006
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 01/24/2013 12:16 PM, Anthony Nadalin wrote:
>
> Basically the spec has a lot of underspecified behaviors which will 
> lead to issues, in security and in expectations of the client.
>
> 3. no, as I can't do anything with an auth_code except get a access_token
>
Right. Which is *exactly* how I'm suggesting it remain. Are you 
reversing your previous position of wanting to use the auth_code to 
revoke an access token?

> 5. The client does not know what to throw out as it does not know the 
> server's policy
>
Yes it does, it throws out the token that it sent to the revocation 
endpoint. It can throw out that token without calling the revocation 
endpoint if it wants.

> 7." no, you've got it backwards. Revoking an *access token* doesn't 
> revoke the *refresh token* (that wouldn't make much sense), but 
> revoking a *refresh token* SHOULD revoke all *associated access 
> tokens." *Don't agree, the specification is not clear, currently it's 
> a policy choice in the specification  and thus the issues that this 
> creates.
>
The text states:

    Depending on the authorization server's revocation policy, the
    revocation of a particular token may cause the revocation of related
    tokens and the underlying authorization. If the particular token is
    a refresh token and the authorization server supports the revocation
    of access tokens, then the authorization server SHOULD also
    invalidate all access tokens based on the same authorization (see
    Implementation Note
    ).


The cascade listed is refresh->access, not access->refresh. Note that it 
leaves the door open to other "related" tokens, such as OpenID Connect's 
ID Token, dynamic registration's Registration Access Token, or others. 
It's completely up to the server whether or not it wants to -- or even 
can -- cascade a delete operation. That's *all* that this is talking about.

Note that, as in regular old OAuth, tokens can be suddenly revoked with 
the client knowing about it at any time. The end user could revoke it, 
the AS could decide to recycle all tokens for a given client, the tokens 
could expire. This is by design. Any given token that a client might 
have might not work and clients MUST already be robust against this, 
without revocation coming into the picture. Revocation doesn't add any 
more mystery or bookkeeping.

> Basically revocation is not well defined in this specification which 
> leads to many issues
>

What issues specifically that haven't been addressed here?

  -- Justin

> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Thursday, January 24, 2013 8:55 AM
> *To:* Anthony Nadalin
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
>
>
>     1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.
>
> Tony, I think you're misunderstanding what I'm saying. I completely 
> agree that we should solve discovery and that we should use webfinger 
> -- but this is a bigger problem than just revocation. Let's solve 
> discovery for all of OAuth consistently. How would your rogue server 
> "sign up" as it is? Get its URL into the documentation for a service? 
> I think it's just as big of a problem for someone to say "hey I'm the 
> token endpoint" and get clients to believe it, isn't it? And it's an 
> even bigger problem, especially with bearer tokens, for someone to 
> show up and say "I'm a protected resource!". Which is exactly why I 
> say this needs to be solved for everything together, not just for 
> revocation. Would you like to volunteer to draft a webfinger profile 
> for all extant OAuth endpoints?
>
>
>     3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token
>
> What you describe here is no longer token revocation, that's auth code 
> revocation. That's a different operation and shouldn't be enabled by 
> this endpoint. The auth code is supposed to eventually expire anyway, 
> and that after a fairly short period of time. If you haven't gotten a 
> token, you have to no token to revoke so you don't need to call the 
> token revocation endpoint. If you just don't want to send your token, 
> you just don't get to revoke it. What are you actually trying to 
> accomplish by this added complexity?
>
> In any case, it's impractical to implement. It's a big -- and novel -- 
> burden for servers to keep around auth codes and tie them to the 
> tokens that they represent anyway. I know our implementation doesn't 
> track that link, and I doubt that many others do either. The auth 
> codes are meant to be ephemeral.
>
>
>     5. That is just the point, how does one know that the token id revoked
>
> The server will return if it's revoked the token. The effects of that 
> revocation may take time to propagate to all PR's, so calling it 
> "immediate" here could be misleading. As far as the client's 
> concerned, it's immediate as soon as the server returns. This is why 
> the client must throw the token out.
>
>
>       
>
>     6. very poor choice, as no one know what is going on
>
>     7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy?
>
> ... no, you've got it backwards. Revoking an *access token* doesn't 
> revoke the *refresh token* (that wouldn't make much sense), but 
> revoking a *refresh token* SHOULD revoke all *associated access 
> tokens*. That's the what the implementor's note (section 3) says. As 
> far as the client is concerned, that token is dead the moment it gets 
> back a positive response from the revocation endpoint. The "this 
> token" in that sentence above is the token that was sent in with the 
> request, there's no guarantee of what happens with "related" tokens. 
> However, it's a good idea for the server to also throw out active 
> access tokens associated with a refresh token, thus the implementor's 
> note.
>
> Sure, the token could be good for another week, but the client won't 
> care because it's thrown things out. It's not the client's problem 
> anymore. An immediacy requirement at the server is unimplementable in 
> distributed systems. Any related tokens that happened to be revoked 
> that the client tries to use (such as an access token tied to a 
> refresh token that the client just revoked) might fail if the client 
> uses them again.
>
> But the thing is, failed token requests aren't a big deal, because you 
> just start doing OAuth again. The code path is very simple and 
> straightforward and is exactly the same whether or not you're using 
> the revocation endpoint.
>
>  -- Justin
>
>
>       
>
>       
>
>     -----Original Message-----
>
>     From: Justin Richer [mailto:jricher@mitre.org]
>
>     Sent: Thursday, January 24, 2013 8:13 AM
>
>     To: Anthony Nadalin
>
>     Cc:oauth@ietf.org  
>
>     Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
>       
>
>       
>
>     On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
>
>         1. we keep punting on discovery, this has an impact on security of
>
>         where I send my credentials and token, can't see punting yet again
>
>         here
>
>     It doesn't make any sense to solve discovery *just* for revocation, which you seem to be advocating. Of course it has an impact on security
>
>     -- this is a security protocol we're talking about, that goes without saying. It also impacts security where I send the user for authorization, and everything else that you do.
>
>       
>
>     I would rather see discovery solved properly for all of OAuth including all of its endpoints. UMA has taken a crack at this, there's a draft defining XRD link types, OIDC has a solution for this as well (in the provider configuration .well-known doc).
>
>       
>
>         2. OK, make this explicit in specification
>
>     Fair enough. Got specific language to suggest?
>
>       
>
>         3. if you have an auth_code you should be able to use it, agree not
>
>         all will have it but some will
>
>     You shouldn't have an auth code anymore -- you're supposed to throw it away since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the token? You're guaranteed to have the token in all cases. I see no value in sometimes sending an auth code and sometimes sending a token when I am guaranteed to always have the token.
>
>       
>
>         4. MAY seems a better choice
>
>     Possibly -- I think SHOULD is fine here but I'm curious what others say.
>
>       
>
>         5. Make it explicit in the spec one way or the other, too vague now
>
>     Explicit how? It can explicitly go either way. From the client's perspective, it's supposed to be immediate. From the server's perspective, it could take a while to actually enforce that.
>
>       
>
>         6. How does one find the policy, as this has an impact on #7
>
>     How does one find any other implementation specific policy? There was already a big discussion about this a while ago. It used to be a MUST to cascade, then as I recall, Google objected to it because their access tokens in the wild can't be revoked at all, so revoking a refresh token revokes only that token. The current language allows the server to decide what it has to do.
>
>       
>
>         7. There is a big difference here in enforcement, the client should
>
>         not have to enforce this rule, the client may not know due to policy
>
>         that revoking 1 token revokes other tokens thus the client would have
>
>         to know the servers policy. This should be a SHOULD not MUST
>
>     You're conflating things here. If the client revokes the refresh token, they must not use that refresh token again. They can try to use any access or other tokens if they want to, but that refresh token is off the table. The server is allowed to also nuke any access tokens that it wants to, but if the client wants to be really, really sure, it can revoke all of its access tokens separately.
>
>       
>
>        -- Justin
>
>       
>
>         -----Original Message-----
>
>         From: Justin Richer [mailto:jricher@mitre.org]
>
>         Sent: Thursday, January 24, 2013 6:17 AM
>
>         To: Anthony Nadalin
>
>         Cc:oauth@ietf.org  
>
>         Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
>           
>
>         Not to jump in and answer for Torsten, but I thought I'd  offer at least my understanding of the document:
>
>           
>
>         On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
>
>             1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?
>
>         It could be separate if your architecture can support that. It gets found the same way other OAuth endpoints get found -- configuration documents, some kind of discovery mechanism, or magic. Which is to say, that's not currently OAuth's problem.
>
>           
>
>             2.       Any token type that is supported can be revoked, including refresh token ?
>
>         That's the idea. We've implemented this on our OIDC server so that you can also revoke ID Tokens for session management purposes.
>
>           
>
>             3.       Why does one have to send the token, can't this just be an auth_code ?
>
>         You don't always use an auth code to get a token (think implicit, client credentials, assertion, or resource owner credentials flows), and auth codes are supposed to be thrown away after use anyway.
>
>           
>
>             4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
>
>         If they have issues, which is to say "A good reason not to", then they don't have to support it. That's the semantics behind "SHOULD", and so it is fine here.
>
>           
>
>             5.       Does not say but is the revocation to be immediate upon the return of the request ?
>
>         This is implementation dependent. Large scale distributed implementations could have trouble making this "immediate", but small systems are more likely to be quick. From the client's perspective, if they get back a success response, they shouldn't count on that token being good anymore (see section 2 note about client behavior).
>
>           
>
>             6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
>
>         That's a policy decision.
>
>           
>
>             7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.
>
>         Why would a client want to use a token that they just revoked? This is prescribing the desired correct behavior to a client so that client developers will do the right thing when they implement it. Isn't that the point of the spec?
>
>           
>
>             -- Justin
>
>           
>
>           
>
>           
>
>       
>
>       
>
>       
>
>       
>


--------------060208010307050700030006
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 01/24/2013 12:16 PM, Anthony Nadalin
      wrote:

    

    

      
      
      
      

        
Basically
            the spec has a lot of underspecified behaviors which will
            lead to issues, in security and in expectations of the
            client.

        
 

        
3.
            no, as I can’t do anything with an auth_code except get a
            access_token

      

    

    Right. Which is exactly how I'm suggesting it remain. Are
    you reversing your previous position of wanting to use the auth_code
    to revoke an access token?

    

    

      

        

        
5.
            The client does not know what to throw out as it does not
            know the server’s policy

      

    

    Yes it does, it throws out the token that it sent to the revocation
    endpoint. It can throw out that token without calling the revocation
    endpoint if it wants.

    

    

      

        

        
7.”
          no, you've got it backwards. Revoking an access
            token doesn't revoke the
          refresh token (that wouldn't make much sense), but
          revoking a refresh token SHOULD revoke all
          associated access tokens.”  Don’t agree, the
          specification is not clear, currently it’s a policy choice in
          the specification  and thus the issues that this creates. 

      

    

    The text states:

    

    
Depending on the authorization server's revocation
      policy, the revocation of a particular token may cause the
      revocation of related tokens and the underlying authorization. If
      the particular token is a refresh token and the authorization
      server supports the revocation of access tokens, then the
      authorization server SHOULD also invalidate all access tokens
      based on the same authorization (see Implementation
        Note).

    

    

    The cascade listed is refresh->access, not access->refresh.
    Note that it leaves the door open to other "related" tokens, such as
    OpenID Connect's ID Token, dynamic registration's Registration
    Access Token, or others. It's completely up to the server whether or
    not it wants to -- or even can -- cascade a delete operation. That's
    *all* that this is talking about.

    

    Note that, as in regular old OAuth, tokens can be suddenly revoked
    with the client knowing about it at any time. The end user could
    revoke it, the AS could decide to recycle all tokens for a given
    client, the tokens could expire. This is by design. Any given token
    that a client might have might not work and clients MUST already be
    robust against this, without revocation coming into the picture.
    Revocation doesn't add any more mystery or bookkeeping.

    

    

      

        
Basically revocation is not well defined in
          this specification which leads to many issues
          

      

    

    

    What issues specifically that haven't been addressed here?

    

     -- Justin

    

    

      

        
 

        

          

            
From:
                Justin Richer [mailto:jricher@mitre.org]
                

                Sent: Thursday, January 24, 2013 8:55 AM

                To: Anthony Nadalin

                Cc: oauth@ietf.org

                Subject: Re: [OAUTH-WG]
                draft-ietf-oauth-revocation-04 Review

          

        

        
 

        


          

          

        

          
1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.

        

        
Tony, I think you're misunderstanding what
          I'm saying. I completely agree that we should solve discovery
          and that we should use webfinger -- but this is a bigger
          problem than just revocation. Let's solve discovery for all of
          OAuth consistently. How would your rogue server "sign up" as
          it is? Get its URL into the documentation for a service? I
          think it's just as big of a problem for someone to say "hey
          I'm the token endpoint" and get clients to believe it, isn't
          it? And it's an even bigger problem, especially with bearer
          tokens, for someone to show up and say "I'm a protected
          resource!". Which is exactly why I say this needs to be solved
          for everything together, not just for revocation. Would you
          like to volunteer to draft a webfinger profile for all extant
          OAuth endpoints?

          

          

          

        

          
3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token

        

        
What you describe here is no longer token
          revocation, that's auth code revocation. That's a different
          operation and shouldn't be enabled by this endpoint. The auth
          code is supposed to eventually expire anyway, and that after a
          fairly short period of time. If you haven't gotten a token,
          you have to no token to revoke so you don't need to call the
          token revocation endpoint. If you just don't want to send your
          token, you just don't get to revoke it. What are you actually
          trying to accomplish by this added complexity?

          

          In any case, it's impractical to implement. It's a big -- and
          novel -- burden for servers to keep around auth codes and tie
          them to the tokens that they represent anyway. I know our
          implementation doesn't track that link, and I doubt that many
          others do either. The auth codes are meant to be ephemeral.

          

          

          

        

          
5. That is just the point, how does one know that the token id revoked

        

        
The server will return if it's revoked the
          token. The effects of that revocation may take time to
          propagate to all PR's, so calling it "immediate" here could be
          misleading. As far as the client's concerned, it's immediate
          as soon as the server returns. This is why the client must
          throw the token out. 

          

          

          

        

          
 

          
6. very poor choice, as no one know what is going on

        

        

          
7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy? 

        

        
... no, you've got it backwards. Revoking
          an access token doesn't revoke the
          refresh token (that wouldn't make much sense), but
          revoking a refresh token SHOULD revoke all
          associated access tokens. That's the what the
          implementor's note (section 3) says. As far as the client is
          concerned, that token is dead the moment it gets back a
          positive response from the revocation endpoint. The "this
          token" in that sentence above is the token that was sent in
          with the request, there's no guarantee of what happens with
          "related" tokens. However, it's a good idea for the server to
          also throw out active access tokens associated with a refresh
          token, thus the implementor's note.

          

          Sure, the token could be good for another week, but the client
          won't care because it's thrown things out. It's not the
          client's problem anymore. An immediacy requirement at the
          server is unimplementable in distributed systems. Any related
          tokens that happened to be revoked that the client tries to
          use (such as an access token tied to a refresh token that the
          client just revoked) might fail if the client uses them again.
          

          

          But the thing is, failed token requests aren't a big deal,
          because you just start doing OAuth again. The code path is
          very simple and straightforward and is exactly the same
          whether or not you're using the revocation endpoint.

          

           -- Justin

          

          

          

        

          
 

          
 

          
-----Original Message-----

          
From: Justin Richer [mailto:jricher@mitre.org] 

          
Sent: Thursday, January 24, 2013 8:13 AM

          
To: Anthony Nadalin

          
Cc: oauth@ietf.org

          
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

          
 

          
 

          
On 01/24/2013 10:58 AM, Anthony Nadalin wrote:

          

            
1. we keep punting on discovery, this has an impact on security of 

            
where I send my credentials and token, can't see punting yet again 

            
here

          

          
It doesn't make any sense to solve discovery *just* for revocation, which you seem to be advocating. Of course it has an impact on security

          
-- this is a security protocol we're talking about, that goes without saying. It also impacts security where I send the user for authorization, and everything else that you do.

          
 

          
I would rather see discovery solved properly for all of OAuth including all of its endpoints. UMA has taken a crack at this, there's a draft defining XRD link types, OIDC has a solution for this as well (in the provider configuration .well-known doc).

          
 

          

            
2. OK, make this explicit in specification

          

          
Fair enough. Got specific language to suggest?

          
 

          

            
3. if you have an auth_code you should be able to use it, agree not 

            
all will have it but some will

          

          
You shouldn't have an auth code anymore -- you're supposed to throw it away since it's single use (per 10.5 of RFC6749). Why wouldn't you just use the token? You're guaranteed to have the token in all cases. I see no value in sometimes sending an auth code and sometimes sending a token when I am guaranteed to always have the token.

          
 

          

            
4. MAY seems a better choice

          

          
Possibly -- I think SHOULD is fine here but I'm curious what others say.

          
 

          

            
5. Make it explicit in the spec one way or the other, too vague now

          

          
Explicit how? It can explicitly go either way. From the client's perspective, it's supposed to be immediate. From the server's perspective, it could take a while to actually enforce that.

          
 

          

            
6. How does one find the policy, as this has an impact on #7

          

          
How does one find any other implementation specific policy? There was already a big discussion about this a while ago. It used to be a MUST to cascade, then as I recall, Google objected to it because their access tokens in the wild can't be revoked at all, so revoking a refresh token revokes only that token. The current language allows the server to decide what it has to do.

          
 

          

            
7. There is a big difference here in enforcement, the client should 

            
not have to enforce this rule, the client may not know due to policy 

            
that revoking 1 token revokes other tokens thus the client would have 

            
to know the servers policy. This should be a SHOULD not MUST

          

          
You're conflating things here. If the client revokes the refresh token, they must not use that refresh token again. They can try to use any access or other tokens if they want to, but that refresh token is off the table. The server is allowed to also nuke any access tokens that it wants to, but if the client wants to be really, really sure, it can revoke all of its access tokens separately.

          
 

          
  -- Justin

          
 

          

            
-----Original Message-----

            
From: Justin Richer [mailto:jricher@mitre.org]

            
Sent: Thursday, January 24, 2013 6:17 AM

            
To: Anthony Nadalin

            
Cc: oauth@ietf.org

            
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

            
 

            
Not to jump in and answer for Torsten, but I thought I'd  offer at least my understanding of the document:

            
 

            
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:

            

              
1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?

            

            
It could be separate if your architecture can support that. It gets found the same way other OAuth endpoints get found -- configuration documents, some kind of discovery mechanism, or magic. Which is to say, that's not currently OAuth's problem.

            
 

            

              
2.       Any token type that is supported can be revoked, including refresh token ?

            

            
That's the idea. We've implemented this on our OIDC server so that you can also revoke ID Tokens for session management purposes.

            
 

            

              
3.       Why does one have to send the token, can't this just be an auth_code ?

            

            
You don't always use an auth code to get a token (think implicit, client credentials, assertion, or resource owner credentials flows), and auth codes are supposed to be thrown away after use anyway.

            
 

            

              
4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS

            

            
If they have issues, which is to say "A good reason not to", then they don't have to support it. That's the semantics behind "SHOULD", and so it is fine here.

            
 

            

              
5.       Does not say but is the revocation to be immediate upon the return of the request ?

            

            
This is implementation dependent. Large scale distributed implementations could have trouble making this "immediate", but small systems are more likely to be quick. From the client's perspective, if they get back a success response, they shouldn't count on that token being good anymore (see section 2 note about client behavior).

            
 

            

              
6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?

            

            
That's a policy decision.

            
 

            

              
7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.

            

            
Why would a client want to use a token that they just revoked? This is prescribing the desired correct behavior to a client so that client developers will do the right thing when they implement it. Isn't that the point of the spec?

            
 

            
   -- Justin

            
 

            
 

            
 

          

          
 

          
 

          
 

          
 

        

        
 

      

    

    

  


--------------060208010307050700030006--

From hannes.tschofenig@gmx.net  Thu Jan 24 23:47:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4221F8A98 for ; Thu, 24 Jan 2013 23:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.952
X-Spam-Level: 
X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CHDtv3HtQxP for ; Thu, 24 Jan 2013 23:47:25 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3655121F8578 for ; Thu, 24 Jan 2013 23:47:24 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7WX3-1UurV641GJ-00xIvS for ; Fri, 25 Jan 2013 08:47:23 +0100
Received: (qmail invoked by alias); 25 Jan 2013 07:47:23 -0000
Received: from unknown (EHLO [10.255.130.189]) [194.251.119.201] by mail.gmx.net (mp016) with SMTP; 25 Jan 2013 08:47:23 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/7+uYaJjb7qhSYdhH3w5jfuSZ1ABeJMWpaUL7P5S HIVsDjTDewxa3o
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Jan 2013 09:47:22 +0200
Message-Id: <5B3AB251-BF88-4AC4-AB15-F6A9E85DC294@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Minutes from the Conference Call (21th Jan. 2013)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 07:47:29 -0000

Here are the minutes from the call:
=
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/minutes/minutes-i=
nterim-2013-oauth-2

Here are the uploaded slides:=20
=
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/slides/slides-int=
erim-2013-oauth-2-0.ppt

----

OAuth Conference Call - 21th Jan 2013

Participants:
- Hannes Tschofenig
- Justin Richer
- Phil Hunt=20
- Prateek Mishra
- Derek Atkins
- Mike Jones
- John Bradley
- Tony Nadalin
- Brian Campbell

Notes:

Hannes used the following slides for the meeting:
http://www.tschofenig.priv.at/OAuth2-Security-21Jan2013.ppt

As a first agenda item Justin explained two scenarios posted to the =
OAuth mailing list in response to the December 2012 conference call:
http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html=20

The first scenario focused on the usage of a keyed message digest in =
HTTP (instead of using JSON). The second scenario was based on placing =
all MAC parameters into the URL (instead of the header).=20

The participants indicated that further thinking about the inclusion of =
these scenarios is needed.=20

A few clarification questions were raised including whether the =
solutions we are working on would require always a signature/keyed =
message computed over some portion of the request, and whether key =
distribution is within scope of the work or not.

Hannes clarified that the work is aiming to provide security properties =
beyond the bearer token and therefore the client needs to demonstrate =
possession of a session key. The available options for key distribution =
were described as part of the presentation slides.=20

Q: What about clients that are either not capable of doing cryptographic =
operations (because they are computationally not powerful enough) or =
when they do not have access to keying material?

Hannes and Derek clarified that those scenarios are outside the scope of =
this work.=20

As part of the different options for key distribution only Justin raised =
his preference for a solution that requires the RS to obtain the session =
key from the AS.=20

The conference call participants agreed to focus on a symmetric key =
based solution and to postpone a solution offering support for =
asymmetric keys at a latter stage.=20

Phil asked whether we really need both replay protection AND message =
signing? =20

Hannes responded that support for replay protection has to be part of =
the solution.=20

Regarding the lifetime of the session key the participants preferred to =
have it set to the same lifetime as the access token. If a new access =
token is obtained then the session key is also renewed. =20

Regarding the naming of the keying material used in the protocol =
exchange there were some diverse views on what to use for the session =
key. Justin suggested that the name of the session key is the access =
token itself.=20




From atapiador@dit.upm.es  Fri Jan 25 06:07:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A236421F881D for ; Fri, 25 Jan 2013 06:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp-ryMptUNc7 for ; Fri, 25 Jan 2013 06:07:29 -0800 (PST)
Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id 9536221F8CAC for ; Fri, 25 Jan 2013 06:07:28 -0800 (PST)
Received: from correo2.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id r0PE7ReC000627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 15:07:27 +0100
Received: from [138.4.7.110] (seraph.dit.upm.es [138.4.7.110]) (authenticated bits=0) by correo2.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r0PE7Pgh013728 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Jan 2013 15:07:27 +0100
Message-ID: <5102919D.5020601@dit.upm.es>
Date: Fri, 25 Jan 2013 15:07:25 +0100
From: Antonio Tapiador del Dujo 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Best practices on client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 14:07:29 -0000

Are there any recommendations for the authorization server when 
generating a client_id. Any security consideration? Should the client_id 
be a random string or it is save being just the database primary key?

Kind regards.

From lainhart@us.ibm.com  Fri Jan 25 06:32:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67E21F8423 for ; Fri, 25 Jan 2013 06:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.329
X-Spam-Level: 
X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTxTagVOdScJ for ; Fri, 25 Jan 2013 06:32:11 -0800 (PST)
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8BE21F841E for ; Fri, 25 Jan 2013 06:32:11 -0800 (PST)
Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Fri, 25 Jan 2013 09:32:10 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Fri, 25 Jan 2013 09:32:08 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0A8A66E803F; Fri, 25 Jan 2013 09:32:06 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0PEW7t3263108; Fri, 25 Jan 2013 09:32:07 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0PEW6n4010329; Fri, 25 Jan 2013 09:32:06 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0PEW6j9010315; Fri, 25 Jan 2013 09:32:06 -0500
In-Reply-To: <5102919D.5020601@dit.upm.es>
References: <5102919D.5020601@dit.upm.es>
To: Antonio Tapiador del Dujo 
MIME-Version: 1.0
X-KeepSent: 530F869B:95D9C743-85257AFE:004F70AA; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Fri, 25 Jan 2013 09:32:05 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 01/25/2013 09:32:06, Serialize complete at 01/25/2013 09:32:06
Content-Type: multipart/alternative; boundary="=_alternative 004FD78785257AFE_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13012514-5806-0000-0000-00001EBD9FDE
Cc: "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Best practices on client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 14:32:12 -0000

This is a multipart message in MIME format.
--=_alternative 004FD78785257AFE_=
Content-Type: text/plain; charset="US-ASCII"

There can't be any security requirements for the client_id - it serves to 
identify both public and confidential clients.  It's only requirement be 
that it be a unique identifier (across public and confidential clients) in 
the domain of clients that the AS serves.





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




From:   Antonio Tapiador del Dujo 
To:     "oauth@ietf.org" , 
Date:   01/25/2013 09:09 AM
Subject:        [OAUTH-WG] Best practices on client_id
Sent by:        oauth-bounces@ietf.org



Are there any recommendations for the authorization server when 
generating a client_id. Any security consideration? Should the client_id 
be a random string or it is save being just the database primary key?

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



--=_alternative 004FD78785257AFE_=
Content-Type: text/html; charset="US-ASCII"

There can't be any security requirements
for the client_id - it serves to identify both public and confidential
clients.  It's only requirement be that it be a unique identifier
(across public and confidential clients) in the domain of clients that
the AS serves.














Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com










From:      
 Antonio Tapiador del
Dujo <atapiador@dit.upm.es>

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

Date:      
 01/25/2013 09:09 AM

Subject:    
   [OAUTH-WG] Best
practices on client_id

Sent by:    
   oauth-bounces@ietf.org









Are there any recommendations for the authorization
server when 

generating a client_id. Any security consideration? Should the client_id


be a random string or it is save being just the database primary key?



Kind regards.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--=_alternative 004FD78785257AFE_=--


From torsten@lodderstedt.net  Sat Jan 26 09:34:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7167B21F8712 for ; Sat, 26 Jan 2013 09:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42LYfOPwLG49 for ; Sat, 26 Jan 2013 09:34:48 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5859A21F86D9 for ; Sat, 26 Jan 2013 09:34:47 -0800 (PST)
Received: from [91.2.78.85] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Tz9eP-0002uW-Up; Sat, 26 Jan 2013 18:34:46 +0100
Message-ID: <510413B5.5050007@lodderstedt.net>
Date: Sat, 26 Jan 2013 18:34:45 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
In-Reply-To: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
Content-Type: multipart/alternative; boundary="------------020506040801020704000702"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jan 2013 17:34:49 -0000

This is a multi-part message in MIME format.
--------------020506040801020704000702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Hannes,


Am 11.01.2013 09:18, schrieb Hannes Tschofenig:
> Thank you Torsten for updating the document.
>
> Two issues have been raised:
>
> 1) Terminology: Authorization vs. access grant vs. authorization grant
>
> There is a little bit of email exchange on that topic:
> http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html
>
> I personally don't have an opinion on the terminology in this case.

I propose to change the term to "authorization grant". Any disagreement?

>
> 2) invalid_token error code
>
> As mentioned on the list, a new error code has to be registered (which is not a big deal). Re-using an error code with different semantic is of course confusing.
>
> Re-using an already defined error code and to provide additional text in the error_description is fine as long as the description relates to the originally defined error description. In the case of the invalid_request error code RFC 6749 defines it as
>
>     invalid_request
>                 The request is missing a required parameter, includes an
>                 invalid parameter value, includes a parameter more than
>                 once, or is otherwise malformed.
>
> and RFC 6750 says:
>
>     invalid_request
>           The request is missing a required parameter, includes an
>           unsupported parameter or parameter value, repeats the same
>           parameter, uses more than one method for including an access
>           token, or is otherwise malformed.  The resource server SHOULD
>           respond with the HTTP 400 (Bad Request) status code.

Peter and George suggested a new error code "invalid_parameter". Do you 
suggest to reuse the

Extension error codes MUST be registered (following the procedures in
    Section 11.4  ) if the extension they are used in conjunction with is a
    registered access token type, a registered endpoint parameter, or an
    extension grant type.  Error codes used with unregistered extensions
    MAY be registered.


>
> Let us know how you want to proceed on these two issues.
>
> Ciao
> Hannes
>   
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------020506040801020704000702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Hannes,

    

    

    
Am 11.01.2013 09:18, schrieb Hannes
      Tschofenig:

    

    

      
Thank you Torsten for updating the document. 

Two issues have been raised:

1) Terminology: Authorization vs. access grant vs. authorization grant

There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html

I personally don't have an opinion on the terminology in this case. 

    

    

    I propose to change the term to "authorization grant". Any
    disagreement?

    

    

      

2) invalid_token error code

As mentioned on the list, a new error code has to be registered (which is not a big deal). Re-using an error code with different semantic is of course confusing. 

Re-using an already defined error code and to provide additional text in the error_description is fine as long as the description relates to the originally defined error description. In the case of the invalid_request error code RFC 6749 defines it as 

   invalid_request
               The request is missing a required parameter, includes an
               invalid parameter value, includes a parameter more than
               once, or is otherwise malformed.

and RFC 6750 says:

   invalid_request
         The request is missing a required parameter, includes an
         unsupported parameter or parameter value, repeats the same
         parameter, uses more than one method for including an access
         token, or is otherwise malformed.  The resource server SHOULD
         respond with the HTTP 400 (Bad Request) status code.

    

    

    Peter and George suggested a new error code "invalid_parameter". Do
    you suggest to reuse the  

    
Extension error codes MUST be registered (following the procedures in
   Section 11.4) if the extension they are used in conjunction with is a
   registered access token type, a registered endpoint parameter, or an
   extension grant type.  Error codes used with unregistered extensions
   MAY be registered.

    

    

      

Let us know how you want to proceed on these two issues. 

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


    

    

  


--------------020506040801020704000702--

From torsten@lodderstedt.net  Sat Jan 26 09:37:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC521F8880 for ; Sat, 26 Jan 2013 09:37:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlP2iYlES4vM for ; Sat, 26 Jan 2013 09:37:46 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0121F8B90 for ; Sat, 26 Jan 2013 09:37:46 -0800 (PST)
Received: from [91.2.78.85] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Tz9hJ-0001Ix-33; Sat, 26 Jan 2013 18:37:45 +0100
Message-ID: <51041468.4000902@lodderstedt.net>
Date: Sat, 26 Jan 2013 18:37:44 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
In-Reply-To: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
Content-Type: multipart/alternative; boundary="------------030908040107090302090600"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jan 2013 17:37:47 -0000

This is a multi-part message in MIME format.
--------------030908040107090302090600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Hannes,

Am 11.01.2013 09:18, schrieb Hannes Tschofenig:
> Thank you Torsten for updating the document.
>
> Two issues have been raised:
>
> 1) Terminology: Authorization vs. access grant vs. authorization grant
>
> There is a little bit of email exchange on that topic:
> http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html
>
> I personally don't have an opinion on the terminology in this case.

I propose to change the term to "authorization grant". Any disagreement?

> 2) invalid_token error code
>
> As mentioned on the list, a new error code has to be registered (which is not a big deal). Re-using an error code with different semantic is of course confusing.
>
> Re-using an already defined error code and to provide additional text in the error_description is fine as long as the description relates to the originally defined error description. In the case of the invalid_request error code RFC 6749 defines it as
>
>     invalid_request
>                 The request is missing a required parameter, includes an
>                 invalid parameter value, includes a parameter more than
>                 once, or is otherwise malformed.
>
> and RFC 6750 says:
>
>     invalid_request
>           The request is missing a required parameter, includes an
>           unsupported parameter or parameter value, repeats the same
>           parameter, uses more than one method for including an access
>           token, or is otherwise malformed.  The resource server SHOULD
>           respond with the HTTP 400 (Bad Request) status code.

Peter and George suggested a new error code "invalid_parameter". Do you 
suggest to reuse the "invalid_request" error code instead?

Another question came into my mind. According to RFC 6749,

"Extension error codes MUST be registered (following the procedures in
    Section 11.4  ) if the extension they are used in conjunction with is a
    registered access token type, a registered endpoint parameter, or an
    extension grant type.  Error codes used with unregistered extensions
    MAY be registered."

Is this rule really applicable to the revocation I-D, since it defines a completly new endpoint?

regards,
Torsten.

> Let us know how you want to proceed on these two issues.
>
> Ciao
> Hannes
>   
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------030908040107090302090600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Hannes,

    

    
Am 11.01.2013 09:18, schrieb Hannes
      Tschofenig:

    

    

      
Thank you Torsten for updating the document. 

Two issues have been raised:

1) Terminology: Authorization vs. access grant vs. authorization grant

There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html

I personally don't have an opinion on the terminology in this case. 

    

    

    I propose to change the term to "authorization grant". Any
    disagreement?

    

    

      
2) invalid_token error code

As mentioned on the list, a new error code has to be registered (which is not a big deal). Re-using an error code with different semantic is of course confusing. 

Re-using an already defined error code and to provide additional text in the error_description is fine as long as the description relates to the originally defined error description. In the case of the invalid_request error code RFC 6749 defines it as 

   invalid_request
               The request is missing a required parameter, includes an
               invalid parameter value, includes a parameter more than
               once, or is otherwise malformed.

and RFC 6750 says:

   invalid_request
         The request is missing a required parameter, includes an
         unsupported parameter or parameter value, repeats the same
         parameter, uses more than one method for including an access
         token, or is otherwise malformed.  The resource server SHOULD
         respond with the HTTP 400 (Bad Request) status code.

    

    

    Peter and George suggested a new error code "invalid_parameter". Do
    you suggest to reuse the "invalid_request" error code instead?

    

    Another question came into my mind. According to RFC 6749, 

    

    
"Extension error codes MUST be registered (following the procedures in
   Section 11.4) if the extension they are used in conjunction with is a
   registered access token type, a registered endpoint parameter, or an
   extension grant type.  Error codes used with unregistered extensions
   MAY be registered."

Is this rule really applicable to the revocation I-D, since it defines a completly new endpoint?

regards,
Torsten.



    

      
Let us know how you want to proceed on these two issues. 

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


    

    

  


--------------030908040107090302090600--

From torsten@lodderstedt.net  Sat Jan 26 10:33:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AD121F859B for ; Sat, 26 Jan 2013 10:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE9HfWwD4KqC for ; Sat, 26 Jan 2013 10:33:07 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 219CE21F858A for ; Sat, 26 Jan 2013 10:33:07 -0800 (PST)
Received: from [91.2.78.85] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TzAYq-0003rM-SD; Sat, 26 Jan 2013 19:33:04 +0100
Message-ID: <51042160.5020908@lodderstedt.net>
Date: Sat, 26 Jan 2013 19:33:04 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Anthony Nadalin 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080208090605020503050009"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jan 2013 18:33:10 -0000

This is a multi-part message in MIME format.
--------------080208090605020503050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tony,

thanks for your review comments.

*** @Justin: thanks for jumping in. ***

I would like to recap the results of the discussion so far and propose 
some changes.

Am 24.01.2013 00:54, schrieb Anthony Nadalin:
>
> Review:
>
> 1.Since not stated I assume that the Revocation Endpoint can exist on 
> a different server from the Authorization server (or is it assumed 
> that they are 1), if so how is the Revocation Endpoint found?
>

Having read your arguments I realize the current text is a bit specific 
about the means to obtain the endpoint location (as it does not mention 
other means).

current text:

The location of
    the token revocation endpoint can be found in the authorization
    server's documentation.  The token endpoint URI MAY include a query
    component.


proposal:

The means to obtain the location of the revocation endpoint is out of scope of this specification.

There is a range of options. The client could, for example,
automatically discover this information (along with other server
andpoints and properties). Alternatively, the client developer could
also get to know the endpoint location from the server's documentation.

Note: As this endpoint is handling security sensible credentials, such information must be obtained from a trustworthy resource.


> 2.Any token type that is supported can be revoked, including refresh 
> token ?
>

The draft currently explicitly states support for access and refresh 
tokens. Do you want the draft to be weaker at this point and to allow 
for the revocation of any token?

> 3.Why does one have to send the token, can't this just be an auth_code ?
>

The draft is intended to support token revocation. I agree with Justin. 
Authz codes are short duration and one time use. I don't see a need to 
revoke them. I also don't see the need to use them to revoke the 
respective access token indirectly.

> 4.Says CORS SHOULD be supported, I think a MAY be better here since a 
> site may have issues supporting CORS
>

I'm fine with MAY since I tend to see CORS as an optional feature. What 
do others think?

> 5.Does not say but is the revocation to be immediate upon the return 
> of the request ?
>

The client must assume the revocation is immediate upon the return of 
the request. I could explicitly express this in the text

current text

In the next step, the authorization server invalidates the token.
    The client MUST NOT use this token again after revocation.


Proposal

   In the next step, the authorization server invalidates the token. The
client must assume the revocation is immediate upon the return of the
request. The client MUST NOT use the token again after the revocation.


> 6.Does the revocation of the access token also revoke the refresh 
> token (if it was provided) ? Or is this a revocation policy decision ?
>

As described by Justin, there are two use cases:

- if the token passed to the request is a refresh token and the server 
supports access token revocation, the server SHOULD also revoke them.
- if the token passed to the request is an access token, the server may 
decide to revoke the respective refresh token as well.

I think every client must be prepared to cope with "sudden" invalidation 
of any token type. So having different server policies with respect to 
related tokens shouldn't create interop problems.

What changes would you expect?

> 7.Section 2 says "the client MUST NOT use this token again", well that 
> seems odd, not sure this should be here as the client could try to use 
> it gain, there is no need to put support in client to prevent this.
>

The client should discard the token immediately after revocation.

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


--------------080208090605020503050009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Tony,

    

    thanks for your review comments.

    

    *** @Justin: thanks for jumping in. ***

    

    I would like to recap the results of the discussion so far and
    propose some changes.

    

    
Am 24.01.2013 00:54, schrieb Anthony
      Nadalin:

    

    

      
      
      
      

        
Review:

        
 

        
1.      
            Since not stated I assume that
          the Revocation Endpoint can exist on a different server from
          the Authorization server (or is it assumed that they are 1),
          if so how is the Revocation Endpoint found?

      

    

    

    Having read your arguments I realize the current text is a bit
    specific about the means to obtain the endpoint location (as it does
    not mention other means). 

    

    current text:

    

    
The location of
   the token revocation endpoint can be found in the authorization
   server's documentation.  The token endpoint URI MAY include a query
   component.

    

    proposal:

    
The means to obtain the location of the revocation endpoint is out of scope of this specification.

There is a range of options. The client could, for example, 
automatically discover this information (along with other server 
andpoints and properties). Alternatively, the client developer could 
also get to know the endpoint location from the server's documentation. 

    
Note: As this endpoint is handling security sensible credentials, such information must be obtained from a trustworthy resource.

    

    

      

        

        
2.      
            Any token type that is supported
          can be revoked, including refresh token ?

      

    

    

    The draft currently explicitly states support for access and refresh
    tokens. Do you want the draft to be weaker at this point and to
    allow for the revocation of any token?

    

    

      

        

        
3.      
            Why does one have to send the
          token, can’t this just be an auth_code ?

      

    

    

    The draft is intended to support token revocation. I agree with
    Justin. Authz codes are short duration and one time use. I don't see
    a need to revoke them. I also don't see the need to use them to
    revoke the respective access token indirectly. 

    

    

      

        

        
4.      
            Says CORS SHOULD be supported, I
          think a MAY be better here since a site may have issues
          supporting CORS

      

    

    

    I'm fine with MAY since I tend to see CORS as an optional feature.
    What do others think?

    

    

      

        

        
5.      
            Does not say but is the
          revocation to be immediate upon the return of the request ?

      

    

    

    The client must assume the revocation is immediate upon the return
    of the request. I could explicitly express this in the text

    

    current text

    

    
In the next step, the authorization server invalidates the token.
   The client MUST NOT use this token again after revocation.

    

    Proposal

    
  In the next step, the authorization server invalidates the token. The 
client must assume the revocation is immediate upon the return of the 
request. The client MUST NOT use the token again after the revocation.

    

    

      

        

        
6.      
            Does the revocation of the
          access token also revoke the refresh token (if it was
          provided) ? Or is this a revocation policy decision ?

      

    

    

    As described by Justin, there are two use cases:

    

    - if the token passed to the request is a refresh token and the
    server supports access token revocation, the server SHOULD also
    revoke them.

    - if the token passed to the request is an access token, the server
    may decide to revoke the respective refresh token as well.

    

    I think every client must be prepared to cope with "sudden"
    invalidation of any token type. So having different server policies
    with respect to related tokens shouldn't create interop problems.

    

    What changes would you expect?

    

    

      

        

        
7.      
            Section 2 says “the client MUST
          NOT use this token again”, well that seems odd, not sure this
          should be here as the client could try to use it gain, there
          is no need to put support in client to prevent this.

      

    

    

    The client should discard the token immediately after revocation.

    

    regards.

    Torsten.

    

      

        

      

      

      

      

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


    

    

  


--------------080208090605020503050009--

From wmills_92105@yahoo.com  Sat Jan 26 11:06:24 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC52E21F88B0 for ; Sat, 26 Jan 2013 11:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.739
X-Spam-Level: 
X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t0DT2enbm30 for ; Sat, 26 Jan 2013 11:06:18 -0800 (PST)
Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) by ietfa.amsl.com (Postfix) with ESMTP id 26B7721F8895 for ; Sat, 26 Jan 2013 11:06:16 -0800 (PST)
Received: from [98.138.90.53] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 19:06:10 -0000
Received: from [98.138.89.172] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 19:06:10 -0000
Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 19:06:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 587154.68423.bm@omp1028.mail.ne1.yahoo.com
Received: (qmail 89995 invoked by uid 60001); 26 Jan 2013 19:06:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359227170; bh=apuDWyrqiO/yJilFZQ0jCoQAXMAMsDmndsJbP0JqfOw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TzydatAHnA3JeHShGEonuiYTwrsaGS9hpuOBq+YpuRpFwnz7dQAG8ZD7YAPmlDjWLxykV4ApaJUXixIpUKfN+ugebRRFI8ocxzaQdY7s/80Q6rdngkH3/zK1CEF+HlSZToRiRmEK43Su2GCTHsX6oKiHeoSKS+P2sJ4nbVbYh/Q=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=u2XNsfO5DhFVIBfQE6TCQ5jHoT6v7E+g9cRU5qUXztawmnzO694y2/tNzPYwrh2xjbWTkX1vW4VJoETD1rTxtJhn3wvvwB7F7mJYwZN2k4lE2SB/yZZ+Y761LJLKzwQ3qzXK1FEUTJAUT8oIi0MN+x3PINuH2frHbHZxhJ/h2QU= ; 
X-YMail-OSG: jZsynR4VM1kVodxYchaPlLs1wxiSdkTb5w7W3dxtQLUHVjX kpIdeSy8Bm3ufD.24lVK_6rvVnxFeN.Goy8YaKaQGI0j624sFwdnoMg61Yqq VEuuamZfd2oNDm3ETTbbcvwChMjJMFhOLoZtQRqLqLdGgFV8vj7aEvj.CVfx W2fMPSTx0zC2ZAkiXuwHg0ymlYjO1UUqBBbeEzSKR7akaMbinBEZBNCQvTTg eDeaxPz8dygKjgBkKU5ovYyAuMLTQhckVXgnr4u3uru0ptM4.HCGOSvtlPxF .9YwAp8FUy998_pOIfSo2I1RLhYn4ceOg.ejEluICmh9B0MlUwt2IKwWFXHy y7n.Kgyxz2Oj8SD0zBSP905ZI0EGZW28xoA5H23S_5venVlggxmYhqyHtDq0 esaCcquAADIkFyo7g5NF3akamwwUJCN60v65JdeZQZJ.GHxK67A62YC.KyzK E90LLirFuR1rApJeak9CshsV5CJ1tOFFykwvRH2miq9ILNRgO9q4cP62eICI wN7PJsF1z_CwQltJW6Knt5J7z9_FP4y2gd.vN5VS3cBuzrF9mLBIbbkp.q8K uoQ--
Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Sat, 26 Jan 2013 11:06:09 PST
X-Rocket-MIMEInfo: 001.001, VGhlIGRyYWZ0IHNob3VsZCBwcm9iYWJseSByZWdpc3RlciBhIGxpbmsgcmVsYXRpb24gdHlwZS4gwqBJJ2QgcmVnaXN0ZXIgaXQgd2l0aCB0aGUgb3RoZXJzLCBidXQgdGhhdCBkcmFmdCBpcyBhbHJlYWR5IGluIHRoZSBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gcGlwZWxpbmUuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PgpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20.IAoBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.131.499
References:  <51042160.5020908@lodderstedt.net>
Message-ID: <1359227169.88220.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Sat, 26 Jan 2013 11:06:09 -0800 (PST)
From: William Mills 
To: Torsten Lodderstedt , Anthony Nadalin 
In-Reply-To: <51042160.5020908@lodderstedt.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-1944681668-1359227169=:88220"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jan 2013 19:06:24 -0000

---551393103-1944681668-1359227169=:88220
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The draft should probably register a link relation type. =C2=A0I'd register=
 it with the others, but that draft is already in the individual submission=
 pipeline.=0A=0A=0A________________________________=0A From: Torsten Lodder=
stedt =0ATo: Anthony Nadalin  =0ACc: "oauth@ietf.org"  =0ASent: Saturday, January 26, =
2013 10:33 AM=0ASubject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Revi=
ew=0A =0A=0AHi Tony,=0A=0Athanks for your review comments.=0A=0A*** @Justin=
: thanks for jumping in. ***=0A=0AI would like to recap the results of the =
discussion so far and=0A    propose some changes.=0A=0A=0AAm 24.01.2013 00:=
54, schrieb Anthony Nadalin:=0A=0A =0A>Review:=0A>=C2=A0=0A>1.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Since not stated I assume that the Revocation Endp=
oint can exist on a different server from the Authorization server (or is i=
t assumed that they are 1), if so how is the Revocation Endpoint found?=0AH=
aving read your arguments I realize the current text is a bit=0A    specifi=
c about the means to obtain the endpoint location (as it does=0A    not men=
tion other means). =0A=0Acurrent text:=0A=0A=0AThe location of the token re=
vocation endpoint can be found in the authorization server's documentation.=
  The token endpoint URI MAY include a query component.=0Aproposal:=0A=0ATh=
e means to obtain the location of the revocation endpoint is out of scope o=
f this specification. There is a range of options. The client could, for ex=
ample, =0Aautomatically discover this information (along with other server =
=0Aandpoints and properties). Alternatively, the client developer could =0A=
also get to know the endpoint location from the server's documentation. =0A=
Note: As this endpoint is handling security sensible credentials, such info=
rmation must be obtained from a trustworthy resource.=0A=0A2.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Any token type that is supported can be revoked, i=
ncluding refresh token ?=0AThe draft currently explicitly states support fo=
r access and refresh=0A    tokens. Do you want the draft to be weaker at th=
is point and to=0A    allow for the revocation of any token?=0A=0A=0A3.=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why does one have to send the token, can=
=E2=80=99t this just be an auth_code ?=0AThe draft is intended to support t=
oken revocation. I agree with=0A    Justin. Authz codes are short duration =
and one time use. I don't see=0A    a need to revoke them. I also don't see=
 the need to use them to=0A    revoke the respective access token indirectl=
y. =0A=0A=0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Says CORS SHOULD be supp=
orted, I think a MAY be better here since a site may have issues supporting=
 CORS=0AI'm fine with MAY since I tend to see CORS as an optional feature.=
=0A    What do others think?=0A=0A=0A5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Does not say but is the revocation to be immediate upon the return of the =
request ?=0AThe client must assume the revocation is immediate upon the ret=
urn=0A    of the request. I could explicitly express this in the text=0A=0A=
current text=0A=0A=0AIn the next step, the authorization server invalidates=
 the token. The client MUST NOT use this token again after revocation.=0APr=
oposal=0A=0A=C2=A0 In the next step, the authorization server invalidates t=
he token. The =0Aclient must assume the revocation is immediate upon the re=
turn of the =0Arequest. The client MUST NOT use the token again after the r=
evocation.=0A=0A6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does the revocation =
of the access token also revoke the refresh token (if it was provided) ? Or=
 is this a revocation policy decision ?=0AAs described by Justin, there are=
 two use cases:=0A=0A- if the token passed to the request is a refresh toke=
n and the=0A    server supports access token revocation, the server SHOULD =
also=0A    revoke them.=0A- if the token passed to the request is an access=
 token, the server=0A    may decide to revoke the respective refresh token =
as well.=0A=0AI think every client must be prepared to cope with "sudden"=
=0A    invalidation of any token type. So having different server policies=
=0A    with respect to related tokens shouldn't create interop problems.=0A=
=0AWhat changes would you expect?=0A=0A=0A7.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Section 2 says =E2=80=9Cthe client MUST NOT use this token again=E2=
=80=9D, well that seems odd, not sure this should be here as the client cou=
ld try to use it gain, there is no need to put support in client to prevent=
 this.=0AThe client should discard the token immediately after revocation.=
=0A=0Aregards.=0ATorsten.=0A=0A=0A>=0A>=0A>________________________________=
_______________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/ma=
ilman/listinfo/oauth =0A=0A_______________________________________________=
=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi=
nfo/oauth
---551393103-1944681668-1359227169=:88220
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


The =
draft should probably register a link relation type.  I'd register it =
with the others, but that draft is already in the individual submission pip=
eline.

  
 
   
  From: Torsten Lodderstedt <torsten@=
lodderstedt.net>
 To: Anthony Nadalin <tonynad@microsoft.com> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
 =
Sent: Saturday, January 26=
, 2013 10:33
 AM
 Subject: Re: [OAUT=
H-WG] draft-ietf-oauth-revocation-04 Review
  
 
=0A
=0A  =0A=0A    =0A  =0A  
=0A    Hi Tony,
=0A    =

=0A    thanks for your review comments.
=0A    
=0A    *** @Justi=
n: thanks for jumping in. ***
=0A    
=0A    I would like to recap th=
e results of the discussion so far and=0A    propose some changes.
=0A  =
  
=0A    
Am 24.01.2013 00:54,=
 schrieb Anthony=0A      Nadalin:
=0A    
=0A    
=0A      =0A      =0A      =0A      
=0A        
Review:=

 =0A        
  
 =0A    =
    
=
1.      =0A      =
      Since not stated I assume that=0A          the Revocati=
on Endpoint can exist on a different server from=0A          the Authorizat=
ion server (or is it assumed that they are 1),=0A          if so how is the=
 Revocation Endpoint found?
=0A      
=0A    
=0A    =

=0A    Having read your arguments I realize the current text is a bit=
=0A    specific about the means to obtain the endpoint location (as it does=
=0A    not mention other means). 
=0A    
=0A    current text:
=0A=
    
=0A    
The =
location of=0A   the token revocation endpoint can be found in the authoriz=
ation=0A   server's documentation.  The token endpoint URI MAY include a qu=
ery=0A   component.
=0A    
=0A    proposal:
=0A    
The mea=
ns to obtain the location of the revocation endpoint is out of scope of thi=
s specification.=0A=0AThere is a range of options. The client could, for ex=
ample, =0Aautomatically discover this information (along with other server =
=0Aandpoints and properties). Alternatively, the client developer could =0A=
also get to know the endpoint location from the server's documentation. =0A    
Note: As this endpoint is handling security sensible credent=
ials, such information must be obtained from a trustworthy resource.
=
=0A    
=0A    
=0A      
=0A         =0A        
2. &nb=
sp;    =0A            Any token type that=
 is supported=0A          can be revoked, including refresh token ?
=
=0A      
=0A    
=0A    
=0A    The draft currently ex=
plicitly states support for access and refresh=0A    tokens. Do you want th=
e draft to be weaker at this point and to=0A    allow for the revocation of=
 any token?
=0A    
=0A    
=0A      
=0A         =0A        
3.      =0A            Why =
does one have to send the=0A          token, can=E2=80=99t this just be an =
auth_code ?
=0A      
=0A    
=0A    
=0A    The d=
raft is intended to support token revocation. I agree with=0A    Justin. Au=
thz codes are short duration and one time use. I don't see=0A    a need to =
revoke them. I also don't see the need to use them to=0A    revoke the resp=
ective access token indirectly. 
=0A    
=0A    
=0A      
=0A         =0A       =
 
4.<=
span style=3D"font:7.0pt;">      =0A         =
   Says CORS SHOULD be supported, I=0A          think a MAY b=
e better here since a site may have issues=0A          supporting CORS=0A      
=0A    
=0A    
=0A    I'm fine with MAY sin=
ce I tend to see CORS as an optional feature.=0A    What do others think?=0A    
=0A    
=0A      
=0A         =0A        
5. &=
nbsp;    =0A            Does not say but =
is the=0A          revocation to be immediate upon the return of the reques=
t ?
=0A      
=0A    
=0A    
=0A    The client mu=
st assume the revocation is immediate upon the return=0A    of the request.=
 I could explicitly express this in the text
=0A    
=0A    current t=
ext
=0A    
=0A    
In the next step, the authorization server invalidates the token.=0A =
  The client MUST NOT use this token again after revocation.
=0A    =0A    Proposal
=0A    
  In the next step, the authorization=
 server invalidates the token. The =0Aclient must assume the revocation is =
immediate upon the return of the =0Arequest. The client MUST NOT use the to=
ken again after the revocation.
=0A    
=0A    
=0A      
=0A         =0A      =
  
6.=
      =0A        =
    Does the revocation of the=0A          access token also =
revoke the refresh token (if it was=0A          provided) ? Or is this a re=
vocation policy decision ?
=0A      
=0A    
=0A    <=
br>=0A    As described by Justin, there are two use cases:
=0A    
=
=0A    - if the token passed to the request is a refresh token and the=0A  =
  server supports access token revocation, the server SHOULD also=0A    rev=
oke them.
=0A    - if the token passed to the request is an access token=
, the server=0A    may decide to revoke the respective refresh token as wel=
l.
=0A    
=0A    I think every client must be prepared to cope with =
"sudden"=0A    invalidation of any token type. So having different server p=
olicies=0A    with respect to related tokens shouldn't create interop probl=
ems.
=0A    
=0A    What changes would you expect?
=0A    
=0A =
   
=0A      
=0A         =0A        
7.   &nbs=
p;  =0A            Section 2 says =E2=80=9Cthe clie=
nt MUST=0A          NOT use this token again=E2=80=9D, well that seems odd,=
 not sure this=0A          should be here as the client could try to use it=
 gain, there=0A          is no need to put support in client to prevent thi=
s.
=0A      
=0A    
=0A    
=0A    The client sho=
uld discard the token immediately after revocation.
=0A    
=0A    re=
gards.
=0A    Torsten.
=0A    
=0A      =0A         =0A      
=0A      
=
=0A      
=0A=
      
=0A      
_______________________________________________=0AO=
Auth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A<=
/pre>=0A    =0A    
=0A  
=0A=0A

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